Cross-Border Data Transfers Under India's DPDP Act: A Practical Guide

Understanding Section 16: The DPDP Act's Cross-Border Framework

Section 16 of India's Digital Personal Data Protection Act establishes the legal framework for transferring personal data outside India. Unlike the GDPR's adequacy-plus-safeguards model, the DPDP Act takes a fundamentally different approach: the Central Government publishes a list of countries and territories to which transfers are restricted, and all other destinations are permitted by default.

This is a blacklist model rather than the GDPR's whitelist model. Instead of requiring organisations to prove that a destination country provides adequate protection, the DPDP Act assumes transfers are permissible unless the government specifically restricts them. The practical effect is that most cross-border transfers are allowed without additional safeguards — at least until the government publishes its restricted list.

The Act also grants the Central Government power to restrict transfers of specific categories of personal data to specific countries, creating a granular regime. For example, the government could restrict transfers of financial data to certain jurisdictions while permitting transfers of other categories. This sector-specific approach reflects India's interest in data sovereignty without implementing a blanket data localisation requirement.

For SaaS companies operating in India, this means the compliance obligation is to monitor the government's restricted list and ensure that no transfers occur to restricted destinations. This is simpler than GDPR's Transfer Impact Assessment process, but the uncertainty about which countries will eventually be restricted creates planning challenges.

The Whitelist Approach: Which Countries Are Approved

As of mid-2026, the Central Government has not yet published the definitive list of restricted countries. The DPDP Rules provide the mechanism for the government to notify restricted territories, but the actual notifications are still being finalised. This creates a period of regulatory uncertainty that organisations must navigate carefully.

The government has signalled through draft rules and public consultations that the approach will be risk-based, considering factors such as the destination country's data protection legislation, its enforcement track record, international agreements with India, and geopolitical considerations. Countries with robust data protection frameworks — the EU, UK, Canada, Japan, Australia — are widely expected to remain unrestricted.

The practical advice for SaaS companies is to document your current cross-border data flows comprehensively now, before the restricted list is published. Map every transfer: which data categories flow to which countries, through which processors, for which purposes. When the restricted list arrives, you will need to rapidly assess whether any of your transfers are affected and implement alternative arrangements if they are.

Organisations should also build contractual flexibility into their data processing agreements. Include clauses that address the possibility of future transfer restrictions, specifying what happens if a destination country is added to the restricted list. This forward-looking approach avoids the scramble that many organisations experienced when Schrems II invalidated the EU-US Privacy Shield overnight.

Standard Contractual Clauses: India's Approach Compared to GDPR

The GDPR relies heavily on Standard Contractual Clauses as a transfer mechanism when adequacy decisions are not available. The European Commission publishes approved SCCs that organisations incorporate into their data processing agreements, creating contractual obligations that compensate for the absence of adequate data protection law in the destination country.

India's DPDP Act does not establish an equivalent SCC mechanism. Because the Act uses a blacklist model rather than a whitelist model, there is no need for a contractual fallback — transfers are either permitted (destination not on the restricted list) or prohibited (destination on the restricted list). There is no middle ground where contractual safeguards make an otherwise impermissible transfer permissible.

However, this does not mean that contractual safeguards are irrelevant under the DPDP Act. Data Fiduciaries remain responsible for the processing activities of their Data Processors regardless of where that processing occurs. If a Data Fiduciary transfers personal data to a processor in a permitted country, the Fiduciary must still ensure that the processor complies with the DPDP Act's requirements — consent obligations, purpose limitation, data security, and breach notification.

The practical recommendation is to use robust data processing agreements that incorporate DPDP Act obligations even when transferring to unrestricted countries. These agreements should specify the purposes of processing, the data categories transferred, the security measures required, the breach notification timeline, and the Fiduciary's audit rights. This is not a legal requirement in the same way that GDPR SCCs are, but it is a best practice that reduces your risk exposure.

GDPR Adequacy vs DPDP Act Restrictions: A Side-by-Side Comparison

The structural differences between the GDPR and DPDP Act cross-border transfer regimes have practical implications for organisations operating under both frameworks. Understanding these differences is essential for building a unified compliance programme.

The GDPR's Chapter V creates a tiered system: adequacy decisions (Article 45), appropriate safeguards including SCCs and BCRs (Article 46), and derogations for specific situations (Article 49). Each tier involves different levels of effort and provides different levels of certainty. An adequacy decision provides blanket permission; SCCs require a Transfer Impact Assessment; derogations are case-by-case.

The DPDP Act's Section 16 is binary: a destination is either restricted or it is not. There are no intermediate tiers, no need for Transfer Impact Assessments, and no derogation mechanism. This simplicity is an advantage for compliance teams — the analysis is straightforward once the restricted list is published.

The key complexity arises for organisations that process data of both Indian and EU data subjects. A transfer from India to the United States might be permitted under the DPDP Act (assuming the US is not on the restricted list) while requiring SCCs and a TIA under the GDPR. These organisations need to apply the stricter standard to each transfer, which in practice means building their compliance programme around the GDPR's more demanding requirements and treating DPDP Act compliance as a subset.

