Data localization under India's Digital Personal Data Protection (DPDP) Act 2023 works differently from what most compliance teams expect. Instead of a GDPR-style adequacy whitelist, where a destination country first has to be certified "safe" before data can flow there, DPDP flips the default: cross-border transfer of personal data is allowed to any country in the world, except the specific ones the central government chooses to restrict by notification. That is a blacklist model, not a whitelist model, and it makes DPDP one of the more transfer-friendly major data protection laws globally — right up until you remember that sector regulators such as the RBI still enforce their own, stricter, in-India-only localization rules that DPDP does not override.
This distinction matters because most Indian companies run on foreign infrastructure by default — AWS, Google Cloud, Azure, Salesforce, Slack, GitHub, and dozens of SaaS tools headquartered outside India. Knowing exactly which rule governs which data flow, and where DPDP's permissiveness stops and a sector-specific localization mandate begins, is now a board-level compliance question, not just an engineering detail.
The DPDP Blacklist Model for Cross-Border Data Transfer Explained
Section 16 of the DPDP Act 2023 sets the default rule: a data fiduciary may transfer personal data outside India to any country or territory, except one the central government notifies as restricted. Until the government notifies specific countries, the practical position is that cross-border transfer is broadly permitted. This is the opposite of the EU's GDPR, which starts from restriction and requires an adequacy decision, standard contractual clauses, or another approved mechanism before data can leave the EU at all.
The blacklist approach was a deliberate policy choice. Earlier drafts of India's data protection bill (2019 and 2021 versions) leaned closer to a whitelist or explicit-approval model, similar to GDPR, and drew industry pushback for making it harder for India's IT services and SaaS export sector to operate globally. The final DPDP Act 2023 text settled on the simpler blacklist mechanism instead.
Practically, this means an Indian company does not need to run a country-by-country legal adequacy assessment before choosing a cloud vendor the way an EU company would. But "no adequacy assessment required" is not the same as "no obligations apply." Section 8 of the Act still requires every data fiduciary to implement "reasonable security safeguards" for personal data, regardless of where it is processed or stored — a location-agnostic duty that survives even when a transfer itself is permitted.
| Dimension | GDPR Adequacy Model | DPDP Blacklist Model |
|---|---|---|
| Default position | Transfer restricted unless approved | Transfer allowed unless restricted |
| Mechanism | Adequacy decisions, SCCs, BCRs | Government-notified restricted list |
| Compliance burden pre-transfer | High — legal mechanism required per country | Low — check restricted list, then proceed |
| Security obligation after transfer | Required regardless of mechanism | Required regardless of destination (Section 8) |
| Sector overlays | GDPR plus national sectoral rules | DPDP plus RBI, IRDAI, DoT, and other sectoral rules |
Why This Matters for Indian Companies Using Foreign Cloud and SaaS Tools
For a typical Indian SaaS company or SMB running on AWS Mumbai or a US-hosted CRM, the DPDP blacklist model is genuinely good news operationally. It removes the friction GDPR-style regimes impose on cross-border data flows — you are not required to prove that Ireland, Singapore, or the United States meets some formal adequacy bar before your engineering team spins up a database there.
But three practical obligations remain even when a transfer itself is legally clean:
Reasonable security safeguards travel with the data. Section 8(5) requires data fiduciaries to protect personal data in their possession or control, including data processed by a third party on their behalf, wherever it sits. Choosing a foreign vendor does not transfer this legal duty away — you remain accountable for a breach at your cloud provider exactly as if it happened on your own servers.
Contracts with foreign vendors need to reflect DPDP duties, not just the vendor's home-country terms. Standard SaaS terms written for a US or EU customer base often don't address India-specific breach notification timelines, data principal rights (access, correction, erasure), or consent-manager obligations DPDP introduces. Data processing agreements should be reviewed and, where necessary, amended.
The restricted-country list can change with limited notice. Because the mechanism is government notification rather than a static legal test, a country could be restricted after your architecture is already built around a vendor located there. Tracking vendor concentration — knowing which providers and regions you depend on — is now a compliance hygiene item, not just an infrastructure one.
Sector-Specific Localization Rules That Still Apply Regardless of DPDP
DPDP is a horizontal, general-purpose law. It sits alongside — and does not replace — sector regulators that already impose their own, often stricter, data localization requirements. A compliance program that stops at "DPDP allows this transfer" without checking sector overlays is incomplete.
RBI payment data localization. The Reserve Bank of India's 2018 directive on storage of payment system data requires payment system operators — banks, card networks, wallets, aggregators, and gateways — to store the entire data relating to a payment transaction in a system located only in India. Where a transaction has a foreign processing leg, that data may be processed abroad if needed, but it must be deleted from the foreign system and brought back to India within a short window, per RBI's directive. This rule predates DPDP by five years and is enforced independently by RBI — DPDP's permissive cross-border stance does not soften it.
Insurance sector expectations (IRDAI). The Insurance Regulatory and Development Authority of India has issued outsourcing and data governance guidance shaping where and how insurers can process policyholder data, particularly for outsourced functions. Insurers using foreign SaaS tools for policy administration or claims need to check these sectoral conditions independently of DPDP.
Telecom subscriber and call data. License conditions issued by the Department of Telecommunications impose retention and in-country handling expectations on telecom operators for subscriber records and call detail records, reflecting national security and lawful-interception considerations that predate DPDP and continue to apply in parallel.
Government and critical infrastructure data. Entities designated as Critical Information Infrastructure, and organizations handling government or critical-sector data, face additional localization and security expectations under India's cybersecurity framework, coordinated through CERT-In and the National Critical Information Infrastructure Protection Centre.
Know your vulnerabilities before attackers do
Run a free VAPT scan — takes 5 minutes, no signup required.
Book Your Free ScanPractical Steps for DPDP Cross-Border and Localization Compliance
- Map your data flows by type and destination. Build an inventory of what personal data you collect, which vendor processes it, and where it is stored geographically. Most companies discover they don't have this map at the detail regulators expect.
- Classify sector overlays first. Before relying on DPDP's general transfer permission, check whether the data is payment data (RBI), insurance data (IRDAI), telecom data (DoT), or critical infrastructure data. Sector rules take precedence where stricter.
- Review vendor and cloud contracts for DPDP-specific terms. Standard SaaS agreements rarely address Indian breach-notification timelines or data principal rights out of the box. Negotiate India-specific data processing addenda where needed.
- Apply reasonable security safeguards uniformly. Encryption at rest and in transit, access controls, logging, and incident response readiness are DPDP obligations that don't vary by whether your infrastructure sits in Mumbai or Virginia.
- Build a monitoring process for the restricted-country list. Assign clear ownership for tracking MeitY notifications under Section 16 so a future restriction isn't discovered only after an incident.
- Validate technical controls with independent testing. Data mapping and contracts are policy controls; they don't confirm systems are actually secure. Regular vulnerability assessment and penetration testing of applications and APIs handling personal data closes that gap.
- Prepare breach-notification workflows in advance. DPDP requires timely notification to the Data Protection Board and affected data principals after a breach; this workflow needs to exist and be tested before it's needed.
Getting the Full Picture Right
Data localization compliance under DPDP is ultimately a mapping and monitoring discipline: know what data you hold, know which rulebook — general DPDP or a sector regulator — governs each category, and keep reasonable security safeguards in place regardless of where the data physically sits. Policy and contracts establish the framework, but they don't verify your systems actually enforce it. Bachao.AI, built by Dhisattva AI Pvt Ltd, runs automated vulnerability assessment and penetration testing that surfaces exposed data stores, misconfigured cloud storage, and insecure APIs handling personal data, giving teams a factual picture of whether their DPDP safeguards hold up under test. If you want to see where your externally-facing systems stand today, a free VAPT scan is a fast starting point, and teams building out their compliance program can review DPDP compliance requirements in more depth. More breakdowns like this one are on the Bachao.AI blog.