Data Residency Compliance for Indian IT Services Firms 2026: DPDP Act, Cross-Border Cyber and PI

This post treats the Indian IT and ITES sector as the insured vertical, and the defining feature of that vertical is simple to state and hard to insure: these firms hold enormous volumes of someone else's data under contract. A tier-1 major runs payroll, claims, card transactions, electronic health records, and source code for thousands of foreign and domestic clients. The firm is rarely the data controller. It is the processor, the data fiduciary's agent, the vendor on the hook through a master-service agreement. That contractual position, rather than the firm's own balance sheet exposure, is what shapes the cyber and professional indemnity (PI) programme.

For brokers and corporate risk managers, the practical question is not "what does Indian data protection law require of this firm" in the abstract. It is "what does this firm owe its clients when client data it processes is breached, and does its insurance programme respond to that obligation." The answer turns on sector structure, the contractual cyber requirements global clients impose, and how cyber and PI cover stack against a single delivery failure.

Four segments, four risk shapes

• Tier-1 majors (TCS, Infosys, Wipro, HCL, LTIMindtree, Tech Mahindra scale). Revenue USD 5 to 35 billion, North America 50 to 65 percent of revenue, Europe 25 to 30 percent. Thousands of concurrent client engagements means a single ransomware event or a common platform defect can trigger claims across many client contracts at once. Aggregation, not single-claim severity, is the dominant exposure.
• Global capability centres (GCCs). Captive technology and back-office arms of multinationals operating in India. They process group data rather than third-party client data, so the exposure runs to the parent and the parent's regulators. Insurance usually sits inside the parent's global programme, with a local Indian admitted layer for DPDP Act and CERT-In compliance.
• Mid-tier IT services firms (USD 0.5 to 5 billion revenue). Fewer but larger engagements. A single flagship client can represent a disproportionate share of liability, so one demanding MSA can drive the whole programme structure.
• SaaS and product firms. They typically control rather than merely process data, run multi-tenant platforms, and carry tech errors-and-omissions exposure alongside cyber. A platform-wide breach hits every tenant simultaneously.

The rest of this post builds the programme for these firms. It deliberately does not relitigate the India-EU transfer corridor, the insurer's own group-programme data flows, or DPDP compliance for insurance operations themselves. Those are distinct lanes covered in the siblings cross-linked below; here the firm is the insured, and client data under contract is the asset at risk.

The compliance obligations that matter to an IT services firm are largely derived obligations: requirements that flow down from the client's regulator and the client's contract, layered on top of India's own framework. Understanding which rules attach to which client data, and where that data must physically sit, is the foundation of programme design.

The Indian baseline

• DPDP Act 2023. With rules notified through 2024 and 2025, the Act governs digital personal data processed in India, including data the firm processes on behalf of others. Where the firm acts as a data processor for a client (the data fiduciary), contractual flow-down obligations apply, and the Data Protection Board's penalty exposure of up to INR 250 crore per breach is the headline financial risk. Firms designated Significant Data Fiduciaries carry heightened obligations they must pass into client engagements.
• CERT-In Direction (28 April 2022). Mandatory reporting of specified incidents within 6 hours of detection, plus 180-day log retention. For a firm running client systems, the 6-hour clock starts on detection across the client estate, not just the firm's own network.
• RBI data localisation (2018 payment-systems framework). Where the firm serves BFSI clients in the payment ecosystem, all payment system data must be stored only in India. This is the single most operationally constraining residency rule for IT services firms with banking and card clients, and it directly shapes where delivery centres and cloud regions sit.
• IT Rules 2021. Apply where the firm provides intermediary or platform technology, directly and through client engagements.

How residency converges in 2026

For client data, residency is driven primarily by the client's home regime and contract, then reconciled with Indian rules. A US healthcare client's data arrives under HIPAA Business Associate terms; a European client's under GDPR transfer mechanisms; an Indian bank's payment data must never leave India under RBI rules. The firm's job is to map each data category to a compliant location and access model. Common operating patterns:

• Dedicated onshore delivery centres in the client jurisdiction, with data never leaving that jurisdiction.
• Data kept in client-region cloud, with Indian engineers accessing remotely under controlled, logged sessions.
• Anonymisation or tokenisation before any transfer to India, reducing the sensitivity of what crosses borders.

