DPDP's Cross-Border Negative List: How Insurers and Brokers Should Map Their Claims and TPA Data Flows

The Digital Personal Data Protection Rules, notified on 13 November 2025, settled a debate that ran for years. India did not adopt blanket data localisation. Instead Rule 15 sets a negative-list model: a data fiduciary may transfer personal data outside India except where the Central Government restricts that transfer to a specified country or class of recipients. As of mid-2026, no such restriction has been notified, and the cross-border provisions are expected to bite around May 2027 on the staggered timeline the Rules set out.

That sounds permissive, and on the surface it is. An Indian insurer can route claims data to a reinsurer in Munich, a TPA platform in Manila or a cloud region in Singapore without first proving adequacy, because nothing on a list says otherwise. The trap is that the list can appear with little warning, and when it does it operates retrospectively against flows you have already built. A broker who has spent two years standing up an offshore claims-processing stack does not get a grace period to unwind it if the destination country lands on the restricted list.

This is why the operational answer is a data-flow map, built now, while the cost of mapping is low and the cost of being caught flat-footed is hypothetical. Insurance is a named localisation-sensitive sector. The probability that insurer data attracts restrictions before, say, retail loyalty data is not low. Brokers who treat DPDP as a consent-banner problem have misread where the real exposure sits.

Rule 15's negative list is the headline. For most large insurers the binding constraint will be the Significant Data Fiduciary (SDF) regime under Rule 12 and related provisions. The government can designate a data fiduciary as an SDF based on volume and sensitivity of data processed, risk to data principals, and impact on sovereignty and public order. Insurers, banks, large telecom and hyperscale platforms are the obvious candidates. A general insurer holding crores of health and KYC records is squarely in frame.

Designation changes the maths. An SDF must appoint an India-resident Data Protection Officer, run a Data Protection Impact Assessment, undergo periodic independent audits, and accept that the government may bar offshore transfer of specified categories of personal data altogether. So even before any country-level negative list, an insurer designated as an SDF can find that a class of data (say, health claims fields, or biometric KYC) must stay onshore irrespective of where the broader negative list stands.

The asymmetry matters for placement. A mid-market broker running a single offshore TPA can move quickly. An insurer carrying SDF obligations cannot, because its DPIA, audit trail and category-level restrictions all assume a documented, governed transfer architecture. If you advise insurer clients, the SDF question ("are you designated, and if not, when do you expect to be?") should drive the data-flow conversation, not the negative list.

One clarification matters here. SDF designation is not self-assessed; it follows a government notification, so no insurer is an SDF until the government says so. The prudent posture is still to build as though designation is coming, because the controls an SDF needs (DPO, DPIA, audit, category mapping) take quarters to stand up rather than weeks. An insurer that waits for the notification before starting will be designated and non-compliant on the same day.

A point that gets lost in DPDP commentary: the Act does not displace sector-specific rules. Where IRDAI, the RBI or other regulators impose stricter localisation, those rules prevail. DPDP sets a floor, not a ceiling, and the floor is more permissive than several sectoral regimes that already exist.

The RBI's payments-data localisation mandate is the clearest precedent. For insurance, IRDAI's regulations on policyholder records, outsourcing and maintenance of records already push insurers toward keeping core data in India, with offshore processing permitted under conditions rather than as a default. The result is a stacked compliance picture: a flow can be permitted under Rule 15 (no negative-list restriction), barred under an SDF category restriction, and separately constrained by IRDAI outsourcing norms. All three layers apply at once.

For brokers this is a placement and contracting issue, not an abstraction. If you place a cyber-insurance programme for an insurer or large corporate, the policy wording's data-handling representations must hold true under the strictest applicable regime, not the most lenient. A warranty that data is processed "in compliance with applicable law" is hollow if the insured cannot evidence which law it treated as applicable for each flow.

The practical reading

• Treat IRDAI outsourcing and records norms as the binding layer for insurer clients, with DPDP underneath it.
• For corporate insureds in regulated sectors (banking, payments, telecom), check whether their own sectoral regulator imposes localisation that DPDP does not.
• Do not let a DPDP "transfer permitted" conclusion override a sectoral "keep onshore" rule. The sectoral rule wins.

There is a placement consequence brokers should anticipate. Reinsurers and global insurer groups often run shared claims and analytics platforms hosted outside India, and they will assume DPDP's permissive default applies. For an IRDAI-regulated cedant or insurer client, that assumption can be wrong. When you place or renew a programme that depends on offshore reinsurer infrastructure, ask the cedant to evidence that its own records and outsourcing obligations are satisfied independently of what DPDP allows. The gap between "the reinsurer says the transfer is fine" and "my Indian client's sectoral regulator agrees" is exactly where a future enforcement question sits, and it is far cheaper to close at placement than during a regulatory review.

The deliverable that protects a broker or insurer is a transfer map: a documented inventory of what personal data exists, which categories it falls into, where it physically sits, who processes it offshore, and on what legal basis. Most organisations cannot produce this today. They know they use an offshore TPA; they do not know precisely which fields cross the border.

