What the DPDP Act actually changes in your engineering backlog

India's Digital Personal Data Protection Act is usually introduced to a company by its lawyers, which is appropriate — it is a law, and legal interpretation belongs with counsel. But once the interpretation is settled, most of what remains is engineering work, and it lands in the backlog of a team that was not part of the original conversation.

This article is about that second half. It is not legal advice, and the specifics of what applies to your organisation should come from your own counsel. What follows is the shape the work usually takes once the obligations are understood.

Knowing where personal data lives

Every other obligation depends on this one, and it is almost always harder than expected. Personal data is rarely confined to the customer table. It accumulates in application logs, analytics events, support ticket attachments, exported spreadsheets, backup archives, the staging database somebody refreshed from production, and third-party services integrated years ago.

The deliverable is an inventory: what personal data you hold, in which systems, for what purpose, who can reach it, and how long it stays. Produce it once properly and most of the remaining work becomes tractable. Skip it and every subsequent requirement turns into a fresh investigation.

Purpose, and the end of collecting by default

The principle that data is collected for a stated purpose, with notice, cuts against a habit most systems have: capture everything now in case it is useful later. In practice this becomes a review of collection points — forms, SDKs, event tracking, integrations — asking for each field whether there is a purpose you would be willing to state to the person it belongs to.

Where consent is the basis for processing, it also becomes a system rather than a checkbox. Consent has to be recorded with its version and timestamp, honoured by downstream systems, and withdrawable — which means the withdrawal has to actually propagate to the analytics pipeline and the marketing platform, not merely set a flag in the primary database.

Retention, which nobody has

Most systems are built to keep things. Deletion is rarely implemented, partly because it is genuinely difficult once data has been copied into warehouses, search indexes, caches and backups.

Expect this to be the largest piece of work. It involves agreeing a retention period for each data category with the business, implementing enforcement, and deciding how backups are handled — since selectively deleting a record from an immutable archive is not straightforward and usually resolves into a documented policy about backup expiry instead.

Requests from the people whose data it is

Rights of access, correction and erasure mean a process that can be executed reliably within a time limit. On the first request most organisations discover their answer is a manual database query performed by whichever engineer is available.

That works until volume rises. The engineering task is to make retrieval and deletion a supported operation across every system in the inventory — including the ones outside the primary database — with an audit trail showing what was done and when.

Access control and security safeguards

The requirement to protect personal data with reasonable safeguards turns into familiar security work: role-based access, multi-factor authentication, encryption in transit and at rest, removal of standing access to production data, and logging of who accessed what.

The most common gap we see is not the production database, which is usually reasonably controlled. It is the copies: analytics environments, staging systems refreshed from live data, exported reports in shared drives, and personal data pasted into third-party tools. Controlling the original while ignoring its copies is a common and expensive mistake.

Being able to detect a breach

Breach notification obligations assume something that is frequently untrue: that you would know. Without centralised logging, alerting and retention of audit trails, an organisation can be unable to say whether data was accessed, by whom, or how much — which makes a required notification impossible to complete accurately.

The engineering work is logging that is centralised, tamper-resistant and retained long enough to investigate with, plus alerting on the access patterns that would indicate a problem. The organisational half is a response plan that has been rehearsed rather than filed.

Most of data protection compliance is knowing where your data is. Almost everything else follows from that.

A sensible sequence

1. 01Build the data inventory. Nothing else is reliable without it.
2. 02Close the obvious access gaps, particularly non-production copies of live data.
3. 03Get centralised logging and alerting in place so an incident could be investigated.
4. 04Agree retention periods with the business and implement enforcement.
5. 05Make access, correction and deletion requests a supported, audited operation.
6. 06Review collection points and consent handling, including downstream propagation.

Taken together this is a substantial programme, and it is worth setting expectations accordingly rather than treating it as a sprint. The compensation is that almost all of it is work you would benefit from regardless of the law. Knowing where your data is, who can reach it, and how long you keep it makes a business easier to run, easier to audit, and considerably easier to sell to.