R I S K

CONDUCTING
AN IT SECURITY
RISK
ASSESSMENT

Personal Copy of Immanuel Giulea (ISACA ID: 1157570)

2 CONDUCTING AN IT SECURITY RISK ASSESSMENT

CONTENTS

4 Introducing Risk Assessment: A

Structured Approach to Risk
5 Driving Business Benefits Through Risk
Assessment
6 Creating the Risk Assessment Process
6 / Key Components of Risk Assessment
6 / Risk Appetite and Impact
6 / Assets
7 / Asset Valuation
7 / Processes
8 / Identifying Risk Factors
8 / Understanding the Threat
Environment
9 / Understanding Vulnerabilities
9 / Understanding Controls
10 / Calculating Risk
10 Updating the Risk Register
10 Risk Treatment
11 Limitations of Risk Assessment
12 Conclusion
13 Acknowledgments

© 2020 ISACA. All Rights Reserved.

Personal Copy of Immanuel Giulea (ISACA ID: 1157570)
3 CONDUCTING AN IT SECURITY RISK ASSESSMENT

ABSTRACT
Every enterprise faces risk—both known and unknown. Many organizations routinely
assess risk, not only in the technology space, but also throughout the enterprise. And
every day, enterprises seek to optimize risk, thereby ensuring the most advantageous
return on investment while sustaining business continuity. Risk changes almost daily, and
IT security leaders are effectively forced to identify and address threats and vulnerabilities
continuously to prevent exposure of important data and maintain risk tolerances at
acceptable levels.

Risk assessments allow the enterprise to reevaluate existing and potential risk within
structured, repeatable frameworks that inform the organizational risk response. In
dynamic and evolving risk environments, enterprise information and technology (I&T)
assets depend upon robust risk-assessment methodology and planning, not only to
secure the assets themselves, but also to understand and appreciate their full institutional
value, to identify business processes that rely on them, potential options for mitigation,
and criticality and priority of any associated risk items relative to organizational risk
appetite.

Intended for new IT security and risk assessment practitioners, as well as other
professionals unfamiliar with the process, this white paper documents how to conduct an
IT security risk assessment. The paper poses key questions that all enterprises must
answer in order to identify assets, determine their value and protect them accordingly.

© 2020 ISACA. All Rights Reserved.

Personal Copy of Immanuel Giulea (ISACA ID: 1157570)
 4 CONDUCTING AN IT SECURITY RISK ASSESSMENT

Introducing Risk Assessment:

A Structured Approach to Risk
ISACA® defines risk as the combination of the probability risk, steps can be taken to reduce risk and mitigate the
of an event and its impact. For risk to exist, there must be damage it can cause.
a chance that some event—or deviation from the norm—
All enterprises should have some form of risk assessment
will produce an unknown or unexpected positive or
in place to account for both current and future threats.
negative outcome.
Such assessments not only provide a basis for
Risk is a part of every enterprise’s daily operation. Risk determining the value of business assets and the impact
comes in different forms, and can cause varying degrees of security breaches, but also promote the overall security
of disruption and damage—or alternatively, return varying and stability of the enterprise on an ongoing basis.
rates of business value. Risk tends to increase over time
There is no one right way to conduct a risk assessment.
as a result of increasing complexity. A recent survey
However, it is generally agreed that risk assessment
conducted by ISACA, CMMI® Institute and Infosecurity®
should adhere to a structured methodology. The most
Group indicates that overall risk increased over the last 12
common steps (figure 1) include:
months across surveyed industries.1 1

• Identifying and valuing assets

The best way for enterprises to prepare for and address • Identifying known threats
possible security threats is to create a risk assessment • Identifying vulnerabilities
strategy and plan that not only complement, but also • Identifying risk
champion enterprise goals. While no plan can eliminate • Determining the risk treatment

FIGURE 1: Risk Assessment Steps

• Identify and value assets

• Identify known threats

• Identify vulnerabilities

• Identify risk

• Determine risk treatment

