How to quantify cyber risk when you have no loss history

The standard objection to quantitative cyber risk analysis is that you cannot calculate a loss expectancy without loss data, and most organisations have never had a material incident.

The objection misunderstands what quantification is for. You are not calculating a known quantity. You are stating your uncertainty in a form that can be reasoned about, compared against the cost of controls, and revised as evidence arrives.

A heat map does the same thing, badly. "High" encodes an estimate too, but one that cannot be aggregated, cannot be compared to a budget line, and cannot be shown to be wrong.

Why heat maps fail at the board table#

Three specific problems.

Everything converges on amber. Risk owners avoid red because it invites scrutiny, and avoid green because it looks complacent. After two cycles, the register is a wall of medium and prioritisation is impossible.

Colours do not aggregate. Twelve medium risks in the same business process may represent more exposure than one high risk elsewhere. There is no arithmetic that tells you.

No comparison to cost. A board decides between a ₹4 crore control investment and other uses of that capital. "This reduces a high risk to medium" is not decision-useful. "This reduces annualised expected loss from ₹11–34 crore to ₹3–9 crore" is.

The method, in short#

We use a FAIR-aligned decomposition. For each risk scenario:

Loss Event Frequency — how often the event occurs per year. Decomposed where useful into threat event frequency and vulnerability (the proportion of attempts that succeed).

Loss Magnitude — what it costs when it happens. Decomposed into primary loss (response, replacement, productivity, revenue) and secondary loss (regulatory penalty, litigation, customer churn, brand impact).

Both are estimated as distributions, not points. A typical scenario input looks like:

Scenario: Ransomware encrypts the manufacturing execution system,
          halting production at one plant
 
Loss Event Frequency
  min 0.05  most likely 0.15  max 0.4    events/year
 
Primary Loss Magnitude
  min ₹6 cr   most likely ₹14 cr   max ₹38 cr
 
Secondary Loss Magnitude
  min ₹0.5 cr  most likely ₹3 cr    max ₹22 cr

Monte Carlo simulation over those distributions produces an annualised loss exposure curve. The output is not a number — it is a statement like "90% confidence that annualised exposure is between ₹1.1 crore and ₹9.4 crore, with a 5% chance of exceeding ₹12 crore in any single year."

That last clause is often what actually moves a board, because tail risk is what keeps directors awake.

Calibrating the estimators#

The inputs come from your own experts, and untrained experts are systematically overconfident. Calibration training fixes most of this in about ninety minutes.

The technique is simple: ask a series of trivia questions with numeric answers and require a 90% confidence interval for each. How long is the Ganges in kilometres? What was Infosys's revenue in FY2020?

A well-calibrated estimator gets about 90% of true values inside their stated intervals. Most people, untrained, land around 40–50% — they state intervals far too narrow. After a round of feedback, most improve substantially.

Where to anchor when internal data is absent#

Estimates should not be free-floating. Useful anchors, roughly in order of reliability:

1. Your own operational data. Not breach history, but adjacent frequencies — phishing click rates from your own simulations, malware detections per month, failed authentication volumes, the number of times a critical system has been unavailable for any reason.
2. Your own cost structure. Revenue per hour by business line, cost per hour of a plant stoppage, the day rate of an incident response retainer, notification cost per affected individual. These are knowable and rarely looked up.
3. Published sector data. Breach cost studies, ransomware payment surveys, regulator enforcement records. Use for order-of-magnitude sanity checking, not as a substitute for your own numbers — sector averages hide enormous variance.
4. Regulatory penalty ceilings. DPDPA's ₹250 crore maximum for security failures and GDPR's 4% of global turnover are upper bounds on one component of secondary loss, useful for tail modelling.

The failure modes#

Four things go wrong repeatedly.

Scenarios that are not events. "Insufficient patching" is a control weakness, not a loss scenario. It cannot have a frequency or a magnitude. Rewrite as an event with a cause and a consequence: "an internet-facing application is exploited via an unpatched vulnerability, resulting in customer data exfiltration."

