Cross Border Transfers Under the DPDPA

Most data protection regimes use a positive list. The regulator identifies countries that provide adequate protection and permits transfers to those jurisdictions. GDPR adequacy decisions work this way. APEC CBPR recognition works this way.

The DPDPA inverts this architecture. Section 16 empowers the Central Government to notify countries to which transfers are restricted. Until such notification, transfers to all countries are permitted. After notification, transfers to restricted countries require specific Government authorisation or must cease.

This creates a compliance paradox. The absence of restrictions today does not relieve the documentation obligation today. An organisation that treats current permissibility as permanent will find itself scrambling to construct transfer governance on the day the Government exercises its Section 16 authority. The time to build the architecture is before the notification, because after it, the time is gone.

Before any cross border compliance architecture can be constructed, every data flow involving Indian personal data must be mapped. This is not preparatory. It is foundational.

The map must identify every category of personal data collected from Indian data principals, every jurisdiction where that data is processed, stored, or accessed, every third party and sub processor that handles the data, the legal basis for each transfer, and the contractual architecture governing each flow.

For multinational operations, the mapping exercise reveals uncomfortable realities. Cloud infrastructure spans jurisdictions by configuration, not by legal design. SaaS platforms route data through regions determined by load balancing, not by regulatory requirement. Customer support teams access Indian personal data from Manila, Dublin, and Austin without awareness that each access point carries a DPDPA obligation.

The map is the diagnostic. Without it, every subsequent compliance investment is built on assumption. Assumptions do not produce compliance undertakings in Board proceedings.

Every transfer to a processor outside India requires a Data Processing Agreement compliant with Section 8(2). The distinction matters: GDPR Standard Contractual Clauses do not satisfy this requirement.

The DPA must contain the specific purposes for which data is processed, mapped to the consent notice under Rule 3. It must impose the obligation to process data only on the Data Fiduciary's instructions. It must require reasonable security safeguards under Section 8(5). It must mandate breach notification to the Data Fiduciary without delay. And it must require data deletion upon completion of the processing purpose or upon withdrawal of consent.

For foreign companies with hundreds of vendor relationships, this means a systematic DPA remediation programme. Every existing vendor contract must be audited against Section 8(2). Every DPA must be reconstructed on DPDPA terms. Every sub processor must be identified and brought within the contractual chain. The organisations that attempt to use a single global DPA template will find that it satisfies the requirements of no jurisdiction fully, and the requirements of the DPDPA not at all.

A data breach affecting Indian personal data triggers Section 8(6) notification obligations, regardless of where the breach occurs. If a Frankfurt data centre suffers a breach exposing personal data of Indian users, the notification obligation under the DPDPA begins the moment the breach is detected. Rule 7 prescribes the form and manner of notification.

The cross border dimension creates a coordination challenge. The breach response team in one jurisdiction must simultaneously satisfy DPDPA notification requirements in India, GDPR requirements in Europe, and potentially notification requirements in every other jurisdiction where affected data principals reside. The DPDPA does not accommodate multi jurisdictional coordination delays. The obligation is to notify "without delay."

Foreign companies must pre position their India breach response protocols. The protocol must identify the Indian notification authority, the DPDPA notification requirements, the legal adviser managing the Indian response, and the evidence preservation requirements. Constructing this protocol after the breach is not an option. The Board's standard of assessment will be whether the protocol existed before the incident, not whether it was created during it.

The foreign company that builds its India cross border compliance architecture before the Section 16 notification is issued will have a defensible position. The architecture has five components.

Data Flow Registry. A maintained, auditable inventory of every cross border data flow involving Indian personal data. Updated quarterly.

DPA Library. India specific Data Processing Agreements with every processor and sub processor. Not GDPR SCCs. Not global templates. DPDPA native contracts constructed on Section 8(2) terms.

Transfer Impact Assessment. For every receiving jurisdiction, a documented assessment of the legal regime, the enforcement landscape, and the adequacy of protections. This becomes the evidence file if transfers to that jurisdiction are restricted.

Breach Response Protocol: India Chapter. A standalone protocol for DPDPA breach notification that integrates with the global incident response plan but operates independently for Indian notification requirements.

Board Response Package. Pre assembled documentation that can be produced within 48 hours of any regulatory inquiry. Consent records. DPA library. Transfer impact assessments. Breach protocol test results.