1
1
ISACA, CMMI® Institute and Infosecurity® Group, State of Enterprise Risk Management 2020, October 2019, https://www.isaca.org/Knowledge-
Center/Documents/State-of-Enterprise-Risk-2020-Report_1019.pdf

© 2020 ISACA. All Rights Reserved.

Personal Copy of Immanuel Giulea (ISACA ID: 1157570)
5 CONDUCTING AN IT SECURITY RISK ASSESSMENT
Across these steps are the key aspects of a risk
assessment that determine its success and overall
usefulness to the organization. Critical considerations
include:
• Identifying and prioritizing assets based on their value
• Identifying threats and vulnerabilities
• Analyzing controls in a structured, repeatable manner
• Determining the likelihood of incidents
Driving Business Benefits Through
Risk Assessment
Enterprises assess risk to expand awareness of their
business environments, ensure business continuity and
sustain growth. Enterprises generally seek certainty in
order to meet their objectives; risk represents the potential
effects of uncertainty on those objectives. Risk
assessment enables an enterprise to plan ahead for risk
and, over time, it creates a record of historical data in the
wake of realized risk events, allowing the enterprise to
quantify financial impact, customer impact, regulatory
consequences and other relevant metrics. Assessing risk
formally, on a routine basis, provides feedback for future
assessments, reducing assessment cost and increasing
overall value.
Creating a risk assessment plan also facilitates
communication between different departments and/or
stakeholders of an enterprise. While IT security personnel
and business managers both have stakes in the
continuous implementation of a risk assessment
program, they may have different perceptions of risk—
including for example, what events constitute major
versus minor risk. Communication helps to bridge any
gaps in perception and expected benefits, and maintain
unity of purpose among stakeholders.
A risk assessment is intended both to evaluate known risk
and to identify and assess unknown risk, including risk
© 2020 ISACA. All Rights Reserved.
Personal Copy of Immanuel Giulea (ISACA ID: 1157570)
• Assessing the impact of incidents
• Promoting communication and collaboration among IT security
teams and organizational management
In some instances, other key stakeholders may need to be
consulted. Recording risk events in a risk register is
recommended for documenting each step of a risk
event—both for historical purposes and to plan ahead.
that is commonly overlooked and/or underestimated.
Although an assessment may focus primarily on known
risk, it should also explore threats not previously
considered, gauge their potential impact on operations,
and determine appropriate mitigation strategies for
advance protection of business assets and processes.
Risk assessment demonstrates due diligence to
stakeholders who have vested interests in business
operations. It brings a consistent methodology to asset
valuation and thus informs management decisions, not
only regarding current risk, but also future budgeting,
strategy, marketing and competitive advantage. A
formalized risk assessment positions the enterprise to
gain greater certainty with respect to the value of its
assets, the processes in place to address vulnerabilities,
and the potential impact risk can have on both the
immediate bottom line and the enterprise’s long-term
reputation.
Although internal considerations often drive risk
assessment, some enterprises are subject to external
legal and regulatory requirements that mandate
structured review of business operations and risk impact.
Where such requirements exist, a formal IT security risk
assessment can help to ensure compliance.
6 CONDUCTING AN IT SECURITY RISK ASSESSMENT

Creating the Risk Assessment

Process
The number of steps required to conduct a risk frequently. Adopting a framework is also generally less
assessment varies by methodology. Practitioners can expensive than adopting a standard.
adopt a well-established approach—such as the
quantitative or qualitative method—or tailor an established
method to meet their unique needs. Regardless of
Key Components of Risk
methodology, however, certain core activities define the Assessment
generic risk assessment process model: To begin the assessment process, an enterprise must

• Identify assets identify its risk appetite and potential risk impact(s).

• Value assets

• Identify known risk Risk Appetite and Impact

