Cyber risk quantification and the risk register: a CISO's working method

Why the register, not a separate model

Most security teams already hold a risk register. The problem is what sits in it: single words such as "high" and "medium", a heat map, and no way to compare a ransomware scenario with a supplier failure or a regulatory fine. NIST SP 800-30 Rev. 1 describes the limits plainly. Qualitative scales have a small range of values, which makes prioritization across risks difficult, and different experts can produce different results unless each value is defined with examples (NIST SP 800-30 Rev. 1, section 2.3.2).

Quantification fixes that by giving each risk a frequency and a magnitude in units that keep their meaning outside the assessment. NIST notes that this is the approach that "most effectively supports cost-benefit analyses" of alternative responses. The working method below keeps the register as the system of record and adds quantified fields to it, rather than building a separate model that nobody outside the security team reads.

Step 1: define the scenario, not the threat

Open FAIR defines risk as "the probable frequency and probable magnitude of future loss" that a primary stakeholder bears within a defined time period (Risk Taxonomy (O-RT), Version 3.0.1, The Open Group, C20B; wording as quoted by The Open Group). The unit of analysis is a loss scenario: a named asset, a named threat, and an effect on confidentiality, integrity or availability.

A register entry that says "ransomware" cannot be quantified. One that says "ransomware encrypts the order management platform and halts fulfillment for more than two days" can. Write the scenario in that form before you estimate anything. NIST CSF 2.0 expects the same discipline: subcategory ID.RA-03 asks that internal and external threats are "identified and recorded", and ID.RA-04 that "potential impacts and likelihoods of threats exploiting vulnerabilities are identified and recorded" (NIST CSF 2.0, CSWP 29).

Step 2: estimate frequency and magnitude as ranges

Open FAIR splits risk into two factors. Loss event frequency is the "probable number of economic losses within a given time period". Loss magnitude is "the probable magnitude of economic loss resulting from a loss event", measured in currency, and it is expressed as a distribution rather than a single number (The Open Group, updates to the Open FAIR Body of Knowledge, part 3). Loss magnitude has two parts: primary loss magnitude, the direct cost of the confidentiality, integrity or availability loss, and secondary loss magnitude, the indirect losses that arise from secondary stakeholders such as customers and regulators.

For each scenario, record a minimum, most likely and maximum for frequency per year and for each loss form. Ranges are honest about uncertainty and they are easier to defend than a point estimate. The Open Group is explicit that "risk measurements are never predictions", only estimates that turn out accurate or inaccurate against observed events (same source). Where the organization has incident, claims or downtime data, use it to anchor the ranges; where it does not, use calibrated estimates from named owners and record who gave them.

If a full quantitative pass is too costly for a given scenario, NIST SP 800-30 offers a semi-quantitative middle ground: bins such as 0-15, 16-35, 36-70, 71-85 and 86-100, or a 1-10 scale, that translate to qualitative terms while still allowing relative comparison. Use the same scale across the whole register or the comparison is lost.

Step 3: add the quantified fields to the register

The register needs eight additional fields per risk, alongside the owner, controls and status it already holds:

1. Scenario statement (asset, threat, effect).
2. Loss event frequency per year (min, most likely, max).
3. Primary loss magnitude (min, most likely, max).
4. Secondary loss magnitude (min, most likely, max).
5. Annualised loss exposure, derived from 2 to 4.
6. Evidence basis for each estimate and the date it was made.
7. Risk tolerance threshold the exposure is tested against.
8. Response chosen, with the expected change to frequency or magnitude.

Field 7 is where governance meets the numbers. CSF 2.0 subcategory GV.RM-02 asks that "risk appetite and risk tolerance statements are established, communicated, and maintained", and GV.RM-06 that "a standardized method for calculating, documenting, categorizing, and prioritizing cybersecurity risks is established and communicated". A tolerance expressed in currency, tested against an exposure expressed in currency, is that method in practice.

Keep the fields in the same register that enterprise risk uses. CSF 2.0 GV.RM-03 asks that cybersecurity risk management outcomes "are included in enterprise risk management processes", and ISO/IEC 27005:2022 adapts the general risk management principles of ISO 31000 to information security so that the two disciplines share one vocabulary (ISO/IEC 27005:2022).

Step 4: choose and track the response

NIST SP 800-30 describes risk assessment as a four-part process: prepare, conduct, communicate the results, and maintain the assessment over time. The register is the maintain step made concrete. For each scenario, record the response (accept, mitigate, transfer or avoid), the control or action that delivers it, the owner, and the review date. CSF 2.0 ID.RA-06 expects that responses are "chosen, prioritized, planned, tracked, and communicated", and ID.RA-07 that changes and exceptions are "managed, assessed for risk impact, recorded, and tracked".

