Cyber risk quantification: a practical method for B2B tech firms

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 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 or a SOC 2 risk assessment already runs. For ISO 27001, ISO/IEC 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, the US guide to conducting risk assessments, sets out the three approaches:

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 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, 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.

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.

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 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, 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 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 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 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