Ready to find your vulnerabilities?Find your vulnerabilitiesStart free scan →
Negative-list, not allowlist
DPDP Cross-Border Data Transfer — Section 16 Restrictions Explained
DPDP Section 16 permits personal data transfers to every country EXCEPT those the Central Government explicitly restricts — the inverse of GDPR's adequacy model.
No restricted countries have been notified as of mid-2026. Transfers are broadly permitted today — but sectoral localisation rules can be stricter.
Unlike GDPR, which requires a positive adequacy finding before data can leave the EU, DPDP Section 16 assumes transfers are permissible unless the Central Government has notified a specific country as restricted. Restrictions are published via Gazette notification after the Government assesses factors such as national security, bilateral diplomatic relationships, and the receiving country's data-protection regime. Until a notification is issued, no country is formally restricted.
Transfers to all countries are permitted by default — the absence of a restriction is itself a legal basis
Restricted-country list will be notified by the Central Government via official Gazette, not by a regulatory circular
As of mid-2026, the Central Government has not notified any restricted countries — the list is effectively empty
Even after a country is restricted, specific transfers may still be permitted if the Government carves out exceptions (e.g., diplomatic, medical emergency, treaty obligations)
Sectoral overrides — where RBI, SEBI, and IRDAI are stricter
DPDP does not supersede sector-specific data-localisation mandates. Regulated entities must layer their sectoral obligations on top of — not instead of — Section 16. This creates a dual-compliance requirement wherever a sectoral regulator has issued data-residency rules.
RBI (2018 circular): payment system data — transaction details, payment instructions — must be stored exclusively in India. Processing and mirroring abroad require a copy retained domestically. Applies to all Payment System Operators (PSOs), not just banks.
SEBI: stock brokers and depositories must retain securities-related data in India; specific records lists are updated periodically via SEBI circulars.
IRDAI: insurance data including policy, claims, and premium information must be stored in India for regulated insurers.
MeitY: sensitive personal data categories (once notified under DPDP rules) may attract additional localisation requirements beyond the base Section 16 framework.
Healthcare (ABDM/NHA): patient health records processed under ABDM norms must be stored in India under the Health Data Management Policy.
What your privacy notice must cover for cross-border transfers
Section 5 of DPDP requires your privacy notice to be clear, plain-language, and complete before consent is sought. For cross-border transfers specifically, the notice must inform data principals of the countries or categories of countries to which their data may be transferred, the purpose of transfer, and the categories of data transferred. Vague language like 'we may transfer your data internationally' is insufficient — name the destination categories.
List countries or regions where data may be processed (e.g., EU, USA, Singapore) — be specific about your cloud provider's regions
State the purpose of the transfer (e.g., payment processing, fraud detection, customer support)
Identify categories of personal data involved in each transfer stream
If relying on processor contracts, state that processors are contractually bound by equivalent protections under Section 8
Update the notice before adding new transfer destinations — retroactive updates require fresh consent if the new transfers are materially different from what was originally disclosed
Processor and sub-processor obligations under Section 8 for cross-border flows
When transfers happen through a processor, Section 8 requires a written agreement imposing the same data-protection obligations the fiduciary has under the Act. For overseas processors, this means the contract must mirror DPDP's consent, purpose limitation, and security requirements — even if the processor's home jurisdiction has no comparable law. Sub-processors introduced by your processor require your express authorisation and must be bound by the same contractual chain.
Data Processing Agreement (DPA) must specify the purpose, categories of personal data, and duration of processing
Processor must process data only on documented instructions from the fiduciary — no autonomous use
Processor must assist the fiduciary in meeting breach notification obligations (Section 8(6))
Sub-processor onboarding: processor must notify the fiduciary of new sub-processors; fiduciary retains the right to object
Audit rights: include a right-to-audit clause covering sub-processors in all DPAs
On termination, overseas processor must delete or return personal data as instructed — get this in writing
Audit evidence to maintain for cross-border transfers
Demonstrating compliance to the Data Protection Board requires contemporaneous documentation — not reconstructed records. For cross-border transfers, the minimum evidentiary baseline includes a current data-flow map, contractual documentation for each processor relationship, and records showing no transfers to notified restricted countries.
Data-flow inventory: every cross-border data stream documented with source system, destination country, processor identity, and legal basis
Current DPAs for all overseas processors and sub-processors, reviewed and dated
Records of consent where the legal basis for processing (and transfer) is consent
Sectoral compliance evidence: RBI localisation compliance certificates or audit logs if applicable
Review cadence: data-flow map reviewed at least annually and on any material change to system architecture or vendor relationships
Common cross-border compliance gotchas
Most cross-border compliance failures stem from incomplete data-flow mapping rather than intentional non-compliance. Organisations frequently underestimate the number of data destinations created by their SaaS stack — each vendor may use multiple cloud regions, third-party analytics, and offshore support teams.
Cloud region sprawl: your SaaS vendor's EU cluster may auto-replicate to US regions — check data residency settings, not just contract terms
Support-team access: offshore customer support with read access to personal data constitutes a transfer — include this in your flow map
Analytics SDKs: client-side tracking scripts (analytics, session recording, A/B testing) send data to vendor servers abroad before you ever process it
AI/ML vendor APIs: sending personal data to overseas model APIs for inference or fine-tuning is a transfer requiring documentation
Subprocessor churn: SaaS vendors change sub-processors frequently; ensure your DPA requires advance notice and track these changes
DPDP cross-border compliance gap review
Map every cross-border data flow, identify sectoral-override risks, and get a Section 8 processor checklist — free first engagement.