Double counting. Two scenarios that both include the same regulatory penalty inflate total exposure. Decompose carefully and check for overlap before aggregating.

Precision theatre. Reporting an exposure of ₹4.37 crore implies accuracy the inputs do not support. Round aggressively and always present ranges.

Abandoning it after one cycle. Quantification earns credibility over time, as estimates are revisited and refined against what actually happened. One cycle produces a number; four cycles produce a capability.

The test that matters#

The measure of whether risk quantification is working is not whether the register looks sophisticated. It is whether, within one quarter, it has caused an investment decision to change.

If a scenario's quantified exposure caused a project to be funded that would not have been, or a proposed control to be rejected because the exposure it addressed was smaller than its cost, the register is doing its job.

If nothing changed, the register is decoration — and expensive decoration, because it consumed senior attention that produced no decision.

A worked example, end to end#

Take the manufacturing scenario from earlier and follow it to a decision.

The scenario. Ransomware encrypts the manufacturing execution system, halting production at one plant.

Frequency. The plant has had two malware events reaching the enterprise network in four years, neither reaching OT. Segmentation is partial. Calibrated estimate: 0.05 to 0.4 events per year, most likely 0.15.

Primary loss. Contribution margin is ₹1.9 crore per production day. Recovery from backup was tested at four days, but the untested dependency chain suggests six to eight is realistic. Response costs — incident response retainer, forensics, overtime — run ₹1.2 to ₹2.5 crore. Range: ₹6 to ₹38 crore, most likely ₹14 crore.

Secondary loss. Two OEM customers hold contractual delivery penalties. One has an audit right that would likely be exercised. Range: ₹0.5 to ₹22 crore, most likely ₹3 crore.

Simulated output. Annualised loss exposure of ₹1.1 to ₹9.4 crore at 90% confidence, with a 5% chance of exceeding ₹12 crore in any single year.

The decision. Two proposals were on the table. Full OT segmentation across nine plants at ₹8.4 crore, and a targeted programme — segmentation at the three highest-margin plants plus validated recovery across all nine — at ₹3.1 crore.

Modelling the targeted option reduced exposure to ₹0.4 to ₹3.2 crore. Risk reduction per rupee was roughly 2.4 times better than the full programme, because most of the exposure sat in three plants and most of the recovery benefit was estate-wide and cheap.

The board funded the targeted option. Without quantification the choice would have been made on the strength of the presentation, and the more expensive proposal was the better presentation.

How to present it without losing the room#

Four rules, learned by getting them wrong.

Lead with the decision, not the method. Directors do not want the FAIR decomposition. Open with "we recommend ₹3.1 crore, here is the exposure it removes" and keep the method in an appendix for the one director who asks.

Show the range, never a point. A single number invites an argument about that number. A range with stated confidence invites an argument about the decision, which is the conversation you want.

Put the tail on the slide. The 5% chance of exceeding ₹12 crore does more work with a board than the central estimate, because directors are accountable for the scenario that ends up in a newspaper.

Name what you are not doing. Every quantified register implies risks you have chosen to accept. Say which ones and why, in writing. A board that discovers an accepted risk after an incident asks different questions than a board that approved the acceptance.

Expect one objection from finance, and welcome it: that the inputs are subjective. They are, and the honest answer is that the alternative was also subjective but concealed it behind a colour. A range with a stated method and named estimators can be challenged, refined and audited. "High" cannot be challenged because it makes no claim precise enough to be wrong. Invite the CFO's team to review the frequency assumptions directly. Finance involvement tends to improve them, and it converts the register from a security artefact into a business one, which is where its authority comes from.

Our Enterprise Risk Management practice builds these programmes, and our Enterprise Trust Risk Register ships with 46 pre-written scenarios and the quantification model already built.