Three Model Providers, One Cloud Region: Dependent System Failure Cover for Indian GCCs and SaaS Firms

On 3 September 2026, three of the four largest AI model providers stopped serving requests inside the same window. 9to5Google put it plainly in its headline that day: "It's not just you; ChatGPT, Claude, and Grok were all down in confirmed outages." Asia Insurance Post reported the same event from the insurance side, noting that "ChatGPT, Gemini, Claude face widespread outages; AWS also hit."

User-submitted outage reports climbed into the tens of thousands across the affected services. The trigger was reported as a regional failure inside Microsoft Azure's East US infrastructure, and the services came back after roughly 90 minutes to three hours depending on which one a business was calling.

No attacker was involved. No data was exposed. No property was damaged. A cloud region degraded, and several of the model endpoints that Indian engineering, support and back-office teams now call thousands of times an hour degraded with it. That combination, real revenue loss with none of the three triggers most policies are built around, is the whole problem.

Most technology risk registers treat vendor diversification as the answer to provider failure. A firm that routes primary traffic to one model provider and holds a second as fallback records the dependency as mitigated. The 3 September event showed why that entry can be wrong.

The providers compete commercially. Their inference capacity, on the reporting available, was sitting in overlapping infrastructure. When the regional failure hit, the fallback failed at the same moment as the primary, because both were downstream of the same physical estate. Diversifying the contract does not diversify the correlation.

This is a familiar shape to any underwriter who has priced accumulation. It is the same logic as writing fire risks on ten separate legal entities that all warehouse stock in one industrial park. The named insureds are independent; the exposure is not. What is new is that a technology buyer cannot easily see the accumulation, because the region a model provider serves inference from is not usually a term in the commercial contract and is not usually disclosed on a status page before the incident.

The exposure is not evenly spread. It concentrates in exactly the businesses India has built most of over the last three years.

• Global capability centres running document extraction, code assistance, ticket summarisation and quality review for a parent entity abroad, under an intra-group service agreement with stated turnaround commitments.
• BPO and voice operations where model calls sit inside the live handling path, so an API failure lengthens average handling time in real time rather than delaying a batch job.
• SaaS firms whose product feature is the model output, where an outage is not internal inconvenience but a visible product failure their own customers experience and can claim credits for.

In all three, the model API has moved from an experiment on the side to a component in the production path. When it stops answering, the fallback is usually human, and the human capacity was sized on the assumption that the machine would carry the routine volume. A 90-minute outage in Indian business hours can push a queue into a backlog that takes the rest of the shift to clear, with overtime, missed service levels and credits attached.

The contractual layer is what converts the technical event into a financial one. Master service agreements written for GCC and BPO work carry service credits keyed to turnaround, accuracy and availability. SaaS contracts carry uptime commitments. Neither usually contains a carve-out for a failure at the customer's chosen model provider, so the Indian entity absorbs the credit even though the failure originated three layers up the stack.

Run the event past the three policies a mid-sized Indian technology business typically holds and the answer in each case is uncomfortable.

Property business interruption. Ordinary business interruption cover is keyed to physical damage at an insured location. There was no fire, no flood, no machinery breakdown, and the affected infrastructure was not the insured's property in any event. Most Indian property placements now also carry a cyber exclusion, which removes loss arising from the failure of any computer system whether or not the insured owns it. The trigger is not met and, separately, the peril is excluded.

Cyber. Most cyber insurance wordings key business interruption to a security failure: unauthorised access, malware, denial of service, an attack of some kind. A regional infrastructure failure with no adversary does not meet that definition. Wordings that add a system failure trigger for non-malicious outages often confine it to the insured's own network, which was working perfectly on 3 September.

Contingent business interruption. Classic contingent business interruption responds to damage at a supplier's or customer's premises. It carries the same physical-damage requirement one step removed, so it fails on this event for the same reason property business interruption does.

The result is a loss that is real, quantifiable, and sitting outside all three responses unless someone has specifically bought the extension that reaches it.

The cover that answers a non-damage, non-malicious third-party outage is dependent system failure, sometimes written as dependent business interruption or contingent system failure inside a cyber policy. It extends business interruption to an unplanned outage at a specified technology provider, without requiring damage and without requiring an attack.

Buying it is not the end of the work, because three drafting questions decide whether it would have answered 3 September.

1. Who is named. Many schedules list hyperscalers (AWS, Azure, Google Cloud) and stop there. If the insured's contract and its outage exposure run to a model provider, the schedule needs to reach that provider by name, or the definition of dependent provider needs to be broad enough to include any third party whose service the insured's operations rely on. A schedule naming only the hyperscaler leaves an argument about whether an outage the insured experienced at the model endpoint is covered.
2. What counts as an outage. The wording should reach degradation and partial unavailability, not only total failure. Model APIs frequently fail as elevated error rates and timeouts rather than a clean zero, and a claim can die on the difference between "unavailable" and "materially degraded".
3. Whether the definition follows the chain. The reported cause sat at the cloud layer while the insured's contract sat with the model provider. A wording that requires the outage to occur at the named provider's own systems invites a dispute about where the failure actually was. Wording that responds to interruption of a named service, however caused, avoids that fight.

