---
title: "Cyber risk quantification: a practical method for B2B tech firms"
canonical: https://www.grcmana.io/vault/risk-management/cyber-risk-quantification
published: 2026-10-21
updated: 2026-10-23
author: "Harry West"
framework: "Risk Management"
control: "Guide Cyber risk quantification: a practical method for B2B tech firms"
journeyStage: advanced
---

# Cyber risk quantification: a practical method for B2B tech firms

## Key takeaways

Cyber risk quantification expresses cyber risk as a probable annual loss range in pounds, built from how often a loss event is likely and what each would cost. A UK tech firm can quantify its top three to five scenarios with calibrated ranges and a spreadsheet, anchored on DSIT base rates and its own contracts, and keep a risk matrix where no decision turns on money.

- **Quantitative assessment** — NIST SP 800-30 Rev. 1 defines quantitative risk assessment as using numbers whose meaning holds inside and outside the assessment; it most effectively supports cost-benefit analysis of alternative risk responses.
- **Three-point estimation** — NIST IR 8286A Rev. 1 (December 2025) describes estimating likelihood or impact as an optimistic, most likely and pessimistic value, polling several experts and averaging their values to reduce bias.
- **UK breach frequency** — DSIT's Cyber Security Breaches Survey 2025/2026, a random probability survey of UK businesses, found 43% reported a cyber security breach or attack in the previous 12 months.
- **Risk statements with uncertainty** — The NCSC's basic risk assessment method warns against giving decision makers a false sense of certainty, and its example risk statement gives both likelihood and cost as ranges.

The investor's due-diligence list has a new line: what is your cyber risk worth, and what is the exposure if the platform goes down for a week? Your answer is a red-amber-green heat map. It shows which risks feel worst. It cannot say what any of them would cost.

Cyber risk quantification closes that gap. This guide is for founders, CTOs and security leads at UK B2B tech firms with 25 to 150 staff that sell into financial services, insurance or the public sector. It shows how to put your top three to five cyber risks into pounds with ranges and a spreadsheet, where the UK base rates come from, how to keep the numbers current from data you already collect, and when a risk matrix is still enough.

## What is cyber risk quantification?

Cyber risk quantification expresses cyber risk as a probable financial loss range over a period, built from how often a loss event is likely to happen and how much each one would cost. A 25 to 150 person tech firm can do this for its top few scenarios in a spreadsheet; a matrix suffices where no decision hinges on money.

One established model for this is FAIR (Factor Analysis of Information Risk), which The Open Group's Security Forum publishes as the Open FAIR standards: a risk taxonomy and an analysis process. At the top of the taxonomy, risk splits into loss event frequency and loss magnitude, and each of those splits into smaller factors. You need only that top layer to start. Our [FAIR glossary entry](https://www.grcmana.io/vault/factor-analysis-of-information-risk) covers the standards and their current versions.

