Cyber Risk Quantification Executive Briefing: What Boards Need to Know and Ask

Boards are asked to approve cyber security budgets, insurance limits and risk acceptances on the strength of red, amber and green heat maps that cannot say how much money is at stake or what a given investment buys. Cyber risk quantification (CRQ) expresses cyber risk as a range of possible financial loss over a period, so it can be compared with other business risks and with the cost of reducing it. This briefing is for board members, chief executives, finance directors and risk committees. It explains what CRQ is and is not, how to read its outputs, how it supports investment, insurance and disclosure decisions, and the questions and red flags that tell directors whether the numbers can be trusted. It stays at board level; the method itself is covered in the Cyber Risk Quantification Guide.

The risk in one paragraph

Without a financial view of cyber risk, boards cannot tell whether they are spending too much or too little, whether an insurance limit is adequate, or which of two competing security programmes reduces more risk per pound. Qualitative ratings hide large differences: two risks both rated "high" can differ in expected loss by orders of magnitude, and ordinal scores cannot be added up or compared with the cost of controls. CRQ addresses this by estimating how often a defined loss event is likely to occur and how much it would cost when it does, using ranges rather than single figures to show uncertainty honestly. The board's risk is twofold: making decisions without such a view, or trusting a precise-looking number built on weak assumptions. Good oversight asks for the financial view and then tests how it was built.

Why this is a board-level issue now

• Directors must describe their oversight: under US SEC rules adopted on 26 July 2023, registrants describe the board's oversight of cybersecurity risk in the annual report (Regulation S-K Item 106) and file a Form 8-K under Item 1.05 within four business days of determining that an incident is material. A financial view of loss helps make those materiality judgements consistent.
• Frameworks now expect a standard method: NIST Cybersecurity Framework 2.0 outcome GV.RM-06 calls for "a standardized method for calculating, documenting, categorizing, and prioritizing cybersecurity risks" to be established and communicated. NIST IR 8286 Rev. 1, published in December 2025, sets out how cybersecurity risk registers feed enterprise risk management, and IR 8286B (February 2025) covers prioritising those risks by their impact on enterprise objectives and recording the projected cost of risk response.
• Losses have reached balance sheet scale: Marks and Spencer estimated a £300 million reduction in profit before recoveries after its 2025 cyber attack. See the Marks and Spencer cyberattack. Losses of this size compete for capital with every other business risk, and need to be discussed in the same units.
• Insurance decisions need numbers: choosing a limit and deductible is a decision about how much loss to retain, which cannot be made from a heat map. See the Cyber Insurance Executive Briefing.
• An open standard exists: The Open Group publishes Open FAIR, comprising the Risk Taxonomy (O-RT) and Risk Analysis (O-RA) standards, as a way to report cyber risk in financial terms. Boards do not need to choose a method, but they can ask whether management uses a recognised one. See the FAIR Model and Open FAIR Standard Guide.

What CRQ is, and what it is not

In the FAIR approach, risk is analysed as the probable frequency of loss events and the probable magnitude of the resulting loss. Each is estimated as a range, then combined, typically by simulation, into a distribution of possible annual loss.

Reading the outputs

Directors do not need to understand the mathematics, but they should know what the common outputs mean and how to use them.

Where CRQ supports board decisions

• Investment: compare the risk reduction of competing programmes, for example phishing-resistant MFA across all remote access versus a new detection platform, and fund the one that reduces more loss exposure per pound.
• Risk appetite: express tolerance in money ("we will not accept more than a stated chance of an annual cyber loss above a stated amount") so management can show whether the organisation is inside it.
• Insurance: set limits and deductibles from the loss exceedance curve rather than from last year's renewal.
• Risk acceptance: require a financial estimate for any material risk acceptance, so directors can see what they are accepting.
• Disclosure and materiality: a consistent financial view supports, but does not replace, the legal judgement of whether an incident or risk is material.
• Third parties and acquisitions: estimate the loss exposure a supplier or acquisition brings. See the Mergers and Acquisitions Cyber Risk Executive Briefing.

Where identity fits in loss scenarios

Many of the largest recent losses began with a login, not an exploit, so the frequency side of a scenario depends heavily on identity controls. Two examples show why boards should expect identity to appear explicitly in the top scenarios:

• Human credentials without MFA: Change Healthcare's attackers used a stolen credential on a remote access portal that did not require multi-factor authentication; UnitedHealth later put the number of affected people at 192.7 million. See the Change Healthcare breach.
• Stolen and unrotated credentials at scale: in the 2024 Snowflake campaign, about 165 organisations were notified after attackers used infostealer credentials on accounts without MFA. See the Snowflake breach.

In practice this means a quantified scenario such as "ransomware via compromised remote access" should show how loss frequency changes when phishing-resistant MFA covers every remote route and privileged account, and when service accounts and API keys are owned, scoped and rotated. That turns identity programmes from a technical request into a priced reduction in loss exposure that directors can weigh against cost. See the Board Briefing: NHI Risk.

Where CRQ sits in the frameworks

Five questions for the board to ask

