Compliance
Keeping training data in India: what the DPDP Act actually asks of you
Data residency gets discussed as though it were a firewall rule. Most of what the DPDP Act requires is about accountability, not geography — but geography still shortens some conversations.
- Topic
- Data protection
- Reading
- About 6 minutes
- Published
- 31 July 2026
- Not legal advice
- See below
Contents
The short version
The DPDP Act 2023 does not impose blanket data localisation. It permits transfer outside India except to countries the government restricts. What it does demand is that you know what personal data you hold, why, on whose instruction, and that you can answer a person who asks about theirs. Hosting in India does not discharge those duties — it just removes one variable.
Not legal advice
We host GPUs; we are not your lawyers. This is a practical orientation for engineers, not a compliance opinion. Rules and notified restrictions change. Get advice for your own situation before relying on any of it.
01What the Act does not say
The most common misconception is that India requires all personal data to stay in India. That was proposed in earlier drafts and is not what the 2023 Act does. The general position is permissive: transfer outside India is allowed, except to territories the central government specifically restricts by notification.
Sector rules are a different matter. Reserve Bank of India directions on payment system data are genuinely localising, and other regulators impose their own requirements. If you are in a regulated sector, that regime — not the DPDP Act — is usually what binds you.
02What it does require
The obligations that actually bite are procedural, and they apply wherever the bytes live:
- Purpose and consent. You process personal data for a lawful purpose the person was told about. “We might train something on it later” is not that.
- Data minimisation. Hold what the purpose needs, not everything you happened to collect.
- Accuracy and erasure. Correct it on request; delete it when the purpose is served or consent is withdrawn. For a training pipeline this is the hard one — see below.
- A named Grievance Officer. A real, reachable person who answers within a defined period. Ours is named in Privacy Policy §8.
- Breach notification. To the Board and to affected people.
- Accountability down the chain. If you use a processor, you remain responsible. Their compliance is your problem.
03Where you sit in the chain
This is the part engineers most often get backwards, and it decides who owes what.
If you rent a GPU from us and put a dataset containing personal data on it, you are the data fiduciary. You decided what to collect and why. We are a data processor: we host the bytes on your instruction and nothing more. We do not decide what goes on your instance, we do not inspect it, and we do not use it for anything of our own.
Practically that means the erasure request lands on you, not on us. We can delete an instance; we cannot find one person’s rows inside your training set. Which is why the design decision matters more than the hosting decision.
The trained-model problem
Deleting a row from a dataset is easy. Removing its influence from a model you already trained is not — retraining is often the only honest answer. If your pipeline may need to honour erasure requests, decide before training how you would do it: keep provenance for every training example, prefer aggregation or pseudonymisation where the signal survives it, and avoid training on identifiable personal data unless the purpose genuinely requires it.
04Where hosting location genuinely helps
Residency is not a compliance silver bullet, but it is not theatre either. It helps in specific, real ways:
- Fewer transfers to justify. If the data never leaves India, cross-border transfer analysis largely stops being a question you have to answer.
- Shorter vendor reviews. Enterprise and public-sector procurement in India asks where data resides. “Mumbai” ends that thread quickly.
- Contractual clarity. One jurisdiction, one governing law, one set of courts. Our Terms §16 is India throughout.
- Latency, incidentally. Not compliance, but if your users are in India, a Mumbai round trip beats a Virginia one.
What it does not do: it does not create consent you never obtained, it does not minimise a dataset you over-collected, and it does not exempt you from erasure.
05A practical checklist
| Do this | Why |
|---|---|
| Inventory personal data in your training sets | You cannot minimise or erase what you have not catalogued |
| Record provenance per example | Makes erasure and audit tractable later |
| Pseudonymise or aggregate before training where signal allows | Reduces the obligations that attach at all |
| Name a Grievance Officer and publish the address | Required, and cheap to do |
| Know your sub-processors and their locations | Your accountability extends to them |
| Write down your retention period and actually enforce it | Indefinite retention is the most common unforced error |
Our own sub-processors and where each one sits are listed in Privacy Policy §4, and instances run on our own hardware in Mumbai. If you need a data processing agreement for your own compliance file, email privacy@vijaycloud.com.