The insurance consequence is direct: a residency control failure (payment data replicated to an Indian region, an engineer downloading EHR to an endpoint) is simultaneously a regulatory breach, a contractual breach of the MSA, and a likely trigger for both the cyber and PI programmes. The convergence of DPDP, CERT-In, RBI localisation and IT Rules in 2026 means a single control lapse rarely sits under one regime alone.

The corridor mechanics for moving European data into India (Schrems II, Standard Contractual Clauses, the India-EU position) are a specialised topic in their own right. For that detail see cross-border data transfer and cyber cover for the India-EU corridor. The point for the IT services firm is operational: the corridor mechanism is something the client typically owns, while the firm owns compliant processing and storage on the India side, and the programme must respond to failures of the latter.

Cyber cover for an IT services firm is fundamentally third-party-heavy. The firm's own downtime matters, but the dominant exposure is liability to clients and to clients' data principals when client data the firm holds is compromised. The programme should be built around that liability.

What the cover must reach

• First-party. Incident response, forensics, breach counsel, business interruption, data restoration, and ransomware (where lawful). Useful, but secondary for this vertical.
• Third-party liability. Liability to clients and to affected data principals for breaches of client data; regulatory investigation and penalty cover; defence costs for class actions and regulator enforcement across multiple jurisdictions; multi-jurisdiction breach notification and credit-monitoring costs.
• Regulatory penalty cover specific to the firm. DPDP Act penalties up to INR 250 crore per breach, plus parallel foreign exposure (GDPR up to 4 percent of global turnover, US federal and state penalties, HIPAA). For a firm holding many clients' data, multiple breach events can stack, so aggregate penalty capacity, not just per-event, needs sizing.

Sizing and structure

Tier-1 majors typically run cyber limits of USD 100 to 500 million; mid-tiers USD 50 to 150 million; smaller firms USD 10 to 50 million. High-limit cyber capacity is scarce, so any programme above roughly USD 100 million is a multi-layer, multi-jurisdiction tower:

• Indian primary layer (USD 50 to 100 million) through ICICI Lombard, HDFC Ergo, TATA AIG, Bajaj Allianz and peers.
• A GIFT City IFSC layer (USD 25 to 100 million) through IIO entities of global cyber specialists.
• Singapore Lloyd's and London market specialty layers above that.
• Occasionally a US market layer aligned to the client geography.

