BY BUSINESS OBJECTIVE
ASSESS & VALIDATE — FIND WEAKNESSES
Digisecuritas logo
Compliance

Cross-Border Data Transfers Under India's DPDP Rules

H

Harsh

Cybersecurity Experts

·8 min read

Under India's Digital Personal Data Protection Act 2023, cross-border transfers of personal data are permitted by default. Your SaaS can host Indian user data on AWS, Azure, or GCP in servers outside India unless the Central Government specifically restricts that country by notification. No adequacy assessment, no Standard Contractual Clauses, no prior government approval, the transfer is allowed unless India adds that country to a restricted list.

That is the default position. Two things complicate it: the restricted country list does not exist yet but will, and Significant Data Fiduciaries face additional localisation requirements that operate differently. If your SaaS processes Indian user data at scale, the current permissive default may not be the full picture of where your obligations land.

Here is the complete state of cross-border transfer rules under DPDP, what they mean for your cloud architecture today, and what to watch as the framework develops.

How the DPDP Cross-Border Transfer Framework Actually Works

Section 16 of the DPDP Act 2023 states that a Data Fiduciary may transfer personal data of a Data Principal to any country or territory outside India, subject to such terms and conditions as the Central Government may specify.

The operative mechanism is a negative list. Personal data can flow to any country until and unless the Central Government adds that country to a restricted list by official notification. There is no positive approval process, no adequacy assessment, no mechanism for the Data Fiduciary to independently authorise transfers to a given country.

This produces a compliance posture that is currently simpler than GDPR for most transfers: if India has not restricted the destination country, the transfer is lawful. No additional transfer mechanism is required.

What this means in practice for the three major cloud providers:

AWS: Regional infrastructure in Singapore, Tokyo, Sydney, Frankfurt, Ireland, US East and West, and other regions is currently available for Indian user data hosting without any DPDP-specific transfer restriction, because none of those countries are on a restricted list that does not yet exist.

Azure: Same position. Microsoft's data centre regions globally are currently available, subject to the same caveat that restrictions may be introduced by notification.

GCP: Same position. Google Cloud regions outside India are currently available for Indian user data without a specific DPDP transfer mechanism requirement.

The practical answer to "can our SaaS still host on AWS, Azure, or GCP abroad" is currently yes, with the significant qualification that this position depends on the Central Government not adding those regions' host countries to a restricted list, and that Significant Data Fiduciaries face a separate set of localisation requirements.

The Restricted Country List: What to Watch

The Central Government has not yet published a list of restricted countries as of mid-2026. The DPDP Rules 2025 notified in November 2025 established the framework for how those restrictions will operate but did not name specific countries at notification.

This creates a compliance monitoring obligation rather than a current restriction. Any company processing Indian user data cross-border needs a process to:

  • Monitor MeitY notifications for restricted country announcements

  • Assess whether any announced restrictions affect their cloud regions or vendor locations

  • Have a documented plan for how data architecture would change if a key region were restricted

Operating on the assumption that the list will never be published, or will never affect your regions, is not a defensible compliance position. The framework exists specifically to allow restrictions to be imposed, and geopolitical and sovereignty considerations make it likely that some restrictions will be introduced over time.

Digisecuritas' DPDP Compliance Services include ongoing regulatory monitoring as part of the compliance programme, so changes to the restricted country list, SDF designations, or framework updates are flagged and acted on without clients having to track MeitY notifications independently.

How DPDP's Transfer Framework Compares to GDPR

For SaaS companies already running GDPR compliance, the contrast is significant and worth understanding clearly.

Under GDPR, transferring personal data outside the European Economic Area requires a lawful transfer mechanism: an adequacy decision for the destination country, Standard Contractual Clauses with the receiving entity, Binding Corporate Rules for intra-group transfers, or specific derogations for limited scenarios. Without one of these, the transfer is unlawful regardless of where the data is going.

This architecture has created substantial compliance overhead for SaaS companies, reviewing and executing SCCs with vendors, tracking adequacy decisions (including their revocation, as with the original EU-US Privacy Shield), and maintaining transfer impact assessments for higher-risk destinations.

DPDP's negative-list model eliminates that overhead in the current state. No transfer mechanism is required. The compliance question for cross-border transfers under DPDP today is simply: has this destination country been restricted? If not, proceed.

Factor

GDPR

DPDP

Default position

Transfers restricted unless mechanism in place

Transfers permitted unless country restricted

Transfer mechanism required

Yes: adequacy, SCCs, BCRs, or derogation

No mechanism required currently

Adequacy assessments

Yes, conducted by European Commission

No adequacy framework

Standard Contractual Clauses

Used extensively

Not part of DPDP framework

Restricted destinations

Requires positive mechanism for all non-adequate countries

