The Digital Personal Data Protection Act, 2023 (DPDPA) is the first Indian privacy law with teeth, and its cross-border transfer framework is already creating false confidence in compliance teams.

Section 16(1) takes a negative-list approach. Personal data of Indian citizens can be transferred to any country outside India, unless the Central Government issues a notification restricting that country. No restricted-country list has been published yet.

Companies treating the current gap as a green light are building on sand. When notifications land, they will take effect on the date of publication. There is no GDPR-style adequacy runway, no transition grace period written into the Act. Organisations that have not mapped their cross-border data flows, built a compliant consent infrastructure, and locked down contractual arrangements with offshore processors will face an immediate gap with a functioning Data Protection Board waiting to receive complaints.

What Section 16 Actually Says, and What It Doesn't

Section 16(1) is blunt: "The Central Government may, after an assessment of such factors as it may consider necessary, notify that the transfer of personal data by a Data Fiduciary to any country or territory outside India shall not be made."

Until that notification, transfers are legally permissible.

What the Act does not currently require: Standard Contractual Clauses (SCCs), Binding Corporate Rules, or Transfer Impact Assessments. Those are GDPR constructs under Articles 46 and 47. They have no equivalent in DPDPA 2023. Any compliance team retrofitting GDPR transfer mechanisms onto Indian law is doing unnecessary work and, more critically, is potentially misdirecting effort from what the Act does require.

What is required, regardless of transfer destination, is a lawful processing basis. For the vast majority of commercial cross-border transfers, that basis is consent under Section 6.

Consider a SaaS HR platform that processes payroll for Indian employees on AWS US-East. The transfer is currently permitted under Section 16. But the consent notice presented to those employees at onboarding must disclose the cross-border transfer, identify the recipient country or region, and specify the purpose. A generic "we use third-party service providers" clause in a privacy policy does not satisfy Section 6(1). It is a void consent.

Where Sectoral Rules Override the DPDPA

The DPDPA does not operate in a vacuum. For several regulated sectors, it is not even the primary instrument governing data movement.

RBI's 2018 Payment Data Localisation Circular (DPSS.CO.PD No.2785/02.14.003/2017-18) mandates that all data related to payment systems must be stored only within India. The circular covers the entire payment transaction data chain, from origination to settlement. There is no carve-out for cross-border processing, no provision for adequacy equivalence, and no alignment mechanism with DPDPA Section 16.

For fintechs, payment aggregators, and NBFCs processing card transactions or UPI flows, this is an absolute constraint. Routing transaction data through offshore analytics pipelines, even with valid consent, violates the RBI circular. The DPDPA does not override it.

SEBI's 2023 data localisation advisory requires regulated entities to maintain all trading data and investor data within the Indian jurisdiction. A broker running a unified customer data platform on a US-headquartered cloud vendor cannot process trading behaviour data offshore, regardless of what Section 16 permits.

IRDAI's 2017 guidelines on data localisation require that all policyholder data remain within India. An insurer using a global CRM with data centres in Singapore or Ireland faces a compliance issue that DPDPA permissiveness does not resolve.

The practical conflict is acute for financial institutions running a unified customer data infrastructure. A bank's marketing behavioural data and its payment or KYC data require different infrastructure treatment. 

This is where purpose mapping becomes operationally critical. The consent captured for a customer must map precisely to the data category being processed and the destination. Marketing consent cannot bootstrap a cross-border transfer of payment data that the RBI has already prohibited.

Consent as Your Transfer Mechanism: Getting It Right

For personal data not covered by sectoral restrictions, consent under Section 6 is the operative lawful basis for cross-border transfer.

Section 6(1) sets the standard: consent must be free, specific, informed, unconditional, and unambiguous. Each element carries weight. "Informed" is the load-bearing word for cross-border scenarios.

A data principal cannot give informed consent to a transfer they don't know is happening. The consent notice must tell them: the transfer is occurring, where the data is going, and what it is being used for at the destination.

Section 6(4) closes a common workaround. Consent given for one purpose cannot be used for another. A user who consents to account creation on a lending app has not consented to their data being processed by an offshore ML vendor for credit scoring. Those are separate processing activities. They require separate consent.

A compliant consent notice for cross-border transfer must include:

• Identity of the Data Fiduciary
• Countries or regions to which data will be transferred
• Specific purposes for the transfer, mapped to the purposes disclosed at collection
• Retention period applicable to transferred data
• Data principal rights available with respect to transferred data

A health-tech company whose privacy policy states "data may be shared with partners globally" has not satisfied Section 6. That language is not specific, not purpose-mapped, and not consent; it is a policy declaration. The Data Protection Board treats policy disclosures and consent as legally distinct.

Section 5(1) compounds the exposure. Personal data must be used only for the specific, lawful purpose for which consent was obtained. If an Indian employee's HR data is transferred to a Workday instance in the US and then used by the US entity for workforce analytics not disclosed in the original consent notice, that is a Section 5 violation, not just a Section 6 irregularity. 

Building the Operational Compliance Layer

Consent capture is the beginning of the compliance record, not the end. Section 8(9) places the burden of proof on the Data Fiduciary. When the Data Protection Board investigates a complaint, the fiduciary must demonstrate that consent was validly obtained. The data principal does not need to prove they didn't consent; you need to prove they did.