• Identify vulnerabilities
• Determine likelihood and impact of risk events
• Determine risk ownership and treatment options
Enterprises may benefit from adopting a standard or
framework when implementing risk assessment
programs. A standard is a mandatory requirement, code
or practice generally promulgated by an external
organization. Enterprises generally adopt standards, such
as those promulgated by the International Organization
for Standardization (ISO®), either in response to regulatory
requirements or as a way to address particular areas of
concern. Standards are appealing because they clearly
establish what must be done to comply, while also
fostering public recognition of compliance. However, the
prescriptive nature of standards can be time-consuming—
particularly for smaller organizations and those in unique
circumstances outside the standard’s original context,
regulatory domain or intent.
In contrast to standards, frameworks establish goals or
outcomes to be accomplished, without specifying how to
achieve them. There is no formal recognition for meeting
framework goals; how an organization chooses to attain
desired outcomes is up to the organization, and can vary
widely. The flexibility of frameworks lends itself to novel
environments or those in which circumstances change
Assessors first need a baseline understanding of the
enterprise and its risk appetite—the magnitude of risk, on
a broad level, that an entity is willing to accept in pursuit of
its mission. Clarity is important when discussing risk, and
everyone—regardless of organizational role—understands
when things are described in monetary terms.
An ability to articulate value in quantifiable, monetary
terms generally helps assessors communicate magnitude
of risk to upper management. Terms such as high,
medium or low (or major, minor and insignificant) can
have different meanings to different people. For example,
the failure of a department to process a monthly report in
a timely manner may be a high priority for that
department; but upper management may not understand
the urgency and, thus, consider it a low priority.
Management should be able to identify risk impact—and
agree on acceptable or unacceptable risk—primarily in
terms of financial cost. A secondary baseline for
communicating magnitude of risk is reputational damage,
although it can be hard to quantify.
Assets
Effective risk assessment requires first identifying and
understanding an enterprise’s assets across the
organization and, in some cases, beyond organizational
boundaries (i.e., with offshore vendors or partners).

© 2020 ISACA. All Rights Reserved.

Personal Copy of Immanuel Giulea (ISACA ID: 1157570)
 7 CONDUCTING AN IT SECURITY RISK ASSESSMENT

Without this information, it is difficult to prioritize and
allocate resources where they are most needed. After
identifying assets, stakeholders can:
• Determine threats that may affect particular assets
• Assess how assets might be vulnerable
• Determine how well protected assets currently are
• Quantify impact
• Determine how best to protect assets and mitigate impact
Asset identification needs to be done in a structured way.
Each asset should be identified and documented in terms
of its properties and characteristics, which may include
hardware, software, intellectual property, customer
information and other factors of importance to valuation.
Asset Valuation
Once assets are identified, the next step is to value them
in a way that supports effective prioritization. Note that
data assets should be included in the assessment at this
stage—valuation of data is best performed by data
owners, who generally have better insight into their data
than upper management. To optimize use of available
resources, “IT should understand the relative significance
of different sets of systems, applications, data, storage
and communication mechanisms.” Enterprises have 2 2 approach. A qualitative term like “high” might be assigned
areas of greater and lesser priority, and understanding
these at a high level can improve alignment between
assessment and executive interest.
There are three general ways to determine an asset’s
value:
• Qualitative valuation
This ambiguity can arise both across teams and within
different levels of the same team.
Quantitative valuation takes the opposite approach,
assigning values based on objective monetary
calculations such as net present value, replacement cost
or book value. This approach allows everyone in the
enterprise to understand both the value of an asset and its
relative importance compared to all other valued assets,
satisfying an objective standard that qualitative
assessments cannot deliver. The scale used for
quantitative valuation is common to the entire
organization and, thus, eliminates the subjective
localization of values assigned by expert opinion.
Wherever possible, it is beneficial for asset valuation to be
done on a quantitative basis.
Semi-quantitative valuation reflects a compromise
approach. It fundamentally involves qualitative
assessment, often by associating subjective categories
with numeric values.
Although ostensibly useful because it renders expert
opinion in a mathematically comparable form, semi-
quantitative analysis is perhaps the most deceptive
a value of five or 10, and these values will produce
significantly different results when used in any form of
equation. There is likely no clear, objective basis for
deciding whether “high” is five or 10 times as valuable as
“low.” Such numbers will likely not represent a consistent
scale, therefore subjective localization is still operative.

