FAIR Without the Folklore

The most common objection to cyber risk quantification is some version of “we don't have the data.” It sounds like a statement about data. It is almost always a statement about method — specifically, an assumption that quantification means producing a precise number from historical frequencies you do not possess.

That is not what FAIR asks for. Factor Analysis of Information Risk is, before it is anything else, an ontology: a structured way of taking the phrase “cyber risk” apart into components small enough that a knowledgeable person can reason about each one. The Monte Carlo simulation that usually gets the attention is the last step, and the least interesting.

The decomposition is the deliverable

FAIR splits risk into two branches. How often does a loss event happen, and how bad is it when it does. Everything else is a refinement of one of those two questions.

Loss Event Frequency decomposes further into how often a threat actor attempts to act against the asset (threat event frequency) and how often such an attempt succeeds against the controls in place (vulnerability, in FAIR's specific sense — a probability, not a CVE).

Loss Magnitude splits into primary loss — what you spend responding, in the form of investigation, remediation, replacement, downtime — and secondary loss, which is what happens when other parties react: regulatory action, litigation, customer attrition, contractual penalties, the cost of credit monitoring.

Decomposing this way does something a severity rating cannot. It makes the argument inspectable. When a scenario estimate looks wrong to someone, they can point at the specific factor they disagree with, propose a different figure, and see what it changes. The conversation becomes about the disagreement rather than about whether the whole exercise is legitimate.

A heat map produces a verdict. A decomposed model produces an argument — and arguments can be improved by the people who disagree with them.

Calibrated ranges, not point estimates

Ask a security engineer how much a ransomware event would cost and you will get a shrug, because the honest answer spans an order of magnitude and a single number would be a lie. Ask the same person for a range they are 90% confident contains the true value, and you will get an answer — usually a considered one.

That reframing is the core estimation technique, and it comes with a testable skill. Calibration training — answering trivia questions with 90% confidence intervals and scoring how often the truth falls inside them — reliably improves estimates, because most people are systematically overconfident and can be corrected once they see it measured. An estimator who lands inside their own intervals about nine times in ten is producing inputs you can defend.

Wide is not the same as useless

Teams new to this get nervous when a range comes out wide. ₹2 crore to ₹40 crore feels like an admission of ignorance. It is the opposite: it is an honest statement of what is known, and it is still decision-relevant.

A range that wide tells you the scenario can plausibly consume a meaningful fraction of annual profit. That is enough to justify attention. And the width itself is information — it points at which factor is driving the uncertainty, which tells you what to go and find out. Narrowing a range is a research task with a clear target, which is a far better position than a red square that gives you nowhere to go.

What the simulation actually adds

Once each factor is a distribution rather than a number, you cannot combine them by hand — multiplying two ranges does not give you the range of the product in any way that respects how likely each combination is. A Monte Carlo simulation samples each distribution thousands of times and builds up the distribution of outcomes.

What comes out is a loss exceedance curve: for any loss amount, the probability of exceeding it in a year. This answers questions a single number cannot. What is the chance of a year worse than ₹50 crore? What loss should we plan for at the 95th percentile? Where does our insurance retention sit on this curve? Is the tail thick enough to justify treating this scenario differently from its average?

That last question is where quantification earns its keep. Two scenarios with identical expected loss can carry completely different tails, and a heat map will place them in the same cell. Only one of them can end the company.

Five ways loss estimates get discredited

In practice, models fail review for a small number of recurring reasons — and none of them are about the mathematics.

Scope drift

The scenario starts as “ransomware encrypts the ERP production environment” and, three workshops later, has quietly absorbed data exfiltration, regulatory penalties and reputational damage. Every participant is now estimating a slightly different event. Write the scenario as one sentence naming the asset, the threat actor and the effect, put it at the top of every worksheet, and refuse contributions that do not fit it.

Anchoring on the worst case

Someone in the room read about a global manufacturer losing hundreds of millions to a wiper campaign, and that figure becomes the gravitational centre of the discussion. The correct question is not what the worst recorded outcome was, but what the plausible range is for this organisation, with these controls, at this scale. Ask for the low end first — it disrupts the anchor.

Double-counting secondary loss

Regulatory penalty gets estimated by the compliance lead. Legal defence cost gets estimated by counsel. Both quietly include the same external law firm. Customer attrition gets estimated twice, once as lost revenue and once as reputational damage. Secondary loss is where the overlaps hide; list the categories explicitly and have one person reconcile them.

Uncalibrated estimators

The subject matter expert who has never been scored on an interval will give you intervals that are too narrow, consistently. Half a day of calibration training before the first workshop changes the quality of every input that follows. Skipping it is the single highest-leverage mistake.

Precision theatre

A model that reports an annualised loss expectancy of ₹17,43,281 invites the reader to ask where the last four digits came from, and there is no good answer. Report to the precision the inputs support — two significant figures is usually generous — and lead with the range, not the mean.

How to review a model you did not build

Reviewers tend to check the maths, which is almost always fine, and skip the decomposition, which is where the problems live. A better sequence:

1. Read the scenario statement. Can you tell exactly which event is being modelled? If it needs a paragraph, it is more than one scenario.
2. Check frequency against reality. Does the implied number of events per decade match what this organisation and its peers have actually experienced? Implied frequencies that would mean an event every eight months usually do not survive this question.
3. Look for the missing loss category. Contract penalties, regulatory notification cost, and the cost of the response itself are the three most commonly omitted.
4. Ask who estimated each factor and whether they were calibrated. Named estimators concentrate the mind.
5. Test sensitivity. Move the most uncertain factor across its range. If the conclusion flips, the model has told you what to research next rather than what to decide today.

Where to start

Do not attempt to quantify the register. Pick the three scenarios that keep the executive team up at night, model those properly, and let the method prove itself on questions people already care about. A single well-built scenario that changes a funding decision does more for adoption than forty scenarios delivered as a dashboard.

If you want to see the shape of the output before committing to a programme, our lightweight quantification tool walks through a FAIR-structured estimate in about five minutes and returns a report you can react to.