Domestic Indian insurers rely on global reinsurance (Munich Re, Swiss Re, Hannover Re, SCOR, Lloyd's syndicates) to deliver these limits; the reinsurance and master-local mechanics of how that capacity is structured for global buyers are a separate subject covered in cross-border data transfer rules under DPDP and their impact on global insurance programmes.

Underwriting reality in 2026

The market remains firm, with rates of 2 to 5 percent of limit. Underwriters scrutinise controls that protect client data specifically: tenant isolation and segmentation, privileged access management for engineer access to client systems, endpoint controls on delivery machines, encryption in transit and at rest, supply-chain and software-bill-of-materials hygiene, and demonstrable CERT-In and DPDP readiness. Submission preparation is heavy and should be led jointly by the firm's CISO, risk function, and broker.

The single most consequential structuring decision for an IT services firm is how cyber and professional indemnity (PI) cover interlock. The two policies are bought to answer different questions, but real claims rarely respect the boundary.

The boundary that does not hold

• PI answers: did the firm make a professional error? Defective code, a misconfiguration, bad architecture advice, a missed project deliverable, IP infringement in delivered work.
• Cyber answers: was there a security incident or data breach? Intrusion, exfiltration, ransomware, privacy breach.

Now take a realistic claim. The firm builds an application for a client, leaves an authentication flaw in it, the flaw is exploited, and the client's customer data is exfiltrated. This is a professional error (PI) that caused a data breach (cyber). Without coordination, each insurer points at the other, and the firm sits in the gap while clients and regulators press for response.

Designing the stack so it holds

• Consistent triggers and definitions. Align the definitions of "claim," "breach," "professional services," and the notification triggers across both wordings so a single event cannot fall between them.
• Decide which policy leads on overlap. For delivery-caused breaches, many firms make cyber the lead for the breach response and recovery, with PI responding to the underlying error-and-omission liability and IP exposure. Document this rather than leaving it to post-loss negotiation.
• Difference-in-conditions and difference-in-limits. PI usually has broader scope for pure professional errors but lower limits; cyber has higher limits but narrower trigger. DIC/DIL provisions let the covers stack with an agreed order rather than competing.
• Insureds-vs-client carve-backs. Some legacy wordings limit cover for claims brought by the insured's own customers. For an IT services firm whose claimants are almost always clients, this must be carved back, or the cover is illusory for the most common claim.
• Single lead or coordinated panel. Placing both lines with the same lead, or with insurers who have an agreed coordination protocol, materially reduces post-loss dispute.

Sizing PI to the contract, not the firm

PI limits for tier-1 majors typically run USD 50 to 200 million, mid-tiers USD 25 to 75 million. The limit should be driven by the contractual liability in the firm's most demanding MSAs and by IP infringement exposure (which can carry large damages and is often a sub-limit worth checking). Because one ransomware event or one common platform defect can breach many MSAs at once, the combined cyber-plus-PI tower should be tested against simultaneous multi-client claims, not a single average engagement.

Claims in this space are technically contested (whose fault, what damages, which liability cap), so broker claims-advocacy capability is a genuine differentiator and should be evaluated alongside placement capability.

For an IT services firm, the master-service agreement is effectively the real insurance specification. Global clients, especially in North America and Europe, dictate the cyber and insurance requirements the firm must meet, and the firm's own programme has to be reverse-engineered from those obligations.

What global client contracts now demand

• Prescribed security controls (technical and organisational measures, often mapped to ISO 27001, SOC 2, or the client's own standard).
• Breach notification on tight clocks, frequently shorter than any regulator's, sometimes 24 or 48 hours, occasionally less.
• Cooperation and audit rights during incidents and investigations.
• Mandatory insurance clauses specifying minimum cyber and PI limits, sometimes naming the client as additional insured or requiring waivers of subrogation, and requiring certificates of insurance as a condition of award.
• Specific cyber and data liability provisions sitting outside the general liability framework.

How liability caps actually run

General contract liability is often capped at one to two times annual contract value. But for cyber and data incidents, the market has moved to separate, higher arrangements:

• Higher dedicated caps for cyber and data events (often three to five times contract value, or a fixed sum such as USD 50 to 100 million per contract).
• Per-incident caps with an aggregate over the contract term.
• Regulatory penalties frequently carved out of the cap, sometimes uncapped.
• Indemnities (data breach, IP infringement) that may sit outside the general cap entirely.

Translating MSAs into the programme

The firm indemnifies the client for losses from the firm's breaches up to the indemnity limit, so the firm's cover must respond to liability it has assumed by contract. Brokers should check three things on every material MSA: that the wording covers contractually assumed liability (not just liability imposed at law); that the limits are adequate for the largest caps and uncapped indemnities across the client book simultaneously; and that the insured-vs-client carve-back discussed earlier is in place so client claims are not excluded.

A disciplined firm runs MSA review through the broker before signature, flagging clauses that are uninsurable as drafted (uncapped consequential loss, unlimited indemnity, notification clocks the programme cannot meet) so they can be negotiated or backed by a specific endorsement. The DPDP compliance obligations that the firm owes as an entity, as distinct from the contractual obligations it owes its clients, are addressed for insurance operations themselves in the DPDP Act and its implications for Indian insurance operations; for the IT services firm, the MSA is usually the more binding constraint than the statute alone.

Pulling the threads together, here is how the integrated cyber and PI programme is priced and built for the segments in this vertical.

Pricing anchors (2025 to 2026)

• Cyber: 2 to 5 percent of limit annually. A tier-1 major with USD 200 million in cyber limit pays roughly USD 4 to 10 million.
• PI: 0.8 to 2.5 percent of limit annually. USD 100 million of PI runs roughly USD 1 to 2.5 million.
• Combined for a tier-1 major: roughly USD 5 to 15 million annually depending on structure, claims history, client mix, and control maturity.

Rate drivers, in order of weight for this vertical: demonstrable control maturity around client data (tenant isolation, privileged access management, encryption), claims history, proportion of regulated-client work (BFSI, healthcare) carrying heavier residency and liability load, and the size of the largest contractual liability caps.

Capacity by segment

• Tier-1 / USD 300 million-plus towers: Indian primary USD 50 to 100 million, GIFT City IFSC USD 25 to 100 million, Singapore Lloyd's and London specialty above, occasional US layer for client-geography alignment.
• Mid-tier (USD 1 to 5 billion revenue): cyber USD 50 to 150 million (premium USD 1 to 5 million), PI USD 25 to 75 million (premium USD 250,000 to 1.5 million); fewer layers, still typically Indian primary plus IFSC plus a specialty layer.
• GCCs: usually folded into the parent's global tower, with a local admitted Indian layer for DPDP Act and CERT-In compliance and to satisfy any India-side contractual or regulatory requirement.
• Smaller / SaaS firms: cyber USD 10 to 50 million, PI (with tech E&O) USD 5 to 25 million, predominantly Indian primary with limited international participation; the binding driver is usually the enterprise customer's procurement checklist.

A practical build sequence

1. Map the data the firm holds by client, category, and required residency (run the BFSI / payment-data and healthcare buckets first, they carry the heaviest constraints).
2. Extract the cyber, insurance, liability-cap, indemnity, and notification clauses from the firm's top MSAs; these set the minimum limits and wording requirements.
3. Test aggregate exposure against a single event hitting multiple client contracts at once (ransomware, common platform defect), not an average claim.
4. Prepare a controls-heavy submission and engage Indian primary, GIFT City IFSC, Singapore, and London markets.
5. Structure cyber and PI together with explicit DIC/DIL, aligned triggers, insured-vs-client carve-backs, and a documented lead-on-overlap rule.
6. Review wordings layer by layer for consistency, then manage the programme with annual review as the client book and threat environment shift.

Platforms supporting integrated cyber-and-PI programme analysis and counterparty review for technology-services buyers are emerging in the Indian market. Sarvada supports brokers in delivering structured programme analysis for IT services and GCC buyers. Request Access to evaluate it for cyber and PI design and counterparty analysis.

For a firm at the edge of the corridor decision, weigh the India-EU mechanics in the India-EU cross-border data transfer and cyber cover post before finalising where European-origin engagements are delivered, since the delivery location flows straight back into residency controls and therefore the cyber programme.

Looking forward, four shifts will keep the IT services programme moving, and each one maps to a programme lever brokers and risk managers should watch.

• DPDP enforcement maturing. As the Data Protection Board accumulates cases through 2026 and 2027, practical compliance standards for data fiduciaries and processors will sharpen. Expect underwriters to ask harder, more specific questions about how the firm handles client data and demonstrates DPDP and CERT-In readiness, and expect regulatory-penalty cover to become a more contested line.
• MSAs getting stricter. Global clients continue tightening cyber clauses, shrinking notification windows, and raising or carving out cyber and data liability caps. The MSA, not the statute, will keep driving required limits upward for firms with large North American and European books.
• Aggregation rising. As tier-1 and mid-tier firms consolidate clients onto common platforms and shared cloud estates, a single incident reaches more clients at once. Programme sizing should increasingly be stress-tested for correlated, multi-client loss rather than single-engagement severity.
• GCC growth. The captive segment keeps expanding. Brokers should expect more requests to fit Indian admitted layers under parent global towers, and to reconcile DPDP and CERT-In obligations with a programme structured abroad.

The through-line is consistent with where this post started. The Indian IT and ITES firm is insured not primarily for its own losses but for its responsibility over client data it holds under contract. Keep the cyber and PI covers coordinated, size them to the toughest MSAs and to correlated multi-client events, and confirm DPDP and foreign regulatory penalties are genuinely covered. The corridor mechanics, the insurer's own group-programme data flows, and DPDP compliance for insurance operations are real and important, but they belong to the sibling lanes cross-linked above; for this vertical, the firm and the client data on its servers are the risk.