Most cyber risk assessments end in a red, amber or green cell that cannot be compared with a budget, an insurance limit or another risk, because nobody wrote down how often the loss might happen or how much it would cost. This worksheet turns one loss scenario into a range of annual loss in money, using the factor names from the Open FAIR standards published by The Open Group (the Risk Taxonomy, O-RT, and the Risk Analysis standard, O-RA). It covers scoping, calibrated range estimates for loss event frequency and loss magnitude, a Monte Carlo outline you can run in a spreadsheet, control comparison and sign-off. It is for risk analysts, CISOs and GRC teams running their first analyses without a dedicated platform. For the concepts behind each field read the Cyber Risk Quantification Guide; this page is the form you fill in.
How to use this template
- Use one worksheet per loss scenario. A scenario names one asset, one threat community, one type of event and one effect. "Ransomware" is not a scenario; "external criminal group encrypts the order management platform, halting online sales" is.
- Replace text in square brackets, such as [Organisation], [Analyst] and [Asset], with your own values. Keep the field names: they match the Open FAIR taxonomy so results compare across analyses.
- Give every estimate as a range (minimum, most likely, maximum) that you are 90 per cent confident contains the true value. O-RA recommends calibrated range estimates and favours accuracy over precision: a wide honest range beats a narrow wrong one.
- Estimate at the highest level of the taxonomy your data supports. If you have incident history for loss events, estimate Loss Event Frequency directly; decompose into Threat Event Frequency and Vulnerability only when you lack that data.
- Record the source of every estimate in the rationale column. An estimate with no rationale cannot be reviewed or challenged.
- Run the simulation, report percentiles rather than a single average, and repeat after any material control change.
1. Analysis header
| Field | Entry |
|---|---|
| Analysis ID and date | [CRQ-2026-014, DD Month YYYY] |
| Decision this analysis supports | [Fund control X / set cyber insurance limit / accept or treat risk register item R-23 / compare two options] |
| Analyst and reviewer | [Analyst name, role] / [Independent reviewer name, role] |
| Risk owner | [Business owner who can accept or fund treatment] |
| Time horizon | [Annual: estimates are per year unless stated] |
| Currency and price basis | [GBP, EUR or USD; current year prices] |
| Related register entry | [Risk register ID, see the Risk Register Template] |
| Risk appetite reference | [Tolerance threshold in money, from the approved appetite statement] |
2. Loss scenario definition
O-RA starts every analysis by identifying the loss scenario. Fill each element; if any cell is vague, the estimates that follow will be too.
| Element | Question | Entry |
|---|---|---|
| Primary stakeholder | Whose loss is being measured? | [Organisation, or a named business unit] |
| Asset | What has value and is at risk? | [Customer database, payment platform, cloud tenant, CI/CD signing key] |
| Threat community | Who or what acts against the asset? | [Financially motivated external groups / privileged insiders / suppliers with access / non-malicious staff error] |
| Threat event | What do they do? | [Use a leaked cloud access key to read storage buckets] |
| Loss event | What harm results? | [Confidentiality breach of 500,000 customer records] |
| Effect | Confidentiality, integrity or availability? | [C / I / A] |
| Out of scope | What is deliberately excluded? | [Other assets reached through lateral movement; analysed in CRQ-2026-015] |
Scoping test: could two analysts read this section and estimate the same thing? If not, narrow it. Machine credentials make good, narrow scenarios: a leaked API key or long-lived access key gives a clear asset, threat event and effect. See the NHI Risk Scoring Guide for signals that make those frequencies estimable.
3. Loss event frequency
Loss Event Frequency (LEF) is how often, in the time horizon, the threat event is expected to result in loss. Use Route A when you have loss history; use Route B to decompose.
Route A: direct estimate
| Factor | Min | Most likely | Max | Rationale and data source |
|---|---|---|---|---|
| Loss Event Frequency (events per year) | [0.05] | [0.2] | [1] | [Internal incidents 2021 to 2026; sector incident reports; insurer loss data] |
Route B: decomposition
| Factor (O-RT term) | Unit | Min | Most likely | Max | Rationale |
|---|---|---|---|---|---|
| Contact Frequency (optional) | Contacts per year | [ ] | [ ] | [ ] | [How often the threat community comes into contact with the asset] |
| Probability of Action (optional) | Per cent of contacts | [ ] | [ ] | [ ] | [Likelihood the contact becomes an attempt] |
| Threat Event Frequency (TEF) | Attempts per year | [2] | [6] | [20] | [Blocked attempts in logs, scanning telemetry, threat intelligence] |
| Vulnerability (susceptibility) | Per cent of threat events that become loss events | [2%] | [5%] | [15%] | [Control test results, red team findings; or derive from Threat Capability against Resistance Strength] |
| LEF (calculated) | Events per year | TEF multiplied by Vulnerability, per simulation run | [Do not multiply the most-likely values alone; let the simulation combine the ranges] | ||
Threat Capability and Resistance Strength: if you cannot estimate Vulnerability directly, O-RT expresses Threat Capability as a percentile of the threat community and Resistance Strength against the same scale. Vulnerability is the probability that the threat's capability exceeds the resistance. Most first analyses estimate Vulnerability directly from control testing instead.
4. Loss magnitude
Loss Magnitude (LM) is the money lost per loss event. Open FAIR separates primary loss, borne directly by the primary stakeholder, from secondary loss, caused by reactions of secondary stakeholders such as customers, regulators and litigants. Estimate per event, by the six forms of loss.
4.1 Primary loss per event
| Form of loss | Typical components | Min | Most likely | Max | Source |
|---|---|---|---|---|---|
| Productivity | Lost revenue during outage, idle staff time | [ ] | [ ] | [ ] | [Business impact analysis, finance] |
| Response | Internal incident hours, forensics, outside counsel, crisis communications | [ ] | [ ] | [ ] | [Retainer rates, past incident costs] |
| Replacement | Rebuilding systems, replacing hardware, rotating credentials and certificates | [ ] | [ ] | [ ] | [IT asset costs, rebuild estimates] |
| Total primary loss | Sum per simulation run | ||||
4.2 Secondary loss
| Factor | Unit | Min | Most likely | Max | Source |
|---|---|---|---|---|---|
| Secondary Loss Event Frequency (SLEF) | Per cent of primary loss events that trigger secondary stakeholder reaction | [30%] | [70%] | [100%] | [Notification thresholds: personal data breach almost always triggers it] |
| Response (secondary) | Notification, call centre, credit monitoring, regulator engagement | [ ] | [ ] | [ ] | [Cost per notified individual, vendor quotes] |
| Fines and judgments | Regulatory penalties, settlements, legal defence | [ ] | [ ] | [ ] | [Counsel view of applicable regimes; published enforcement] |
| Competitive advantage | Loss of trade secrets or market position | [ ] | [ ] | [ ] | [Strategy or product owner] |
| Reputation | Customer churn, higher cost of capital, lost deals | [ ] | [ ] | [ ] | [Churn after past incidents, sales pipeline data] |
| Secondary Loss Magnitude (SLM) | Sum per simulation run, applied only when the SLEF draw triggers | ||||
Check against limits: no per-event maximum should exceed what the organisation could plausibly lose. Compare the largest values with revenue, insurance limits and any statutory cap on penalties before you run the model.
5. Calibration and estimate quality
| Check | Done | Note |
|---|---|---|
| Estimators completed calibration practice (trivia ranges at 90 per cent confidence) before estimating | [Y/N] | [Names, date] |
| Each range tested with the "equivalent bet" question: would you rather bet on the range or on a 90 per cent wheel? | [Y/N] | |
| At least two independent sources consulted for the three largest inputs | [Y/N] | |
| Subject matter experts named for frequency and for magnitude | [Y/N] | [Security for frequency; finance, legal and business for magnitude] |
| Inputs stated in the same time horizon and currency | [Y/N] | |
| Known gaps recorded, not hidden by narrow ranges | [Y/N] | [List] |
6. Monte Carlo simulation outline
O-RA derives risk by combining the frequency and magnitude ranges, typically with Monte Carlo simulation. You can run this in a spreadsheet; a dedicated platform adds speed, libraries and portfolio views (see the Cyber Risk Quantification Platform Buyers Guide).
- Choose a distribution per input: a PERT (modified beta) distribution built from minimum, most likely and maximum suits most expert estimates; a lognormal suits long-tailed losses where the maximum is uncertain. Record the choice.
- Set the iteration count: 10,000 runs is a common starting point; increase it until the 90th and 95th percentiles stop moving between runs.
- For each run, draw the number of loss events: draw LEF, then draw an event count for the year (a Poisson draw with LEF as its mean handles fractional frequencies). Most runs will have zero events for rare scenarios; that is correct.
- For each event in the run, draw magnitude: sum the primary loss forms; draw against SLEF to decide whether secondary loss occurs; if it does, add the secondary forms.
- Sum the year: annual loss for the run is the sum across its events.
- Summarise: calculate the mean (annualised loss exposure), the 10th, 50th, 90th and 95th percentiles, and the probability that annual loss exceeds the tolerance in section 1.
- Plot the loss exceedance curve: for each loss amount, the probability of exceeding it in a year. O-RA names loss exceedance curves and percentile tables as standard ways to present results.
- Find the drivers: vary each input from its minimum to maximum while holding others at most likely, and rank the effect on the mean (a tornado chart). The top two drivers are where better data pays.
| Output | Current state | With proposed control |
|---|---|---|
| Annualised loss exposure (mean) | [ ] | [ ] |
| Median annual loss | [ ] | [ ] |
| 90th percentile annual loss | [ ] | [ ] |
| 95th percentile annual loss | [ ] | [ ] |
| Probability of exceeding tolerance in a year | [ ] | [ ] |
| Top two input drivers | [ ] | [ ] |
7. Control and treatment comparison
O-RA models controls by the factor they change: avoidance and deterrent controls reduce contact or action (and so TEF), vulnerability controls reduce the share of events that become losses, and responsive controls reduce loss magnitude. Re-run the model with changed inputs only for the factors the control actually affects.
| Option | Factor changed | New range | Annual cost (run plus amortised build) | Reduction in mean annual loss | Reduction in 95th percentile |
|---|---|---|---|---|---|
| [Rotate and vault cloud access keys, remove long-lived keys] | [Vulnerability] | [1% / 2% / 6%] | [ ] | [ ] | [ ] |
| [Immutable backups with tested restore] | [Productivity and replacement loss] | [ ] | [ ] | [ ] | [ ] |
| [Cyber insurance, limit X, retention Y] | [Transfers part of magnitude] | [ ] | [Premium] | [Net of retention] | [ ] |
| [Accept] | [None] | [0] | [0] | [0] |
A control is good value when its cost is below the reduction it buys in expected loss, or when it brings the probability of exceeding tolerance within appetite even at a higher cost. Say which test you used. For insurance limits, compare the 95th percentile with the limit and retention; see the Cyber Insurance Guide.
8. Worked example (hypothetical)
The figures below are illustrative only and are not drawn from any real organisation or dataset.
| Input | Min | Most likely | Max |
|---|---|---|---|
| Scenario | External actor uses a leaked long-lived cloud access key to copy a customer data bucket | ||
| LEF (per year) | 0.05 | 0.15 | 0.6 |
| Primary loss per event (response and replacement) | 150,000 | 400,000 | 1,500,000 |
| SLEF | 60% | 85% | 100% |
| Secondary loss per event (notification, fines, churn) | 300,000 | 1,200,000 | 8,000,000 |
Read the result as a range: most simulated years have no event, so the median annual loss is zero, while the mean and the 90th and 95th percentiles carry the decision. If the proposed control (removing long-lived keys) narrows LEF, compare the new 95th percentile with the tolerance in section 1. The pattern is not theoretical: in the TruffleNet campaign, attacker infrastructure checked stolen AWS keys automatically, and in a separate environment an account with Amazon SES permissions sent a fake invoice asking for a USD 50,000 payment, so both frequency and magnitude inputs have real precedent.
9. Results statement and sign-off
| Field | Entry |
|---|---|
| Plain-language result | [We estimate a 1 in [X] chance per year of a loss above [amount]; the expected annual loss is [amount].] |
| Comparison with appetite | [Within / outside tolerance, by how much] |
| Recommended treatment | [Option, cost, residual 95th percentile] |
| Key assumptions and limits | [Top three assumptions; what would change the answer] |
| Reviewer comments | [ ] |
| Risk owner decision and date | [Accept / treat / transfer / avoid, signature, date] |
| Next review | [Date, or trigger such as major incident, control change or acquisition] |
Implementation guidance
- Start with three scenarios: pick the risks leadership already argues about, so the first results answer a live question. Credential exposure, ransomware on a revenue system and a supplier breach are common first choices.
- Separate estimators by expertise: security staff estimate frequency and vulnerability; finance, legal and the business own magnitude. A single analyst estimating everything is the most common source of bias.
- Do not translate back to colours: O-RA warns against converting quantitative results into qualitative scales, because the conversion discards the information that made the analysis useful. If a heat map is mandatory, show the money ranges beside it.
- Keep a data register: record which incident data, telemetry and external reports fed each estimate, so the next analysis starts from the same evidence and can be refreshed annually.
- Link to the register and appetite: store the results summary against the risk register entry, and express tolerance in the same units. See the Cyber Risk Appetite Statement Template.
- Measure the practice: track the number of decisions supported by a quantified analysis, the share of estimates with a documented source, and how often actual annual losses fall inside the predicted 90 per cent range.
Framework mapping
| Worksheet section | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 |
|---|---|---|
| 1 Header, appetite reference | GV.RM-02 | PM-9 Risk Management Strategy, PM-28 Risk Framing |
| 2 to 6 Scenario, frequency, magnitude, simulation | GV.RM-06, ID.RA-04, ID.RA-05 | RA-3 Risk Assessment |
| 7 Treatment comparison | ID.RA-06 | RA-7 Risk Response |
| 9 Sign-off and review | GV.OV-03 | PM-9 Risk Management Strategy |
Standards and references
- The Open Group: Risk Analysis (O-RA) Standard, Version 2.0.1
- The Open Group: Risk Taxonomy (O-RT) Standard, Version 3.0.1
- FAIR Institute: What is FAIR
- NIST: IR 8286A Rev. 1, Identifying and Estimating Cybersecurity Risk for Enterprise Risk Management
- NIST: IR 8286B, Prioritizing Cybersecurity Risk for Enterprise Risk Management
- NIST: SP 800-53 Rev. 5
- NIST: Cybersecurity Framework 2.0
This template is provided for guidance and must be adapted to your organisation. Related NHI Mgmt Group resources: Cyber Risk Quantification Guide · FAIR Model and Open FAIR Standard Guide · FAIR-CAM Controls Analytics Model Guide · Cyber Risk Quantification Executive Briefing · Risk Register Template