Cross-Border Data Transfer Rules Under DPDP and Their Impact on Global Insurance Programmes

Section 16 of the Digital Personal Data Protection Act, 2023 sets out the framework for transferring personal data outside India. The section adopts a blacklist approach: transfers are permitted to all countries except those specifically notified by the Central Government as restricted. As of April 2026, no such restricted country list has been issued, which means Indian insurers, brokers, and corporate policyholders can currently move personal data to the United Kingdom, United States, Bermuda, Switzerland, Singapore, and every European Union member state without needing country-specific authorisation.

This permissive default is deceptively simple. Section 16(2) expressly preserves any higher restriction imposed by sectoral laws, meaning IRDAI's data localisation and cyber security directions continue to apply in parallel. The IRDAI Information and Cyber Security Guidelines, 2023 (circular IRDAI/IT/GDL/MISC/82/4/2023 dated 24 April 2023) require insurers to maintain policyholder and claims data within Indian data centres unless specific exemptions apply. Section 16 therefore governs personal data flows outside India only insofar as no sectoral rule already restricts them.

For a global insurance programme covering an Indian subsidiary of a multinational corporation, this dual-layer regime matters. A master policy issued by AIG in London covering the worldwide group, with a local India policy issued by Tata AIG under a fronting arrangement, will involve Indian personal data (employee names, PAN details, claims information) flowing to the London master underwriter, to the captive reinsurer in Bermuda or Guernsey, and potentially to a European third-party administrator. Each of these data flows must be justified under Section 16, the IRDAI Guidelines, and, where relevant, GDPR at the receiving end.

Indian insurers and brokers should treat the current permissive environment as a planning window rather than a permanent state. The Central Government retains the authority under Section 16(1) to restrict any country at any time, and the Data Protection Board can direct specific Data Fiduciaries to halt transfers where security safeguards are inadequate. Building contractual and technical safeguards now, before a restriction is imposed, avoids the disruption of having to unwind data flows mid-policy.

Master-local structures are the workhorse of multinational insurance. A corporate group with operations in 40 countries buys a single master policy in London or Zurich, and each jurisdiction's insurance regulator requires a locally admitted policy issued by a domestically licensed insurer. In India, IRDAI's fronting regulations under the IRDAI (Insurance Business in Special Economic Zones) Rules and the reinsurance regulations governing cessions mean the local Indian insurer retains primary responsibility while the majority of premium and risk flows upstream to the master carrier.

The data architecture of these programmes is intricate. Bordereau files containing Indian policyholder data (including sums insured, claim values, and in some lines of business, personal data of directors, employees, or patients) are exchanged between the Indian fronting insurer, the local broker, the global broker in London, the master underwriter, and the reinsurance panel. For a property programme, the data may include employee counts at each Indian location. For a D&O programme, it will include named insured persons, their PAN numbers, and their directorship histories. For a global health programme, claims data will include sensitive personal data of Indian employees and their dependents.

Under the DPDP Act, the Indian fronting insurer is the Data Fiduciary for all Indian-origin personal data in the bordereau. The London master underwriter and the Bermuda reinsurer are Data Processors or joint Data Fiduciaries depending on the contractual arrangement. Section 8(2) makes the Data Fiduciary responsible for ensuring that every downstream processor complies with the Act, which means the Indian insurer must push DPDP obligations down the chain through contract.

Practically, this means updating the standard fronting agreement template. Older fronting agreements rarely address data protection with any specificity. Current versions should include clauses specifying the categories of personal data transferred, the lawful basis for transfer, the permitted purposes, sub-processor restrictions, security standards (aligned with ISO 27001 and the IRDAI 2023 Guidelines), breach notification timelines matching CERT-In's six-hour requirement, and a data deletion protocol for when the treaty period ends. Absent these clauses, the Indian fronting insurer bears the full weight of DPDP liability while the offshore parties retain practical control of the data.

Third-party administrators are a common feature of global health, travel, and liability programmes. A European TPA (for example, Cigna Global in Belgium or AXA Partners in France) may handle claims for Indian employees of a French or German parent company under a global health programme. The TPA receives sensitive personal data, including medical diagnoses, treatment records, hospital invoices, and bank details for reimbursement.

For the Indian insurer transmitting this data, Section 16 of the DPDP Act permits the transfer because no EU country is currently restricted. For the TPA receiving the data, the GDPR applies with full force, including Article 9's special category rules for health data and Article 44 onwards governing international data transfers. The TPA's onward transfers, for example, to a sub-processor in the Philippines for claims indexing, must be covered by GDPR-compliant mechanisms such as standard contractual clauses or adequacy decisions.

The Digital Operational Resilience Act (DORA), which became fully applicable across the EU on 17 January 2025, adds another layer for EU-licensed insurers and their service providers. DORA categorises TPAs and IT service providers as critical third-party ICT service providers, subject to concentration risk monitoring, contractual specifications under Article 30, and regulatory oversight under Articles 31 to 44. For an Indian insurer feeding claims data into an EU TPA's systems, DORA is not directly applicable, but the EU TPA's DORA obligations translate into contractual demands (audit rights, subcontracting restrictions, exit provisions) that flow back to the Indian end of the relationship.