Only countries on Central Government restricted list

Who decides restrictions

European Commission (adequacy)

Central Government of India (by notification)

For companies operating under both frameworks, which covers most SaaS businesses with both EU and Indian user bases, GDPR transfer compliance is the more complex obligation today. DPDP's current simplicity does not reduce the GDPR overhead; it means the Indian user data stream has fewer transfer-specific requirements for now.

Our piece on running GDPR and DPDP compliance as one programme covers how to structure that dual compliance without duplicating effort across both frameworks.

Significant Data Fiduciaries and Data Localisation

The picture changes for companies designated as Significant Data Fiduciaries under the DPDP Act.

Rule 12 of the DPDP Rules 2025 imposes additional requirements on SDFs regarding certain categories of personal data and related traffic data. SDFs may be required to store and process specific categories of data within India, effectively reintroducing data localisation for those categories even under a framework that is otherwise transfer-permissive.

The specific categories subject to localisation requirements under Rule 12 are determined by the Central Government and have not been fully enumerated at the time of the Rules' notification. The framework creates the mechanism; the specific data types will be specified through subsequent government notifications.

For SaaS companies that may be designated SDFs, typically large consumer-facing platforms, financial services, or health applications processing substantial volumes of Indian user data,the localisation risk is real and needs to be built into cloud architecture planning now, before designation occurs. Redesigning data residency after designation is considerably more expensive than accounting for it in advance.

Our detailed guide on what DPDP expects from a Significant Data Fiduciary covers the full SDF obligation set, including the localisation requirements under Rule 12.

Digisecuritas' Cloud Security Audit and DPDP compliance practice work together to assess your current cloud architecture against both the standard transfer framework and the SDF localisation requirements, identifying where architecture changes may be needed before designation creates a deadline.

What SaaS Companies Should Do Now

Map where Indian user data actually goes: Before assessing compliance, you need an accurate picture of where your Indian user data flows, which cloud regions, which third-party vendors, which sub-processors. Many SaaS companies discover during this mapping that data flows to more locations than their architecture documentation suggests, particularly through analytics tools, customer support platforms, and monitoring services.

Check your vendor contracts: Even under DPDP's permissive transfer framework, your contracts with data processors need to meet the Act's requirements for Data Processor agreements, processing scope, security obligations, breach notification upstream, and deletion on termination. A vendor located abroad is still a processor that needs a compliant contract. Our third-party vendor risk management guide covers the vendor contract discipline this requires.

Set up regulatory monitoring: The restricted country list will come. Build a process to track MeitY notifications so you are not discovering restrictions after they have been in force for months.

Assess SDF designation risk: If your SaaS processes personal data for a large Indian user base, evaluate the likelihood of SDF designation against the criteria the Act specifies, volume, sensitivity, risk to data principals, national security implications. If designation is plausible, factor localisation requirements into your cloud roadmap now.

Document your current transfer position: Even where no formal transfer mechanism is required, documenting your data flow map, the legal basis for each transfer, and your monitoring process for the restricted list is the evidence that demonstrates a compliance programme was in place if a question is ever raised.

A Practical Checklist for Cross-Border Transfer Compliance

  • Data flow map completed covering all cloud regions, vendors, and sub-processors handling Indian user data

  • Confirmed no destination countries are currently on the Central Government restricted list

  • Process established for monitoring MeitY notifications for restricted country updates

  • Data Processor contracts in place with all vendors and cloud providers handling Indian user data, meeting DPDP contractual requirements

  • SDF designation risk assessed against the Act's designation criteria

  • Cloud architecture review conducted for localisation feasibility if SDF designation is a realistic scenario

  • Cross-border transfer position documented as part of the broader DPDP compliance programme

Final Thoughts

The DPDP Act's cross-border transfer framework is genuinely more permissive than GDPR's in its current state. For most SaaS companies, hosting Indian user data on major cloud platforms abroad is lawful today without any specific transfer mechanism. That permissiveness has led some companies to deprioritise this area of DPDP compliance entirely, which is a mistake for two reasons.

The restricted list will come, and the companies with no monitoring process or documented transfer position will be reactive when it does. And for potential SDFs, the localisation requirements under Rule 12 mean the permissive default never fully applied in the first place.

Building the data flow map, the vendor contracts, and the monitoring process now costs a fraction of what reactive remediation costs after a restriction notification or an SDF designation. The architecture decisions your engineering team makes today about where Indian user data lives are compliance decisions with a potentially long shelf life.

Digisecuritas helps SaaS companies map their cross-border data flows, assess SDF designation risk, and build a transfer compliance programme that holds up as the DPDP framework develops. Book a Discovery Call to walk through your current cloud architecture and understand where your obligations sit today and where they may move.


Frequently Asked Questions

Related reading