The enforcement landscape also differs significantly. GDPR enforcement is decentralised across 30+ Data Protection Authorities with varying levels of aggressiveness. DPDP Act enforcement is centralised through the Data Protection Board of India, which is still establishing its enforcement posture. Organisations should not assume that the DPDP Act's simpler framework means lighter enforcement — the penalties under the Act can reach 250 crore rupees (approximately 30 million USD).

Practical Steps for SaaS Companies: A Transfer Compliance Checklist

SaaS companies face particular challenges with cross-border transfers because their architecture inherently involves data flowing across jurisdictions. A customer in Mumbai using a SaaS product hosted on AWS in Mumbai might have their data processed by a sub-processor in the United States, backed up to a region in Ireland, and accessed by a support team in the Philippines. Each of these flows is a cross-border transfer that must be assessed.

Step one is a comprehensive data flow mapping exercise. Document every instance where personal data of Indian data principals crosses a national border. Include primary processing, backup and disaster recovery, sub-processor access, support and maintenance access, and analytics processing. Many SaaS companies discover transfers they were not aware of during this exercise — a third-party analytics tool that sends data to servers outside India, or a customer support platform hosted in another jurisdiction.

Step two is to assess each transfer against the DPDP Act's requirements. Currently, with no restricted list published, this means documenting the transfers and monitoring for regulatory developments. Establish a process for reassessing transfers when the restricted list is eventually published.

Step three is to update your privacy notices and consent mechanisms. The DPDP Act requires Data Fiduciaries to inform data principals about the transfer of their data. Your privacy notice should specify which countries receive personal data and for what purposes. If you use a consent-based approach, ensure that cross-border transfers are clearly disclosed in the consent request.

Step four is to review and update data processing agreements with all sub-processors who receive personal data outside India. Ensure these agreements include DPDP Act-specific obligations: the sub-processor's commitment to comply with the Act's requirements, breach notification timelines aligned with the Act, and the Fiduciary's right to audit the sub-processor's compliance.

Data Localisation Requirements: What the DPDP Act Actually Requires

There is widespread confusion about whether the DPDP Act imposes data localisation requirements. The short answer is: the Act itself does not mandate data localisation, but it creates a mechanism through which the government can effectively achieve localisation for specific data categories.

The DPDP Act does not contain a provision requiring that personal data be stored or processed within India's borders. This is a deliberate departure from earlier drafts of the legislation, which included explicit localisation requirements for certain categories of sensitive personal data. The final Act removed these provisions in response to industry feedback about the impracticality and cost of strict localisation.

However, Section 16's blacklist mechanism gives the government the power to restrict transfers of specific data categories to all countries, which would effectively mandate localisation for those categories. If the government restricts transfers of financial personal data to all foreign destinations, organisations would have no choice but to process that data within India. This indirect localisation power is one of the most significant aspects of the Act's cross-border framework.

For SaaS companies, the practical implication is to build architecture that can accommodate potential localisation requirements. This does not mean you need to deploy everything in India today, but your infrastructure should support data residency options. Cloud providers like AWS, Azure, and GCP all offer Indian regions, so the technical capability is available. The question is whether your application architecture supports configuring data residency on a per-tenant or per-data-category basis.

Organisations that have already invested in data residency capabilities for GDPR compliance are well-positioned. The architectural patterns for GDPR data residency — tenant-level region configuration, regional data isolation, cross-region replication controls — apply equally to DPDP Act localisation scenarios. If your platform can guarantee that a European customer's data stays within the EU, extending that capability to guarantee that an Indian customer's data stays within India is an incremental effort rather than a ground-up rebuild.

Preparing for Regulatory Changes: Building an Adaptive Compliance Programme

The DPDP Act's cross-border transfer regime is still evolving. The restricted country list has not been published, the Data Protection Board is still being constituted, and enforcement practices are yet to be established. Organisations need a compliance programme that can adapt to regulatory developments without requiring a complete overhaul each time the rules change.

Build your compliance programme on a foundation of comprehensive data flow documentation. Regardless of how the restricted list evolves, you will always need to know what personal data flows where and why. Invest in automated data discovery and classification tools that continuously map data flows across your infrastructure. Manual data mapping exercises become stale within months as architectures evolve — automated tools keep the mapping current.

Establish a regulatory monitoring process that tracks DPDP Act developments — new rules, government notifications, Data Protection Board guidance, and enforcement actions. Assign responsibility for this monitoring to a specific role or team, and define escalation procedures for developments that require action. The transition from the current uncertainty to an active enforcement regime could happen quickly once the Board is fully operational.

Develop playbooks for likely scenarios. What if the US is added to the restricted list? What if financial data is subject to localisation? What if specific sub-processors are affected? Having pre-planned responses to these scenarios reduces your reaction time from weeks to days when regulatory changes occur.

Finally, engage with industry groups and legal advisors who are actively participating in the DPDP Act's rulemaking process. The rules are still being shaped, and informed industry participation can influence outcomes. Understanding the direction of regulatory thinking helps you make better architectural and compliance decisions today, even in the absence of final rules.