The DPDP Act as an engineering problem, not a legal one

Data protection legislation usually enters an organisation as a policy document and a privacy notice, which is the part that is straightforward. The part that is not is that several of the obligations are only satisfiable if the software was built to satisfy them, and cannot be retrofitted with a policy.

The useful question for an engineering team is narrow: what does the system have to be able to do that it currently cannot? There are about five answers, and each is a design decision rather than a document.

Consent is a record, not a checkbox

A boolean saying the user agreed is not evidence of anything. What has to be reconstructable later is what they agreed to, when, which version of the notice was shown, through which interface, and whether they have since changed it.

That makes consent an append-only log of events rather than a field on the user record, and it makes the notice itself a versioned artefact you retain — because demonstrating consent means showing the text that was actually displayed, not the text currently on the site. Systems that store only the current state can say that a user consented. They cannot say to what.

Erasure cannot be retrofitted

The obligation to delete personal data on request is the one that exposes architecture. To honour it you must know every place a person's data exists, which in a system of any age is more places than anyone expects.

• The primary database, including soft-deleted rows that were never actually removed
• Analytics and warehouse copies, where data was denormalised and the link back to the person is often lost
• Application and access logs, which routinely contain email addresses, phone numbers and identifiers in request payloads
• Backups, which cannot be selectively edited and need a documented position rather than a deletion
• Third-party processors — email providers, support desks, payment processors — each holding their own copy
• Exports: the CSV somebody generated for a report and left in shared storage

You cannot delete what you cannot find. A data map is not documentation — it is the prerequisite for being able to honour a deletion request at all.

Logs are the part everyone forgets

Application logs are the most common unmanaged store of personal data, because nobody decided to put it there. A request payload gets logged for debugging and now the log contains a name, an address and a phone number, retained for however long the log retention policy says — frequently longer than the data would be kept in the database it came from.

The fix is redaction at the point of logging, applied structurally rather than by remembering. In practice that means a logging wrapper that scrubs known-sensitive field names, and a test that fails if a payload containing a personal field reaches the logger unredacted. Cleaning logs afterwards is possible and much harder than not writing them.

Purpose limitation means your model needs purpose

Data collected for one reason may not be freely used for another. Most schemas have no representation of why a field exists, so the constraint cannot be checked or enforced — it lives in the heads of whoever built the feature.

A workable middle path, short of a full data-governance implementation, is to classify fields at the schema level with the purpose they were collected for, and to make new uses of personal data require an explicit decision rather than a join. This is cheap when done during design and expensive later, which is the recurring theme.

Retention is a job, not a policy

Stating that records are kept for a defined period and then deleted is a sentence in a privacy notice. Making it true requires a scheduled process that identifies expired records and removes them, across every store, with a log of what it removed so the claim is demonstrable.

Almost nobody builds this at the start, and it is worth being honest that it is not a large piece of work — it is simply one that never becomes urgent until it is. It is also the single most convincing thing to be able to show, because it is the obligation most organisations are demonstrably not meeting.

Breach notification is an observability requirement

Reporting an incident within a short window requires knowing that it happened and which records were affected. That is not a legal capability, it is a monitoring one, and it depends on access logging that records who read what — the same requirement that arrives from the clinical side in healthcare systems.

Without it, the honest answer during an incident is that the extent is unknown, which usually forces the most conservative notification. The cost of instrumentation is paid once; the cost of not having it is paid at the worst possible moment.

Your processors are your exposure

Every third party holding personal data on your behalf is part of your obligation, whether or not anyone maintains a list. Building that list is the unglamorous first step and usually finds services nobody remembered — an analytics tool from a campaign two years ago, a support widget, a form provider.

A maintained subprocessor list is also the fastest thing to produce when a customer's own compliance team asks, which they increasingly do. We publish ours for exactly that reason.

One note on scope: this describes how the requirement shapes system design. It is not legal advice, and the obligations, timelines and exemptions that apply to your organisation are a question for your counsel — the rules are being operationalised in stages, which argues for building the capabilities rather than coding to a specific deadline.