Work it category by category. Claims data carries the heaviest exposure because it bundles identity, financial and often health information. Medical and health-claims fields are the most likely candidates for a category-level SDF restriction, so they deserve their own line in the map. KYC and onboarding data (PAN, Aadhaar-linked verification outputs, bank details) sits close behind. For each, record the destination country, the processor, the contractual basis, and, most importantly, the repatriation time if that flow had to come back onshore in 30 days.

1. Inventory the flows. List every offshore recipient: reinsurers, TPAs, cloud regions, analytics vendors, parent-group shared services.
2. Classify the data. Map each flow to data categories, flagging health, biometric and financial fields separately.
3. Attach the legal basis. Rule 15 default, sectoral permission, intra-group arrangement, or consent.
4. Score the repatriation risk. How long, and at what cost, to bring each flow onshore if restricted.
5. Fix the contracts. Ensure processor agreements carry data-localisation step-in and audit rights.

The repatriation score is the part most teams skip and the part underwriters and boards will ask about first. A flow that takes 18 months and a platform migration to repatriate is a strategic risk, not a compliance footnote. Surfacing it now lets the broker price it into the professional-indemnity and cyber conversation rather than discovering it during a claim.

Cross-border data risk lands in three places in a programme: the cyber policy, the professional indemnity policy, and the data-handling warranties in commercial contracts. Brokers should pressure-test all three against the DPDP picture.

On the cyber tower, the live question is whether DPDP regulatory penalties are covered. Many India cyber wordings cover "regulatory fines and penalties where insurable by law." That phrase is doing heavy lifting. If a DPDP penalty (up to INR 250 crore for a security-safeguard failure, up to INR 200 crore for notification failure, assessed per violation) is held uninsurable as a matter of public policy, the cover evaporates exactly when it is needed. Brokers should get the insurer's position in writing rather than assuming the grant responds.

Notification cost is the more reliable recovery. DPDP's breach regime requires prompt notification to the Data Protection Board and to affected data principals, with a 72-hour clock to principals after the Board filing. That triggers exactly the first-party costs (forensics, legal, notification, call-centre) that cyber policies are built to fund. Ensure the policy's incident-response panel and sub-limits are sized for an India notification event at the insured's record count.

For liability-insurance and PI placements covering brokers and TPAs themselves, the exposure runs the other way: the broker-as-processor can be the party that mishandled a transfer. The transfer map is the document that defends the broker's own conduct.

Under DPDP the insurer or corporate is typically the data fiduciary and the broker or TPA is a data processor acting on instructions. That allocation is not cosmetic. A processor that transfers data offshore outside its instructions, or onward to a sub-processor without authority, creates liability for the fiduciary and reputational and contractual exposure for itself.

Most broker and TPA contracts written before the Rules do not address this cleanly. They predate the negative-list model and say nothing about repatriation, sub-processor disclosure, or category-level restrictions. That gap is the single most fixable item on the list, and brokers should drive the remediation rather than wait for insurers to redraft.

The processor schedule should, at minimum, do five things. First, bind the processor to transfer data only to destinations and recipients the fiduciary has approved in writing. Second, require full sub-processor disclosure and a right to object. Third, carry a repatriation step-in: if the government restricts a flow, the processor must bring data onshore within a defined window at its own cost. Fourth, grant audit rights aligned to the SDF audit obligation, so the fiduciary can evidence compliance. Fifth, allocate DPDP penalty exposure between the parties with an indemnity that is realistic rather than uncapped boilerplate.

For TPAs handling commercial-health claims, the medical-data sensitivity makes this urgent. A group-health health-insurance book processed through an offshore TPA platform is exactly the flow most likely to attract a category restriction. The broker who has already negotiated repatriation and audit terms into the TPA contract is protecting both the client and the placement. The one who has not is exposed the day a restriction is notified.

The work is not glamorous and it is not optional. A broker can add real value here because most insureds will not run this themselves, and the broker sits across the placement, the wording and the vendor relationships. Here is a sequence that fits a quarter.

Weeks 1 to 4: map

• Run the transfer-map exercise across claims, medical, KYC and analytics flows.
• Identify every offshore processor and sub-processor by name and country.
• Flag health, biometric and financial categories for category-restriction risk.

Weeks 5 to 8: assess

• Score each flow for repatriation time and cost.
• Cross-check flows against IRDAI outsourcing and records norms, treating the sectoral rule as binding where stricter.
• For insurer clients, form a view on SDF designation likelihood and the DPO, DPIA and audit gap that follows.

Weeks 9 to 12: fix

• Renegotiate processor and TPA schedules to add approval, disclosure, repatriation and audit clauses.
• Get the insurer's written position on DPDP penalty insurability under the cyber tower.
• Size notification and incident-response sub-limits to the India record count.
• Replace unsupported data-handling warranties with representations the map can evidence.

The output is a defensible file: a transfer map, a repatriation plan, fixed contracts, and a cyber and PI programme whose wordings match reality. That file is what a board wants before the negative list arrives, what an underwriter rewards at renewal, and what defends the broker if a flow is later challenged. None of it depends on predicting which country lands on the list first. It only depends on knowing where your data is before someone else decides it cannot stay there.