# Cross-Border Data Transfers Under DPDPA: What Changes for Your Cloud, Your Vendors, and Your AI Pipelines

Your AWS Mumbai region is fine. That is the reassuring half of the answer, and it is where most cross-border assessments stop.

The unreassuring half: what about the inference endpoint in Singapore that your AI feature calls? The fine-tuning cluster in the United States that ran for six weeks? The support team in Manila with read access to the customer database? The observability platform ingesting logs that contain user identifiers?

Section 16 of the DPDP Act is more permissive than most Indian enterprises assume, and simultaneously less relevant than they assume - because the constraints that actually bind them usually come from somewhere else.

## Section 16: The Negative List

Section 16 permits the transfer of personal data outside India by a Data Fiduciary, save to countries the Central Government restricts by notification.

This is a **negative-list** model, and it inverts the assumption most privacy professionals carry from GDPR.

| | GDPR | DPDP Act Section 16 |
|---|---|---|
| Default posture | Transfer prohibited unless a mechanism applies | Transfer permitted unless the destination is restricted |
| Mechanism required | Adequacy decision, SCCs, BCRs, or a derogation | None required by Section 16 itself |
| Burden | On the exporter, to establish a valid mechanism | On the Government, to restrict a country |
| Assessment | Per transfer, per destination, with a transfer impact assessment | Check the notified restriction list |
| Direction of travel | Restrictive, with a growing body of case law | Permissive by default |

Read alone, Section 16 imposes a light obligation: know your destinations, check them against the restricted list, and monitor for changes.

The trap is reading it alone.

![Section 16 permits transfer by default, subject to the countries the Central Government restricts by notification](/assets/blog-images/dpdpa-cross-border-data-transfers/section-16-transfer-restrictions.jpg)

## Three Things That Override the Permissive Default

**1. Sectoral law survives, and usually binds harder.**

The Act expressly preserves stricter requirements under other laws. This matters more than Section 16 itself for most regulated entities.

RBI's directive on storage of payment system data requires payment system operators to store the full end-to-end transaction data in India. Telecom licence conditions carry their own constraints on subscriber data. Health and insurance sector requirements apply to their respective entities.

An enterprise concluding "DPDPA permits transfer, therefore we may transfer" has read the general instrument and ignored the specific one that licenses it. When the two differ, the sectoral requirement is the operative constraint.

**2. Significant Data Fiduciaries may face additional restrictions.**

The framework contemplates that entities notified as Significant Data Fiduciaries may be restricted from transferring specified categories of personal data outside India. If you are large enough to expect the designation, architect on the assumption that some categories may become localisation-bound, and prefer designs where that is a configuration change rather than a re-platforming.

**3. Inbound transfers are the harder direction.**

Indian enterprises focus on data leaving India. If you serve European customers, the harder problem is EU personal data coming *in*.

India has no GDPR adequacy decision. Transfers from the EU to India therefore require a transfer mechanism - in practice Standard Contractual Clauses - accompanied by a transfer impact assessment that considers the legal environment in the destination country, including government access powers. That assessment is materially more demanding than anything Section 16 requires of you, and it is the one your European customers will ask to see.

## The AI Pipeline Problem

This is where residency analysis most commonly fails, because the analysis is performed against the serving path and AI systems move data along several other paths.

Consider a system that appears fully localised: the application runs in Mumbai, the database is in Mumbai, and the model inference endpoint is a regional deployment in Mumbai. Residency assessed at the inference endpoint returns a clean result.

Now trace the other flows:

- **Training and fine-tuning.** The fine-tuning job ran on capacity in another region because that is where the GPUs were available. The training dataset was copied there for the duration.
- **Evaluation and testing.** Held-out datasets used for evaluation, often stored alongside the training environment.
- **Prompt and completion logging.** The provider logs inputs and outputs for abuse monitoring, frequently in a different region from the inference endpoint, sometimes with human review.
- **Vector and embedding stores.** Embeddings derived from personal data, hosted wherever the vector database is deployed. Whether embeddings are personal data is contested, and the safe assumption is that they may be.
- **Telemetry and observability.** Traces and logs shipped to a monitoring platform whose ingestion endpoint is offshore, carrying identifiers in payloads.
- **Model artefacts.** A fine-tuned model encodes information derived from its training data and may be stored or replicated in another region.
- **Support and operations access.** The provider's support engineers, wherever they sit, may have access paths into the environment.

Seven flows, of which conventional residency analysis inspects one.

The compounding factor is that the training flow typically carries the largest volume of personal data, and the logging flow carries the least predictable data - because prompt logs contain whatever a user chose to paste.

![Network cabling representing data residency across infrastructure paths](/assets/blog-images/dpdpa-cross-border-data-transfers/data-residency-and-localisation.jpg)

## Contractual Safeguards

