DPDPA Section 16 — Cross-Border Data Transfers — Complete Guide 2025
Every Indian company using Amazon Web Services, Google Cloud Platform, Microsoft Azure, Salesforce, SAP, Workday, or any foreign SaaS is already transferring Indian personal data across borders — every single day. The Digital Personal Data Protection Act, 2023 directly governs these transfers under Section 16. The framework is not yet fully operational — the list of countries to which transfers are restricted has not yet been notified by the Data Protection Board — but the legal architecture is in place, the Board is active, and the compliance window is closing. This guide explains exactly what Section 16 requires, what it means for your AWS infrastructure, your foreign SaaS stack, your MNC data flows, and your cloud hosting decisions — and what you must do before May 2027 to ensure you are not caught in violation the moment the Board notifies the restricted country list.
🌐 Who This Guide Is For — High Commercial Intent
🏢
MNC India Subsidiaries
Sending employee, customer, and operational data to parent company HQ
☁️
Cloud-First Tech Companies
AWS, GCP, or Azure infrastructure outside India hosting Indian customer data
💼
Enterprise SaaS Users
Salesforce, SAP, Workday, ServiceNow, HubSpot, Zendesk — all foreign, all processing Indian employee or customer data
🔬
Research & Clinical Trial Sponsors
Pharma MNCs and CROs sending Indian patient trial data to global regulatory bodies
🏦
Financial Services and Fintech
Cross-border payment processing, AML/KYC data sharing with foreign regulators, global fraud analytics
Nov 2025
DPDP Rules notified — Board operational
2026 (est.)
Restricted country list expected to be notified
Nov 2026
Consent Manager registration opens
May 2027
All DPDPA obligations enforceable — DEADLINE
📋 What This Guide Covers
- What Section 16 actually says — the legal text decoded
- The "whitelist" model — how the approved country system works
- What happens before the Board notifies the restricted list
- AWS, GCP, and Azure — your cloud infrastructure and DPDPA
- Foreign SaaS platforms — Salesforce, SAP, Workday, and 20 others
- MNC subsidiaries sending data to parent company HQ
- Standard Contractual Clauses — do they work under DPDPA?
- Data localisation — what DPDPA requires vs. what sector regulations require
- Cross-border transfers in specific sectors — healthcare, fintech, HR
- What "transfer" actually means — the technical definition matters
- Consent as a transfer mechanism — when and how it works
- The Data Processing Agreement obligation for cross-border flows
- How to map and audit your current cross-border data flows
- Practical compliance framework for cross-border transfers
1. What Section 16 Actually Says — The Legal Text Decoded
Section 16 of the DPDP Act, 2023 is the operative provision governing cross-border data transfers. It is deliberately structured as a permissive framework with a restricted list — rather than a prohibitive framework with an approved list — which is a significant architectural difference from the GDPR model.
📜 Section 16 — The Core Provision (Paraphrased)
A Data Fiduciary may transfer personal data of a Data Principal to a person outside India, subject to such terms and conditions as may be prescribed by the Central Government. The Central Government may, after an assessment of such factors as it considers necessary, restrict the transfer of personal data by a Data Fiduciary to a country or territory outside India, by notification.
What This Means in Plain Language:
- Transfers are permitted by default — unlike GDPR, which prohibits transfers unless a valid mechanism exists, DPDPA starts from a position of permissiveness
- The government will notify a restricted list — specific countries will be blocked; everything else is presumptively allowed
- The terms and conditions for transfers will be prescribed — the Rules will specify what contractual or other safeguards must be in place for permitted transfers
- The Board will assess countries based on undisclosed factors — geopolitical relationship, data protection standards, and reciprocity are likely criteria
The critical practical implication: Until the restricted list is notified, transfers to all countries are presumptively permitted — but the obligation to have terms and conditions (i.e. contractual safeguards) in place applies from May 2027. Companies must prepare their DPA and transfer documentation now so they are not scrambling when the restricted list drops and creates compliance deadlines simultaneously.
2. The "Restricted List" Model — How the Approved Country System Works
India's approach to cross-border transfers under DPDPA is fundamentally different from GDPR's "adequacy decision" model. Understanding the architectural difference is essential for compliance planning:
| Feature |
GDPR (EU) Model |
DPDPA (India) Model |
| Default Position |
Prohibited — transfers are banned unless a specific mechanism applies (adequacy, SCCs, BCRs, consent) |
Permitted — transfers are allowed unless the destination country is on the restricted list |
| Country Assessment |
EU Commission issues adequacy decisions for countries meeting GDPR standards (UK, Japan, Canada etc.) |
Central Government notifies restricted countries — the criteria for restriction are not yet fully disclosed |
| Transfer Mechanisms |
Multiple: adequacy, SCCs, BCRs, consent, vital interests, contract necessity |
To be prescribed in Rules — likely to include contractual terms, consent, and specific government-approved mechanisms |
| Current Status |
Fully operational — organisations must have a transfer mechanism before transferring |
Restricted list NOT YET notified — but transfer terms and conditions framework in development |
| Sector Overrides |
GDPR is lex generalis — sector rules may be stricter |
RBI, SEBI, IRDAI, and health regulations may impose stricter localisation requirements that override DPDPA's permissiveness |
| Geopolitical Factor |
Adequacy based on data protection law standards, not geopolitics |
Restriction based on factors including geopolitical relationship, national security, and diplomatic considerations — China is widely expected to be restricted |
🟢 Countries Likely to Remain Unrestricted
USA, UK, EU member states, Japan, Singapore, Australia, Canada — based on current India diplomatic relationships and data protection maturity. Not confirmed — monitor Board notifications actively.
🔴 Countries Likely to Face Restrictions
China — near-certain restriction based on national security concerns and geopolitical tensions. Pakistan. Potentially other countries with adversarial relationship with India or inadequate data protection regimes. Not confirmed — monitor closely.
⚠️ Countries With Uncertain Status
Russia, Middle East countries, several African nations — geopolitical relationship with India is complex. If your data flows to these regions, prepare contingency plans now rather than waiting for the Board's notification.
3. What Happens Before the Board Notifies the Restricted List
This is the question every legal and compliance team at Indian companies is asking right now: are we in violation today? The answer requires careful parsing of the Act's transitional provisions.
1
Transfers Are Currently Permitted to All Countries
Until the Central Government notifies a restricted country list under Section 16, transfers to all countries are presumptively permitted. There is no current legal prohibition on sending Indian personal data to the US, UK, EU, Singapore, or any other country under DPDPA. Companies already using AWS us-east-1, Salesforce US instances, or SAP Germany are not currently in violation of Section 16 specifically.
2
But Other DPDPA Obligations Apply NOW — Including to Cross-Border Flows
The fact that Section 16's restricted list is pending does not exempt cross-border data flows from the Act's other obligations. If you transfer Indian customer data to a foreign SaaS vendor, that vendor is your Data Processor — and Section 9 requires a Data Processing Agreement today. The consent given for data collection must cover its cross-border transfer — and your privacy notice must disclose that transfer. These obligations apply now, not after the restricted list is notified.
3
The Transfer Terms and Conditions Framework Will Drop Simultaneously With the Restricted List
When the government notifies the restricted country list, it will simultaneously prescribe the terms and conditions for permitted transfers — likely including mandatory DPA language for cross-border flows, data minimisation requirements for transfers, and possibly sector-specific restrictions. Companies that have not already mapped their cross-border data flows and prepared DPA documentation will face an impossible compliance timeline when this happens.
!
The Strategic Compliance Window Is Right Now
The period between now and the notification of the restricted country list is the optimal window to map all cross-border data flows, execute DPAs with foreign vendors, update privacy notices to disclose transfers, and ensure consent architecture covers cross-border processing. Organisations that do this now will be ready for immediate compliance when the list drops. Organisations that wait will be in simultaneous violation of multiple DPDPA provisions.
4. AWS, GCP, and Azure — Your Cloud Infrastructure and DPDPA
The three hyperscale cloud providers collectively host a significant proportion of Indian enterprise data — and all three have data centres outside India as well as within it. DPDPA's impact on cloud architecture depends entirely on where your data actually sits and what the provider does with it.
| Cloud Provider |
India Regions Available |
DPDPA Transfer Risk |
DPA Status |
| Amazon Web Services |
ap-south-1 (Mumbai), ap-south-2 (Hyderabad) |
MEDIUM — if you use India regions only, primary risk is control plane data flowing to US. If using non-India regions, HIGH risk once restricted list is notified. |
AWS has GDPR-compliant DPA available. Needs DPDPA-specific review and supplemental DPA addendum. |
| Google Cloud Platform |
asia-south1 (Mumbai), asia-south2 (Delhi) |
MEDIUM — India regions available but many Indian companies still use Singapore or US regions for latency or cost. Cross-region replication is a transfer trigger. |
Google Cloud DPA available. Requires DPDPA addendum specifying Indian law as governing law for Indian data. |
| Microsoft Azure |
Central India (Pune), South India (Chennai), West India (Mumbai) |
LOWER — most comprehensive India region coverage of the three. But Azure AD, Microsoft 365, and Teams data may still flow to non-India Microsoft data centres. |
Microsoft DPA (Data Processing Agreement) available. GDPR-compliant DPA provides a useful starting framework but needs DPDPA supplementation. |
⚠️ Hidden Cross-Border Transfer Triggers in Cloud Infrastructure
- Control plane traffic — AWS, GCP, and Azure control plane operations (IAM, billing, monitoring, support) may process metadata outside India even when data is in India regions
- Cross-region replication and disaster recovery — DR backups to Singapore or US regions are cross-border transfers of whatever data is replicated
- CDN and edge caching — CloudFront, Cloud CDN, and Azure CDN cache content at global edge nodes — if that content includes personal data, it is transferred globally
- AI and ML training services — using SageMaker, Vertex AI, or Azure ML may send data to training infrastructure outside India
- Security and threat intelligence — AWS GuardDuty, Google Chronicle, Azure Sentinel may send telemetry data outside India for global threat analysis
- Support tickets and debugging — raising a support case about customer data may involve that data being accessed by support engineers outside India
✅ Cloud Architecture Actions to Take Now
- Audit your AWS/GCP/Azure regions — document where Indian customer data actually resides
- Review cross-region replication and backup policies — map what is replicated where
- Enable data residency controls where available — AWS Data Residency policies, Google Cloud Assured Workloads, Azure Sovereign Regions
- Execute a DPDPA-reviewed DPA addendum with your cloud provider
- Update your privacy notice to disclose that cloud infrastructure may be located outside India
- Evaluate whether Indian region deployment is feasible and cost-effective for your workloads
- Document the business necessity justification for any non-India region usage
5. Foreign SaaS Platforms — The DPDPA Risk Audit Every Company Must Do
The average Indian enterprise uses between 80 and 200 SaaS applications — the vast majority of which are foreign-headquartered, process Indian employee or customer data, and store that data on servers outside India. Each one is a cross-border data transfer. Each one requires a Data Processing Agreement reviewed for DPDPA compliance.
| SaaS Platform |
Indian Data It Processes |
Data Location |
DPA Available |
DPDPA Risk |
| Salesforce |
Customer CRM data, contact details, sales pipeline, support tickets, marketing lists |
US / EU (no India DC) |
✓ Available |
HIGH |
| SAP (S/4HANA / SuccessFactors) |
Employee HR data, payroll, financials, procurement records, supply chain partner data |
Germany / EU |
✓ Available |
HIGH |
| Workday |
Employee personal data, salary, performance records, benefits, leave history, org structure |
US only |
✓ Available |
HIGH |
| ServiceNow |
IT service desk data, employee requests, vendor management, ITSM workflows, security incidents |
US / EU |
✓ Available |
MEDIUM |
| HubSpot |
Marketing contacts, lead data, email engagement, customer journey, CRM records |
US only |
✓ Available |
HIGH |
| Zendesk / Freshdesk |
Customer support tickets, contact details, complaint content, interaction history |
US / EU |
✓ Available |
MEDIUM |
| Slack / Microsoft Teams |
Employee communications, file sharing, internal HR discussions, client communication data |
US / EU |
✓ Available |
MEDIUM |
| Zoom / Google Meet |
Meeting recordings, participant data, chat logs, transcripts, attendance records |
US / Global |
✓ Available |
MEDIUM |
| Klaviyo / Mailchimp |
Customer email lists, marketing preferences, engagement data, purchase-triggered automations |
US only |
✓ Available |
HIGH |
| Oracle HCM / PeopleSoft |
Employee personal data, payroll, time and attendance, benefits administration |
US / EU |
✓ Available |
HIGH |
The DPA review problem: Every major foreign SaaS platform has a GDPR-compliant Data Processing Agreement available. But GDPR compliance does not equal DPDPA compliance. The key differences: DPDPA Section 9 has specific requirements for Indian law-governed DPAs; GDPR-standard DPAs may not address the Board notification obligation, may not cover the specific rights prescribed under Sections 11–14, and may have governing law and dispute resolution clauses incompatible with DPDPA enforcement. Each DPA needs a DPDPA-specific review and, where necessary, a supplemental addendum — not a blanket acceptance of the vendor's standard terms.
6. MNC Subsidiaries Sending Data to Parent Company HQ
For multinational corporations operating in India — whether as wholly-owned subsidiaries, joint ventures, or branch offices — the flow of Indian employee and customer data to the global parent company or to shared services centres is one of the largest and most complex cross-border data transfer scenarios under DPDPA.
👥 Indian Employee Data Flows to Global HQ
When a US or European parent company's HR systems process the personal data of Indian employees — salary, performance reviews, leave records, health insurance data, disciplinary records — that is a cross-border data transfer of Indian personal data. Under DPDPA: the Indian subsidiary is the Data Fiduciary; the global parent's HR system is a Data Processor; a DPDPA-compliant Data Processing Agreement must exist between the Indian subsidiary and the global parent; the Indian employee must have received a privacy notice disclosing this transfer; and the transfer must be to a country not on the restricted list (once notified). Binding Corporate Rules (BCRs) used under GDPR may provide a useful starting framework for intra-group transfers but will need DPDPA supplementation.
🏢 Centralised Shared Services — Global vs. India-Specific Functions
Many MNCs operate centralised shared services for finance, legal, procurement, and IT — often in the parent country or in low-cost hubs like the Philippines or Eastern Europe. When these shared services process Indian customer or employee data, each processing activity is a cross-border transfer. The Indian entity must: map which shared services handle Indian data, ensure DPAs are in place with each shared service entity, ensure the privacy notice discloses shared service processing, and be prepared to demonstrate that the transfer complies with Section 16 once the terms and conditions are prescribed.
📊 Indian Customer Data in Global CRM and Analytics Systems
MNCs that operate a global Salesforce, Adobe Analytics, or customer data platform instance — where Indian customer data sits alongside global customer data — have Indian personal data flowing to and processed in foreign systems. This is a cross-border transfer regardless of whether the Indian entity consciously "sends" data abroad. The flow is automatic by virtue of the platform architecture. These flows must be identified, disclosed in the privacy notice, covered by a DPA, and compliant with Section 16 conditions once prescribed.
The intra-group transfer misconception: Many MNC legal teams assume that transfers between group entities are automatically permissible under DPDPA because the entities are part of the same corporate group. This is incorrect. DPDPA does not have a general intra-group exemption. Each transfer — regardless of whether it is to a parent, subsidiary, or affiliate — must have a lawful basis, a DPA, and must comply with Section 16's terms and conditions. The GDPR's Binding Corporate Rules mechanism provides a useful model, but BCRs developed for GDPR do not automatically satisfy DPDPA requirements.
7. Standard Contractual Clauses — Do They Work Under DPDPA?
Standard Contractual Clauses (SCCs) are the workhorse transfer mechanism under GDPR — pre-approved template contracts that organisations use to legitimise data flows to countries without adequacy decisions. The question every Indian compliance team is asking: can we use EU SCCs, or India-adapted SCCs, for DPDPA cross-border transfers?
✅ What SCCs Can Do Under DPDPA
- Provide a contractual framework for documenting transfer obligations between Indian Data Fiduciary and foreign Data Processor
- Incorporate the data protection obligations of Section 9 (DPA requirements) into a template that can be adapted for multiple vendor relationships
- Demonstrate good-faith compliance efforts to the Data Protection Board — even before the Board prescribes specific transfer terms and conditions
- Serve as the foundation for an India-specific SCC framework once the Board prescribes the required terms and conditions for permitted transfers
❌ What EU SCCs Cannot Do Under DPDPA
- Substitute for the specific terms and conditions the Central Government will prescribe for Section 16 permitted transfers — these are yet to be notified
- Override a restricted country designation — if the Board restricts transfers to a country, no SCC will make that transfer permissible
- Satisfy DPDPA's specific requirements for DPAs under Section 9 without modification — EU SCC language is calibrated to GDPR obligations, not DPDPA obligations
- Replace the need for India-law governed dispute resolution and enforcement provisions — EU SCCs specify EU jurisdiction, which is not applicable for DPDPA enforcement
📋 What India-Adapted SCCs Should Cover for DPDPA Cross-Border Transfers
▶Processing purpose, data types, and categories of Data Principals — aligned with the DPDPA-compliant privacy notice
▶Data Principal rights obligations under Sections 11–14 — how the foreign processor supports the Indian fiduciary in fulfilling these rights
▶Breach notification obligation — foreign processor must notify Indian fiduciary within a defined period sufficient to meet the Board's notification timeline
▶Sub-processor obligations — restrictions on the foreign processor engaging further sub-processors outside the permitted country list
▶Security standards — aligned with Section 8(5) reasonable security safeguards, specified for the sensitivity of the transferred data
▶Deletion and return obligations — data must be deleted or returned after the processing purpose ends
▶Indian law as governing law for DPDPA-specific obligations — dispute resolution under Indian jurisdiction for data protection matters
▶Compliance with future Board notifications on permitted transfer conditions — auto-update mechanism for when terms are prescribed
8. Data Localisation — What DPDPA Requires vs. What Sector Regulations Require
One of the most important points of analysis for Indian companies is the distinction between DPDPA's general cross-border transfer framework and the sector-specific data localisation requirements that apply in parallel — and which are often more restrictive.
| Sector |
Data Localisation Requirement |
Regulator |
Stricter Than DPDPA? |
| Payment Data |
All payment system data must be stored only in India. A copy may be stored abroad for international transactions but the master copy must be in India. This is a hard localisation requirement with no transfer mechanism exception. |
RBI (2018 Storage of Payment System Data circular) |
YES — significantly stricter |
| Banking / Financial Data |
Customer financial data of banks, NBFCs, and payment service providers must be stored in India. Certain cross-border flows (correspondent banking, trade finance) are permitted with specific safeguards. |
RBI |
YES — stricter |
| Insurance Data |
Customer data must be stored in India. Cross-border transfers for reinsurance and global risk management are permitted with IRDAI approval on a case-by-case basis. |
IRDAI |
PARTIALLY stricter |
| Health / Patient Data |
ABDM framework requires health data to be stored in India. DISHA (draft) would impose hard localisation. Currently no hard RBI-style mandate but strong policy direction toward localisation. |
NHA / MoHFW |
LIKELY to become stricter |
| Telecom Data |
Subscriber data, CDRs, and location data of telecom customers must be stored in India per DoT licensing conditions. International roaming data flows are specifically regulated. |
DoT / TRAI |
YES — stricter |
| Securities / Capital Markets |
Trading data and investor records must be stored in India. SEBI has issued data localisation requirements for its regulated entities. Cloud infrastructure for trading systems must have primary data in India. |
SEBI |
YES — stricter |
| E-Commerce / Retail |
No specific localisation mandate beyond DPDPA. The Non-Personal Data Governance Framework (draft) may impose community data localisation requirements in the future. |
MeitY / DPIIT |
NO — DPDPA applies |
9. Cross-Border Transfers in Specific Sectors — Healthcare, Fintech, HR
🏥
Healthcare — Clinical Trial Data to Global Sponsors
Pharmaceutical companies conducting clinical trials in India routinely send patient data — adverse event reports, efficacy data, pharmacovigilance records — to global sponsors in the US, EU, or Japan for regulatory submissions. Under DPDPA: each patient must have consented specifically to cross-border transfer of their data as part of the informed consent process; the CRO or hospital conducting the trial is the Indian Data Fiduciary; the global sponsor is a Data Processor (and potentially an additional Data Fiduciary for their regulatory submissions); a DPDPA-compliant DPA must govern each relationship. Additionally, Schedule Y and ICMR guidelines on consent apply in parallel and may impose stricter requirements.
💰
Fintech — Cross-Border Payments and Global Fraud Analytics
Fintech companies processing cross-border payments must navigate both RBI's hard payment data localisation requirement and DPDPA's transfer framework simultaneously. Payment data must be stored in India — but customer KYC data, transaction metadata, and fraud signals may flow to global fraud analytics systems. This creates a split-architecture requirement: payment data stays in India; other customer data can be transferred subject to DPDPA Section 16 compliance. FATF compliance and AML data sharing with foreign FIUs adds another regulatory layer requiring specific legal gateways for data disclosure.
👥
HR and Workforce — Global Payroll, Performance Management, and Background Checks
MNCs with Indian employees using global Workday, SuccessFactors, or Oracle HCM instances transfer extensive employee personal data cross-border continuously. Beyond payroll systems, global background verification agencies (First Advantage, HireRight, Kroll) conduct checks and send reports internationally. Performance calibration meetings where Indian employee performance data is discussed at global leadership level are also data transfers in substance. Each of these flows requires: employee privacy notice disclosure, DPA with each foreign vendor, and Section 16 compliance. HR compliance teams must map the full employee data lifecycle across all global systems.
10. What "Transfer" Actually Means — The Technical Definition Matters
Not every data flow is legally a "transfer" under DPDPA. The technical and legal definition of what constitutes a cross-border transfer determines which obligations apply — and getting this right prevents both over-compliance (treating every API call as a transfer) and under-compliance (missing genuine transfers).
🔴 Activities That ARE Cross-Border Transfers
- Uploading Indian customer data to a foreign-hosted SaaS platform
- Syncing Indian employee records to a global HR system hosted abroad
- Replicating Indian user data to a disaster recovery site outside India
- Sending logs containing personal data to a foreign SIEM or analytics platform
- Sharing Indian patient data with a global pharma sponsor via a secure portal
- A foreign support engineer remotely accessing Indian customer data to resolve a ticket
- Bulk export of Indian customer records to a foreign marketing automation tool
🟢 Activities That May NOT Be Cross-Border Transfers
- A foreign employee viewing anonymised aggregate data (no personal data transferred)
- Routing network traffic through foreign servers where data is in transit only — not stored or processed
- Accessing India-hosted data via a foreign IP address (the data does not leave India)
- Using a CDN that caches non-personal static content at global edge nodes
- Pseudonymised data flows where re-identification is not reasonably possible without a key held only in India
- Email to a foreign counterpart containing only publicly available information about the recipient
11. Consent as a Transfer Mechanism — When and How It Works
Individual consent is one of the mechanisms under GDPR for legitimising transfers — and it is likely to be available under DPDPA's prescribed transfer conditions as well. But consent as a transfer mechanism has significant limitations that make it unsuitable for most commercial cross-border data flows.
| Scenario |
Consent as Transfer Mechanism |
Why / Why Not |
| Consumer e-commerce — customer data to foreign CRM |
WORKABLE — WITH CARE |
Consent can work if the transfer is disclosed specifically in the consent notice. But withdrawal of consent would require the foreign CRM to delete the data — a complex operational requirement. |
| Employee HR data to foreign parent HQ |
UNRELIABLE |
Employee consent is inherently coerced in an employment relationship — the power imbalance makes it invalid as a standalone mechanism. Contractual necessity or legitimate use grounds are more defensible for employment-related transfers. |
| Clinical trial data to global sponsor |
APPROPRIATE |
Clinical trial participants give informed consent specifically for data sharing with sponsors. Consent notices already include cross-border transfer disclosure under GCP/ICH guidelines. This is a well-established consent-based transfer model. |
| Bulk customer database to foreign analytics platform |
IMPRACTICAL |
Obtaining specific, informed consent from every existing customer for cross-border transfer to a named foreign analytics vendor is operationally infeasible for most businesses. Contractual transfer mechanisms are more appropriate for bulk B2B-style data flows. |
| New customer sign-up with disclosed foreign hosting |
APPROPRIATE |
For new sign-ups where the consent notice clearly discloses that data will be processed on servers outside India (naming the country), consent covers the transfer. Best practice for platforms with foreign-hosted infrastructure. |
12. The Data Processing Agreement Obligation for Cross-Border Flows
Regardless of the transfer mechanism used, every cross-border data transfer under DPDPA requires a Data Processing Agreement under Section 9. For foreign vendors, this creates specific requirements that differ from typical domestic DPAs:
📋 Cross-Border DPA — Additional Requirements vs. Domestic DPA
- Explicit acknowledgement that the transfer is subject to DPDPA Section 16 compliance
- Obligation on the foreign processor to comply with all restrictions notified by the Board on the destination country
- Prohibition on onward transfers to further third countries without prior written consent of the Indian Data Fiduciary
- Obligation to maintain equivalent data protection standards to those required by DPDPA — not merely GDPR or local law
- Right of the Indian Data Fiduciary to audit the foreign processor's compliance and inspect records
- Breach notification timeline calibrated to Indian Board reporting requirements — not the 72-hour GDPR standard
- Governing law clause that preserves the Indian Data Fiduciary's ability to enforce the DPA under DPDPA
- Automatic termination and data deletion obligation if the destination country is added to the restricted list
⚠️ Common DPA Pitfalls With Foreign Vendors
- Accepting the vendor's standard GDPR DPA as-is — it will not cover DPDPA obligations
- DPA specifying EU law as governing law — creates jurisdictional conflict for DPDPA enforcement
- No sub-processor restriction — vendor free to transfer Indian data to any sub-processor in any country
- Breach notification window of 72 hours (GDPR) may be incompatible with faster DPDPA Board notification requirements
- No specific obligation on the vendor to support Data Principal rights requests under Sections 11–14
- No "restricted country" compliance clause — DPA has no mechanism if the Board restricts transfers to vendor's location post-signing
13. How to Map and Audit Your Current Cross-Border Data Flows
Before any compliance documentation can be prepared, organisations must have a complete and accurate picture of where their data actually goes. This cross-border data flow mapping exercise is the foundation of Section 16 compliance and is itself a best-practice requirement under the Act's data governance obligations.
🗺️ Cross-Border Data Flow Mapping — The 6-Step Process
1
Inventory All Vendors and Systems
List every SaaS tool, cloud service, data processor, and partner that your organisation uses — across every function (sales, HR, IT, finance, marketing, operations, customer support). Include tools used by individual departments that IT may not have formally approved.
2
Identify Data Headquarters and Server Locations
For each vendor, identify where data is stored and processed. Many SaaS platforms publish their data centre locations in their security documentation, Trust pages, or DPA schedules. Where not published, ask explicitly — this is your right as a customer and a legal necessity as a Data Fiduciary.
3
Classify the Data Being Transferred
For each vendor, identify what categories of Indian personal data are transferred — customer data, employee data, health data, financial data, children's data. Higher-sensitivity categories (health, financial, children) face greater scrutiny and may be subject to sector-specific localisation requirements that override DPDPA.
4
Assess DPA Status for Each Cross-Border Flow
For each vendor with a cross-border data flow, determine: Is a DPA in place? Is it DPDPA-reviewed? Does it contain the cross-border-specific provisions required? Flag vendors with no DPA (priority), vendors with GDPR-only DPAs (requires review and addendum), and vendors with DPDPA-reviewed DPAs (compliant).
5
Check Privacy Notice Disclosure
Review your privacy notice — does it disclose cross-border transfers? Does it name the countries to which data is transferred? Does it explain the safeguards in place? Update the privacy notice to include this disclosure for all identified cross-border flows.
6
Risk-Rate and Prioritise Remediation
Not all cross-border flows carry equal risk. Prioritise remediation based on: data sensitivity (health, financial = highest priority), data volume (the more data, the higher the penalty exposure), likelihood of Board scrutiny (regulated sectors first), and whether the destination country is likely to be restricted (China-linked flows require immediate attention regardless of volume).
14. Practical Compliance Framework for Cross-Border Transfers
Immediate Actions — Do These Now
Complete the 6-step cross-border data flow mapping exercise. Update your privacy notice to disclose all cross-border transfers, naming destination countries. Identify the five highest-risk cross-border flows (by data sensitivity and volume) and prioritise DPA remediation for those five. Cancel or migrate any data flows to countries that are widely expected to be restricted (particularly China) — it is far easier to migrate before the restricted list drops than after.
Medium-Term — DPA Review and Execution Programme
Systematically review and remediate DPAs with all foreign vendors — starting with priority vendors identified in the flow mapping. For large cloud providers (AWS, GCP, Azure), execute DPDPA-reviewed DPA addenda. For major SaaS platforms (Salesforce, SAP, Workday), engage their legal teams on India-specific DPA addenda. For smaller vendors without standard DPAs, prepare and seek execution of your own DPDPA-compliant DPA template.
Before the Restricted List Is Notified — Architecture Review
Conduct an architecture review of your cloud infrastructure — assess feasibility of migrating workloads to India-region deployments for highest-sensitivity data. Evaluate India-based alternatives for foreign SaaS tools where migration is commercially viable. Prepare a restricted country contingency plan — for each cross-border flow, document the migration or alternative plan that would be activated if the destination country is restricted. Ensure your DPAs include automatic termination and data repatriation clauses triggered by Board restriction notifications.
After the Restricted List and Transfer Conditions Are Notified — Rapid Response
When the Board notifies the restricted country list and transfer conditions simultaneously, organisations with completed flow mapping, reviewed DPAs, and updated privacy notices will need only to: check each identified transfer against the restricted list, activate contingency plans for any restricted-country flows, and update DPAs to incorporate the newly prescribed transfer conditions. Organisations that have not done the preparatory work will face simultaneous, cascading compliance deadlines with no time to meet them.
📊 Cross-Border Data Transfers Under DPDPA — At a Glance
S.16
The governing provision — permissive by default with restricted list forthcoming
₹250 Cr
Maximum penalty — data security breach involving cross-border data flows
14
Compliance areas covered — from cloud to SCCs to sector-specific rules
NOW
Flow mapping and DPA review should start immediately — before the restricted list drops
May 2027
Full enforcement — all transfer conditions and DPAs must be in place
Cross-Border Data Transfer Compliance Is Time-Critical — and Technically Complex
The window between now and the Board's notification of the restricted country list is the most valuable compliance window in DPDPA's implementation timeline. Organisations that map their data flows, remediate their DPAs, and update their consent and privacy documentation during this window will be positioned for immediate compliance when the list drops. Those that wait will face a simultaneous multi-front compliance crisis.
Our Cross-Border Data Transfer Compliance Programme is designed specifically for MNC subsidiaries, cloud-first technology companies, and enterprises with complex foreign SaaS stacks. It includes: a full cross-border data flow mapping exercise, DPDPA-reviewed DPA analysis for your top 10 foreign vendors, India-adapted SCC template development, privacy notice cross-border disclosure drafting, restricted country contingency planning, and a Board-notification readiness assessment — all delivered by advocates specialising in data protection law and technology transactions.
We work with Indian subsidiaries of global MNCs, tech companies with US or EU infrastructure, financial services firms with global data flows, and pharmaceutical companies managing cross-border clinical trial data. Every engagement is confidential and begins with a no-obligation scoping call.