Link each response to the threat and vulnerability records that feed it. CISA's Known Exploited Vulnerabilities catalog lists vulnerabilities with an assigned CVE identifier, reliable evidence of active exploitation and a clear remediation action, and CISA "strongly recommends" that every organization prioritises them (CISA, Known Exploited Vulnerabilities). A KEV entry on an asset named in a loss scenario raises the frequency estimate; patching it lowers the estimate again. That is the loop a quantified register makes visible.

Step 5: report exposure, not colors

The board does not need the heat map. It needs the top scenarios by annualised loss exposure, the tolerance each one is tested against, the trend since the last review, and the responses that moved the numbers. Because the estimates are ranges, report the range and say which end the evidence supports. NIST warns that quantified results "may require interpretation and explanation", so attach the evidence basis from field 6 to every figure a director will see.

How SmartSuite supports this method

Enterprise Risk Management holds the central risk register with configurable assessment models, key risk indicators and mitigation tracking, so the eight fields above sit in the register the whole business uses. Cyber Threat Management records threat intelligence, classifies and prioritises threats, tracks vulnerabilities and links them to risk scoring, so a change in the threat picture reaches the scenario it affects. Both are part of the Cyber & IT Risk suite.

Key facts

Frequently asked questions

Do we need a full FAIR analysis for every risk in the register?

No. Reserve full ranges for the scenarios that could breach tolerance or that the board asks about. NIST SP 800-30 recognises semi-quantitative scales as a valid approach, so lower-priority scenarios can carry a scored estimate on the same scale until they earn a fuller analysis. The rule is one consistent method across the register, which is what CSF 2.0 GV.RM-06 asks for.

Where do the frequency numbers come from if we have no loss history?

Start with calibrated estimates from the people who run the asset, expressed as a minimum, most likely and maximum, and record who gave them and when. Then narrow the range as evidence arrives: incident records, threat intelligence, vulnerability scan results and CISA KEV entries on the asset. The Open Group describes these measurements as estimates rather than predictions, so document the basis and revisit it.

How does quantification change the vulnerability backlog?

It gives the backlog a business order. A vulnerability that sits on an asset named in a high-exposure scenario moves up, whatever its base score. CISA's BOD 26-04 uses the same logic for federal agencies, setting timelines by asset exposure, KEV status, exploit automation and technical impact, with the most urgent tier at three days. A quantified register lets a private organization apply a comparable rule to its own estate.

What should the risk tolerance field contain?

A threshold in the same units as the exposure, set by the body that owns the appetite statement. CSF 2.0 GV.RM-02 expects appetite and tolerance statements to be established, communicated and maintained. If exposure is annualised loss in currency, tolerance is a currency figure per scenario or per category, so the comparison is direct and the breach is visible without interpretation.

Does ISO/IEC 27005 require quantitative assessment?

ISO/IEC 27005:2022 gives guidance on managing information security risks in support of an ISO/IEC 27001 management system, built on the principles of ISO 31000. It does not mandate a quantitative method. What it does require is that the organization defines its risk criteria and applies them consistently, which a quantified register with a tolerance field does in a form an auditor can trace.

Sources

• The Open Group, Risk Taxonomy (O-RT), Version 3.0.1, C20B, November 2021: https://publications.opengroup.org/c20b
• The Open Group, Risk Analysis (O-RA), Version 2.0.1, C20A, November 2021: https://publications.opengroup.org/c20a
• The Open Group, Updates to the Open FAIR Body of Knowledge, Part 3, 9 December 2020: https://blog.opengroup.org/2020/12/09/updates-to-the-open-fair-body-of-knowledge-part-3/
• NIST SP 800-30 Rev. 1, Guide for Conducting Risk Assessments, September 2012: https://csrc.nist.gov/pubs/sp/800/30/r1/final (PDF: https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-30r1.pdf)
• NIST CSWP 29, The NIST Cybersecurity Framework (CSF) 2.0, 26 February 2024: https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf
• ISO/IEC 27005:2022, Information security, cybersecurity and privacy protection, Guidance on managing information security risks: https://www.iso.org/standard/80585.html
• CISA, Known Exploited Vulnerabilities Catalog: https://www.cisa.gov/known-exploited-vulnerabilities
• CISA, BOD 26-04, Prioritizing Security Updates Based on Risk, 10 June 2026: https://www.cisa.gov/news-events/directives/bod-26-04-prioritizing-security-updates-based-risk

Related

• Category: Cyber & Technology Risk
• Cyber Risk Quantification vs Cyber Risk Management
• Vulnerability Exceptions and Risk Acceptance
• Cyber Threat Management
• What is: What is a Risk Register?
• Products: Cyber Threat Management, Enterprise Risk Management
• Suite: Cyber & IT Risk

Reviewer: to be assigned by Jon (credential line left empty; not invented).