How Many Cyber Risk Scenarios Should You Model?

Scenario libraries grow. A program starts with ransomware and a data breach, adds a third-party failure after a supplier incident, splits ransomware into encryption and extortion variants, adds a cloud outage, and two years later holds forty entries nobody has revisited.

‍

The usual guidance suggests a range, somewhere between five and fifteen, which is a reasonable starting point and answers the wrong question. The number falls out of what the library has to support rather than being chosen in advance.

‍

The Test Is Whether the Figure Would Change a Decision

‍

Before adding a scenario, name the decision its output would inform. Retention setting, a budget allocation, a control investment, a limit at renewal, a board threshold. Where no decision depends on it, the entry is documentation rather than modeling.

‍

Applied without flinching this removes more entries than it adds. Several scenarios in a typical library exist because somebody wanted the coverage to look complete, and their figures have never been consulted by anyone making a choice.

‍

Coverage Is Not the Objective

‍

A library is not attempting to enumerate everything that could happen, which is unbounded. It is attempting to describe enough of the loss distribution that decisions about it are sound. Those are different targets, and pursuing the first produces a maintenance burden that eventually stops the second from happening at all.

‍

Split Where Controls Differ, Not Where Threats Differ

‍

The most useful granularity rule comes from what the model is for. Two threats mitigated by the same controls, producing the same business consequence, belong in one scenario regardless of how different they look in a threat briefing.

‍

Ransomware and destructive malware often qualify. If both are addressed by the same backup regime, the same segmentation and the same recovery capability, and both manifest as an operational outage of comparable duration, modeling them separately doubles the maintenance and produces no information anyone acts on.

‍

The Reverse Also Holds

‍

One threat warrants several scenarios where controls or consequences genuinely differ across the organization. A ransomware event in a corporate environment and the same event in a production environment have different recovery paths, different durations and different costs, and combining them averages away the distinction a decision depends on. Environments with distinct operating units are where that split matters most.

‍

Avoid Variant-Level Detail

‍

Modeling a named malware family or a specific technique produces a library that ages badly and requires threat intelligence updates to stay current. Functional description at the level of what happens to the business survives changes in attacker tooling, which is most of the point of modeling rather than tracking.

‍

The Maintenance Cost Nobody Prices

‍

Every scenario carries a recurring obligation. Assumptions need periodic review, asset values move, dependencies change, and somebody has to own each entry. A library of forty scenarios reviewed annually is forty review events that compete with everything else a risk function does.

‍

Programs add without subtracting because adding requires a reason and removing requires permission. Setting a working ceiling, and treating a new addition as a swap rather than an increment once that ceiling is reached, forces the comparison that keeps the library useful.

‍

Stale Scenarios Are Worse Than Missing Ones

‍

An entry carrying assumptions from two years ago produces a figure that looks current and is not, and it will be read alongside recently reviewed entries as though both are equally reliable. Recording the last review date against every scenario and reporting the proportion reviewed within the period is a cheap control on this, and a register built for decisions needs the dates anyway.

‍

When to Add One

‍

Four triggers justify an addition, and each names a change in the world rather than a wish for completeness.

‍

• A New Dependency: An acquisition, a new critical supplier or a platform migration creates exposure the existing set does not describe.
• A Peer Event: An incident elsewhere reveals a pathway the library assumed away rather than considered and rejected.
• A Named Obligation: A regulator or an insurer asks about a specific scenario type, which makes it a required entry regardless of its modeled size.

‍

A material change in an existing entry completes the set, where a dependency grew enough that the original scenario no longer describes it and splitting is more honest than adjusting. Bringing real events into the register is a discipline in itself, and working from documented incidents keeps additions grounded in something that happened.

‍

When to Retire One

‍

Retirement is the neglected half and it needs criteria as explicit as addition.

‍

The underlying asset or dependency no longer exists, which is the easy case and still requires somebody to notice. The decision the scenario informed has been settled, so a scenario built to size a specific limit has done its work once the limit is set and can move to periodic rather than active review. Or the entry has ranked so far down every prioritization for several cycles that its figure has never influenced anything, which is the uncomfortable case and the most common.

‍

Retire, Do Not Delete

‍

Keeping retired scenarios with their final figures and a reason preserves the history, so a later question about why something was dropped has an answer. It also prevents the same scenario being reintroduced by someone who does not know it was considered.

‍

What a Working Library Looks Like

‍

Most organizations converge on a small core with a longer supporting tail rather than a flat list.

‍

A handful of scenarios carry the majority of modeled exposure and receive genuine attention, including assumption review each cycle and named owners. A second tier exists for completeness against obligations and gets lighter treatment. Everything else is either retired or was never worth creating. Reporting which tier each entry sits in, rather than presenting a uniform list, prevents the common failure where a board sees forty entries and assumes forty are equally maintained.

‍

Rank by Figure, Not by Category

‍

A library grouped by threat type invites the reading that each group deserves equal attention. Ranking by modeled loss produces a sequence and usually reveals that the top three or four entries account for most of the exposure, which is the finding that determines where review effort should go. Concentration of that kind also appears at portfolio level, where shared dependencies pull several scenarios toward one event. Scenario-based modeling earns its value from that concentration rather than from breadth.

‍

Size the Library to the Decisions

‍

The question is not how many scenarios are enough but which decisions the library has to support, and the count follows. Splitting where controls and consequences differ rather than where threats differ keeps granularity useful, treating additions as swaps once a working ceiling is reached prevents accumulation, and explicit retirement criteria keep stale entries from being read as current. Kovrr's cyber risk quantification provides a maintained scenario library alongside custom entries, which lowers the cost of the additions worth making.

‍

To see which scenarios carry the majority of your modeled exposure, book a demo with our cyber risk experts.