Cyber accumulation management program: the KPIs a board should see

A cyber accumulation management program is the standing set of tolerances, data, scenarios, decisions and reports by which an insurer keeps the limit riding on any one shared cause (a cloud region, an identity provider, a payroll platform, a widely used security product) within what its board has agreed to bear. New York's DFS, the UK's Prudential Regulation Authority and the EU's EIOPA all expect one, in writing, owned by the board. None of them says what the numbers should be. That leaves each insurer to choose its own measures, and the choice decides whether the board sees a list of exposures or a book under control. Botminds' Cyber Accumulation Management is an agentic solution that keeps those measures current: agents map which insureds depend on which vendor with evidence, read the policies and estimate loss, and the head of cyber declares events and signs what goes to reinsurers.

The values below come from a fictional sample book run through the solution: Thistlebrook Specialty, 2,846 insureds, $2.93 billion of aggregate cyber limit and 11 shared vendors, with a board tolerance of $300 million per vendor. Every company and person in it is invented; figures marked as targets are design goals, not results.

What is a cyber accumulation management program?

It is the part of cyber risk management that deals with one cause hitting many insureds at once, as opposed to the risk of each insured on its own. Its parts are simple to name: a tolerance per shared cause, data that says which insureds depend on each cause, scenarios at several outage lengths and both causes (system failure and attack), named people who declare events and sign estimates, and reinsurance bought against the result. What makes it a program rather than a model run is that the parts are kept current between events and used during them.

The reason to manage it separately is that ordinary portfolio controls do not see it. A book can be spread across ten sectors and forty states and still put a third of its limit on one cloud provider. The tools insurers already use are partial answers. "Low limits and sublimits for cyber policies are used as a means to avoid significant individual company losses and to manage accumulation risk," CISA observed in its 2018 assessment of the cyber insurance market (CISA, Assessment of the Cyber Insurance Market, December 2018). Limits cap each loss; they do not tell you how many will arrive together.

What do regulators expect for cyber accumulation?

They expect a board-owned strategy with quantitative limits, regular measurement against them, stress tests that include accumulation through shared technology, and reinsurance that reflects the result. New York put it most directly: its 2021 framework asks for a formal cyber risk strategy approved by senior management and the board, with qualitative and quantitative goals, and says "progress against those goals should be reported to senior management and the board, or the governing body if there is no board, on a regular basis" (NYDFS Insurance Circular Letter No. 2, 2021).

Supervisors watch the same measures across the market. In the IAIS's 2022 monitoring exercise, 58% of responding jurisdictions said they periodically assess total accumulation on affirmative cyber cover, 42% on non-affirmative cover, and 32% ran an insurance stress test with a cyber scenario (IAIS GIMAR cyber special topic, April 2023). An insurer that can produce those numbers on request is ahead of the question. How the same New York framework reads as day-to-day underwriting checks is set out in NYDFS cyber insurance requirements.

What KPIs measure cyber accumulation?

Four families, each answering a question the board will ask. Exposure measures say how much limit rides on each shared cause against tolerance. Evidence measures say how much of that figure is known rather than assumed. Speed measures say how quickly a defensible estimate exists after a vendor fails. Protection measures say where the reinsurance responds and what is kept net. The tree above shows ten of them with the sample book's values.

