Your underwriting team is evaluating applications from companies relying on AWS, Azure, or Google Cloud for critical operations. The question isn't whether to cover cloud-related business interruptions, you already do. It's whether you need a distinct modeling approach for systemic cloud provider outages versus traditional cyber events.
The AWS outage, dubbed "Amazonk" by CyberCube, affected over 2,000 large organizations and nearly 70,000 in total. CyberCube's global insured loss estimate ranged from $38 million to $581 million, with an expected loss ratio impact in the low- to mid-single digits for cyber insurers. This spread highlights the modeling uncertainty for cloud concentration risk, even for events insurers already price into their portfolios.
Here's how to decide whether your book needs separate cloud outage modeling or if your existing Frequency-Severity Modeling framework already captures it.
The Decision You're Facing
You're considering whether to treat hyperscale cloud provider outages as a distinct peril in your cyber portfolio management. This isn't about whether to cover them, your Business Interruption Coverage and Contingent Business Interruption provisions already respond to these events. It's about how you model accumulation exposure and set concentration limits.
Your choice comes down to three paths: integrate cloud outages into your general cyber loss modeling, build a separate model for systemic cloud events, or implement a hybrid approach that tracks cloud dependency as a risk attribute within your existing framework.
Key Factors That Affect Your Choice
Your portfolio's cloud concentration. If more than 30% of your insureds rely on a single cloud provider for revenue-critical systems, you're carrying significant accumulation exposure. Review your underwriting questionnaires for answers about hosting infrastructure. If you don't ask about cloud dependencies in your Pre-Bind Requirements, you can't model what you don't measure.
Your reinsurance structure. Does your treaty include specific sublimits or exclusions for non-malicious systemic events? Some reinsurers treat cloud outages differently from ransomware or data breaches in their Reinsurance Cession terms. If your treaty aggregates all cyber losses without distinguishing event types, separate modeling may not change your capital requirements.
The duration pattern of cloud outages. CyberCube noted that the short duration of the AWS event likely pushed losses toward the lower end of their estimate range, partly because companies might decide "it is not worth the hassle to claim." Your own claims data should show whether cloud-related business interruption claims follow different waiting period and duration patterns than breach-related interruptions.
Your attachment point and policy limits. If you're writing $1 million limits with 8-hour waiting periods, most cloud outages won't trigger claims at all. Companies like McDonald's, Zoom, and Salesforce likely had varying loss profiles based on their dependency depth and revenue models. Your modeling choice matters more if you're writing $10 million or $25 million limits where a 4-hour outage could exceed your attachment.
Path A: Integrate Cloud Risk Into Existing Models
Choose this path if your portfolio is geographically and sector-diversified, your average limit is below $5 million, and you already capture infrastructure dependencies in your Underwriting Questionnaire.
When this works: You're tracking cloud provider as a risk attribute in your policy data, similar to how you track industry sector or revenue band. Your Aggregation Exposure Analysis can filter and stress-test cloud concentration without building separate loss curves. You treat cloud outages as non-malicious systemic events that fall within your expected frequency for service provider failures.
Implementation requirements: Add mandatory fields to your underwriting data schema for primary cloud provider, percentage of revenue-critical workloads hosted externally, and backup provider arrangements. Update your Cyber Maturity Assessment to include questions about multi-cloud architecture and failover testing. Run quarterly concentration reports that show your total limits exposed to each major cloud provider.
What you're betting on: That cloud outages behave like other Contingent Business Interruption events, lower frequency than direct attacks, shorter duration, and predictable severity based on waiting periods and revenue concentration. CyberCube's statement that "this type of event is something that is modeled, priced for, and underwritten, and is well within insurers' expectations" supports this approach.
Path B: Build Separate Cloud Outage Models
Choose this path if you write large limits to technology companies, your portfolio has significant single-provider concentration, or your reinsurance treaty treats systemic non-malicious events differently from cyber attacks.
When this works: You're seeing cloud dependencies in 40% or more of your book, you write Business Interruption Coverage with short waiting periods (2 hours or less), and you need to set specific accumulation limits for cloud provider scenarios in your risk appetite statement. You want to model cloud outages with their own frequency distributions and loss curves because the event characteristics differ from ransomware or breach scenarios.
Implementation requirements: Build scenario libraries for each major cloud provider based on their historical outage patterns. Estimate probable maximum loss for scenarios where a provider experiences regional failures lasting 4, 8, and 24 hours. Map your insureds to provider dependencies and model correlated losses. Set portfolio limits expressed as "maximum aggregate limits exposed to AWS outages in US-East region" or similar constraints.
What you're betting on: That cloud provider outages represent a distinct accumulation risk with different frequency and severity characteristics than cyber attacks. The wide range in CyberCube's estimate, $38 million to $581 million, suggests that loss development for these events depends on factors (reimbursement policies, claim hassle thresholds, contract terms) that may not correlate with traditional cyber loss drivers.
Path C: Hybrid Attribute Tracking
Choose this path if you're still building claims experience with cloud-related losses, you want flexibility to shift approaches as data emerges, or you need to satisfy reinsurance reporting requirements without completely rebuilding your models.
When this works: You tag cloud provider dependency as a mandatory risk attribute in your portfolio management system but don't yet have enough claims data to build confident separate loss curves. You can generate concentration reports for underwriting reviews and treaty discussions while continuing to price cloud risk within your general cyber rates. You're watching how insurers like those affected by the AWS outage handle claims, whether they pursue provider reimbursement, whether they file claims at all, and how waiting periods interact with typical outage durations.
Implementation requirements: Enhance your policy administration system to capture and report cloud dependencies. Build dashboard views that show your cloud concentration by provider, region, and industry. Include cloud accumulation scenarios in your quarterly risk reporting without yet setting hard portfolio limits. Use the data to inform individual risk selection (declining accounts with single-provider dependency and no documented failover) while you build the claims history needed for formal modeling.
Summary Matrix
| Approach | Best For | Data Requirements | Underwriting Impact |
|---|---|---|---|
| Integrated Modeling | Diversified books, standard limits, mature cyber models | Cloud provider field in underwriting data; quarterly concentration reports | Minimal, cloud risk priced into general cyber rates |
| Separate Cloud Models | Tech-heavy portfolios, large limits, high single-provider concentration | Historical outage data by provider; mapped insured dependencies; separate loss curves | Significant, may trigger portfolio limits or require cloud-specific rates |
| Hybrid Tracking | Emerging exposure, building claims data, treaty reporting needs | Mandatory cloud dependency attribute; concentration dashboards | Moderate, informs individual risk selection and reinsurance discussions |
CyberCube expects AWS "to reimburse companies for downtime and to avoid lawsuits," which would push actual insured losses toward the lower end of their range. That expectation, and whether it holds across future events, should inform your modeling choice. If cloud providers consistently absorb most of the financial impact through service credits and contractual remedies, integrated modeling may be sufficient. If insureds increasingly pursue coverage rather than provider reimbursement, separate modeling becomes more valuable.
Your decision ultimately depends on whether you believe cloud outages represent a fundamentally different accumulation risk than the cyber events you already model. The loss ratio impact in the low- to mid-single digits suggests this event fell within normal expectations. Whether that remains true as cloud dependency deepens is the question your modeling approach needs to answer.