• Quantitative valuation
Whenever incompatible perspectives of scale are

• Semi-quantitative valuation
Qualitative valuation is based on the expertise of the
person making the assessment. Qualitative assessments
are inherently subjective and tend to use ordinal rankings
such as high, medium or low. It is difficult to apply
qualitative rankings consistently because their subjectivity
is inherently localized: what may be categorized as high in
one context can be considered low or medium in another.
combined in mathematical operations, the results can be
profoundly misleading. Methods of valuation of course
depend on enterprise needs, available resources and
requirements; however, risk assessors should avoid semi-
quantitative valuation when possible.
Processes
While the direct monetary value of an asset informs the
impact of its loss on an organization, its value can be

2
2
Schmittling, R.; A. Munns; “Performing a Security Risk Assessment,” ISACA Journal, vol. 1, 2010, https://www.isaca.org/Journal/archives/2010/Volume-
1/Pages/Performing-a-Security-Risk-Assessment1.aspx

© 2020 ISACA. All Rights Reserved.

Personal Copy of Immanuel Giulea (ISACA ID: 1157570)
8 CONDUCTING AN IT SECURITY RISK ASSESSMENT
further informed—that is, indirectly—by the processes or
supporting technologies in which it is implicated.
Understanding the processes and technologies that an
asset utilizes—along with their associated vulnerabilities—
facilitates both risk assessment and consideration of risk
treatment options. It also clarifies how processes work
together with assets in the value chain. It is essential to
remember that risk may not remain isolated; an impact on
one process may have a cascading effect throughout the
system. Identifying which assets are involved in which
processes (and vice versa) is essential for an assessor to
grasp the entire value chain and gauge the impact if an
asset or process is compromised.
Understanding the processes and technologies that an
asset utilizes—along with their associated vulnerabilities—
facilitates both risk assessment and consideration of risk
treatment options.
Independent of particular assets, processes may interact
with and influence each other. Understanding the
interrelationship of technologies, assets and
vulnerabilities should clarify not only how each asset is
mapped to a process, but also how processes affect each
other. Structured risk assessments must therefore include
sufficient time to map assets and processes across their
manifold relationships.
Identifying Risk Factors
After creating a comprehensive inventory of assets, their
values and relationships to processes, assessors can
begin to identify areas of risk. Risk reflects the
combination of the probability of an event and its impact—
so an event must both be possible and have a meaningful
effect, in order to pose risk for the organization.
The impact attributable to risk depends on what is
affected (i.e., assets and processes). Probability depends
not only on whether something seeks to cause harm, but
also whether that attempt could possibly succeed. The
first factor constitutes a threat, while the second reflects a
vulnerability. Both must be present for probability to be
above zero—so both are preconditions of risk. Accordingly,
© 2020 ISACA. All Rights Reserved.
Personal Copy of Immanuel Giulea (ISACA ID: 1157570)
the two broad approaches in identifying risk include threat
and vulnerability assessment.
Before considering threats and vulnerability in more detail,
it is worth observing that risk can be identified using a
scenario approach, which may be top-down or bottom-up.
In a bottom-up approach, assessors generally begin with
an asset and consider what sorts of negative outcomes
might befall it, and from there, extrapolate conditions that
could create those outcomes. In a top-down approach,
assessors begin with a potential threat event (such as a
cyberattack or flood) and consider each asset in turn to
determine how the asset—and by extension, the
organization as a whole—might be affected.
Both approaches to risk scenarios are effective. Bottom-
up scenarios tend to originate from the operational levels
of an organization, while top-down scenarios are more
likely to reflect the concerns of senior management.
Understanding the Threat Environment
A threat is any action or occurrence that seeks to cause
harm to an enterprise. Threats may arise:
• Intentionally, when hackers, malicious external actors or internal
employees deploy malware, or otherwise interfere or
compromise systems, delete data, cause denial of service,
physically steal hardware, engage in corporate espionage, or
impersonate an employee
• Accidentally, when systems fail through nonmalicious human
error that results from improper training, poor judgment or
inadequate performance
• Naturally or by force majeure, when lightning strikes, hurricanes
make landfall or floods inundate critical facilities
Threat assessment is an active process in which an
organization seeks to identify any attempt to create
adverse effects and understand the motivation of threat
actors. Because intent is the key factor, threat
assessment generally excludes natural events, but may
include accidental threat actors. Depending on the
observed action(s), an organization may be able to
determine what the threat actor is trying to do, and thus
leverage the understanding of intent to identify additional
 9 CONDUCTING AN IT SECURITY RISK ASSESSMENT

