The Board Scenario Test for Incident Response Severity Risk
On this page
- Why Boards Need a Dedicated Scenario for Incident Response Severity Risk
- What specific scenario should the board ask to see run on this driver?
- Is this scenario different from a standard cyber catastrophe stress test?
- What should the board expect management to already know before this scenario is run?
- How often should this scenario be refreshed?
- What risk appetite question does this scenario actually answer?
- Should this scenario be shared with rating agencies or regulators?
- What governance failure does skipping this scenario create?
- What should the board ask for immediately after seeing this scenario?
- Should this scenario be shared with retrocession partners?
- What role does management incentive design play in sustaining this oversight?
- Should this scenario change depending on whether the cyber market is hardening or softening?
- Who should present this scenario to the board, and how often should the presenter rotate?
- Sources
- Frequently Asked Questions
Why Boards Need a Dedicated Scenario for Incident Response Severity Risk
Most board-level cyber risk reporting still centers on a single large catastrophic scenario. That leaves a quieter, more probable scenario unexamined: response-capability-driven severity accumulating across many separate, ordinary-looking claims.
What specific scenario should the board ask to see run on this driver?
A stress test showing what happens if response-capability-driven severity across several moderate claims lands in the same underwriting year.
Unlike a single catastrophic event, this scenario does not need a shared trigger, only a shared underlying weakness across multiple unrelated insureds. CyberCube and Munich Re's joint systemic cyber research notes that even a severe malware event fully compromises only around 15% of infected systems, suggesting most cyber loss activity is dispersed rather than singular. That dispersion is exactly what makes this scenario plausible: it does not require an unlikely mega-event, only an ordinary bad year concentrated by weak response capacity. The diagnosis behind why this driver behaves this way is the necessary context for the board to interpret this scenario correctly.
Is this scenario different from a standard cyber catastrophe stress test?
Yes, because it models many separate incidents growing severe for the same reason, rather than one correlated event.
A catastrophe scenario typically assumes a single cause, such as a cloud outage or a widely exploited vulnerability, hitting many insureds at once. This scenario instead assumes ordinary, unrelated incidents each grow more severe than expected because the underlying insureds share weak response capability. Both scenarios matter, but boards that only see the catastrophe version are missing a more probable, harder-to-diagnose pattern. Running both side by side gives a more complete picture of where the book's real severity risk concentrates.
What should the board expect management to already know before this scenario is run?
What share of the cyber book carries verified incident response readiness, since that split determines how the scenario should be calibrated.
Without this baseline, the scenario is only a theoretical exercise rather than a grounded estimate tied to the actual portfolio. Management should be able to state, even approximately, what proportion of insureds behind the treaty have evidenced retained forensics and tested response plans. If that number does not exist yet, producing it should be the board's first request, ahead of running the scenario itself. A scenario built on a guessed baseline gives false confidence, which is worse than acknowledging the baseline is not yet known.
How often should this scenario be refreshed?
Annually at minimum, and again whenever the portfolio's cedant mix or size distribution changes meaningfully.
A book that shifts toward smaller insureds should be re-tested, since Sophos's 2026 data found smaller organizations stopped attacks before encryption only 34% of the time, against 46% at larger firms. That kind of size-mix shift changes the scenario's assumptions materially, even if overall premium volume looks stable. Annual refresh keeps the scenario aligned with the actual book being carried, rather than a stale snapshot from a prior underwriting year. Boards should treat a stale version of this scenario as a governance gap, not a completed task.
What risk appetite question does this scenario actually answer?
How much severity concentration from this specific driver the reinsurer is willing to carry before requiring a formal pricing or capacity response.
Risk appetite statements are more useful when tied to a specific, named mechanism rather than a general statement about cyber severity tolerance. This scenario gives the board a concrete number, a modeled loss under a defined set of assumptions, to compare directly against existing appetite thresholds.
| Scenario input | What it represents |
|---|---|
| Share of book with unverified readiness | Base exposure to this driver |
| Assumed severity uplift for weak responders | Calibrated from claims and industry data |
| Number of moderate claims modeled together | Reflects a plausible bad-but-not-catastrophic year |
Once the board has seen this number, appetite conversations become specific rather than abstract.
Should this scenario be shared with rating agencies or regulators?
A summary version is worth including in ORSA or equivalent capital adequacy documentation.
Demonstrating active management of a named, specific severity driver is generally viewed favorably in capital adequacy review, since it shows risk identification beyond generic peril categories. The operating discipline that supports this kind of scenario is also the same discipline regulators and rating agencies look for when assessing risk management maturity. The detailed cedant-level data underlying the scenario does not need to be shared externally, only the methodology and headline result. This is a relatively low-cost way to strengthen a capital adequacy narrative that might otherwise rely on generic cyber risk language.
What governance failure does skipping this scenario create?
The board approves cyber risk appetite without seeing the specific mechanism most likely to breach it.
That gap makes oversight technically satisfied, since a cyber scenario was reviewed, but substantively incomplete, since the scenario reviewed was not the one most likely to matter. Boards operating this way can be caught off guard when a bad year arrives not through a single catastrophic event, but through exactly the dispersed pattern this scenario describes. Reinsurance News's polling on the CrowdStrike outage found industry loss estimates ranging from under $1 billion to well over it depending on the modeler, itself a reminder that even well-studied events carry real estimation uncertainty. A board that has only ever reviewed the catastrophe case is unprepared for the version of severity risk that is actually more common.
What should the board ask for immediately after seeing this scenario?
A committed timeline for closing the gap between verified-readiness exposure and unverified exposure across the book.
Seeing the scenario without requiring a follow-up commitment turns the exercise into a reporting formality rather than a governance tool. A specific, time-bound target, such as a defined percentage reduction in unverified exposure by the next renewal cycle, gives management something concrete to be held accountable against. An Cyber Aggregation Risk AI Agent style analytics tool can help track progress against that target between board meetings, rather than waiting for the next annual review. This closes the loop between identifying the risk and actually managing it down over time.
Should this scenario be shared with retrocession partners?
Yes, in summary form, since retrocessionaires are ultimately carrying a share of the same exposure this scenario describes.
A retrocessionaire pricing a cyber retrocession program benefits from understanding whether the underlying cedant book carries meaningful unverified incident response exposure. Sharing the scenario's methodology and headline result, without necessarily disclosing individual cedant-level detail, gives retrocession partners a more informed basis for their own pricing. This transparency can also strengthen the retrocession relationship, since it signals the reinsurer is actively managing a named severity driver rather than passing an unexamined risk further up the chain. Reinsurers that withhold this kind of analysis from retrocession partners risk a less favorable retrocession price, priced instead on the retrocessionaire's own more conservative assumptions.
What role does management incentive design play in sustaining this oversight?
A significant one, since incentives determine whether management keeps prioritizing this driver once board attention shifts elsewhere.
Boards cannot review every risk topic at every meeting, so oversight effectiveness depends partly on management staying engaged even between formal board reviews. Tying a portion of relevant executive compensation to progress on closing the verified-versus-unverified exposure gap keeps the incentive aligned with the board's stated priority. Without that link, management attention to this driver can fade once it stops being the newest item on the board agenda, regardless of its actual financial importance. A board that pairs its oversight request with an incentive structure is more likely to see sustained progress than one relying on reporting requirements alone.
Should this scenario change depending on whether the cyber market is hardening or softening?
Yes, since market conditions affect how much leverage a reinsurer has to demand better cedant behavior on this driver.
In a hardening market, reinsurers have more negotiating leverage to require verified incident response readiness as a condition of capacity, since cedants have fewer alternative sources of capacity to turn to. In a softening market, that leverage weakens, and cedants unwilling to meet the standard may simply find capacity elsewhere, making enforcement harder without losing business. The scenario itself does not need to change, but the board's expectations for how quickly the unverified-exposure gap can realistically close should adjust with market conditions. Boards that hold management to the same pace of improvement regardless of market cycle risk setting a target that is either too easy in a hard market or unachievable in a soft one.
Who should present this scenario to the board, and how often should the presenter rotate?
The Chief Actuary or CRO should present it, since both roles carry the technical credibility needed to defend the scenario's assumptions under board questioning.
Rotating primary ownership of the presentation between these two roles every few cycles keeps the analysis fresh and avoids it becoming a rote, unchanged slide repeated year after year. A new presenter is more likely to challenge inherited assumptions than someone repeating the same analysis they built themselves in a prior cycle. This rotation also builds broader institutional knowledge of the scenario across the executive team, reducing the risk that understanding of it leaves with a single departing executive. Keeping the underlying methodology consistent while rotating who presents it balances continuity with the healthy scrutiny a fresh perspective brings.
Boards that only stress test the single catastrophic cyber scenario are seeing half the picture. Adding this scenario, grounded in a driver that is already showing up in claims data, gives oversight a far more realistic view of where next year's severity is likely to come from.
Sources
- Sophos, "The State of Ransomware 2026 - Payments Drop as Encryption Climbs"
- CyberCube and Munich Re, "joint systemic cyber risk report"
- Reinsurance News, "poll predicts CrowdStrike IT outage losses could exceed $1bn for re/insurance industry"
Frequently Asked Questions
What specific scenario should the board ask to see run on this driver?
A stress test showing what happens to the cyber book if response-capability-driven severity across several mid-sized claims arrives in the same underwriting year.
Is this scenario different from a standard cyber catastrophe stress test?
Yes. Catastrophe stress tests model one large correlated event, while this scenario models many separate, moderate incidents growing severe for the same underlying reason.
What should the board expect management to already know before this scenario is run?
What share of the cyber book carries verified incident response readiness, since that split determines how the scenario should be calibrated.
How often should this scenario be refreshed?
Annually at minimum, and again whenever the portfolio's cedant mix or size distribution changes meaningfully.
What risk appetite question does this scenario actually answer?
How much severity concentration from this specific driver the reinsurer is willing to carry before it requires a formal pricing or capacity response.
Should this scenario be shared with rating agencies or regulators?
A summary version is worth including in ORSA or equivalent capital adequacy documentation, since it demonstrates active management of an identified severity driver.
What governance failure does skipping this scenario create?
The board approves cyber risk appetite without seeing the specific mechanism most likely to breach it, leaving oversight technically satisfied but substantively incomplete.
What should the board ask for immediately after seeing this scenario?
A committed timeline for closing the gap between verified-readiness exposure and unverified exposure across the book.

Hitul Mistry
CEO, Insurnest
An InsurTech leader with more than a decade of experience across insurance and technology, focused on solving business problems with the help of technology. Has worked with brokers, insurance carriers, and reinsurance firms across the India, UAE, and US markets.
View LinkedIn profile →