Quantification does not replace your risk assessment. It sharpens the few risks where a decision turns on money, inside the same process an [ISO 27001 information security risk assessment](https://www.grcmana.io/vault/iso-27001/clause-8-2-information-security-risk-assessment) or a SOC 2 risk assessment already runs. For ISO 27001, [ISO/IEC 27005](https://www.grcmana.io/vault/iso-27005) is the supporting guidance on running that process.

## How is cyber risk quantification different from a risk matrix?

A risk matrix rates likelihood and impact on labels or scores, such as one to five. Cyber risk quantification uses numbers that keep their meaning outside the assessment: pounds and events per year. NIST SP 800-30 calls these qualitative, semi-quantitative and quantitative assessments, and notes that quantitative results most effectively support cost-benefit analysis of alternative responses.

[NIST SP 800-30 Rev. 1](https://csrc.nist.gov/pubs/sp/800/30/r1/final), the US guide to conducting risk assessments, sets out the three approaches:

| Approach | What it uses | What it is good for | Where it falls short |
| --- | --- | --- | --- |
| Qualitative | Labels such as very low to very high | Communicating risk to decision makers | A narrow range of values makes ranking within the set difficult |
| Semi-quantitative | Bins, scales or scores (for example 1 to 10) whose meaning does not hold outside the assessment | Relative comparison and easy translation into labels | Rigour drops when subjective judgements are buried in the scores |
| Quantitative | Numbers whose meaning and proportion hold inside and outside the assessment | Cost-benefit analysis of alternative risk responses | Needs more effort, and results need explaining |

Many risk registers use the semi-quantitative middle row: a 5×5 grid where a "4" for impact means something to the team and nothing to an investor. The NCSC's [basic risk assessment method](https://www.ncsc.gov.uk/collection/risk-management/a-basic-risk-assessment-and-management-method) puts it plainly: matrices are easy to use, but "they can lead to errors and miscommunication of risk if not used carefully."

A heat map tells you which risk worries you most. It cannot tell you whether a £40,000 control is worth buying.

## When is a risk matrix enough, and when does cyber risk quantification earn its keep?

A risk matrix is enough when the decision is about order: which risk to treat first, or whether a risk sits inside appetite. Cyber risk quantification earns its keep when the decision is about money: a security investment, an insurance limit, an investor or board question, or a customer asking what an outage would cost. Most firms need both.

NIST IR 8286A Rev. 1, NIST's December 2025 guide to [identifying and estimating cybersecurity risk for enterprise risk management](https://csrc.nist.gov/pubs/ir/8286/a/r1/final), quotes the test from IEC 31010, the international standard on risk assessment techniques: the form of output most useful to stakeholders, and the availability and reliability of data. The table applies that test to the decisions a UK tech supplier usually faces. It is our guidance, not a requirement.

| Decision | Matrix enough? | Why quantify |
| --- | --- | --- |
| Ranking risks for the next quarter's work | Yes | Order is the output; money adds little |
| Choosing between two security investments | No | You need loss reduced per pound spent |
| Setting a cyber insurance limit or excess | No | Limits are in pounds; a red cell cannot be compared with a policy limit |
| An investor or board asks for exposure | No | They want a range they can weigh against revenue and runway |
| An enterprise customer asks what an outage would cost them or you | Usually no | Contract terms such as SLA credits are already in pounds |
| Prioritising a SOC 2 or ISO 27001 roadmap | Often yes | Quantify only the two or three items competing for the same budget |
| Reporting that a risk sits inside appetite | Yes, if appetite is set in labels | Quantify if appetite is set in pounds |

Neither SOC 2 nor ISO 27001 prescribes quantification. ISO 27001 asks for a defined, repeatable risk assessment process and leaves the choice of method to you, and SOC 2's criteria ask you to identify and analyse risks without fixing a scale. Quantification is a choice you make for decisions, not for the auditor.

## How do you quantify cyber risk in a small tech firm, step by step?

Quantify cyber risk in six steps: choose three to five loss scenarios, gather the data you already hold, estimate frequency and cost as calibrated ranges, combine them into an annual loss range, test which inputs move the answer, and report the range with its assumptions. Each step fits in a spreadsheet; none needs a platform.

### Step 1: Choose three to five loss scenarios

A scenario names a threat, the asset it hits and the loss that follows, in one sentence: "Ransomware takes the production platform offline for up to two weeks." Pick the scenarios behind the decision you face, not every risk in the register. Three to five is enough for a first pass, and we suggest keeping the estimating workshop to an afternoon.

### Step 2: Gather the data you already hold

Before anyone guesses, collect what exists: incident and near-miss logs, uptime and outage history, support tickets, contract terms with your largest customers, insurance policy wording, and recent penetration test findings. Add UK base rates from the sources in the next section. The aim is to anchor each estimate on evidence, so the workshop argues about adjustments, not starting points.

### Step 3: Estimate calibrated ranges

For each scenario, estimate two things as a range with a minimum, a most likely value and a maximum: how many times a year the loss event is likely to happen, and what one occurrence would cost. NIST IR 8286A Rev. 1 calls this three-point estimation, and recommends polling several people and averaging their values to reduce bias.

Calibration means the range is honest about what you do not know. NIST describes the equivalent bet test: would you bet money that the true value falls inside your range? If not, widen it. A range you would bet on beats a precise number you would not.

### Step 4: Combine into an annual loss range

Multiply frequency by cost to get an annual loss range for each scenario. A simple spreadsheet approach is to work out a low, most likely and high case. For a quick central figure, NIST's three-point technique weights the most likely value: add the minimum, four times the most likely and the maximum, then divide by six.

A hypothetical example shows the arithmetic. The figures are invented for illustration; they are not benchmarks or survey data. Say a two-week outage is estimated at once every five to ten years (0.1 to 0.2 times a year), and one occurrence would cost £150,000 to £600,000 in SLA credits, recovery and lost renewals. The annual loss then sits roughly between £15,000 (0.1 × £150,000) and £120,000 (0.2 × £600,000). Replace every figure with your own estimates; the resulting range is what you weigh against the cost of a control.

Where two options sit close, a spreadsheet simulation that samples the ranges thousands of times gives a fuller distribution. NIST IR 8286A Rev. 1 describes this Monte Carlo approach. It is optional; most first decisions are clear from the three cases.

### Step 5: Test which inputs move the answer

Change one input at a time and watch the result. If the annual loss barely moves when frequency doubles but jumps when the outage length changes, outage length is where better data pays off. NIST calls this sensitivity analysis, and recommends applying it to the input assumptions, not only the model.

### Step 6: Report the range and its assumptions

Write each result as a range with a sentence on what drives it and what would change it. Keep the scenario, the ranges, the sources and the date in one row of the risk register, so the next review starts from the last one.

A single number with no range hides how much you do not know.

## Which loss scenarios does a supplier to regulated customers face?

A tech supplier to regulated customers faces two kinds of loss: its own costs, such as recovery, response and lost revenue, and contract losses that flow from its customers, such as SLA credits, termination and lost renewals. The second kind is often larger, and it starts in documents you already have: your contracts and order forms.

NIST IR 8286A Rev. 1 lists "revenue losses from organizations that choose not to renew contracts" among the consequences to consider, and it is the one tech suppliers most often leave out. Build your scenarios around the losses in this table.

| Scenario | Loss components to estimate | Where the numbers come from |
| --- | --- | --- |
| Platform outage after ransomware or a failed change | Recovery effort, SLA credits, staff time, lost new sales | Uptime history, SLA schedules, incident logs |
| Customer data exposed through your service | Response and legal costs, notification support, customer claims up to the liability cap | Contract liability caps and indemnities, insurance wording |
| A customer incident that starts in your product | Investigation support, contract remedies, termination rights | Master services agreements, customer security schedules |
| Losing a key regulated customer after an incident | Lost annual recurring revenue, lost renewals, slower sales cycles | Revenue by customer, renewal dates, pipeline |
| Failing a customer's supplier assessment | Delayed or lost deals | Pipeline value of deals with security reviews |

Larger customers are checking their suppliers: the government's Cyber Security Breaches Survey 2025/2026 found 48% of large UK businesses and 30% of medium ones reviewed the cyber security risks posed by their immediate suppliers. The NCSC's [supply chain security guidance](https://www.ncsc.gov.uk/collection/supply-chain-security) warns that "a vulnerable supply chain can cause damage and disruption", and notes that securing your own supply chain may help you win new contracts.

## Where does UK base-rate data for cyber risk quantification come from?

UK base rates for cyber risk quantification come from three places: the government's Cyber Security Breaches Survey for how often UK businesses report breaches, your own incident, uptime and outage records for your actual history, and your insurer and broker for policy terms. Use survey data to anchor frequency, and your own contracts to anchor cost.

The [Cyber Security Breaches Survey 2025/2026](https://www.gov.uk/government/statistics/cyber-security-breaches-survey-20252026/cyber-security-breaches-survey-20252026), commissioned by DSIT and the Home Office and published on 30 April 2026, is the main UK source. It is a random probability telephone and online survey of 2,112 UK businesses, with fieldwork between August and December 2025. Its headline figures:

- 43% of UK businesses reported a cyber security breach or attack in the previous 12 months.
- Among medium businesses (50 to 249 employees), the figure was 65%.
- 47% of businesses had some form of cyber insurance, but only 10% held a specific cyber policy (24% of medium businesses).

Treat the survey's cost figures with care. It reports self-reported, perceived costs: the median cost of the most disruptive breach was £30 for medium and large businesses, and £10,000 at the 95th percentile. In its cyber crime cost findings, DSIT also cautions that high-cost incidents are rare, highly variable and hard to measure robustly in a survey of this size, so extreme costs are not always reflected in the headline statistics.

A survey median is a base rate, not your exposure.

That is why cost estimates for a tech supplier should come mainly from its own contracts, revenue and recovery history. The survey tells you how often firms of your size report a breach or attack; your contracts tell you what one would cost.

## How do you keep cyber risk quantification current?

Keep cyber risk quantification current by connecting it to the control and incident data you already collect for SOC 2 or ISO 27001. When a control weakens, an incident happens or a contract changes, update the matching range. Compare past estimates with what actually happened, so each review makes the next estimate more accurate.

An annual spreadsheet goes stale the week after the board sees it. The GRC Engineering approach treats the estimate as a living output of continuous control monitoring and risk intelligence. In practice, that means three connections:

1. **Control signals to frequency.** Link each scenario to the controls that reduce it, such as multi-factor authentication coverage, patch age, backup restore tests and change failures. When monitoring shows a control slipping, revisit that scenario's frequency range.
2. **Incidents and outages to both estimates.** Every incident, near miss and outage is a data point. Add it to the scenario it belongs to and check whether the ranges still hold.
3. **Contract and revenue changes to cost.** A new large customer, a tighter SLA or a higher liability cap changes cost. Review the cost ranges when commercial terms change, not only at the annual review.

NIST IR 8286A Rev. 1 calls the last discipline tracking actuals against forecasts, "common in finance but rarely applied in cybersecurity". It shows which estimates, and which estimators, run consistently high or low.

The evidence your SOC 2 or ISO 27001 programme already produces is the input. If you are working towards a first SOC 2 report, our [SOC 2 overview](https://www.grcmana.io/vault/soc-2) explains the controls that generate it.

## How should you present cyber risk quantification to a board or investors?

Present cyber risk quantification to a board or investors as a short set of scenario ranges in pounds, each with its main driver, the decision it supports and what would change it. Lead with the decision, not the method. Show uncertainty openly, because a range with stated assumptions earns more trust than a precise figure nobody can defend.

The NCSC's [Cyber Security Toolkit for Boards](https://www.ncsc.gov.uk/collection/board-toolkit/principle-a-risk-management/risk-management-for-cyber-security) frames the purpose: every organisation has to decide how much time and money to spend protecting its technology and services, and one of the main goals of cyber risk management is to "inform and improve these decisions". The toolkit also asks that cyber risk sit within the overall approach to risk, not be treated as a standalone IT topic.

The NCSC's basic risk method shows the format. Its example risk statement gives an 80% chance, "give or take 10%", of being targeted with ransomware by a criminal gang in the next 12 to 24 months, costing "around £1-2M per day" if successful. Likelihood, timescale and impact all carry their uncertainty.

For a tech firm's board pack or investor data room, we recommend one page:

- **The question.** For example: should we buy a second region, or raise the insurance limit?
- **Three to five scenarios.** Each with an annual loss range and a one-line driver.
- **The comparison.** Annual loss reduced against the cost of each option.
- **Confidence.** What the ranges rest on, and the data that would narrow them.
- **The ask.** The decision you need, by when.

Keep jargon out. [Research the NCSC commissioned](https://www.ncsc.gov.uk/blog-post/how-to-talk-to-board-members-about-cyber) with board members and security leaders found boards see "the excessive use of technical language and jargon as barriers to understanding".

## What are the common mistakes in cyber risk quantification?

The common mistakes in cyber risk quantification are false precision, single-point estimates, annualized loss expectancy used without ranges, inputs nobody can trace, and quantifying everything instead of the few risks that drive a decision. Each one makes the result look more certain or more complete than it is, which undermines the trust the exercise is meant to build.

1. **False precision.** "£347,250" implies knowledge you do not have. Round to the level your inputs support.
2. **Single-point estimates.** NIST IR 8286A Rev. 1 cites industry specialists who find a range of possible values more helpful, and likely more accurate, than a single point estimate. Keep the range in the register.
3. **Annualized loss expectancy without ranges.** Annualized loss expectancy is the total expected loss from a risk over a year, usually the cost of one loss multiplied by its yearly frequency. As a single figure, it hides the rare, severe year that matters most to a small firm. Report the range, and the high end on its own line.
4. **Untraceable inputs.** Every range needs a source: a log, a contract, a survey or a named estimator. If no one can say where a number came from, nobody can update it.
5. **Quantifying everything.** Start with the scenarios behind a live decision. A matrix handles the rest.

Garbage in, garbage out still applies; calibrated ranges just make the garbage visible.

## Frequently asked questions

### Do I need a platform for cyber risk quantification?

No. A spreadsheet with three to five scenarios, three-point ranges and clear sources is enough for most firms with 25 to 150 staff. Dedicated tools help when you run many scenarios or need simulation at scale. Start with the decision you face, and add tooling only if the spreadsheet becomes the bottleneck.

### How long does a first cyber risk quantification take?

We suggest planning a first pass for three to five scenarios around a week of data gathering and one estimation workshop. The time depends mostly on how easily you can pull incident, uptime and contract data. Later reviews are faster, because each one starts from the previous ranges and the data collected since.

### Who should estimate the ranges?

The people closest to the evidence: engineering for outage length and recovery effort, finance for revenue and contract exposure, and the security lead for frequency. NIST IR 8286A Rev. 1 recommends polling several people and averaging their estimates to reduce individual bias.

### Is annualized loss expectancy the same as cyber risk quantification?

No. Annualized loss expectancy is one output: the expected loss from a risk over a year. Cyber risk quantification is the wider practice of estimating frequency and cost as ranges, testing assumptions and reporting the result for a decision. A single annualized figure without its range loses most of the value.

### How often should the estimates be updated?

Review the ranges at least at each risk assessment cycle, and also when a monitored control weakens, an incident occurs or a major contract changes. Linking scenarios to control and incident data means most updates are small adjustments, not a fresh exercise.