For cross-border transfers, the audit trail must contain more than a timestamp and a tick-box. It must document: the exact version of the privacy notice presented at the time of consent, the data categories covered by that notice, the transfer destinations disclosed, the purposes specified, and confirmation that the consent was free and not bundled.

The CERT-In directive of April 2022 (No.20(3)/2022-CERT-In) adds urgency to the contractual layer. It mandates reporting of cybersecurity incidents within 6 hours of detection. If a breach occurs at an offshore processor, say, a cloud CRM provider, the Indian Data Fiduciary's clock starts running the moment they become aware. They cannot wait for the offshore vendor to complete its own investigation.

This makes Data Processing Agreements with offshore vendors a compliance-critical document, not a legal formality. Even without mandatory SCCs under DPDPA today, the DPA with an offshore processor should contractually bind them to: process only on documented instructions per Section 8(3), notify the Indian fiduciary of breaches within a timeframe compatible with the CERT-In window, support the fiduciary's data principal rights obligations, and be subject to audit.

Companies using Salesforce, HubSpot, Workday, or SAP SuccessFactors on global instances need data processing addenda that specifically address Indian data subject rights access under Section 12, correction and erasure under Section 13, and make those rights enforceable against the offshore vendor contractually.

Rights Fulfilment Across Borders: The Underrated Problem

Section 12 gives data principals the right to access information about their personal data. Section 13 gives them the right to correction and erasure.

Neither right is limited to data held in India.

If personal data has been transferred offshore, the Indian Data Fiduciary cannot unilaterally fulfil these rights. They are operationally dependent on the offshore processor's technical capability and willingness to execute deletion or correction on the Indian fiduciary's instruction.

An erasure request filed by a data principal does not pause at the international border. It applies to all copies of their data, wherever processed. An e-commerce company storing order history on AWS Mumbai, but customer behavioural profiles on a US-based analytics vendor must push deletion to both systems on receipt of a valid erasure request.

DPDPA does not yet define statutory SLA timelines for rights fulfilment that will come with rules. But the Data Protection Board will apply a reasonableness standard, and "our offshore vendor hasn't responded yet" is not a defence.

What to Do Before the Restricted-Country List Drops

The Central Government's restricted-country notifications will arrive without a grace period. Publication equals enforcement date.

Three actions to take now:

1. Complete a cross-border data flow inventory: Map every dataset containing personal data of Indian citizens. Identify where it is processed, stored, and accessed by third parties. Include SaaS tools, analytics vendors, and cloud sub-processors. Most companies cannot answer this question accurately today.

2. Audit all existing consent notices for transfer disclosure adequacy: Apply the Section 6(1) standard. Does each notice identify the transfer destination? Does it map the transfer to a specific purpose? Is the consent mechanism an affirmative act or a bundled pre-tick?

3. Verify contractual obligations with offshore processors align with Section 8(3): Your DPAs need Indian-law-specific provisions, not boilerplate. If your offshore vendor refuses to accept Section 8(3)-aligned obligations, that is a risk disclosure that needs to reach your board.

Frequently Asked Questions

Q: Is a privacy policy disclosure sufficient as consent for cross-border transfers under DPDPA, or is explicit opt-in required?

No. A privacy policy disclosure is not consent under Section 6. The Act requires consent to be free, specific, informed, unconditional, and unambiguous — and obtained through an affirmative act. Posting a policy that users are assumed to have read does not meet this standard. An explicit, purpose-specific opt-in is required before transferring personal data cross-border.

Q: How does RBI's payment data localisation requirement interact with DPDPA Section 16 — which regulation governs in case of conflict?

RBI's 2018 circular governs the payment system data. It is a sector-specific mandate and was in force before DPDPA. DPDPA Section 16 permissiveness does not override a prior RBI directive. Payment aggregators, fintechs, and banks must comply with the RBI circular regardless of what Section 16 permits. In regulatory conflicts, the more restrictive sector-specific rule applies.

Q: If an Indian company uses a US-based SaaS tool that processes employee data, does it need separate consent from employees for that transfer?

Yes, if consent is the lawful basis. The employment relationship alone does not constitute consent under Section 6. Employees must be informed that their personal data is being processed by a named offshore vendor, for what specific purpose, and in which country. That disclosure must be made at the time of data collection, and the employee must provide an affirmative consent. A standard employment contract or IT policy acceptance is insufficient.

Q: What happens if a data principal withdraws consent after their data has already been transferred offshore?

Withdrawal of consent under Section 6 triggers a cease-processing obligation. The Data Fiduciary must instruct the offshore processor to stop processing the data and, where erasure has been requested under Section 13, to delete it. The fiduciary cannot use "data is already offshore" as a reason to delay. The DPA with the offshore processor should include contractual obligations that make withdrawal instructions executable within a defined timeframe.

Q: Are there any safe harbour provisions under DPDPA for intra-group transfers similar to Binding Corporate Rules under GDPR?

No. DPDPA 2023 contains no equivalent to GDPR Binding Corporate Rules. There is no intra-group transfer safe harbour, no group-entity carve-out, and no adequacy equivalence mechanism. Each transfer from an Indian entity to a related entity outside India is subject to the same Section 16 framework and requires the same lawful basis — including valid consent — as a third-party transfer.

Map your cross-border data flows, audit your consent notices, and generate DPDPA-compliant transfer disclosures with CoTrust. Book a technical walkthrough with our team.

This content is for informational purposes and does not constitute legal advice. Consult qualified legal professionals for advice specific to your circumstances.