Data residency under the DPDP Act, for engineering teams

The Digital Personal Data Protection Act 2023 is often treated as a legal question with an engineering appendix. For the teams building systems that handle personal data, the reverse is more accurate: most of the compliance burden lands in the data model.

Consent, purpose limitation and retention are not policies you attach to a database. They are constraints on what your schema and queries are permitted to do.

Consent is a schema property

The common failure is storing a boolean called has_consented. It cannot answer the questions that matter:

• consent for which purpose
• granted when, and withdrawn when
• evidence of the notice the person actually saw
• whether consent was explicit, or bundled with other terms

The minimum workable shape is a consent record with purpose, timestamp, notice version, capture method, and a withdrawal timestamp. Consent for one purpose says nothing about another — marketing consent does not imply you may process the data for fraud scoring.

If your schema cannot distinguish purposes, you cannot honour a withdrawal for one purpose without deleting data you are entitled to retain.

Retention has to be enforceable, not aspirational

Most policies state a retention period. Few systems enforce it.

Enforcement means three things, all in the data layer:

• a defined retention period per data category
• an automated process that deletes or irreversibly anonymises on schedule
• a documented legal-hold mechanism that suspends deletion for a defined scope

Without the third, you cannot safely run the second — because an unresolved legal hold, discovered afterwards, means the deletion was a spoliation event.

Retention is also where the DPDP position and commercial reality diverge. Financial records in India have eight-year statutory retention requirements. Personal data in the same table has a much shorter reasonable period. These must be separated in the schema, or the longer period silently wins and over-collection becomes inevitable.

Purpose limitation changes query design

"Only process for the stated purpose" is a constraint engineers hit daily.

It means the customer 360 view is not free — each field needs a purpose, and joining data from two purposes may require the visitor to have consented to both. It means a support agent who should see delivery addresses cannot automatically see medical history, even in the same record.

This is uncomfortable, and it is the correct behaviour. Design the access model with purpose tags early. Retrofitting it into an existing estate is one of the more expensive pieces of work in a privacy programme.

Data residency is narrower than it is often assumed

The Act does not impose blanket localisation. It requires that transfers outside India be notified to the Data Principal.

That still produces real engineering constraints:

• knowing precisely where every replica of a given field lives
• knowing which vendors process it, and on what terms
• contractual and technical controls over those processors

For a lending or insurance business, a customer record replicated across three regions by a managed database is a transfer question. So is a support tool with access to production data, and so is a log pipeline.

Inventory the locations before you answer a regulator. The answer is rarely "one place", and teams who discover otherwise during an examination have a difficult conversation.

The rights that generate engineering work

Access, correction, erasure and grievance redress are all implementation problems.

• Access means assembling a portable export of everything held, from every system including processors.
• Erasure means deleting or anonymising across every store, which fails silently if one system is missed.
• Correction means propagating an update, which requires knowing the write order across duplicated records.

Each needs a rehearsed process, not a documented intention. Test them on production-shaped data at least annually, and time how long they take.

A workable first pass

You cannot retrofit compliance onto an estate in a quarter. You can:

1. Choose the highest-risk data category and map every system holding it, including vendors.
2. Separate consent by purpose in the schema for that category.
3. Implement retention with a legal-hold suspension path.
4. Build the access export for that category end to end.
5. Document what remains, and put it on a plan.

That is a defensible starting position, and it is far better than a complete policy document and no enforcement.