DPDPA Cross-Border Data Transfer: What Section 16 Means for Indian Businesses with Global Ops

If your customer data ever leaves Indian shores, maybe it sits on a cloud server in Singapore, gets processed at a data centre in Europe, or flows through a global analytics platform based out of the US, then Section 16 of the DPDPA is already relevant to you.

A lot of businesses hear "cross-border data transfer" and assume it is something only the big multinationals need to worry about. That is not really true anymore. If you are using AWS, Azure, GCP, or pretty much any SaaS tool that is not hosted in India, there is a good chance your customer data is quietly crossing borders every single day.

What Section 16 Actually Does

Here is where a lot of people get confused, and honestly, it is understandable. If you have studied GDPR before, you are used to the idea of "adequacy decisions", where the EU decides certain countries are safe enough to receive data and permits transfers to them.

The DPDPA works differently. Instead of pre-approving countries, the Indian government has taken the opposite approach: it can publish a negative list of countries where data transfer is restricted. Think of it less like a whitelist and more like a blacklist that has not been written yet.

Section 16(1) of the Act states: "The Central Government may, after an assessment of such factors as it may consider necessary, notify that the transfer of personal data by a Data Fiduciary to any country or territory outside India shall not be made." Until that notification, transfers are legally permissible.

And that "has not been written yet" part matters a lot right now. As of mid-2026, the Central Government has not issued any notification identifying restricted countries. That means all cross-border transfers are currently permitted under DPDPA, subject to sectoral rules.

But that does not mean businesses should just relax and wait. It means the opposite, really. You need to know exactly where your data lives so that if a country you are relying on suddenly lands on that list, you are not scrambling. When notifications land, they will take effect on the date of publication. There is no GDPR-style adequacy runway, no transition grace period written into the Act.

What Counts as a Cross-Border Transfer

This is broader than most people expect. It is not just about deliberately shipping data overseas for some business reason. A transfer happens the moment personal data belonging to an Indian individual is accessed from, stored in, or transmitted to any location outside India.

In practice, that covers a lot of ground:

• Cloud storage sitting in international regions, think AWS us-east, Azure Europe, or even GCP Singapore

• SaaS platforms that are headquartered or run their infrastructure outside India

• Analytics tools that quietly route your Indian customer data through servers abroad

• Email marketing platforms hosted overseas

• Any data-sharing arrangement you have with a global parent company or partner

If you sat down and actually traced where your data goes, you might be surprised how many of these boxes your business ticks without anyone having consciously decided it that way. Most of it just happened, as tools got added over the years.

What the DPDPA Does Not Require

One of the distinguishing features of India's data protection framework is that it deliberately refrains from incorporating several transfer mechanisms that are central to the GDPR. The DPDPA does not currently require organisations to execute Standard Contractual Clauses (SCCs), implement Binding Corporate Rules (BCRs), or undertake Transfer Impact Assessments (TIAs) as a condition for transferring personal data outside India. These remain GDPR constructs under Articles 46 and 47 and have no direct statutory equivalent under Indian law.

Any compliance team retrofitting GDPR transfer mechanisms onto Indian law is doing unnecessary work and, more critically, is potentially misdirecting effort from what the Act does require.

What is required, regardless of transfer destination, is a lawful processing basis. For the vast majority of commercial cross-border transfers, that basis is consent under Section 6. A SaaS HR platform that processes payroll for Indian employees on AWS US-East, for example, can transfer the data under Section 16. But the consent notice presented to those employees at onboarding must disclose the cross-border transfer, identify the recipient country or region, and specify the purpose. A generic "we use third-party service providers" clause does not satisfy Section 6(1).

Step One: Map It Before You Manage It

You genuinely cannot comply with something you have not mapped. That is the starting point, and it is not glamorous work, but it is necessary.

For every process that touches personal data, you need to figure out where that data physically sits and gets processed. That means going back to your cloud providers, your SaaS vendors, and any data processors you work with, and asking them directly where their infrastructure lives. The good news is that most established, multinational tech providers already have data residency documentation ready to hand over. You just have to ask for it.

It is tedious, sure. But it is a lot less painful to do this now, on your own timeline, than to do it later under pressure with a compliance deadline looming.

When Localisation Becomes the Answer

For data that cannot be sent to a country that ends up restricted, the practical fix is localisation, simply keeping personal data stored and processed within India instead of shipping it abroad.

The good news here is that this has gotten a lot easier over the past few years. Indian regions from the major cloud providers, AWS Mumbai, Azure India, GCP Mumbai, can handle localisation for most standard use cases without much friction.

Where it gets trickier is for companies that depend heavily on global SaaS tools that simply do not offer an Indian hosting option. In those cases, localisation might mean switching vendors entirely, or rethinking parts of your architecture. Not a fun conversation to have with your tech team, but better to have it proactively than reactively.

Sectoral Regulators Are Already in This Game

If you are in BFSI, none of this should feel entirely new. The RBI has, for a while now, required that certain categories of payment and financial data stay exclusively within India, no exceptions, no ambiguity.

The DPDPA's cross-border provisions layer on top of this. Section 16(2) is a savings clause that preserves the applicability of any existing Indian law that provides a "higher degree of protection for or restriction on transfer." This means sectoral rules like RBI's payment data localisation continue to apply even if DPDPA permits the transfer.

RBI's 2018 Payment Data Localisation Circular mandates that all data related to payment systems must be stored only within India. The circular covers the entire payment transaction data chain, from origination to settlement. There is no carve-out for cross-border processing. For fintechs, payment aggregators, and NBFCs processing card transactions or UPI flows, this is an absolute constraint. The DPDPA does not override it.

SEBI's 2023 data localisation advisory requires regulated entities to maintain all trading data and investor data within Indian jurisdiction. IRDAI's 2017 guidelines on data localisation require that all policyholder data remain within India.

So if you have already built localisation practices around RBI rules, you are not starting from scratch here. You are extending something you have already got in place.

Preparing for Cross-Border Data Transfer Compliance

At this stage, managing cross-border data transfer is really a risk preparation exercise more than an active restriction problem. The negative list, the thing that would actually block specific transfers, has not been published yet. Nobody knows exactly which countries will end up on it, or when.

But that uncertainty is exactly why the businesses that get ahead of this now will be in a much better position later. If you map your data flows today and start building localisation capability where it makes sense, you will be able to adapt quickly the moment restrictions do land. The alternative, waiting until there is a deadline attached, means trying to restructure your entire technology setup under pressure, which is never a good place to be.

Better to do the groundwork now, while there is still time to do it properly.
Cross-border data compliance starts with knowing exactly where personal data is collected, stored, processed, and shared. A centralised consent management approach can help organisations maintain visibility into processing purposes and user permissions across different data flows. OneConsent is designed for DPDPA focused consent management, helping businesses build a more structured and auditable approach to consent and data processing.

Request a demo to witness OneConsent in action.