1. What are our top loss scenarios, in money? Show us our five largest cyber loss scenarios with a range of annual loss for each and the probability of a loss above our tolerance.
2. Where do the numbers come from? Which inputs are based on our own data, which on industry data, and which on expert estimates, and who reviewed them?
3. What does this investment buy? For each major security proposal, how much does it reduce loss exposure, and how does that compare with its cost?
4. Are we inside our risk appetite? How does our modelled loss exposure compare with the appetite the board approved, and what would bring us inside it?
5. How good have past estimates been? When incidents or near misses happened, how did they compare with what the model predicted, and what changed as a result?

Red flags in management answers

• A single precise number: "our cyber risk is £43.7 million" with no range, no scenarios and no assumptions.
• A black box: results come from a tool or vendor and nobody internally can explain the inputs.
• Scenarios that are too broad: "a cyber attack" rather than a defined threat, asset and loss type.
• Numbers that never change: the analysis is not updated after incidents, control changes or business changes.
• Quantification used only to justify a decision already taken: results appear after the budget is set.
• No link to identity and access risk: scenarios ignore stolen credentials and machine identities, which are the entry point in many large incidents.

What good looks like

• A documented method based on a recognised standard, with a named owner and an independent challenge function, such as risk management or internal audit.
• Five to ten top scenarios quantified with ranges, assumptions written down and data sources stated.
• Risk appetite expressed in financial terms and approved by the board.
• Major security investments justified by modelled risk reduction, and tracked afterwards.
• Results integrated into the enterprise risk register and the regular board risk report. See the Board Cyber Risk Reporting Guide.
• Estimates compared with incidents and near misses at least annually, with lessons fed back.

Where to invest first

1. Scenario definition: agree the top scenarios with the business; this is cheap and immediately improves conversations.
2. A pilot on one decision: quantify one live decision, such as an insurance renewal or a major programme, rather than the whole risk register.
3. Skills before tools: train analysts in the method and in estimating ranges before buying a platform. See the Open FAIR Foundation Certification Guide and the Cyber Risk Quantification Platform Buyers Guide.
4. Internal loss data: start recording the actual costs of incidents, outages and response so future estimates rest on your own data.
5. Financial risk appetite: once the first scenarios are quantified, ask the board to set a monetary tolerance.

Metrics to track

A 90-day plan

1. Days 1 to 30: the board asks for a CRQ proposal; management agrees five top scenarios with business owners, chooses a recognised method and names an owner and an independent reviewer.
2. Days 31 to 60: quantify the scenarios with ranges and documented assumptions; apply the analysis to one live decision, such as the insurance renewal or the largest security programme.
3. Days 61 to 90: present results with the loss exceedance curve and drivers; the board discusses a financial risk appetite; agree how CRQ results will appear in the regular risk report and when they will be refreshed.

Common failure patterns

• False precision: point estimates presented as facts, which collapse at the first challenge.
• Boiling the ocean: trying to quantify every risk in the register before delivering any decision value.
• Tool first, method second: a platform bought before anyone can define a scenario or review an input.
• Ignoring the identity entry point: scenarios built around exotic threats while stolen credentials and unmanaged service accounts drive real incidents.
• No feedback loop: estimates never compared with outcomes, so the model never improves.

Lessons from incidents

Real incidents are the test of any quantification. The Marks and Spencer estimate of £300 million before recoveries is the kind of tail loss a loss exceedance curve should already show as possible for a large retailer whose online sales and operations depend on its systems. The useful board exercise is to ask management where an incident like that sits on the organisation's own curve: if the model said it was nearly impossible, the model needs revisiting; if the model showed it but the insurance limit and investment plan did not reflect it, the decisions need revisiting.

Practitioner checklist

• Define five to ten top loss scenarios with business owners, each naming a threat, an asset and a loss type.
• Use a recognised method and document assumptions and data sources for every input.
• Present results as ranges, loss exceedance curves and key drivers, never as a single figure.
• Quantify risk reduction for every major security investment and track delivery.
• Propose a financial risk appetite for board approval.
• Feed results into the enterprise risk register and the board risk report.
• Record actual incident costs and compare them with estimates at least annually.
• Arrange independent challenge of the model by risk management or internal audit.

Standards and references

• NIST: Cybersecurity Framework 2.0
• NIST: IR 8286 Rev. 1, Integrating Cybersecurity and Enterprise Risk Management
• NIST: IR 8286B, Prioritizing Cybersecurity Risk for Enterprise Risk Management
• The Open Group: Open FAIR
• FAIR Institute: What is FAIR
• US SEC: Cybersecurity Risk Management, Strategy, Governance, and Incident Disclosure rules
• NIST: SP 800-53 Rev. 5

How NHI Mgmt Group can help

We provide independent identity and non-human identity risk assessments and board briefings, including how stolen credentials, privileged accounts and machine identities feature in loss scenarios. Our NHI Foundation Level Training Course helps security and IAM teams govern service accounts, API keys and secrets. Contact us to arrange a briefing.

Related NHI Mgmt Group resources: Cyber Risk Quantification Guide · FAIR Model and Open FAIR Standard Guide · FAIR-CAM Controls Analytics Model Guide · Board Briefing: NHI Risk