vulnerabilities. Organizations can then apply that
knowledge in risk treatment decisions.
Understanding Vulnerabilities
Vulnerabilities are areas of weakness. Not every
vulnerability is exposed (and/or accessible) to a threat
actor. For instance, an air-gapped computer that lacks
network connectivity may not incur the threat of
cyberattack. Nonetheless, any system that could be
compromised when a threat actor makes an adequate
attempt is reasonably considered vulnerable.
Organizations typically develop and implement structured
programs for vulnerability assessment, using both manual
and automated processes to identify weaknesses. With
few exceptions, these programs are limited to
weaknesses that are already known, including those
identified in audit reports, published in the US National
Institute for Standards and Technology (NIST)
vulnerability database, detected when applying third-party
vulnerability intelligence, or discovered by an enterprise’s
own incident response teams or software security
analysts.3 3
vulnerabilities. Identifying unknown vulnerabilities is
possible using code analysis, but this approach is
typically available only to vendors assessing their own
software.
Because of the extent to which different applications
interact, it is commonly accepted that attaining a level of
zero vulnerability is impossible in a complex information
system. This means that even the most rigorously
assessed environments may be compromised by zero-
day exploits that target vulnerabilities whose existence up
to that point had been unknown, both to vendors and
cybersecurity professionals.
Understanding Controls
Assessed vulnerability typically considers only the
inherent state of an information system. In most
environments, this inherent state is heavily modified by
the influence of controls, which may include general or
targeted countermeasures. Controls generally do not
eliminate threats, but they can make it more difficult for

the threat to exploit a vulnerability. Controls may seek to

Organizations typically develop and implement structured identify threat events and support intervention, or limit the
programs for vulnerability assessment, using both manual
impact of compromises that do occur.
and automated processes to identify weaknesses.

Automated tools are effective for rapid vulnerability Controls may be technical or nontechnical. Technical

identification, but should not be the sole method used to controls are found in hardware and software and include

detect and assess vulnerabilities. Often, manual reviews firewalls, intrusion detection systems, automatic updates

are necessary when special-use systems or uncommon and continuous data-leak detection.

software applications are involved. Nontechnical controls include policies, administrative

Vulnerability assessment reports can be misleading in two actions and physical mechanisms, such as locks and

ways. The first reflects the error of aggregation: An keycards. Hiring a security guard is also a form of

enterprise may identify only three vulnerabilities out of a nontechnical control.

list of 100, but it would be incorrect to say that the

organization is only 3% vulnerable, because any assets
that have one or more of those three vulnerabilities are
100% vulnerable to threats designed to exploit them.
The other misleading aspect of vulnerability assessment
is that it only identifies the presence of known
In many cases, controls modify vulnerability without
eliminating it outright. Understanding the extent to which
a given control limits vulnerability is an important part of
assessing risk, because the coexistence of threat with any
remaining vulnerability is sufficient to create a negative
outcome.

3
3
Upguard, “How to Perform an IT Cyber Security Risk Assessment: Step-by-Step Guide,” 30 October 2019, https://www.upguard.com/blog/cyber-security-
risk-assessment