The practical result is that the Data Processing Agreement between the Indian insurer and the EU TPA must reconcile three regimes: DPDP Act obligations owed to Indian Data Principals, GDPR obligations triggered by the TPA's establishment in the EU, and DORA-driven governance requirements imposed on the TPA by its local regulator. Well-drafted DPAs treat this reconciliation explicitly, identifying which regime applies to which category of data and which party bears the compliance cost for each obligation. Poorly drafted DPAs leave the allocation ambiguous, creating the risk of duplicative compliance work or, worse, gaps where no party is clearly accountable.

Global liability towers, particularly for D&O, cyber, and product liability lines, are built on layered capacity from insurers in multiple jurisdictions. A USD 500 million D&O tower for an Indian-headquartered multinational may involve an Indian primary insurer, a Lloyd's excess layer, a Bermuda quota share, and a Swiss reinsurer on the top layer. Placing or renewing this tower requires loss run data to be aggregated across years and jurisdictions and shared with every prospective underwriter on the panel.

Loss runs for D&O and cyber lines contain personal data by definition. Director names, executive roles, allegations (often involving personal conduct), settlement values, and claimant identities are embedded in the data. Sharing this loss run with a panel of 15 underwriters across five countries means 15 cross-border transfers, each subject to Section 16 of the DPDP Act and any applicable local law at the receiving end.

The technique most sophisticated brokers use is data tiering. The full loss run, with named individuals and detailed narratives, is shared only with the insurers on the final placement panel under a non-disclosure agreement. Prospective insurers who are shortlisted but not yet bound see a redacted version where personal identifiers are anonymised or pseudonymised. Early-stage market soundings use purely aggregated data: loss ratios, frequency, severity, and no personal identifiers. This tiering approach reduces the population of personal data flowing across borders and limits the DPDP Act exposure accordingly.

For Indian corporate risk managers placing global towers, data tiering should be written into the broker's service agreement. The broker should warrant that personal data is shared only with insurers under binding confidentiality and data protection obligations, that anonymisation is applied wherever risk assessment does not require named data, and that a record of data sharing is maintained and available on request. This record becomes important if a Data Principal (for example, a former director whose name appears in a loss narrative) exercises their right to access under Section 11 of the DPDP Act and asks who has received their data.

US litigation discovery is the single largest source of involuntary cross-border data transfer for Indian insurers and their insureds. A securities class action in the Southern District of New York against an Indian company with US-listed ADRs can trigger document requests covering hundreds of gigabytes of email, policy files, claims records, and board materials, all of which may contain personal data of Indian citizens. Discovery orders issued by US courts do not pause for foreign data protection regimes, and non-compliance can result in adverse inferences, monetary sanctions, or default judgments.

Section 16 of the DPDP Act does not contain an explicit exemption for foreign legal process. Section 17(1)(c) does permit processing necessary for compliance with any judgment or order issued under Indian law, but this does not extend to foreign judgments. For Indian insurers responding to US discovery on a policy covering an Indian insured, the only practical option is to rely on consent from the relevant Data Principals (often impractical given the number of individuals involved) or on the lawful use ground under Section 7(1)(b) for performance of a contract, where producing the policy file is a precondition to defending the claim under a duty-to-cooperate clause.

For personal data specifically, the safer path is data minimisation before production. Privileged review tools can tag personal data, and the production set can be limited to what is directly responsive to the discovery request. Where the data is not necessary to the underlying merits (for example, the email addresses of unrelated recipients on a cc list), redaction should be the default. Privilege logs, privilege challenges, and protective orders can all be used to narrow the scope of production.

A secondary concern is the EU blocking statute and national blocking laws such as France's Loi de blocage. If a global insurance programme involves data in both India and France, a US discovery demand can trigger conflicting legal obligations: produce under US law, but criminal exposure under French law for producing French-origin data without channelling through the Hague Convention. Experienced outside counsel coordinating across jurisdictions is essential when multiple blocking regimes interact, and the insurer's incident response plan should include a protocol for notifying coverage counsel at the earliest sign of a foreign discovery subpoena.

The contractual toolkit for managing cross-border data transfer in insurance has matured. Three mechanisms now dominate: standard contractual clauses, data processing agreements with reinsurers, and binding corporate rules for Indian multinationals operating captive insurance structures.

Standard contractual clauses, originally a GDPR innovation, have become the default mechanism for data transfers involving EU counterparties. The 2021 EU SCCs (Commission Implementing Decision 2021/914) offer four modules: controller-to-controller, controller-to-processor, processor-to-processor, and processor-to-controller. For a global insurance programme where an Indian insurer (controller under DPDP) transfers claims data to an EU TPA (processor), the controller-to-processor module is the standard choice. The SCCs impose specific obligations including purpose limitation, security measures, sub-processor consents, and data subject rights, and they are enforceable by the Data Principal as a third-party beneficiary.