The second half of the exposure is liability rather than income. A GCC or SaaS firm that missed contractual commitments faces claims from its own customers, and that sits in technology errors and omissions or professional indemnity rather than in business interruption. Check whether the E&O wording excludes liability arising from third-party infrastructure failure, because a number do, and that exclusion turns the two policies into a pair that each point at the other.

Here is the part a broker should say out loud before quoting anything. Cyber business interruption cover conventionally carries a waiting period, a deductible measured in time, commonly in the region of 8 to 24 hours. The 3 September outage ran roughly 90 minutes to three hours.

On standard terms, that outage produced no recovery for anyone. It sat entirely inside the time deductible. A firm that bought dependent system failure cover in good faith, paid the premium, and lost a full shift of throughput would have collected nothing.

That is not a reason to skip the cover. It is a reason to place it on terms that match how model-API outages actually behave, which is short, frequent and correlated rather than long and isolated. Practical levers to put in front of an underwriter:

• A shorter waiting period, in the region of 4 to 6 hours, priced explicitly rather than accepted as a default.
• An aggregation provision that lets repeated short outages at the same provider within a policy period be treated together, so a pattern of 90-minute failures is not written off one by one.
• A stated hourly or daily indemnity sub-limit, which removes the argument about quantum on a short interruption where the insured cannot easily separate lost revenue from deferred revenue.
• Increased cost of working cover sized to the real fallback cost, meaning overtime, contract staff and expedited processing, since on a short outage that spend is often larger than the revenue actually lost.

A model-API outage produces no damaged asset for a surveyor to inspect, so the claim stands or falls on records the insured either kept or did not. Building the evidence set before an event is cheaper than reconstructing it after one.

What a dependent system failure claim needs:

1. Call-level telemetry. Request volumes, error rates and latency per provider endpoint, timestamped, showing the start and end of the degradation from the insured's own side rather than only from the provider's status page.
2. A throughput baseline. Tickets closed per hour, documents processed per hour, or transactions completed per hour for a normal comparable period, so the shortfall during the window is measurable rather than asserted.
3. The contractual consequence. The specific service credits, penalties or fee reductions triggered, with the clause and the calculation, because this is often the cleanest and largest quantified head of loss.
4. Fallback cost. Overtime approved, contract staff engaged, and any expedited processing paid for, evidenced as increased cost of working.
5. The provider record. The provider's own status history and incident postmortem, which establishes that the interruption was an outage at a dependent provider rather than an internal failure.

The policy wording will usually require notification within a stated period, and short outages are easy to under-notify because they feel like operational noise at the time. Set an internal rule that any model-provider degradation past a fixed threshold gets logged and notified, whether or not anyone believes it will reach the waiting period, so the aggregation argument is available later.

The 3 September event was short, and short events are the ones that teach cheaply. A firm that treats it as a near miss can be structured properly before a longer failure arrives.

1. Rebuild the dependency map by infrastructure rather than by vendor. For each model provider in the production path, record which cloud and which region serves the inference, and mark fallbacks that share a region as correlated rather than independent.
2. Price the hour. Calculate what one hour of full model-API unavailability costs across lost throughput, service credits and human fallback. Without that number no waiting period or sub-limit can be set sensibly.
3. Read the cyber wording against this specific event. Does the business interruption trigger require a security failure? Does system failure cover extend beyond the insured's own network? Are dependent providers named, and are the model providers among them?
4. Read the technology E&O wording for the mirror exclusion, which is liability arising out of third-party infrastructure or service-provider failure.
5. Fix the contract layer where possible. Push for outage carve-outs or credit caps in customer master service agreements, since every rupee of credit avoided contractually is a rupee that does not need to survive a waiting period.
6. Negotiate the time deductible deliberately, with aggregation of related outages and increased cost of working sized to the real fallback plan.

The wider pattern is covered in our analysis of cloud-dependency business interruption for Indian SaaS startups, and the same non-damage trigger problem shows up across utilities and telecom in non-damage business interruption.

All of this turns on what the wordings actually say, and dependent system failure language varies widely between Indian cyber markets and the London capacity behind them. Sarvada gives commercial insurance brokers structured, searchable access to insurer policy wordings and the intelligence around them, so a dependency programme can be built against the clause rather than the brochure. Request Access to compare dependent system failure triggers, named-provider schedules and waiting periods side by side.