© 2020 ISACA. All Rights Reserved.

Personal Copy of Immanuel Giulea (ISACA ID: 1157570)
10 CONDUCTING AN IT SECURITY RISK ASSESSMENT
Calculating Risk
Once threats and vulnerabilities have been analyzed, it
becomes possible to determine likelihood, which is an
assessment of the probability that a vulnerability will be
exploited. As with valuation, likelihood is best assessed on
a quantitative basis, pairing specific threats with
compatible vulnerabilities. However, obtaining solid data
for threat activity in particular is difficult, and the existence
of unknown vulnerabilities compounds the problem. In
many organizations, a qualitative or semi-quantitative
approach is the best that can be done. To assess risk, the
determined likelihood is combined with the potential
impact of compromise. Identification of assets, their
Updating the Risk Register
Areas of risk identified by the risk assessment should be
recorded in a risk register, which serves as both a
historical document and an enterprise’s knowledge base
for matters of risk. The register documents how the risk
was discovered, the different risk scenarios used and the
implications of the risk. When updated regularly and used
Risk Treatment
Risk assessment concludes with the recording of risk in
the register—but organizations do not stop considering
risk once it has been assessed.
There are four possible treatments for assessed risk:
• Accept
• Transfer
• Mitigate
• Avoid
The goal of risk treatment is to bring risk to an acceptable
level; deciding which treatment option is appropriate
depends entirely on the organization’s risk appetite.
© 2020 ISACA. All Rights Reserved.
Personal Copy of Immanuel Giulea (ISACA ID: 1157570)
valuation and the determination of how they fit into the
enterprise value chain, all make it possible to anticipate
how operations may be affected in the aggregate by
specific asset-level fail states, such as a server outage or
loss of data integrity.
Risk combines the estimated frequency of an exploited
vulnerability annually, the cost of each occurrence and the
weight factor of each instance. Thus, for data whose
compromise would incur a US$50,000 loss, estimating the
occurrence once every 50 years implies an annualized
cost of $1,000 per year. This calculation is the end state of
risk assessment.
actively, it can assist managers in making informed
decisions, provide real-time visibility to the risk
governance function, and support retrospective discovery
and analysis of threat patterns, including a step-by-step
accounting of how risk was previously addressed.
If a risk is within the enterprise’s risk appetite, it is
acceptable without further action. In this case, the risk
should be formally accepted through documentation in
the risk register, and no further action should be taken.
If the risk is not acceptable, the enterprise might choose
to either transfer or mitigate the risk. Transferring risk is a
misleading term, because risk can never be fully
transferred; risk sharing is a more accurate
characterization. The idea is to assign some portion of the
potential impact to another organization, as with the
purchase of insurance. Transferring risk does not reduce
11 CONDUCTING AN IT SECURITY RISK ASSESSMENT
the likelihood of impact but, by sharing impact, it can
reduce risk to an acceptable level.
The other option is mitigation, which is the application of
controls to reduce one of the risk factors—generally
vulnerability or impact—because the number of threat
actors, their motivations and goals tend to be unknown.
The decision to mitigate or transfer risk should be based
on which of the two can produce an acceptable level of
risk at the lowest cost to the organization. An organization
should never spend more to treat risk than the cost
associated with the risk itself. On rare occasions, it may
be impossible to reduce risk to an acceptable level
without allocating an untenable level of resources to the
task. In this case—and only in this case—the risk should
Limitations of Risk Assessment
Risk assessments can be limited in a number of ways. For
example, qualitative analysis is subjective, and the effects
of localization can lead to varying interpretations of
categories used for impact, threat and vulnerability at
different levels of an organization. Potential for significant
confusion exists, whether categories reflect colors or
designations such as high and low. Assigning numbers to
these values (in semi-quantitative fashion) can heighten
the problem by inducing data recipients to apply objective
mathematical formulas to values that arise from expert
opinion rather than objective quantification.
When and where possible, it is best to base risk
assessment on quantitative values such as historical
probability of a threat event or the monetary value of an
asset. Quantitative values from known, objective sources
avoid the problem of localized expertise in qualitative
rankings, and help to convey a universal understanding of
risk factors and implications. Quantitative data also lend
© 2020 ISACA. All Rights Reserved.
Personal Copy of Immanuel Giulea (ISACA ID: 1157570)
be avoided by eliminating the conditions that bring it
about.
In general, this means ceasing a noncritical business
operation or exiting a particular market. Threats to life
safety in areas of escalating violence or significant natural
disasters are the most common cases in which risk
avoidance is the best treatment option.
Documenting treatment decisions in the risk register is a
vital part of the process. The register should be updated
accordingly so it can serve as an ongoing reference to
management, business process owners, risk managers
and auditors alike. In addition, every risk should have an
assigned owner who is responsible for overseeing
implementation of the treatment decision.
themselves to mathematical formulas without distortion
or bias.
When and where possible, it is best to base risk
assessment on quantitative values such as historical
probability of a threat event or the monetary value of an
asset.
Unfortunately, quantitative data can be difficult (and/or
prohibitively expensive) to gather. Also, while the effects of
mathematical operations on quantitative data are reliable,
the accuracy of the data itself is not guaranteed simply as
a result of being numeric. Questionable data lead to
questionable results and, as noted, enterprises thrive on
certainty. If data are inaccurate, they could lead to the
wrong risk treatment decisions and a waste of resources,
without providing protection or indicating actions that will
reduce or eliminate risk. In an expert-driven qualitative
approach, subjectivity is accepted as part of the process,
and can promote greater flexibility in interpretation than
an assessment based on quantitative data.
12 CONDUCTING AN IT SECURITY RISK ASSESSMENT
Conclusion
A structured IT security risk assessment enables an
enterprise to identify, evaluate and align its overall security
position with its risk appetite. Assessments provide the
opportunity for staff to work across functional areas and
promote communications among IT teams, security
managers and upper management, contributing to a
broader understanding of how processes and assets
interact. All of these insights benefit senior managers who
seek to conduct operations while maintaining an
acceptable level of risk.
Risk assessment should be done on a regular or
continuous basis in order to keep pace with an ever-
changing threat environment. Security managers and
staff should be prepared for controls that delivered
sufficient assurance yesterday to become inadequate
tomorrow. This eventuality can be true even for controls
addressing natural disasters—and it is especially
applicable to controls for intentional cyberattacks by
threat actors who learn from experience.
© 2020 ISACA. All Rights Reserved.
Personal Copy of Immanuel Giulea (ISACA ID: 1157570)
Developing an effective IT risk assessment involves
determining the enterprise’s risk appetite and tolerance,
identifying and valuing its assets, assessing control
effectiveness, and isolating threats and vulnerabilities to
pinpoint risk. Assigning impact and likelihood based on
predetermined criteria is essential to an accurate account
of risk.
Risk treatment occurs after an assessment, but relies on
the results of the assessment to be done effectively.
Quantifying the financial cost of risk events can assist in
determining their criticality and promote resource
prioritization, including current and future IT security-
related investments. Having accurate, quantifiable data
and an up-to-date plan to identify and address possible
threat events can lead to improved productivity of IT
operations, security and audit, as well as cost savings in
the long run that help keep an enterprise viable. Risk
assessment is most effective when risk is documented in
a risk register that is regularly updated and consulted by
decision makers at all levels of the enterprise.
13 CONDUCTING AN IT SECURITY RISK ASSESSMENT

