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.
Free risk register tools to start immediately:
SimpleRisk — free, self-hosted open-source GRC platform with a built-in risk register, treatment workflows, and reporting. Installs in under 30 minutes.
Eramba Community Edition — free open-source GRC platform covering risk register, control mapping, and exception tracking.
ISO27k Toolkit — free Excel risk register template, ready to populate immediately.
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, including major security investments, board-level risk reporting, and 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]
A worked FAIR example you can recompute. Suppose you're estimating the annual risk from phishing leading to a business email compromise (BEC). You don't need expensive tooling — you need estimates and arithmetic.
Loss Event Frequency (LEF). Last year your staff received roughly 12 credible phishing attempts that got past filters. Historically about 1 in 4 leads to someone entering credentials, and of those, about half are caught by MFA or quick reporting before any loss. So: 12 × 0.25 × 0.5 ≈ 1.5 successful loss events per year.
Loss Magnitude (LM). When a BEC succeeds, you estimate the fraudulent transfer plus investigation, notification, and downtime costs. You're not certain, so you give a range: minimum $20,000, most likely $90,000, maximum $400,000.
Annualized Loss Expectancy. Multiply frequency by magnitude across the range. Most-likely annual loss ≈ 1.5 × $90,000 = $135,000/year, with a plausible band running from roughly $30,000 to over $600,000 in a bad year.
Now compare that to the cost of treatment: phishing-resistant MFA and a reporting button might cost $15,000/year and cut the success rate in half. That turns "we should probably do security awareness" into "this control returns roughly 4-to-1." That's the conversation FAIR enables — and you just did it with multiplication, not a PhD.
Free FAIR resources: The FAIR Institute provides free membership, introductory training, and community-built quantitative risk calculators. The free FAIR Foundation course is the right starting point for anyone moving from qualitative ratings to financial risk quantification.
A word of realism: don't quantify everything. FAIR is powerful, but it needs data and estimation skill that many organizations don't have, and quantifying every risk is a fast route to "analysis fatigue." The pragmatic approach most mature teams actually use is hybrid: qualitative scoring (the 5×5 matrix) to triage the whole register cheaply, then full quantitative analysis reserved for the top five to ten risks where a board decision or a major investment is on the line. Precision is expensive — spend it where the decision is expensive.
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]
Free ISO 27001 SoA template: The ISO27k Toolkit includes a pre-built Statement of Applicability spreadsheet with all 93 Annex A controls pre-loaded. You document your inclusion/exclusion decisions and justifications for each — the core artifact for ISO 27001 certification.
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.
A practical control has emerged from this wave of supply-chain incidents: the Software Bill of Materials (SBOM), a machine-readable inventory of every component and dependency inside a piece of software. When the next Log4Shell-class vulnerability is announced, the difference between organizations that can answer "are we affected?" in minutes and those that spend weeks manually hunting is whether they have SBOMs for what they run. US Executive Order 14028 and subsequent federal guidance pushed SBOMs from best practice toward baseline expectation, and they're increasingly written into vendor contracts. For third-party risk management, requiring vendors to provide an SBOM — and having a process to act on it — is now part of a credible program. (The mechanics of generating and consuming SBOMs live in Chapter 10.)
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
Templates and Examples You Can Use Today
Risk management produces artifacts. These free resources let you build those artifacts immediately rather than starting from scratch.
Risk Register and GRC Platforms
Free, self-hosted open-source risk register with risk treatment workflows, reporting, and user management
Organizations wanting a proper risk register tool without vendor cost; installs in under 30 minutes
Free open-source GRC platform with risk register, control mapping, exception tracking, and compliance management
Teams managing multiple frameworks and needing a single platform to track risks and controls
Free Excel risk register, Statement of Applicability template, Annex A control list, and risk treatment plan
ISO 27001 preparation; a working risk register and SoA you can populate immediately
Free risk assessment guide with worked example tables in Appendix I showing a complete assessment with representative entries
Understanding what a complete, professional risk assessment looks like in practice
Free model documentation, introductory training, and community-built quantitative risk calculators
Organizations moving from qualitative ratings to financial risk quantification
Vulnerability Register: A Minimal Schema
A vulnerability register is a tracked list of known weaknesses and their remediation status. Most teams build this in Jira, a spreadsheet, or their GRC platform. The minimum viable column set:
ID
Unique identifier for tracking and referencing in reports
CVE / Reference
CVE number if applicable; internal reference otherwise
Affected Asset
System, service, or component with the vulnerability
CVSS Score
Base severity score (NIST NVD publishes these for known CVEs)
Exploitability
Is a public exploit available? Is it being actively exploited in the wild?
Owner
The team or individual responsible for remediation
Due Date
Remediation deadline based on severity SLA
Status
Open / In Progress / Patched / Accepted / Mitigated
Evidence
Link to patch ticket, change record, or exception documentation
NIST SP 800-30 Appendix I provides the closest authoritative reference for this structure. Severity SLAs should be defined in your vulnerability management policy first — how quickly must a Critical, High, Medium, or Low vulnerability be remediated? That policy drives the Due Date column.
Start with a spreadsheet, then graduate to a platform. A well-maintained spreadsheet beats a poorly configured GRC tool. The ISO27k Toolkit Excel risk register is a solid starting point. Once the process is mature and the team understands the workflow, migrate to SimpleRisk or a dedicated vulnerability management platform.
Try This
Fill in one risk register row, properly. Pick a real risk for any organization you know (say, "ransomware via an unpatched VPN appliance"). Using the NIST SP 800-30 Rev 1 Appendix I tables as a guide, fill in: threat source, vulnerability, likelihood, impact, the resulting risk rating, your treatment decision (mitigate/accept/transfer/avoid), and the control. One complete, defensible row teaches more than reading the whole standard — and it's the literal day-job of a risk analyst.
Quantify one risk with FAIR. Take the same risk and run the worked example above on it: estimate loss event frequency and a min/likely/max loss magnitude, then compute annualized loss expectancy. Compare it to the cost of one control. Notice how the financial framing changes which risks suddenly look urgent.
Key Takeaways
Risk = threat × vulnerability × impact. Remove any one and the risk collapses — which is why prioritization beats trying to fix everything.
Define risk appetite and tolerance explicitly, or you're implicitly accepting whatever risk exists. That's abdication, not management.
The lifecycle is continuous: context, identify, analyze, treat, monitor. The risk register is a living tool, not a one-time document.
Qualitative matrices are cheap and subjective; quantitative methods like FAIR translate risk into dollars boards can act on. Use hybrid — quantify only the top handful of risks.
Third-party and concentration risk are now front-line concerns. SBOMs are becoming the baseline answer to "are we affected?" when the next widespread vulnerability lands.
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