Even where Section 16 requires no mechanism, contractual safeguards remain necessary - because your obligations as Data Fiduciary follow the data, and because sectoral and customer requirements demand them.

**Named permitted regions.** Not "may process globally," but an enumerated list of countries for processing, storage and access, with changes requiring notice and giving you a right to object.

**Support access as a transfer.** State explicitly that access from a location constitutes processing in that location. Vendors routinely treat storage residency as the whole commitment while operating global support rotations.

**Sub-processor geography.** The list must include each sub-processor's processing location, and it must cover the AI supply chain - base model provider and inference host included.

**Flow-down.** The vendor imposes materially equivalent obligations on sub-processors and remains liable for their performance. This is the only mechanism that reaches your fourth parties.

**Government access notification.** Commitment to notify you of any government access request to the extent legally permitted, and to challenge overbroad requests. This clause is what your European customers' transfer impact assessments will look for.

**Deletion on withdrawal of permission.** If a destination becomes restricted, you need a contractual route to require repatriation or deletion within a defined period.

For intra-group transfers, binding corporate rules or an intra-group data transfer agreement provides a durable structure. India has not established a mechanism directly equivalent to GDPR SCCs under the DPDPA; in practice, enterprises use contractual terms modelled on the EU clauses adapted to Indian requirements, which is a pragmatic rather than a prescribed approach.

## A Transfer Impact Assessment Process

Even where the Act does not mandate one, a TIA is the artefact that demonstrates you assessed rather than assumed - and it is required for your inbound EU transfers regardless.

**Step 1: Identify the transfer.** Data categories, volume, Data Principal categories, sending and receiving entities, destination country, and the purpose. Include access-based transfers.

**Step 2: Establish the basis.** Section 16 position for the destination, plus any sectoral requirement, plus the customer contractual position.

**Step 3: Assess the destination.** Legal framework, government access powers, availability of redress, and any enforcement history relevant to the sector.

**Step 4: Assess safeguards.** Contractual terms in place, encryption in transit and at rest, key management location - a genuinely important detail, since data encrypted with keys held only in India has a materially different exposure profile - access controls, and logging.

**Step 5: Determine residual risk and decide.** Proceed, proceed with additional safeguards, or do not proceed. Record the reasoning either way.

**Step 6: Set review triggers.** New destination, new sub-processor, change in the restricted-country list, change in the destination's legal framework, or a material change in volume or sensitivity.

Integrate this with the RoPA rather than running it as a standalone exercise. The RoPA's geography fields identify the transfers; the TIA assesses them; the result feeds back as an attribute of the processing activity.

## Evidencing AI Data Locality

The hardest evidentiary question you will face is proving where AI training data went. Build the capability before you are asked.

- **Dataset lineage records** capturing, per dataset version, where it was assembled, where it was stored, which regions processed it, and for how long.
- **Model provenance records** linking each model version to its training dataset versions and training location.
- **Infrastructure evidence** - region-scoped resource inventories and cloud audit logs demonstrating where compute ran.
- **Provider attestations** for managed services where you cannot observe the infrastructure directly, ideally as contractual commitments rather than documentation.
- **Configuration as evidence** - region restrictions enforced through policy controls, so that the evidence is the enforced configuration rather than a claim about intent.

The last point is the strongest. A cloud policy that makes it technically impossible to provision outside approved regions is better evidence than any number of assurances that nobody did.

## Conclusion

Section 16 is permissive, and that permissiveness misleads. The binding constraints on most Indian enterprises come from sectoral regulators, from customer contracts, from GDPR on inbound flows, and from the possibility of Significant Data Fiduciary restrictions - not from Section 16 itself.

For AI systems specifically, the analytical error is assessing residency where the model serves rather than everywhere the data goes. Training, evaluation, logging, embeddings, telemetry and support access are all transfers, and most of them are invisible from the architecture diagram the assessment was performed against.

**Actionable recommendations:**

- **Check the instrument that licenses you before the one that governs personal data generally.** RBI, telecom, health and insurance requirements survive Section 16's permissive default and are usually the operative constraint.
- **Trace all seven AI data flows, not the serving path.** Training and logging carry the largest and least predictable volumes respectively, and neither appears in a residency check on the inference endpoint.
- **Treat access as transfer, contractually and in your RoPA.** A support team reading data from another country is a transfer that storage-residency analysis will never surface.
- **Architect so that localisation is a configuration change.** If Significant Data Fiduciary restrictions arrive, the difference between a config change and a re-platforming is months.
- **Enforce region restrictions through policy controls.** An enforced configuration is stronger evidence of locality than any attestation about intent.

> **Tag every data flow with residency metadata.** Automatic detection of transfers to restricted jurisdictions, AI pipeline flows traced end to end, and transfer impact assessments linked to the processing activities they cover. See how [Dedups.ai](https://dedups.ai) makes data residency provable.