Acknowledgments
ISACA would like to acknowledge:

Lead Developer Board of Directors

James C. Samans Brennan Baybeck, Chair David Samuelson
CISA, CRISC, CISM, CBCP, CISSP-ISSEP, CISA, CRISC, CISM, CISSP Chief Executive Officer, ISACA, USA
CPP, PMP Oracle Corporation, USA
American Institutes for Research, USA
Rolf von Roessing, Vice-Chair
CISA, CISM, CGEIT, CISSP, FBCI
Expert Reviewers FORFA Consulting AG, Switzerland
Christopher Coyne
Tracey Dedrick
CISA, CRISC, CA, CIA
Former Chief Risk Officer with Hudson
Australia City Bancorp, USA
Melike Etem Pam Nigro
CRISC, CIPT, CISSP, PMP CISA, CRISC, CGEIT, CRMA
Symantec Corp., USA Health Care Service Corporation, USA
Katja Feldtmann R.V. Raghu
CISA, CRISC, CISM, QSA CISA, CRISC
Quantum Security Services, New Zealand Versatilist Consulting India Pvt. Ltd., India
Demetri Gittens Gabriela Reynaga
CISA, CRISC CISA, CRISC, COBIT 5 Foundation, GRCP
Central Bank of Trinidad and Tobago, Holistics GRC, Mexico
Trinidad and Tobago
Gregory Touhill
Yusuf Ashfaq Hashmi
CISM, CISSP
CISA, CRISC, CGEIT, CIPR, MBCS, ISO
Cyxtera Federal Group, USA
31000/27001/22301 Lead Implementer
Tata TeleServices Ltd., India Asaf Weisberg
CISA, CRISC, CISM, CGEIT
Peter Kirk
introSight Ltd., Israel
CISA, CRISC
Aviva, United Kingdom Rob Clyde
ISACA Board Chair, 2018-2019
CISM
Board Director, Titus and Executive Chair,
White Cloud Security, USA

