DPDPA restricts cross-border transfer of Indian personal data to countries on a government-approved list — here is how the framework works, which data requires localisation, and what this means for multi-cloud and SaaS-heavy organisations.
How DPDPA Approaches Cross-Border Data Transfers
Section 16 of the Digital Personal Data Protection Act 2023 addresses cross-border transfers of personal data. The approach is a whitelist model: personal data may only be transferred to countries or territories outside India that the central government has approved for this purpose. Transfers to non-approved countries are prohibited — there is no equivalence assessment mechanism (as under GDPR) or binding corporate rules framework that allows transfers to non-listed countries.
This is more restrictive than GDPR's approach, which allows transfers to countries with an adequacy decision, to countries without adequacy decisions using appropriate safeguards (SCCs, binding corporate rules), and in specific circumstances using derogations. Under DPDPA, if a country is not on the approved list, personal data cannot be transferred there — full stop.
The government publishes and maintains the approved countries list, and can add or remove countries based on their data protection frameworks and bilateral considerations. This dynamic list creates an ongoing compliance obligation — a transfer that was compliant when the arrangement was set up may become non-compliant if the destination country is removed from the list.
The Approved Countries Framework: How It Works
The approved countries list is maintained by the Ministry of Electronics and Information Technology (MeitY) and updated by notification. Countries with robust data protection frameworks — notably EU member states (given GDPR), the UK, Canada, Australia, and select others — are candidates for inclusion.
For organisations operating across India and GCC markets, the practical question is whether Saudi Arabia, UAE, and other GCC countries are on the approved list. GCC countries have their own data protection frameworks (Saudi Arabia's PDPL, UAE's PDPPL) which may or may not meet India's adequacy criteria. Organisations with data flows across these jurisdictions need to monitor the approved list actively.
What organisations need to do:
- Map all cross-border personal data flows — cloud storage regions, SaaS vendor data centres, processor locations
- Check whether each destination is on the current approved countries list
- Monitor the list for changes that could affect existing arrangements
- For non-approved destinations, either restructure the data flow (localise storage to India or to an approved country) or cease the transfer
Data Localisation: Which Data Must Stay in India
Beyond the approved countries framework, DPDPA introduces data localisation requirements for specific categories of personal data — categories where the government determines that the national security, sovereignty, or data protection interests of India require that the data remain within Indian territory.
The localisation categories are specified by notification and can be updated. The categories identified in the DPDP Rules 2025 for localisation include sensitive personal data as defined in the Act and data notified on national security or sovereignty grounds.
Sensitive personal data under DPDPA includes:
- Financial data — account numbers, payment card data, credit scores
- Health and biometric data
- Official identifiers — Aadhaar numbers, PAN numbers, passport numbers
- Data related to children
For organisations in banking, healthcare, insurance, or any consumer-facing sector handling financial or health data — localisation requirements apply to a significant portion of the personal data they process. Cloud architectures that rely on global regions outside India for storing this data need to be reviewed and potentially restructured.
What Cross-Border Restrictions Mean for Cloud Infrastructure
The practical impact of DPDPA's cross-border framework on cloud infrastructure decisions is significant. Most major cloud providers (AWS, Azure, GCP) have India-based regions — Mumbai, Pune, Hyderabad — that can serve as compliant storage locations for Indian personal data. The question is whether organisations have configured their cloud architecture to use these regions for Indian data rather than defaulting to global regions.
Common infrastructure patterns that need review:
- Multi-region replication: If your primary database is in India but you replicate to a US or European region for disaster recovery, the replication itself constitutes a cross-border transfer. If the replica contains personal data, the destination country must be on the approved list.
- CDN caching: If personal data is cached at CDN edge nodes globally — even temporarily — this may constitute a cross-border transfer. CDN configurations for Indian personal data should be reviewed.
- Global SaaS platforms: If you use a SaaS CRM, HR system, or analytics platform that stores data in data centres outside India, and that data includes Indian personal data subject to localisation requirements, you may have a compliance gap.
- Backup and archiving: Cross-border backup replication follows the same rules as primary storage — the destination must be an approved country.
SaaS Platforms Serving Indian Customers: The Processor Angle
For SaaS companies that serve Indian enterprise customers — and who are therefore processing Indian personal data as a Data Processor — the cross-border framework applies to where you store and process that data, not just where your customer is located.
If you are a SaaS company headquartered in the US or EU and you have Indian enterprise customers, you are likely operating as a Data Processor for Indian personal data. Your cloud infrastructure choices — specifically where you store the Indian customer data your platform processes — must comply with DPDPA's cross-border framework.
This creates a product infrastructure decision: either store Indian customer data in Indian (or approved-country) cloud regions, or restructure data flows so that Indian personal data does not leave India. For SaaS companies with a significant Indian customer base, this is increasingly a sales-table question — enterprise procurement teams are asking about data residency as a standard RFP item for DPDPA compliance.
Managing Cross-Border Risk with Tokenisation
One approach to managing cross-border data transfer risk is tokenisation at the point of data ingestion — replacing raw personal data identifiers with non-sensitive tokens before data moves across borders. If the data that crosses the border is tokenised — and the tokenisation vault that can resolve those tokens stays in India — then what crosses the border is not personal data within the meaning of DPDPA.
Privault by OpenBlockAI provides PII and PHI tokenisation at the source, before data enters global data pipelines, analytics systems, or cross-border processing workflows. The raw personal data stays in Privault's India-hosted vault; tokens move freely across borders because they carry no personal data. For organisations with complex multi-cloud or multi-region architectures, this approach can significantly reduce the scope of data flows subject to DPDPA's cross-border restrictions — without requiring a full infrastructure rebuild.
The tokenisation approach works best for identifiers (names, phone numbers, account numbers, Aadhaar numbers) that are used as keys in data systems but don't need to be in plaintext for the analytical or operational purpose they serve. For data that genuinely needs to be processed in plaintext cross-border, the approved countries framework must be directly complied with.