Risk Management
Risk Is Not the Enemy
Organizations do not fail because they face risk. They fail because they face risk they did not understand, did not measure, and did not make deliberate decisions about.
Every organization that has ever operated has accepted risk. A hospital that stores patient records accepts the risk that those records could be breached. A bank that offers online banking accepts the risk that accounts could be compromised. A manufacturer that connects its production floor to the internet accepts the risk that an attacker could disrupt operations. The question is never whether to accept risk. It is whether the risk being accepted is understood, proportionate, and managed.
Risk management is the discipline that makes those decisions systematically instead of accidentally.
What Risk Actually Is
Risk in information security is the potential for harm resulting from a threat exploiting a vulnerability in an asset. Three components interact to produce risk.[1]
Threat
A potential cause of harm
Ransomware operator, disgruntled insider, hardware failure
Vulnerability
A weakness that could be exploited
Unpatched software, weak access controls, untrained staff
Impact
The consequence if exploitation occurs
Data loss, operational downtime, regulatory fines, reputational damage
Remove any one component and the risk collapses. A threat with no vulnerability to exploit cannot cause harm. A vulnerability with no threat actor to exploit it carries no risk. An asset with no value carries no meaningful impact. This is why risk management focuses on all three -- and why prioritizing based on likelihood and impact matters more than treating all vulnerabilities equally.
Risk appetite vs. risk tolerance:
Risk appetite is the amount and type of risk an organization is willing to accept in pursuit of its objectives. It is a strategic decision made by senior leadership and the board.
Risk tolerance is the acceptable variation around that appetite -- the operational boundaries within which the organization is willing to deviate before action is required.
An organization might have a risk appetite of "no unpatched critical vulnerabilities on internet-facing systems for more than 72 hours." Its risk tolerance might allow 96 hours in exceptional circumstances with documented approval. Both must be defined. Organizations that have neither are accepting whatever risk exists, which is not a strategy.
The Risk Management Lifecycle
Risk management is not a one-time assessment. It is a continuous cycle. ISO 31000:2018, the international standard for risk management, describes it as an iterative process of identification, analysis, evaluation, treatment, and monitoring.[2]
Step 1: Context and Scope
Before identifying risks, define what you are protecting and what you are protecting it from. This means:
Defining the scope of the risk assessment (which systems, processes, data, or business units)
Understanding the organization's objectives (what does success look like, and what would threaten it)
Identifying internal and external context (regulatory environment, technology landscape, threat intelligence)
Establishing risk acceptance criteria (at what point is a risk considered acceptable without further treatment)
Step 2: Risk Identification
Identify threats to information assets within scope. Sources of risk include:
External threats: attackers, natural disasters, supply chain failures
Internal threats: accidental errors, system failures, malicious insiders
Process risks: inadequate controls, poor change management, untrained staff
Compliance risks: regulatory changes, contractual obligations
A risk register is the primary artifact here -- a structured document recording identified risks, their sources, affected assets, current controls, and status. A risk register that is maintained and reviewed is an active management tool. One that was created once and filed is a false comfort.
Step 3: Risk Analysis
For each identified risk, assess:
Likelihood: How probable is it that this threat will exploit this vulnerability? Consider historical data, threat intelligence, and existing controls.
Impact: If exploitation occurs, what is the consequence? Consider financial loss, operational disruption, regulatory penalty, and reputational damage.
The combination of likelihood and impact produces a risk rating. A 5x5 risk matrix is the most common visualization, with likelihood on one axis and impact on the other, producing a heat map that distinguishes low-priority risks from critical ones.
The limitation of qualitative risk matrices: A 5x5 matrix uses subjective ratings ("high," "medium," "low") that different people will score differently. Two analysts assessing the same risk can produce different ratings based on judgment alone. Qualitative matrices are useful for communication and prioritization but should not be mistaken for precision.
For high-stakes decisions -- major security investments, board-level risk reporting, insurance decisions -- consider quantitative risk analysis methods that express risk in financial terms.
Quantitative Risk Analysis: The FAIR Model
Factor Analysis of Information Risk (FAIR) is the leading framework for quantitative cyber risk measurement.[3] Instead of "high/medium/low" ratings, FAIR produces risk in financial terms: expected loss in dollars over a defined period, expressed as a range.
FAIR decomposes risk into:
Loss Event Frequency: How often an event is expected to occur (combining threat event frequency and vulnerability)
Loss Magnitude: The financial impact when it does occur (combining primary and secondary losses)
The output is a probability distribution of annual loss expectancy -- for example, "there is a 90% probability that annual losses from this risk category will fall between $200,000 and $4.2 million, with a most likely value of $850,000."
This language is meaningful to CFOs, boards, and insurance underwriters in ways that "high risk" is not. FAIR is increasingly required in mature GRC programs and is the basis for the Open FAIR standard maintained by The Open Group.[4]
Step 4: Risk Treatment
Once risks are analyzed and prioritized, each requires a treatment decision. The four standard options:[5]
Mitigate (Treat)
Implement controls to reduce likelihood or impact
When the risk exceeds appetite and a cost-effective control exists
Accept (Tolerate)
Acknowledge the risk and continue without additional controls
When residual risk falls within appetite, or treatment cost exceeds potential loss
Transfer (Share)
Shift financial impact to a third party via insurance or contract
When risk cannot be fully mitigated and financial exposure needs to be bounded
Avoid (Terminate)
Cease the activity that creates the risk
When risk exceeds appetite and cannot be sufficiently reduced
Treatment decisions must be documented with rationale, approved by an appropriate authority, and reviewed periodically. A risk that was accepted three years ago may no longer be acceptable given changed circumstances.
ISO 27001 Annex A provides 93 control objectives across information security domains that serve as a library of treatment options. The Statement of Applicability (SoA) -- a required ISO 27001 document -- maps identified risks to the controls selected to treat them, explicitly noting which controls are included or excluded and why.[6]
Step 5: Monitor and Review
Risk is not static. New threats emerge. Vulnerabilities are discovered. Business processes change. Regulatory requirements shift. The risk management process must be:
Continuously monitored: Risk owners track control effectiveness and report changes
Formally reviewed: Management reviews risks at defined intervals (at minimum annually; more frequently for high-rated risks)
Audit-ready: Internal audits verify that risk treatment plans are implemented and effective
Risk Assessment Methods
Asset-Based Risk Assessment
Start with information assets, identify threats to each, assess the vulnerabilities those threats could exploit, and calculate risk. This is the approach mandated by ISO 27001 and is well-suited to organizations that need to demonstrate comprehensive coverage of their information security landscape.
Scenario-Based Risk Assessment
Start with plausible attack scenarios -- ransomware deployment, insider data theft, supply chain compromise -- and assess the likelihood and impact of each scenario. This approach is more intuitive for executives and easier to communicate to boards. It also maps naturally to cyber threat intelligence, since threat intel describes specific attack scenarios used by specific threat actors.
Hybrid Approaches
Most mature organizations use both: asset-based assessment for ISO 27001 compliance documentation and scenario-based assessment for executive reporting and strategic decision-making. The two perspectives are complementary.
Third-Party and Supply Chain Risk
Organizations do not operate in isolation. Their risk profile includes the security posture of every vendor, supplier, and partner with access to their systems or data. The SolarWinds breach, the MOVEit breach, and the 3CX supply chain attack all demonstrate that sophisticated attackers have learned to use trusted third parties as entry points.[7]
Third-party risk management (TPRM) is an extension of the risk management program that:
Inventories third-party relationships and the access each has
Assesses each vendor's security posture (through questionnaires, certifications, or direct audit)
Establishes contractual security requirements and right-to-audit clauses
Monitors vendor security posture on an ongoing basis
Defines processes for responding when a vendor is breached
The concentration risk problem: Many organizations rely on a small number of critical vendors for security-sensitive functions -- a single identity provider, a single cloud platform, a single security tool vendor. When one of these vendors is compromised, the blast radius extends to every customer simultaneously. The Log4Shell vulnerability (2021) and the XZ Utils backdoor (2024) demonstrated how a single widely-used component can expose millions of systems at once.
Understanding and managing concentration risk -- the risk that too many critical functions depend on a single point of failure -- is increasingly a governance-level responsibility.
Risk Reporting
Risk management produces no value unless findings reach the people who can act on them. Effective risk reporting varies by audience:
Board / Audit Committee
Strategic risk posture, top risks, trend over time, alignment to risk appetite
Concise dashboard, heat map, top 5-10 risks in business language
Executive Team
Operational risk status, resource requirements, compliance exposure
Summary report with action items and owners
Security Team
Detailed risk register, control gaps, treatment priorities
Full risk register with technical detail
Auditors / Regulators
Evidence of risk assessment process, treatment decisions, control effectiveness
Documented methodology, completed risk assessments, SoA
Risk reporting that only flows up the security team and never reaches the board is governance theater. It creates the appearance of risk management without the accountability.
Risk Management Certifications and Career Path
Risk management is a core competency for GRC professionals and is increasingly valued across all security disciplines. Certifications most relevant to risk management:
CRISC (Certified in Risk and Information Systems Control) -- ISACA's dedicated risk management certification; the most recognized credential specifically for IT risk practitioners
CISM (Certified Information Security Manager) -- covers risk management as a core domain alongside governance and incident response
CISSP -- includes risk management across its eight domains; relevant for senior generalist roles
ISO 31000 Lead Risk Manager -- practitioner-level certification in the ISO risk management standard
FAIR Institute membership -- for practitioners pursuing quantitative risk analysis
References
[1] Stoneburner, G., Goguen, A., & Feringa, A. (2002). Risk Management Guide for Information Technology Systems. NIST Special Publication 800-30. National Institute of Standards and Technology. doi:10.6028/NIST.SP.800-30
[2] International Organization for Standardization. (2018). ISO 31000:2018 -- Risk Management -- Guidelines. ISO. Retrieved from https://www.iso.org/standard/65694.html
[3] Jones, J., & Freund, J. (2015). Measuring and Managing Information Risk: A FAIR Approach. Butterworth-Heinemann. ISBN 978-0-12-420231-3.
[4] The Open Group. (2013). Open FAIR Body of Knowledge. The Open Group Standard. Retrieved from https://www.opengroup.org/open-fair
[5] National Institute of Standards and Technology. (2012). Guide for Conducting Risk Assessments. NIST Special Publication 800-30 Rev. 1. doi:10.6028/NIST.SP.800-30r1
[6] International Organization for Standardization. (2022). ISO/IEC 27001:2022 -- Information Security Management Systems -- Requirements. ISO/IEC JTC 1/SC 27.
[7] Cybersecurity and Infrastructure Security Agency. (2023). #StopRansomware: CL0P Ransomware Gang Exploits CVE-2023-34362 MOVEit Vulnerability. CISA Advisory AA23-158A. Retrieved from https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-158a
Further Reading
The authoritative NIST guide for conducting risk assessments. Free, comprehensive, well-structured.
Resources on quantitative cyber risk measurement. Free membership, active practitioner community.
The international risk management standard. Purchase required; summaries freely available.
Jones & Freund, Measuring and Managing Information Risk (2015)
The definitive book on the FAIR model. Required reading for anyone doing quantitative risk analysis.
Details on the leading IT risk management certification.
Questions about risk management or GRC career paths? Join the community on Discord or reach out on LinkedIn. If this chapter helped, contribute back -- this book is open source and your additions are welcome.
Last updated