The Colocation Insurance Interface: Why Operator and Tenant Cover Must Be Read Together
A colocation contract puts two insured parties in the same building, sharing the same physical perils, but carrying separate insurance programmes that are designed to respond to different parts of the same loss. The third-party data centre operator (CtrlS, NTT, ST Telemedia, Yotta, Sify, Iron Mountain Web Werks, Nxtra and the regional cohort) owns the shell, the power train, the cooling plant and the security envelope. The tenant owns the racks, the servers, the storage and the network gear sitting inside its cage. When a fire, a flood, a cooling failure or a UPS event hits a hall, both parties have a claim, and the question that decides who is made whole is not in either insurance policy. It is in the colocation master services agreement (MSA).
This post owns one lane and one lane only: the operator-to-tenant insurance interface. It addresses how responsibility splits between the two parties, which policy responds to which loss, and how the MSA clauses (indemnities, additional-insured status, waiver of subrogation, certificate-of-insurance requirements, limits demanded) reroute money between two separate insurer panels after a single physical event. It treats the SLA service-credit mechanism as the driver of operator business interruption (BI) exposure, and it draws the boundary between tenant customer-equipment cover and operator property cover with precision because that boundary is where uninsured loss hides.
We deliberately do not cover the generic operator exposures here. For the per-MW property, fire and lithium-ion UPS picture and premium benchmarks, read the Indian data centre operator risk profile and, for the very largest campuses, the hyperscale data centre operator insurance profile. For how a BI wording actually works (indemnity period, named perils, time-element deductibles), read the [data centre business interruption underwriting note](/underwriting-risk/data-centre-business-interruption-underwriting-india-2026). For grid and discom power-outage underwriting, read the AI data centre power outage underwriting note. Those four siblings carry the depth on their topics. This post stays on the contract interface between operator and tenant.
For a broker, this means the colocation engagement is never a single-programme placement. Whether you act for the operator or the tenant, you have to read the counterparty's insurance obligations and the MSA risk-allocation clauses alongside your own client's cover. The sections below map that interface clause by clause and set out the playbook for advising each side.
Who Pays for What: Mapping the Loss to the Responsible Policy
Start with a clean default rule and then layer the contract on top. The default rule of a colocation arrangement is that each party insures what it owns. The operator's all-risks property programme responds to damage to the building, the electrical distribution, the UPS and battery systems, the cooling plant, the generators, the security systems and the network handoff equipment up to the demarcation point defined in the MSA. The tenant's customer-equipment cover responds to damage to tenant-owned IT hardware inside the cage: servers, storage arrays, top-of-rack switches, customer cabling and customer racks. The demarcation point in the contract is the physical line that allocates ownership and therefore first-party insurance responsibility.
That clean rule survives only until the loss propagates across the demarcation line, which is what most data centre losses actually do. Consider the four recurring events and trace which policy responds:
- Fire in an operator battery or transformer room that spreads or produces smoke and water damage to tenant equipment. Operator property cover pays for the operator's plant. Tenant customer-equipment cover pays for the damaged servers. The tenant's insurer then looks at whether the operator caused the loss, and if the MSA does not block it, subrogates against the operator, dragging in the operator's liability programme as a third payer.
- Cooling plant failure that overheats and damages tenant servers. No damage to operator property in many cases, so the operator property cover may not respond at all. The tenant customer-equipment cover responds to the heat damage if its perils wording reaches operator-originating causes. Subrogation against the operator follows the same path as the fire case.
- UPS or power-quality event that fries tenant power supplies. Tenant customer-equipment cover responds; operator property cover responds only if the UPS itself is damaged; operator liability is engaged through subrogation or MSA indemnity.
- An outage with no physical damage at all (control-system glitch, human error, network handoff failure). No property policy responds, on either side, because there is no physical damage. The only money that moves is the SLA service credit the operator owes the tenant under the contract, plus any tenant BI loss the tenant absorbs. This is the case standard insurance is worst at addressing, and it is covered in the SLA section below.
The practical takeaway for both sides of the contract is that the policies do not, on their own, produce a clean outcome. The MSA risk-allocation clauses are what convert four overlapping policies into a predictable settlement. We turn to those clauses next.
Reading the MSA: Indemnities, Additional-Insured, Subrogation Waiver and COI Requirements
The colocation MSA contains a discrete set of insurance and risk-allocation clauses that, taken together, determine how loss flows between the parties and their insurers. A broker advising either side must read them as a block, because a generous indemnity with a low cap, or an additional-insured grant without a matching subrogation waiver, produces contradictions that surface only at claim time.
Indemnities and liability caps
The operator typically indemnifies the tenant for loss arising from operator infrastructure or process failure, with carve-outs for the tenant's own fault and for events outside operator control. The indemnity is almost always capped, commonly at 12 to 24 months of monthly recurring revenue (MRR) or at a negotiated monetary figure, with consequential and indirect loss excluded and with super-caps reserved for severe heads such as data breach, regulatory-penalty trigger, and death or personal injury. The single most important broker test is whether the indemnity the operator accepts is matched by recoverable insurance. An operator should not sign an indemnity obligation that exceeds the limit available under its own liability programme, and a tenant should not rely on an indemnity that the operator cannot fund.
Additional-insured status
Tenants, especially hyperscale tenants, increasingly require the operator to name the tenant as an additional insured on the operator's liability programme, and sometimes vice versa. Additional-insured status gives the named party a direct right of recovery against the policy rather than relying solely on the contractual indemnity. It is valuable but narrow: it generally responds only to liability arising out of the named insured's operations, and the scope of the grant (ongoing operations, completed operations, primary and non-contributory wording) determines its real worth. Brokers should confirm the additional-insured endorsement actually exists on the policy, that its wording matches the MSA requirement, and that it is reflected on the certificate of insurance.
Waiver of subrogation
This is the clause that closes the third claim track described in the prior section. A mutual waiver of subrogation has each party agree that its insurer will not pursue the other for losses covered by that party's own insurance. Operators favour the full mutual waiver because it removes the inter-insurer recovery fight after a propagating loss. Tenant insurers sometimes resist, particularly where the operator has identifiable fault, which is why the 2026 market is settling on limited waivers (waived up to the cover level or indemnity cap, retained above). The critical mechanical point is that the policy must permit the waiver. Many Indian policies require the insurer's consent to a pre-loss subrogation waiver, and an MSA waiver that the policy does not honour is worthless. Read the MSA clause and the policy condition together.
Certificate-of-insurance (COI) requirements and limits demanded
The MSA will list the covers, limits and endorsements each party must maintain and evidence by certificate. Tenants commonly demand the operator carry property, public liability, professional indemnity and cyber cover at stated minimum limits, name the tenant as additional insured, include the subrogation waiver, and deliver a COI at onboarding and at each renewal. Operators increasingly demand reciprocal evidence that the tenant carries customer-equipment cover and a BI or contingent BI programme so that the tenant's own loss does not convert into an operator indemnity claim. The broker role here is unglamorous but decisive: maintain a COI tracker, confirm the evidenced cover actually matches the MSA schedule, and flag lapses before they become coverage gaps. A COI that recites a limit the underlying policy does not carry is a latent dispute.
SLA Service Credits as the Driver of Operator BI Exposure
The uptime service level agreement is the commercial heart of the colocation relationship and the mechanism that converts an outage into an operator liability. Understanding the service-credit pass-through is essential to understanding operator BI exposure, because the credit is a contractual debt the operator owes the tenant that conventional BI cover was never built to pay.
A representative 2026 hyperscale SLA at a Tier III certified Indian operator commits to 99.999% availability on power feeds (5.26 minutes of permitted annual downtime), 99.99% on cooling (52 minutes) and 99.9% on the bundled service including network handoff (8.76 hours). Service-credit ladders begin around 5% of monthly recurring revenue per affected MW for the first breach band and step up to 25% to 50% for severe bands, with annual aggregate caps near 100% of MRR and termination rights where breaches recur within a rolling window. When the operator misses the SLA, it owes the tenant a credit. That credit is the pass-through: the tenant's outage loss is partly absorbed by the operator through the contract, regardless of which party's equipment failed.
Here is the insurance problem. The operator's standard consequential-loss (loss of profits) cover responds to the operator's own revenue loss when an insured peril damages the facility. It does not respond to a contractual service credit, because a service credit is a contractual liability, not lost revenue from physical damage. The two are mechanically different, and the BI wording is the place this gets decided. The mechanics of indemnity period, named perils and the time-element deductible that governs the operator's own loss-of-profits recovery are covered in depth in the data centre business interruption underwriting note; this post stays on the contractual-credit layer that sits beside it.
Indian insurers now offer a stand-alone SLA liability extension on operator programmes, with a separate limit (commonly INR 25 crore to INR 100 crore on a hyperscale operator) triggered when the SLA breach is causally linked to an insured physical peril. The cover responds well to a fire-triggered or flood-triggered outage. It responds poorly, or not at all, to the events that produce the most frequent SLA breaches: cooling control-system failures, network handoff failures and human error, none of which involve a clearly insured proximate cause of physical damage. The exclusion stack typically removes SLA breaches caused by tenant action, by force majeure, by upstream telecom or discom failure, and by ordinary operator error. For the discom and grid-outage piece specifically, the underwriting treatment is set out in the AI data centre power outage underwriting note.
For the tenant side, the SLA credit is only a partial recovery. The credit is capped at a fraction of MRR, while the tenant's true outage loss (lost compute, missed delivery commitments, delayed AI training campaigns) can run far higher. The gap above the credit and above the operator indemnity cap is what the tenant's own contingent business interruption (CBI) cover must reach, which we address in the customer-equipment section below.
The Boundary: Tenant Customer-Equipment Cover vs Operator Property Cover
The boundary between tenant customer-equipment cover and operator property cover is the most operationally significant line in the colocation insurance ecosystem, because it is where a single physical event splits into two claims on two separate insurer panels. Drawing it correctly, and writing each policy so it actually meets the other at the line, is the work that prevents uninsured gaps.
The coverage logic, in principle, is clean. Operator property cover responds to operator-owned infrastructure up to the demarcation point. Tenant customer-equipment cover (also written as tenant equipment all-risks or as an extension of the tenant's electronic equipment insurance) responds to tenant-owned IT hardware beyond it. The MSA defines the demarcation point, typically at the network handoff or the cage perimeter, and that definition is the reference both policies should incorporate so neither insurer can argue the loss falls in the other's territory.
In practice the boundary produces three recurring disputes. First, propagation: damage that begins in operator infrastructure (a cooling failure, a UPS surge, fire spread, water from a chilled-water leak) reaches tenant equipment, and proximate-cause analysis must allocate the loss across the two policies. Second, timing and information: one physical event generates two claims handled by two panels on different timelines, and information sharing across the panels can stall settlement. Third, subrogation: where the operator carries any fault, the tenant equipment insurer's subrogation right engages the operator's liability cover, opening the third claim track that the MSA subrogation-waiver clause is meant to close.
For a broker advising the tenant, three positions are non-negotiable on the customer-equipment programme:
- The perils wording must explicitly reach operator-originating causes (cooling failure, UPS failure, fire spread, water damage from cooling leaks, electrical surge) with no exclusion for events that start in operator infrastructure. A customer-equipment policy that excludes operator-originating perils leaves the most likely loss uninsured.
- The sum insured must track current replacement cost, not historic capex, because AI accelerator hardware has repriced sharply and a single rack of current-generation GPUs can represent a far higher value than the rack it replaced. Quarterly sum-insured review is appropriate where AI hardware is being added.
- The BI or contingent BI extension must reach the gap above the operator's SLA credit and above the operator indemnity cap, must name the operator facility, and should provide for recovery at an alternative site (disaster-recovery relocation, recovery run-rate inefficiency) where the colocation hall is unavailable.
For a broker advising the operator, the mirror positions are: align the public-liability sub-limit with the aggregate tenant-equipment exposure across the hall (because a single propagating event can trigger liability to many tenants at once), maintain professional indemnity for design and management failures that tenants may allege, and structure the MSA indemnity cap to sit within recoverable liability limits. The per-MW property and fire benchmarks that size the operator's own first-party cover sit in the Indian data centre operator risk profile; the interface point here is purely the liability-to-tenant-equipment alignment.
DPDP Act: Allocating Tenant-Data Liability Between Operator and Tenant
The Digital Personal Data Protection Act, 2023, with implementation rules notified through 2025-26, reshapes how data liability is allocated between a colocation operator and its tenant. The allocation runs through the contract, not through the statute, which is why it belongs in this interface analysis rather than in a generic compliance discussion.
Under the DPDP Act, statutory penalty exposure attaches to the data fiduciary (the entity that determines the purpose and means of processing) and, to a defined extent, the data processor (the entity that processes on the fiduciary's behalf). A colocation operator that provides only space, power, cooling, security and network, without touching tenant data content, is generally neither fiduciary nor processor for the tenant's personal data. The tenant is the fiduciary. The Data Protection Board of India, operative since H1 2025, can levy penalties up to INR 250 crore for failure to take reasonable security safeguards, INR 200 crore for failure to notify a breach, and lower amounts for other heads, and those penalties fall on the fiduciary, that is, the tenant.
The operator's exposure is therefore indirect, and it travels along two MSA-driven paths. First, the tenant indemnity flow: the tenant fiduciary will seek indemnity from the operator wherever a breach is traceable to operator infrastructure or process failure (physical access control, environmental failure that destroyed data, operator-personnel action). Even with no statutory penalty against the operator, this contractual indemnity can produce a material operator claim. Second, the operator personnel and vendor path: the operator's own staff and contractors handling tenant equipment can create incidents the tenant treats as operator-caused for indemnity purposes. CERT-In direction obligations (six-hour incident notification, 180-day log retention) apply to the operator directly and feed the same indemnity exposure where non-compliance contributes to a breach.
The allocation question for the contract is who bears which slice of a data-breach loss. Hyperscale tenants negotiate broad operator indemnities for breaches attributable to operator failure, with carve-outs for tenant fault, and with the data-breach head frequently carrying a super-cap above the general indemnity cap. The operator's cyber liability cover must be read against this contractual exposure: it should respond to first-party breach-response costs and to third-party tenant indemnity claims for breaches traceable to physical access, infrastructure failure or operator personnel.
The insurability of DPDP Act statutory penalties under the regulatory-liability head is contested, and in any event the penalty falls on the tenant fiduciary, not the operator, so for the operator the live exposure is the contractual indemnity rather than the penalty. Wordings vary; the consolidating 2026 pattern provides defence-costs cover with an explicit statutory-penalty exclusion. For brokers, three contract-interface positions follow:
- Align the operator's data-breach indemnity cap with recoverable cyber cover. An operator should not accept a super-cap data-breach indemnity that exceeds its cyber limit.
- Confirm the operator's cyber wording responds to tenant indemnity claims, not only to the operator's own first-party breach costs, because the indemnity flow is where the operator's real DPDP exposure lives.
- Treat residual statutory-penalty exposure as a separate risk-financing question for the tenant fiduciary, with the operator's role limited to the contractual indemnity it has agreed and funded.
Broker Playbook: Advising the Operator Side and the Tenant Side
Because the colocation interface has two principals, the broker engagement splits into two distinct playbooks. A broker may act for the operator, for the tenant, or (in a larger firm with separated client teams) for both in unrelated engagements with shared market intelligence. Each side has a different deliverable, but both turn on reading the counterparty's cover and the MSA risk-allocation clauses alongside the client's own programme.
Advising the operator
The operator-side deliverable is a programme that funds every indemnity the operator signs and an SLA liability layer that matches the credit exposure the operator carries. The priorities:
- Match indemnity to insurance. Run the MSA indemnity heads (general, data-breach super-cap, personal-injury super-cap) against available liability and cyber limits and refuse, or reprice, any indemnity that exceeds recoverable cover.
- Place the SLA liability extension deliberately. Confirm the trigger (insured physical peril, causally linked), map the exclusion stack against the operator's most frequent outage causes, and tell the operator plainly which outage types fall outside cover (cooling control failures, network handoff, human error, discom).
- Maintain the COI and additional-insured machinery. Ensure the additional-insured endorsements demanded by tenants actually exist on the policy and match the MSA wording, and that the subrogation waiver is permitted by the policy condition.
- Pre-position claims advocacy. Document surveyor selection (the pool with genuine data centre loss experience is small; international firms engage above the larger loss thresholds), notification triggers, and the protocol for a multi-tenant propagating loss where four insurer panels respond at once.
The per-MW pricing, sums-insured sizing and reinsurance-panel mechanics for the operator's own first-party programme are covered in the Indian data centre operator risk profile and, at the largest scale, the hyperscale data centre operator insurance profile; the operator-side broker uses those benchmarks as inputs, then does the interface work above.
Advising the tenant
The tenant-side deliverable is a cover stack that reaches every loss the operator's indemnity and SLA credit do not. The priorities:
- Calibrate customer-equipment cover to replacement cost and confirm the perils wording reaches operator-originating causes with no exclusion.
- Size CBI to the gap. The CBI sum insured must reach above the SLA credit and above the operator indemnity cap, name the operator facility, allow for partial-hall outage, and respond to operator-originating perils.
- Coordinate the cyber programme with the operator's incident-response obligations, so a breach traceable to operator infrastructure produces a clean indemnity claim rather than a coverage argument.
- Support the MSA negotiation. Review the operator indemnity scope, cap and super-caps, the subrogation-waiver and additional-insured grants the tenant receives, and the force-majeure language that can quietly shift loss back to the tenant.
Where the integrated broker adds value
Three engagement types reward a broker who can see both sides: a hyperscale RFP where the tenant is choosing among operators and wants each operator's insurance and indemnity posture scored alongside commercial terms; an MSA dispute where ambiguous loss allocation needs a broker who can read both programmes; and a multi-tenant major loss where inter-insurer negotiation runs in parallel with operator-tenant negotiation.
Platforms that let a broker hold the operator programme, the tenant programme and the MSA risk-allocation clauses in a single view make this interface work faster and more defensible. Sarvada supports brokers in delivering that integrated operator-and-tenant analysis for colocation engagements. Request Access to evaluate it for your technology-infrastructure clients.