Foreign SaaS tools for Indian customer data: what DPDP says

At a glance

Using foreign SaaS tools — Salesforce, HubSpot, Dropbox, Slack, an overseas AI vendor — for Indian customer data is generally allowed under the DPDP Act’s negative-list model; no destination country is currently restricted. What the Act doesn’t let you outsource is accountability: the tool is your processor and you stay the Data Fiduciary, answerable for its security, purpose-limitation, retention and breach response. So the real work is vendor due diligence and a proper data-processing agreement — not which country the server sits in.

Educational resource only. This explains how using foreign SaaS tools for Indian personal data sits under India’s Digital Personal Data Protection Act, 2023 (DPDP Act) and its Rules; it is not formal legal advice.

The situation

Almost every Indian business runs on foreign SaaS — a US-headquartered CRM, a cloud storage tool, a support desk, an email platform, increasingly an AI vendor — and all of them hold customer personal data on servers outside India. The recurring worry is whether the DPDP Act quietly bans this, or forces everything back onto Indian soil. It mostly doesn’t. But “allowed” comes with a condition that’s easy to miss: the accountability stays with you, and that’s where the actual compliance work sits.

Are foreign SaaS tools allowed at all?

Yes — under the Act’s negative-list model, transferring Indian personal data to a foreign tool is permitted unless the government has restricted that destination, and so far none is restricted. Section 16 of the DPDP Act lets the central government notify countries or territories to which transfers are barred or conditioned, but as of now no such destination has been notified — so the working default is permissive. A US or EU SaaS vendor holding your Indian customers’ data is not, by that fact alone, a DPDP violation. This surprises teams who assume India runs a strict data-localisation regime; the enacted Act does not impose blanket localisation, and building your tooling strategy around a restricted-country list that doesn’t yet exist is planning for a rule that isn’t in force.

Why the vendor is your processor, not your excuse

Handing data to a foreign SaaS tool moves the data, not the responsibility — you remain the Data Fiduciary for everything that happens to it. Under the Act, a vendor processing personal data on your behalf and on your instructions is your Data Processor, and the fiduciary’s obligations (Section 8) don’t transfer with the upload. If your CRM vendor suffers a breach, mishandles the data, or keeps it after you’ve stopped using them, that’s your exposure as much as theirs, because you chose them and you direct them. “It’s the vendor’s system” is not a defence to a Data Principal or the Data Protection Board of India. That’s why the country of the data centre is a second-order question: what actually protects you is the contract that binds the processor and the diligence you did before signing it.

What to check before routing Indian data through a foreign tool

The vendor’s location matters far less than these six things — check them before the data flows, not after a problem:

• A written processing agreement that binds the vendor to process only on your instructions, for your purposes, with defined security and deletion obligations.
• Sub-processors — who else the vendor hands the data to (their own cloud, analytics, support tooling), and whether that chain is disclosed and controlled.
• Security posture — encryption in transit and at rest, access controls, and a track record you can actually verify, not just marketing claims.
• Breach cooperation — a contractual commitment to notify you fast enough that you can meet your own breach-reporting timelines, which are measured in hours and days.
• Retention and deletion on exit — what happens to your data when you stop using the tool, and whether you can get it deleted (including from backups) on demand.
• Purpose confinement — that the vendor won’t repurpose your customers’ data (for its own model training, product analytics, or resale) beyond what you’ve authorised.

The AI vendors are the sharpest version of the last point: before feeding customer data into a third-party AI tool, confirm what it does with the inputs, because “we improve our services with your data” can mean your customers’ personal data trains someone else’s model.

Step by step: a DPDP-ready vendor setup

Diligence first, contract second, oversight ongoing.

1. Inventory which tools hold Indian personal data, and what each one holds — you can’t govern a data flow you haven’t mapped.
2. Run the six-point check above on each material vendor before onboarding, and re-run it at renewal.
3. Put a data-processing agreement in place with every processor, covering instructions, security, sub-processors, breach notice, and deletion.
4. Reflect the tool in your notice and records — your privacy notice and internal processing record should account for the fact that data goes to that vendor.
5. Constrain purpose in the contract, especially any AI or analytics use of the data beyond delivering the service to you.
6. Set the exit terms up front — how data is returned or deleted when you leave, so offboarding isn’t a scramble.
7. Keep oversight live — a vendor that was fine at signing can change sub-processors or terms; review periodically.

Use the template

Data Processing Agreement (DPA) template — a free, ready-to-adapt DPA covering the processor obligations above. It’s the instrument that makes “the vendor is bound” true rather than assumed.

The sector and SDF exceptions to watch

Two things can override the permissive default and force Indian data to stay in India — know if either applies to you. First, sectoral rules: Section 16 preserves any Indian law that imposes stricter localisation, and some sectors have one — most notably the Reserve Bank of India’s payment-data localisation directive, which requires payment-system data to be stored only in India. If you’re in a regulated sector, your regulator’s localisation rule sits on top of DPDP and can bar the foreign tool for that data class. Second, Significant Data Fiduciary status: a business the government notifies as an SDF (a status assigned, not self-selected) can be separately required to keep specified categories of data within India. Neither is a general rule you can ignore if it applies — so if you’re in finance, insurance, or plausibly SDF-scale, check your sector’s localisation position before defaulting to a foreign tool.

FAQ