Data processing agreements with reinsurers are the more insurance-specific mechanism. A reinsurance DPA typically sits as a schedule to the reinsurance treaty or facultative slip and addresses categories of personal data transferred (proposal data, claims data, loss run data), purposes of processing (risk assessment, claims handling, actuarial analysis, regulatory reporting), security standards (ISO 27001 or equivalent), breach notification timelines (commonly 72 hours to align with GDPR, though DPDP Act rules may impose tighter timelines once notified), sub-processor restrictions (typically requiring written consent for onward sharing with retrocessionaires), and data return or deletion obligations at treaty expiry. Reinsurance DPAs should be negotiated at placement rather than renewal, as changing a DPA mid-treaty is procedurally difficult.

Binding corporate rules are the heaviest-weight mechanism and are generally appropriate only for large Indian multinationals with captive insurance operations. BCRs under GDPR Article 47 are internal codes of conduct approved by a lead supervisory authority that permit intra-group data transfers across jurisdictions without SCCs. For an Indian group with a Guernsey captive, a European holding company, and Indian operating subsidiaries, a unified BCR can simplify the contractual architecture significantly. The approval process takes 18 to 24 months and requires commitment from the top of the group, but once approved, BCRs provide enduring transfer authority and reduce the administrative burden of managing dozens of bilateral SCCs.

The most resilient data architecture separates personal data from de-identified underwriting data at the source. Personal data (names, PAN, Aadhaar, health information, financial identifiers) is retained within Indian data centres and shared across borders only when strictly necessary and only under appropriate safeguards. Anonymised or pseudonymised underwriting data (risk characteristics, sums insured, loss ratios, industry codes) flows freely to global underwriting platforms, analytics providers, and reinsurance markets because it falls outside the DPDP Act's scope once the identifiability link is severed.

The engineering discipline required to do this well is not trivial. True anonymisation, as understood in GDPR jurisprudence and expected to be mirrored in DPDP Act rulemaking, requires that the data cannot be re-identified even by combining it with other information reasonably available to the recipient. Pseudonymisation, where a key allows re-identification, remains personal data and is still subject to the DPDP Act. Many insurance data sets sit in the pseudonymised category rather than the anonymised one, particularly where the holding company retains the key or where the data is granular enough to permit re-identification by inference.

For most underwriting purposes, genuine anonymisation is achievable. A reinsurer pricing a property treaty does not need the name of the individual insured; it needs the occupancy type, sum insured, sprinklered status, COPE data, and loss history. A D&O underwriter pricing a programme for an Indian-listed company needs the company's sector, market cap, litigation history, and governance metrics; the individual directors' names matter only at the named-insured stage, which can be handled separately under targeted consent. Designing the data pipeline to strip identifiers early in the flow, before it crosses the border, is technically achievable and materially reduces DPDP exposure.

Sarvada's underwriting intelligence platform treats this separation as a design principle. Risk scoring, exposure analysis, and actuarial model inputs are generated in anonymised form wherever the underlying decision does not require identified data, with personal data kept in localised, access-controlled environments and surfaced only to authorised personnel for specific purposes. This architecture is what allows Indian insurers to participate in global reinsurance markets without importing cross-border compliance risk into every workflow.

The classification of the broker under the DPDP Act is one of the most contested questions in the Indian insurance market. Section 2(i) of the Act defines a Data Fiduciary as any person who, alone or in conjunction with others, determines the purpose and means of processing personal data. Section 2(k) defines a Data Processor as a person who processes personal data on behalf of a Data Fiduciary. The broker's position depends on whether they determine the purpose of processing (collecting and submitting proposal data to multiple markets, managing claims data across carriers) or merely execute instructions from the client.

The prevailing view, supported by the IRDAI (Insurance Brokers) Regulations, 2018 and reinforced by the broker's fiduciary duty to the client, is that brokers are Data Fiduciaries in their own right. A broker collecting proposal data, approaching multiple insurers on behalf of the client, maintaining a central policy repository, and handling claims is exercising independent judgement about the purpose and means of processing. This means brokers carry the full weight of DPDP obligations: consent management, breach notification, data subject rights, security safeguards, and potentially Data Protection Officer appointments under Section 10 for Significant Data Fiduciaries.

For global brokers operating in India (Marsh, Aon, WTW, Howden, and the Indian operations of global groups), the practical implication is that their India broking entity is the Data Fiduciary for Indian clients, and data flows to affiliated entities in London, Singapore, or New York are intra-group cross-border transfers that must be documented under Section 16. Most global brokers have implemented intra-group data transfer agreements to address this, but these agreements need ongoing review as the DPDP Act rules evolve.

For Indian corporate clients selecting a broker for a global programme, the DPDP posture of the broker is now a procurement criterion. Clients should ask: does the broker have a documented DPDP compliance programme, where is policy and claims data stored, which affiliates receive Indian personal data and under what contractual basis, what is the breach notification protocol, and how does the broker handle data subject rights requests from employees covered under group policies? Brokers who can answer these questions crisply, with supporting documentation, are likely to be materially better positioned as enforcement ramps up.