Chris K. Dimitriadis, Ph.D.

ISACA Board Chair, 2015-2017
CISA, CRISC, CISM
INTRALOT, Greece

Greg Grocholski
ISACA Board Chair, 2012-2013
CISA
Saudi Basic Industries Corporation, USA

© 2020 ISACA. All Rights Reserved.

Personal Copy of Immanuel Giulea (ISACA ID: 1157570)
14 CONDUCTING AN IT SECURITY RISK ASSESSMENT

About ISACA
Now in its 50th-anniversary year, ISACA® (isaca.org) is a global association
1700 E. Golf Road, Suite 400
helping individuals and enterprises achieve the positive potential of
Schaumburg, IL 60173, USA
technology. Today’s world is powered by information and technology, and
ISACA equips professionals with the knowledge, credentials, education and
Phone: +1.847.660.5505
community to advance their careers and transform their organizations. ISACA
leverages the expertise of its 460,000 engaged professionals—including its Fax: +1.847.253.1755
140,000 members—in information and cybersecurity, governance, assurance,
Support: support.isaca.org
risk and innovation, as well as its enterprise performance subsidiary, CMMI®
Institute, to help advance innovation through technology. ISACA has a Website: www.isaca.org
presence in more than 188 countries, including more than 220 chapters
worldwide and offices in both the United States and China.

DISCLAIMER
Provide Feedback:
ISACA has designed and created Conducting an IT Security Risk Assessment www.isaca.org/conducting-an-IT-
(the “Work”) primarily as an educational resource for professionals. ISACA security-risk-assessment
makes no claim that use of any of the Work will assure a successful outcome.
The Work should not be considered inclusive of all proper information, Participate in the ISACA Online
procedures and tests or exclusive of other information, procedures and tests Forums:
that are reasonably directed to obtaining the same results. In determining the https://engage.isaca.org/onlineforums

propriety of any specific information, procedure or test, professionals should Twitter:

www.twitter.com/ISACANews
apply their own professional judgment to the specific circumstances
presented by the particular systems or information technology environment. LinkedIn:
www.linkedin.com/company/isaca

RESERVATION OF RIGHTS Facebook:

www.facebook.com/ISACAGlobal
© 2020 ISACA. All rights reserved.
Instagram:
www.instagram.com/isacanews/

Conducting an IT Security Risk Assessment

© 2020 ISACA. All Rights Reserved.

Personal Copy of Immanuel Giulea (ISACA ID: 1157570)