A DPDP Act engineering checklist for software teams

Most privacy programmes fail at the same point: the policy is written, published and then found to be unimplementable, because the systems cannot do what it promises. A deletion request arrives and nobody can enumerate where the data lives. Consent is withdrawn and three downstream systems never hear about it. The gap is engineering, and it is best closed before the policy is published rather than afterwards.

1. Know what you hold and where it is

Every other obligation depends on this one. A data inventory is not a one-off document; it is a maintained record that has to survive the next six months of schema changes.

• Catalogue personal data by system, table and field — including analytics stores, search indexes, caches, queues, logs and backups
• Record purpose, lawful basis, retention period and downstream recipients per category
• Include third parties: payment providers, email and SMS services, support tools, AI APIs and analytics vendors
• Tag fields in code or schema so the inventory can be regenerated rather than hand-maintained
• Review it whenever the data model changes, as part of the change itself

2. Collect less, and stop collecting what you never use

Minimisation is the cheapest control available: data never collected needs no protection, no retention rule and no deletion path. Audit your forms against actual use. Fields collected because they might be useful one day are pure liability. Where a full identifier is not needed, store a derived value — an age band rather than a birth date, a pincode rather than a full address.

3. Make consent a record, not a checkbox

The Act requires notice and consent that is specific, informed and withdrawable, and withdrawal must be as easy as giving it. Engineering-wise, that means consent must be a first-class record rather than a boolean flag on a user row.

• Store consent per purpose, with timestamp, the exact notice version shown, and the capture mechanism
• Keep an append-only history, so a past state can be reconstructed during an inquiry
• Make withdrawal available through a self-service path, and propagate it to every downstream system
• Check consent at the point of processing rather than only at the point of collection
• Handle children's data separately — the Act imposes specific obligations including verifiable parental consent

-- Append-only: withdrawal is a new row, never an update.
CREATE TABLE consent_events (
  id            uuid PRIMARY KEY,
  principal_id  uuid NOT NULL,
  purpose       text NOT NULL,        -- 'service_delivery', 'marketing_email'
  granted       boolean NOT NULL,
  notice_version text NOT NULL,
  captured_at   timestamptz NOT NULL DEFAULT now(),
  mechanism     text NOT NULL         -- 'signup_form', 'preference_centre'
);

-- Current state is derived, so history is never destroyed by a change.
CREATE VIEW consent_current AS
SELECT DISTINCT ON (principal_id, purpose) principal_id, purpose, granted, captured_at
FROM consent_events
ORDER BY principal_id, purpose, captured_at DESC;

4. Be able to answer access, correction and erasure requests

Data principals can request access to their data, correction of it, and erasure. If answering takes an engineer a week of manual queries, the process will not survive volume — and the delay itself becomes the compliance problem.

1. 01Build an export that assembles everything you hold about one person, across every system in the inventory
2. 02Build deletion that reaches the same systems, including caches, search indexes, analytics stores and third-party processors
3. 03Decide in advance what must survive erasure for a legal or statutory reason, and document that reasoning
4. 04Use anonymisation where records must persist — an invoice can keep its line items without keeping the identity
5. 05Define how backups are handled: deletion in live systems now, with backup expiry documented and enforced
6. 06Log every request and its fulfilment, because demonstrating compliance is itself an obligation

5. Enforce retention automatically

Retention periods written in a policy and unenforced in code are simply data you have not deleted. Implement scheduled deletion per data category, apply it to derived stores as well as primary ones, monitor that the jobs actually run, and record what was deleted and when. Table-level partitioning by period makes bulk expiry cheap enough that it will not be deferred.

6. Restrict and review access

• Least privilege by default, with elevated access requested, time-boxed and logged
• No standing production data access for engineers; use break-glass with recorded justification
• Masked or synthetic data in non-production environments — copying production data into staging is a recurring source of exposure
• Access review on a fixed cadence, with a joiner-mover-leaver process that actually revokes
• Audit logs that record who read which personal data, not only who changed it

7. Reasonable security safeguards, demonstrably

The Act requires reasonable security safeguards and does not enumerate them, which means you need a position you can defend. In practice that is the ordinary baseline, evidenced: encryption in transit and at rest, secrets in a managed store with rotation, dependency and container scanning on a cadence, multi-factor authentication for privileged access, tested backups and a documented patching process. The word doing the work is 'demonstrably' — a control you cannot evidence is one you cannot rely on during an inquiry.

8. Be able to detect and report a breach

Breach notification obligations under the Act are demanding, and the constraint is detection rather than paperwork. You cannot report within any timeframe what you have not noticed.

• Alerting on anomalous access patterns and bulk data reads
• Log coverage sufficient to determine scope: which records, which principals, over what period
• An incident runbook with named roles, and a rehearsed tabletop exercise
• Pre-drafted notification templates for the Board and for affected principals
• Contractual notification obligations flowing down to your processors, and tested

9. Third parties are your responsibility

Engaging a processor does not transfer accountability. Maintain a current list of every processor touching personal data, hold contracts that set purpose limits and breach-notification duties, and know where each one processes data physically. This now includes AI providers: if personal data is sent to a model API, that provider is a processor, and their retention and training position needs to be documented — and defensible.

Where to start

If none of this exists yet, the order that produces the fastest reduction in risk is: build the inventory, then delete what you should never have kept, then implement retention enforcement, then close the access gaps, then build the rights-request tooling. The first two weeks of that sequence usually remove more exposure than the following six months of policy drafting.