The Risk Register Line That Should Be a Range
Most risk registers carry a single expected-loss figure per scenario. That number is almost always wrong, and it hides the part of the risk that matters most.
Open almost any enterprise risk register and you will find a column labelled something close to “expected annual loss,” populated with one dollar figure per row. Suppose a ransomware row reads $2.4M. In practice that figure gets treated as a fact. It is not a fact. It is the midpoint of a distribution that nobody drew.
The arithmetic behind that number is older than most of the people using it. Annual Loss Expectancy, ALE = ARO x SLE, comes out of classical information security risk management, the NIST SP 800-30 lineage and the CISSP curriculum, and it predates modern quantitative cyber risk management methodology by years. Annual Rate of Occurrence times Single Loss Expectancy. Frequency times severity. As arithmetic it is fine.
The problem is the inputs. ARO and SLE are each uncertain, often by an order of magnitude, and multiplying two point estimates carries none of that uncertainty forward. A quantitative cyber risk management methodology adds no new equation here. It maps ARO to Loss Event Frequency and SLE to Loss Magnitude, and it insists that both be expressed as probability distributions rather than single values. The output is a range, conventionally reported at the 10th, 50th, and 90th percentile, plus everything past the 90th.
The tail is the point
That last part is what the single number erases. A scenario with a modest median can still have a 90th-percentile outcome several times larger. If you are sizing a cyber insurance tower, or deciding whether a control investment clears its hurdle rate, the 90th-percentile figure is the one that should drive the conversation, and it is invisible on a register that shows only the median.
Two errors that make it worse
Analysts hand-building these estimates tend to make two mistakes. The first is confusing Threat Event Frequency with Loss Event Frequency. TEF is how often a threat acts against the asset. LEF is how often that action actually produces a loss. The conversion factor between them is Vulnerability, the probability that a given attempt succeeds. A high TEF with a low Vulnerability yields a low LEF. Treating “we are attacked constantly” as “we lose constantly” inflates the frequency side of every scenario in the book.
The second is treating published breach-cost averages as the severity input. IBM’s Cost of a Data Breach figures are mean values across roughly 600 organizations. They are a reasonable anchor for the 50th percentile of Loss Magnitude, and only that. A defensible quick calibration places the published average at the median and applies roughly plus or minus 50 percent for the 10th and 90th percentile bounds using a PERT estimate, unless better organization-specific data exists. Dropping the average straight into the register as “the cost” repeats the original error at the severity end.
What quantification is actually for
The reason to quantify a risk is not to swap a qualitative label for a number that looks more precise. It is to produce a distribution you can reason about: how bad the typical year is, how bad a bad year is, and how much a proposed control moves each. A register row that reads “$2.4M” answers none of those questions. A row that reads “median $2.4M, 90th percentile several times higher, driven mostly by regulatory and third-party liability” answers all three.
The single number is comfortable because it fits in a cell and does not invite argument. That is exactly the problem. The uncomfortable range is the one that helps you decide.