Cloud outage scenario analysis estimates what a cyber insurer would lose if a cloud provider, or one of its regions, became unavailable for a set time. It answers four questions in order: which insureds depend on the provider and how that is known, what their policies say about dependent business interruption and system failure, how many outlast their waiting periods at each outage length, and what the loss is gross, net of quota share and against the event cover. Run in advance, it is a stress test for capital and reinsurance. Run live, it is the first hour after a vendor's status page turns red, when the head of cyber needs an estimate rather than a total limit. The hard part is the first question, because few insurers can say which cloud their insureds use. Botminds' Cyber Accumulation Management keeps that answer ready, with evidence, so the scenario can start from named insureds rather than market-share guesses.
The worked example is a fictional sample book run through the solution: Thistlebrook Specialty, 2,846 insureds and $2.93 billion of cyber limit, on the Monday morning its main cloud vendor, Nimbara Cloud, reports elevated errors in its US-East 3 region. Every company and person in it is invented. Regulators' figures are linked where they appear.
The sample outage’s first 53 minutes, drawn to scale
- Vendor matched7 min
- Insureds5 min
- Declared7 min
- Estimate9 min
- 41 broker emails drafted25 min
What is cloud outage scenario analysis?
It is a deterministic scenario: one named failure, with fixed assumptions about duration, recovery and cause, run across the book to see who is hit and what it costs. That makes it different from a probabilistic catastrophe model, which simulates thousands of possible events to estimate how often losses of each size occur. The market often calls the deterministic kind a realistic disaster scenario; supervisors call it a stress test.
Supervisors put cloud outages near the top of their lists. When the International Association of Insurance Supervisors asked jurisdictions in its 2022 monitoring exercise to name the three cyber scenarios that would cause the largest underwriting losses, more than a third named a cloud outage.
Supervisors’ top cyber scenarios: a cloud outage is named by more than a third
New York's Department of Financial Services named the same event three years earlier. Its 2021 cyber framework asks insurers to "understand the critical third parties used by their insureds and model the effect of a catastrophic cyber event on such critical third parties that may cause simultaneous losses to many of their insureds", and its examples include "a cyber event that disables a major cloud services provider" (NYDFS Insurance Circular Letter No. 2, 2021).
What did the PRA's cloud-down scenario assume?
The most detailed public cloud outage scenario is the UK Prudential Regulation Authority's 2022 general insurance stress test. Scenario B1 assumed the largest cloud provider in each insurer's own portfolio suffers "a catastrophic outage for a week (7 days) from a cyber attack facilitated by an insider", with customers losing access worldwide (PRA IST 2022 scenario specification). Its assumptions are a ready template for any insurer building its own.
The PRA’s 2022 cloud-down scenario, assumption by assumption
| Assumption | What the PRA specified | Why it matters for your own scenario |
|---|---|---|
| Which provider | The one with the largest concentration in the insurer’s own portfolio; where data is lacking, assume the largest has a 35% market share. | The fallback is a market share, not your book. Without dependency data you are testing the market, not yourself. |
| Duration | A catastrophic outage for a week (7 days), worldwide, across infrastructure, platform and software services. | A week is a tail case. In a shorter live outage, waiting periods decide the loss. |
| Recovery after restoration | 40% of policyholders back immediately; 30% after 9 days in total; 30% after 12 days, because data and systems must be checked. | Recovery time is a separate assumption from the outage itself and belongs in every estimate. |
| Cause and war | A malicious insider-assisted attack; possible state support cannot be proved, so war exclusions cannot be applied. | Malicious cause brings in policies that cover attack but not system failure. |
| Lines affected | Business interruption and contingent business interruption, D&O claims at large firms, professional indemnity, technology providers. | Accumulation does not stop at the cyber book. |
The results show what such a scenario does to a market. Across participating UK insurers, the cloud-down scenario produced £9.2 billion of gross losses and £4.0 billion net, with 56% of the gross ceded to reinsurers; two entities fell below 100% of their solvency capital requirement (PRA, Insurance Stress Test 2022 feedback, 23 January 2023). The PRA added that the figures are "potentially overstated" because each insurer chose its most material provider.
Why most insurers could not say which cloud their insureds use
Because the dependency was never collected in a usable form. The PRA asked participants for the reliance of their insureds on cloud providers, and three policies in four came back with no answer. "Responses on this subject were limited (representing a quarter of total policies)," the feedback letter says, "and where CSPs were named, some entities appear to have based this on vendor model market share assumptions rather than their own data" (PRA IST 2022 feedback).
Three standalone cyber policies in four had no named cloud provider
The same letter noted "positive examples by a minority of entities referencing external scanning tools to gain technographic insight." That is the point of departure for a live scenario. A cloud outage scenario that starts from a market share tells you the market's exposure; one that starts from the insureds you can name, with evidence, tells you yours.
What data shows which insureds use a cloud provider?
Three kinds of evidence, each with a blind spot. Outside-in scans show which internet-facing services answer from a provider's addresses, but not what runs privately behind them. Application answers show what the insured says it depends on, but they are dated to the last renewal and often name a vendor without a region. Provider disclosures show which managed-IT or software firms run on the vendor, which catches insureds that depend on it without knowing.
The indirect route matters because concentration compounds. The U.S. Treasury's 2023 review of cloud use in financial services put the risk this way: "concentration could expose many financial services clients to the same set of physical or cyber risks (e.g., from a region-wide outage)" (U.S. Treasury, The Financial Services Sector's Adoption of Cloud Services, February 2023). A region-wide outage is the event in the sample, and region is where most evidence is weakest.
In the sample book, the dependency matcher found the 418 Nimbara insureds by all three routes: 236 seen in scans ($198 million of limit), 131 declared on applications ($104 million) and 51 through a provider ($38 million). The split matters for confidence. A scan from two days earlier showing an insured's booking hosts on US-East 3 addresses is stronger than an April application naming "Nimbara Cloud, US-East region", and both are stronger than a managed-IT firm's general disclosure. The guide on cyber aggregation tools goes through how each kind of evidence is read and kept.
The first hour, traced step by step
The first hour has five steps, and each must leave something a person can check. In the sample, the event watcher read the vendor's notice at 06:12 ("Increased error rates for compute and storage in US-East 3") and matched it to the shared-vendor register by name, product and region, which keeps a fault in one region from being counted against every customer of the vendor worldwide. It opened a watch at 06:19.
By 06:24 the dependency matcher had the 418 insureds and the policy reader had read each in-force policy and endorsement: $340 million of limit, $181.5 million of dependent business interruption sublimits, 41 brokers, and 63 policies with no cover for system failure. That last figure is the one most hand-built estimates miss. A non-malicious outage only reaches policies that cover system failure; until the vendor says why it failed, the scenario has to be run both ways.
How the 418 were found, with each agent step and its time
At 06:31 the head of cyber declared the event, because the exposed limit was $40 million over the board's $300 million per-vendor tolerance. Declaration is the hinge of the hour: before it, agents watch and assemble; after it, outreach and the note to reinsurers begin. At 06:40 the outage estimator produced the first estimate at 12 and 24 hours.
How are waiting periods applied in a cloud outage?
Each policy's waiting period is compared with the insured's total interruption, which is the outage plus the time the insured needs to recover once the vendor is back. Only the hours beyond the waiting period are covered, at the insured's income per hour, less its retention and capped at its dependent business interruption sublimit. The PRA built the same logic into its scenario when it staggered recovery at 7, 9 and 12 days.
In the sample, the 355 insureds with system-failure cover had waiting periods of 6 hours (25 insureds), 8 hours (72), 10 hours (40), 12 hours (121) and 24 hours (97). With 3 hours of recovery added, a 12-hour outage passes every waiting period up to 12 hours and none of the 24-hour ones: 258 insureds, $9.32 million gross. The arithmetic for one insured, and why so many never reach a claim, is worked in the guide to the cyber insurance waiting period.
The what-if: a slider from 2 to 72 hours, and the insureds past their waiting period
What does a board want after a cyber event?
A board wants five things on one page: what failed and why, the exposed limit against its tolerance, an estimate at a few outage lengths with the assumptions stated, where the reinsurance attaches, and what the team is doing. It does not want a total limit presented as a loss, and it does not want a single point estimate for an outage whose end nobody knows.
The sample note gave 12, 24 and 48 hours: $9.32 million, $40.4 million and $97.1 million gross; $6.52 million, $28.3 million and $68 million net of the 30% quota share; with the $20 million excess of $10 million event cover attaching at about 14.5 hours and exhausted by 48. The head of cyber signed it at 09:42, three and a half hours after the vendor's first notice.
Running the scenario before the vendor fails
The live hour goes well only if the same scenario has been run on a quiet day. That means every shared vendor above a threshold, at several outage lengths and both causes, refreshed as scans and renewals arrive. The Bank for International Settlements' Financial Stability Institute and the IAIS put the reason in one line in their 2026 review of cyber insurance.
The industry’s core challenge is not “average ransomware” but instead includes correlated, tail events such as cloud outages, widely exploited vulnerabilities, destructive malware or critical infrastructure attacks that can trigger losses across multiple policies.
FSI Insights No 75, Financial Stability Institute (BIS) and IAIS, 2026
In the sample book, the standing view showed 11 shared vendors, one over the $300 million tolerance and two near it, with every vendor's 12-month trend. Running a 24-hour scenario on each of them once a quarter costs minutes; discovering on the morning of an outage that a vendor was over tolerance costs a conversation with the board nobody wants. The measures a board should track between events are set out in a companion guide.
Questions people ask
How do insurers model a cloud outage?
Two ways. A probabilistic cyber catastrophe model simulates many possible outages to estimate how often losses of each size occur; a deterministic scenario fixes one provider, one duration and one cause and runs it across the book. The PRA's 2022 stress test used the second: a seven-day outage of each insurer's largest provider.
What is a cyber realistic disaster scenario?
It is a market term for a deterministic, severe but plausible cyber event that insurers run against their books to test capital and reinsurance, such as a major cloud outage or a self-spreading malware attack. New York's DFS asks insurers to stress test against catastrophic cyber events that are improbable but realistic, covering silent as well as affirmative cover.
How fast can an insurer estimate exposure to a vendor outage?
It depends on whether dependencies are known before the event. By hand, our estimate is about three working days to a first figure. In the fictional sample, the solution matched 418 insureds and $340 million of limit 12 minutes after the vendor's notice.
What is dependent business interruption?
It is cover for the income an insured loses when a provider it relies on, rather than its own systems, is disrupted. It usually carries its own sublimit and a waiting period, and many policies cover it only when the provider was attacked, not when it simply failed.
Does an outage in one cloud region hit every customer of the provider?
No. Many outages are confined to one region or one service, which is why matching should be done at region and product level. In the sample, the vendor reported errors for compute and storage in US-East 3 only, and the estimate counted only insureds with evidence of depending on that region.
How much did the PRA's cloud-down scenario cost the UK market?
Participants reported £9.2 billion of gross losses and £4.0 billion net, with 56% ceded to reinsurers, in the 2022 stress test. The PRA cautioned that the totals are likely overstated because each insurer picked its own most material provider.