Skip to content
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.

Section 16allowlist model
Negative listtransfer mechanism
SectoralRBI / SEBI / IRDAI
Freegap review
Section 16 negative-list analysisSectoral override mappingSub-processor audit

How Section 16's negative-list model works

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.

Find your vulnerabilitiesStart free scan →