DPDP for SaaS builders: where the Act meets the schema

The Digital Personal Data Protection Act 2023 is short for an Indian statute and long for a piece of code. Most writeups about it are for buyers (here is what the Act says, here is the certification you need). This note is for the engineer at the schema design step, when the obligations stop being legal text and start being column constraints.

Consent as a ledger, not a flag

A boolean consent_given column is wrong. The Act asks for evidence of consent for a specific purpose, with the notice that was shown at the time, and a record of any withdrawal.

A consent ledger is the right shape: a separate table where each row captures the notice version, the purpose, the timestamp, the channel (web, mobile, paper), and a separate row for withdrawal. The current state is a query against the ledger; it is not a column on the user table.

CREATE TABLE consent_events (
  id           UUID PRIMARY KEY,
  data_principal_id UUID NOT NULL,
  notice_version   TEXT NOT NULL,
  purpose          TEXT NOT NULL,
  action           TEXT NOT NULL CHECK (action IN ('grant','withdraw')),
  channel          TEXT NOT NULL,
  occurred_at      TIMESTAMPTZ NOT NULL DEFAULT now()
);

This pattern survives audits and it survives the day a user asks "When did I consent to that?"

Retention as a property of the row

DPDP requires purpose limitation: keep data only as long as the purpose requires. The lazy implementation is a deleted_at column that nobody enforces. The correct implementation is a retention policy attached to the row, plus a nightly job that enforces it.

ALTER TABLE inquiries ADD COLUMN
  retention_until TIMESTAMPTZ NOT NULL
  DEFAULT (now() + INTERVAL '24 months');

The nightly job deletes or anonymises rows past their retention. A signed deletion log captures what was removed, when, and why. Soft delete flags without enforcement are not retention; they are a liability that pretends to be a policy.

Principal rights as workflows, not endpoints

The five data principal rights (access, correction, erasure, grievance redressal, nomination) are presented as if they were API endpoints. They are not. They are workflows with a first response SLA.

• Access: you join across many tables (user, inquiries, consent, audit log) and return a coherent export. This is a workflow, not a query.
• Erasure: you propagate the deletion to every copy: production, backups, replicas, third party processors. This is a workflow, not a DELETE.
• Correction: you record the corrected value, the previous value, and the timestamp. The audit log needs to know it was a principal rights correction, not an admin edit.
• Grievance: you log it, you respond inside the regulatory window (30 days), and you escalate to the Data Protection Officer if unresolved.

Build these as queued, audited workflows from day one. Retrofitting them is much more expensive than building them in.

Breach as an upstream signal

The Act mandates breach notification, but the right metric is not "how fast do we detect" but "how fast do we detect upstream." Anomaly detection on immutable logs (failed authentications spike, sudden tenant cross reads, unexpected bulk exports) is the leading indicator. Watching production dashboards is the lagging one.

The runbook should be ready before the breach: pretemplated notifications, named recipients, decision points. We aim for a confirmed to notified window inside thirty minutes.

The broader takeaway

DPDP compliance is a forcing function that improves the architecture. The consent ledger is a useful structure regardless of regulation. The retention policy reduces the data you have to defend. The audit log helps debugging. The breach runbook is the kind of muscle every team should have.

The mistake is treating compliance as a layer to bolt on at certification time. The right framing is that the Act is a checklist of design decisions you would want to make anyway, with a deadline attached.