Skip to content
Service

Risk Management & Quantitative Risk Analysis

Cyber risk expressed in dollars and probabilities, so the board can make investment decisions, not read a heat map.

A loss exceedance curve: for any annual loss on the horizontal axis, the curve gives the probability of exceeding it. The dashed line is the board's stated tolerance, and the marked point is where modelled exposure crosses it. A heat map cannot draw this, which is why it cannot tell you whether a control is worth buying.

Most cyber risk registers score likelihood and impact on a one-to-five scale, multiply the two, and colour the result. The arithmetic does not hold. Ordinal scores are ordered labels, not quantities, so multiplying them produces a number with no defined meaning, and a risk with a plausible loss of $300,000 lands in the same band as one that could cost $30 million. The distinction that matters most to the business is destroyed at the point of data entry.

Quantification replaces that with two honest statements per scenario: how often you expect the event, and how much it would cost if it happened, expressed as a range you are 90% confident in. Those estimates come from your own people, calibrated against published base rates, then run through a Monte Carlo simulation. The output is not a single number pretending to be certain. It is a distribution, usually with a long tail, and the tail is the part the heat map was hiding.

What that buys you is the ability to price a control. If a proposed programme reduces expected annual loss by less than it costs, that is worth knowing before the money is committed, not after. The method is not a crystal ball and it will not make an uncertain future certain. It makes your uncertainty explicit, auditable, and comparable against every other investment the business is weighing.

You might need this if

  • The board asks whether you are spending the right amount on security, and the honest answer is a colour
  • Two risks sit in the same amber cell and nobody can say which to fund first
  • A security business case keeps getting deferred because it cannot be compared to other capital requests
  • The register is scored once a year and never checked against what actually happened

Who it's for

Boards, CISOs, and heads of risk who need to defend a security budget and prioritise spend on evidence.

How the engagement runs

  1. 01

    Scope and scenario selection

    We pick a small number of scenarios that actually matter rather than trying to model the whole register. Ten well-modelled rows beat three hundred scored ones.

  2. 02

    Calibration

    A working session with the people who will supply the estimates, scoring them against known answers until their 90% intervals genuinely contain the answer 90% of the time. Almost everyone starts overconfident, and it is trainable.

  3. 03

    Elicitation and modelling

    Frequency and loss-magnitude estimates for each scenario, anchored on published base rates and your own incident history, then simulated to produce a loss exceedance curve.

  4. 04

    Decision support and handover

    Return-on-control analysis for the proposed mitigations, a board-ready view against your stated risk tolerance, and the model itself handed over so your team can rerun it.

What's delivered

  • FAIR-based loss quantification for your top risk scenarios
  • Monte Carlo simulation of loss exposure with stated confidence ranges
  • Scenario modelling that connects controls to reduced expected loss
  • Risk-to-investment translation the board can act on
  • A repeatable method your team can run after the engagement ends

Proof point

Quantitative risk modelling built into Antan IRM, the risk-management platform I built and use, which began life as a spreadsheet replacement.

Common questions

We don't have enough data for this.
You have less than an actuary would like and more than you think. Base rates are published, and your ticket, incident and downtime data already exist. Note the asymmetry too: the ordinal score was produced from the same evidence, then processed with worse mathematics. Sparse data is an argument for Bayesian updating, not for abandoning quantities.
Isn't this false precision?
Precision and accuracy are different things. A 90% interval spanning two orders of magnitude is an explicit statement of how much you do not know. "Impact: high" is an implicit one, and it cannot be audited, aggregated, or proved wrong.
Do we have to buy a platform?
No. The core method runs in a spreadsheet, and I will show you how. I built Antan IRM because I wanted the workflow around it, not because the maths requires it.
Our auditor expects a heat map.
Then render one from the model. Deriving a matrix from a quantitative result is trivial. The error is using the matrix as the model in the first place.
Get in touch

Let's talk about your security programme

Considering a vCISO, a security strategy and architecture, a SOC uplift, an AI assurance review, or a secure web build? Tell me where you are and where you need to get to.