Three deserve emphasis because they are rarely reported. The share of exposed policies with no system-failure cover (63 of 418 on the sample's largest vendor) tells the board how much of the exposure disappears if an outage is non-malicious, and how much returns if it turns out to be an attack. The share of dependencies known only through a provider (51 of 418) is the part most likely to be missed, and the first thing a stress test should vary. And the comparison of first estimate with incurred, on every closed event, is the only measure that tells the board whether the others can be trusted; replaying a real outage on your book is how to start it.

What is a cyber risk tolerance per vendor?

It is the most limit the board is willing to have depending on one shared vendor (or one vendor region), whatever the sector mix. It is usually set against capital and the event cover: large enough to write the business, small enough that a long outage at that vendor stays within what the reinsurance and the balance sheet can absorb. It needs three companions: a watch threshold below it, a rule for new business on a vendor already over it, and a named person who can approve exceptions.

Notice what the ranking does not follow. The email platform has the most dependent insureds (806) but sits below the cloud vendor, because its insureds are smaller. The identity provider is near tolerance with no event in sight. A tolerance measured in insured counts would rank them differently, which is why the measure should be limit, with sublimits alongside, and why the ranking should be redrawn whenever a scan or renewal changes a dependency. In the solution, every vendor carries a 12-month trend, and the rule for new business on a vendor over tolerance (refer, allow with a note, or decline) is a setting the board can see.

Shared vendors, limit against tolerance and the 12-month trend

How often should cyber accumulation be reported?

Continuously to the head of cyber, at least quarterly to the board, and at once when an event is declared. The PRA's text sets the floor for the board: the strategy and non-affirmative exposure "should be reviewed by the board at least on an annual basis. For affirmative cyber risk the review should be more regular" (PRA SS4/17, 3.3). For a book that writes affirmative cyber, that points to a quarterly pack with the vendor ranking, the evidence measures and one or two scenarios, and an event note whenever an event is declared.

The event note is the report that tests the program. It should reach the chief underwriting officer and the reinsurers within hours, with every number cited and every estimate labelled. In the sample, it went 3.5 hours after the vendor's first notice and gave the estimate at 12, 24 and 48 hours, gross and net, with the outage length at which the event cover attaches.

How should a board oversee cyber aggregation?

By owning four decisions and asking for four pieces of evidence. The decisions: the tolerance per shared cause, the rule for new business above it, who may declare an event, and the reinsurance bought against the result. The evidence: the vendor ranking against tolerance, how much of it rests on dated evidence, the scenario results with their assumptions, and how past first estimates compared with incurred.

The board should also be told plainly what the controls cannot do. The BIS's Financial Stability Institute and the IAIS put it bluntly in 2026: "To manage accumulation risk, insurers typically rely on scenario-based stress testing, exposure caps, sub-limits, exclusions, coinsurance and tight policy wording as imperfect accumulation controls" (FSI Insights No 75). And the PRA's 2022 stress test found that UK general insurers "continue to be materially dependent on the global reinsurance market to mitigate the financial impact of gross losses" (PRA IST 2022 feedback). A program whose reports never mention the reinsurance or the limits of its own controls is reporting half the picture.

The board’s rules as settings: tolerance, assumptions, reinsurance and who decides

What does a cyber accumulation program cost, and what does it protect?

The cost is mostly people's time and data, and the honest way to price it is per event and per quarter on your own book. No public source gives a benchmark; the method is to count the hours your desk spends producing a first exposure figure after a vendor event, multiply by the events you take seriously in a year, and add the quarterly pack. By our estimate, a hand-built first figure for one shared-vendor outage takes about 72 working hours across the desk, most of it searching for dependent insureds; with the solution we estimate about 2.6 hours, mostly reading the broker emails and the note before they go.

What it protects is easier to see in the reinsurance. In the sample, the event cover is $20 million excess of $10 million on the net after a 30% quota share, so it attaches at $14.3 million gross, about 14.5 hours into the outage. Knowing that number before the event lets the buyer decide whether the attachment is where the board wants it, and knowing it within the hour after an event lets the head of cyber tell the reinsurer before the reinsurer asks. A program that can show its tolerance, its evidence and its estimates is also easier to explain to the reinsurers at renewal.

Buying software for the program: what to look for

Look for software that keeps the dependency map between events, ties every dependency to evidence, reads the policy terms that decide loss, and leaves the declaration and the signature with people. Be wary of anything that reports total limit as loss, hides how a dependency was found, or sends to brokers and reinsurers on its own.

On the last point, Cyber Accumulation Management is a fit where the gap is the named list and the event-day estimate. It does not replace a probabilistic catastrophe model for capital and return periods, and it does not set reserves; it feeds the first and informs the second. How it sits beside an existing model is covered in cyber aggregation tools beside your cat model.

Questions people ask

Do regulators require a cyber accumulation program?

They require its parts. New York's DFS expects a board-approved cyber strategy, systemic-risk evaluation and stress tests; the PRA expects risk appetite with aggregate limits and board reporting on aggregate exposure; EIOPA expects key indicators and reinsurance against accumulation. None prescribes the numbers.

What is the difference between cyber accumulation and cyber aggregation?

In practice the terms are used interchangeably for many losses from one cause. Some insurers keep aggregation for the arithmetic of adding exposures up and accumulation for the risk that they arrive together; what matters is that the board sees limit per shared cause, not just per insured.

How do you set a per-vendor limit tolerance?

Start from the loss you can absorb net of reinsurance in a long outage, then work back through waiting periods and sublimits to the limit that loss implies. Add a watch level below it and a rule for new business above it. In the sample book the tolerance is $300 million with a watch list at 90%.

Should provider-only dependencies count toward the tolerance?

Usually yes, labelled separately. Insureds that depend on a vendor through a managed-IT or software provider are exposed in the same outage, but the evidence is weaker; counting them, flagged, avoids the most common miss. In the sample book it is a setting, switched on.

How often should a board see cyber accumulation?

The PRA's floor is at least annually for non-affirmative exposure and more often for affirmative cyber. A quarterly pack plus an event note for every declared event fits a book that writes standalone cyber.

What is the single most useful KPI?

Limit on the largest shared vendor against tolerance, because it is the number a board can act on. It is only as good as the evidence behind it, so report the share of that limit resting on dated evidence beside it.