When the Cloud Goes Dark: Insuring Indian SaaS Startups Against Cloud-Dependency Business Interruption After the 2025 AWS and Azure Outages

Two events in late 2025 turned an abstract risk into a concrete one. On 20 October 2025, AWS suffered a major us-east-1 disruption traced to a network configuration error, lasting over 12 hours and hitting EC2, S3 and Lambda. Shortly after, Azure Front Door experienced a global outage from a configuration change. Neither was a hack and neither involved physical damage; both were configuration errors at a hyperscaler that cascaded to every business sitting on top of it.

For an Indian SaaS startup, the lesson was uncomfortable. A firm whose product runs entirely on a hyperscaler can be knocked offline for hours by an event it did not cause, cannot prevent and cannot fix, and during that window it loses revenue, breaches service commitments to its own customers and may owe service-level credits. The outage is somebody else's, but the loss is the startup's.

The events exposed a gap between how SaaS firms assume they are covered and how their policies actually respond. Many founders assume business interruption cover would answer a cloud outage. In most traditional wordings it does not, and understanding why is the starting point for closing the gap.

The reason a conventional business interruption policy stays silent on a cloud outage is structural, not a matter of a missing endorsement.

Traditional business interruption is built on a physical-damage trigger. It responds to loss of income that follows physical damage to insured property, the classic example being a fire that stops a factory. The interruption has to flow from damage to something physical. A hyperscaler outage caused by a configuration error involves no physical damage to the SaaS firm's property, so the trigger is never met, and traditional business interruption policies typically exclude cloud-provider outages outright in any case.

This is the trap. A SaaS firm reasons that it has business interruption cover, so an interruption to its business should be covered. But the policy was designed for a physical-asset world, and a software business whose only productive asset is access to someone else's infrastructure does not fit that design. The income loss is real, but the wording that was meant to protect income is keyed to a peril that did not occur.

If traditional business interruption does not respond, the cover that does sits inside the cyber policy, and it has a specific name and shape.

Dependent-system business interruption (also described as dependent or contingent business interruption) extends cyber or property business interruption to losses arising from outages at third-party providers such as AWS, Azure or Google Cloud. It is built precisely for the situation where the insured's own systems are fine but the provider it depends on has failed. This is the coverage a SaaS firm should be looking at, and it lives in the cyber market rather than the traditional property market.

Within cyber wordings, the relevant trigger is often system failure, which can extend cover to non-malicious outages and human or configuration error rather than only to attacks. That matters because the 2025 outages were configuration errors, not attacks, so a cyber policy that only responds to malicious events would have left the same gap. The broker's task is to confirm the cyber wording reaches non-malicious, third-party system failure, not just hacking.

Even where dependent-system cover exists, a feature of the wording shapes how much of a short outage is actually recoverable, and a broker has to set expectations around it.

Cyber business interruption cover commonly carries a waiting period, a time deductible expressed in hours, often in the region of 8 to 24 hours, before cover begins to respond. The waiting period works like a deductible measured in time: loss during the first hours of an outage is borne by the insured, and only the period beyond it is potentially recoverable.

This interacts directly with the nature of cloud outages. The October 2025 AWS event lasted over 12 hours, which sits inside the range where the waiting period matters enormously. A policy with a 24-hour waiting period would not have responded to a 12-hour outage at all, while one with an 8-hour waiting period might have answered the portion beyond the first 8 hours. For a SaaS firm, the length of the waiting period relative to the typical duration of a hyperscaler outage is therefore one of the most important commercial terms in the policy, and the broker should match it to the firm's realistic exposure rather than accept the default.

Quantifying the loss is the other half. Because the SaaS firm did not suffer physical damage, the claim rests on demonstrating the income lost during the covered period: the revenue that did not arrive, the service-level credits owed to customers, and the duration of the interruption, all evidenced against normal trading. A firm that can show its baseline revenue and tie the outage window to a measurable drop is in a far stronger position than one reconstructing the loss after the fact.

Pulling the analysis together, a broker advising a cloud-dependent SaaS startup should work through a defined set of questions rather than assume the existing programme answers a cloud outage.

1. Map the dependency. Identify which hyperscaler and which services the firm's product actually runs on, because the cover has to name and reach those providers.
2. Test the existing business interruption cover. Confirm whether it has a physical-damage trigger and a cloud-outage exclusion, which in most cases means it will not respond to a hyperscaler failure.
3. Place dependent-system business interruption within cyber. Secure cover that extends to outages at the named third-party providers the firm relies on.
4. Confirm the trigger reaches non-malicious system failure, so that a configuration error like the 2025 events is covered, not just an attack.
5. Set the waiting period against real outage durations, recognising that a waiting period longer than a typical outage can leave the firm recovering nothing.
6. Build the evidence discipline now, keeping baseline revenue and service-level commitments documented so a future outage loss can be quantified cleanly.

The 2025 outages made the point that cloud dependency is a business-continuity exposure a SaaS firm cannot engineer away by choosing a good provider, because even the largest providers fail. The response is a programme that puts the loss where a policy will actually answer it.

Getting that right depends on reading the wordings closely, where the business interruption trigger sits, whether the cyber policy's system-failure cover reaches non-malicious third-party outages, and how the waiting period is defined. Sarvada gives commercial insurance brokers structured, searchable access to insurer policy wordings and the intelligence around them, so a cloud-dependency programme can be built on what the policies actually say rather than on what a founder assumes. Request Access to structure SaaS business-interruption cover with that wording detail in front of you.