DPDP Compliance in Practice: Consent, Erasure, and Breach Workflows

Our earlier piece on the DPDP Act read the law as a residency problem: where personal data physically sits, who holds the keys, and whether the boundary is enforced by your platform or promised in a contract. That is the static half. This article is the operational half — the machinery the Act obliges a Data Fiduciary to run continuously, not just architect once. The Digital Personal Data Protection Act, 2023, became operable through the DPDP Rules, 2025, notified on 13 November 2025, with the substantive obligations enforceable on 13 May 2027 and the consent-manager regime a year earlier. Between now and then, three systems have to exist and work: consent capture, data-principal rights fulfilment, and breach notification. None of them is a policy PDF; each is a service with a schema, a queue, and a deadline.

As always, this is the engineering read and not a legal register — your counsel will produce a sharper statement of the obligations than anything here. What follows is the translation layer: how the duties in Sections 5 through 14 and the corresponding Rules become tables, pipelines, and state machines, and why owning that machinery outright is the difference between a control you can demonstrate on demand and one you hope a vendor implemented correctly. The connective tissue across all three systems is a single artifact — a map of where every Data Principal's data lives — and the teams that build it first find that consent, rights, and breach response all fall out of it.

The Three Operational Surfaces DPDP Creates

Strip the Act to what a platform team has to build and there are three surfaces. The first is consent: Section 6 requires that consent be free, specific, informed, unconditional, and unambiguous, given by a clear affirmative action for an itemized set of purposes, and — the clause that reshapes systems — as easy to withdraw as it was to give. The second is data-principal rights: Sections 11 to 14 grant every individual the right to access a summary of their data and the processing done on it, to correct and complete it, to have it erased, and to grievance redressal within a bounded window. The third is breach notification: Section 8(6) and the Rules oblige you, on becoming aware of a personal-data breach, to inform each affected Data Principal and the Board on a defined timeline.

These are not independent. All three depend on a capability most systems never built because nothing forced them to: answering, quickly and completely, "where is all of this one person's data?" A consent withdrawal triggers erasure, which needs that answer. An access request needs it. A breach needs it, scoped to the compromised store. Build the map that answers it — an inventory keyed by Data Principal across every datastore, index, cache, log, and downstream processor — and the three surfaces become three consumers of one primitive. Skip it, and each becomes a frantic, manual, and unprovable scramble under a clock.

Consent Is an Event Log, Not a Boolean

The most common way to get consent wrong in code is to store it as a column — a boolean, or a timestamp, that gets overwritten. That model cannot answer the questions the Act actually asks: what exactly did this person consent to, under which version of the notice, in which language, at what moment, and has any of that since been withdrawn? Consent under DPDP is per-purpose and reversible, so it is naturally an append-only event log. Each grant and each withdrawal is a new immutable row referencing the purpose and the exact notice served under Section 5. The current consent state is a projection over that log, never a mutable field — which means the history an auditor or the Board asks for is the storage model itself, not a reconstruction after the fact.

-- Consent as an append-only event ledger. Grant and withdraw are inserts,
-- never updates: the current state is a projection, the history is the store.
CREATE TABLE consent_event (
  event_id     uuid        PRIMARY KEY DEFAULT gen_random_uuid(),
  principal_id uuid        NOT NULL,          -- pseudonymous Data Principal key
  purpose      text        NOT NULL,          -- itemized purpose, matches the notice
  action       text        NOT NULL CHECK (action IN ('grant','withdraw')),
  notice_id    text        NOT NULL,          -- exact Section 5 notice version served
  lang         text        NOT NULL,          -- language the notice was served in
  method       text        NOT NULL,          -- 'web-form','consent-manager','api'
  occurred_at  timestamptz NOT NULL DEFAULT now(),
  artifact_sha text        NOT NULL           -- hash of the rendered notice + choice
);
-- No UPDATE / DELETE grant on this table; append-only enforced by role + trigger.

-- Current consent for a purpose = the latest event wins.
CREATE VIEW consent_current AS
SELECT DISTINCT ON (principal_id, purpose)
       principal_id, purpose, action AS state, occurred_at, notice_id
FROM   consent_event
ORDER  BY principal_id, purpose, occurred_at DESC;

The Act also anticipates a Consent Manager — a Board-registered, interoperable platform through which a Data Principal can give, review, and withdraw consent across multiple fiduciaries. Integrating with one is an obligation you will likely carry, but it is not a reason to surrender ownership of your consent state. Treat the Consent Manager as an interface, not the system of record: your ledger remains authoritative, and you reconcile against the manager's events. That keeps you portable if the registered manager you chose changes terms, loses its registration, or you simply outgrow it — the optionality pillar applied to the most sensitive record you hold, the one that authorizes every downstream processing decision.

Purpose Propagates, or Purpose Limitation Is Fiction

Consent is specific to a purpose, and purpose limitation is only real if the purpose travels with the data. A record collected for order fulfilment that quietly feeds a marketing model has escaped the consent that authorized it — and no consent ledger, however clean, catches that on its own. The enforcement point is the processing path: every record carries the purpose tags it was collected under, and each processing job asserts, at the point of use, that active consent exists for the purpose it is about to serve. When consent for a purpose is withdrawn, the projection flips, and jobs for that purpose stop reading the record — before, under Section 8(7), the erasure obligation even comes due.

On Kubernetes this is where the consent layer meets policy-as-code: the same discipline that pins workloads to a jurisdiction can require that any job touching personal data declare the purpose it processes for and carry the label that lets an admission policy — and an auditor — see it. Purpose becomes a first-class attribute of a workload, not a comment in a runbook. The failure mode this closes is the quiet one that regulators find most damning: data lawfully collected, then lawfully stored, but unlawfully used for a purpose no one consented to, with no technical control that could have stopped it.

Rights Fulfilment Is a Discovery Problem

The access and correction rights (Sections 11 and 12) look administrative and are, underneath, a distributed-query problem. To return a Data Principal a summary of their personal data and the processing performed on it, you have to enumerate every place that data lives — the primary database, denormalized read models, the search index, object storage holding uploads and generated exports, analytics warehouses, message queues in flight, and the audit logs of what was done to it. Most organizations discover, the first time a request lands, that no single system knows the full list. That is why the data map is the load-bearing artifact: a maintained registry, per store, of which fields hold personal data and how they key back to a Data Principal.

Click to zoom

Identity verification sits in front of the whole pipeline and is easy to underweight. Fulfilling an access or erasure request for someone who is not the Data Principal is itself a breach — you have just handed one person's data to another, or destroyed it on a stranger's say-so. The verification has to be proportional to the sensitivity of the data and auditable in its own right, and it belongs to you rather than a form on a vendor portal you cannot inspect. The stateful data layer these requests run against is exactly the one you most want in-house, because the rights pipeline reaches into every table it holds.

Erasure Is a Fan-Out, Not a DELETE

The right to erasure (Section 12) and the erasure-on-withdrawal duty (Section 8(7)) are where most implementations quietly fail, because a single DELETE is nowhere near enough. One person's data is scattered across systems with fundamentally different mutability. Primary rows delete cleanly. Object-store uploads need their versions and delete-markers cleared. Search indices need document deletes, not just tombstones that still return in results. Caches and queues need eviction. And then there are the stores you deliberately made immutable — WORM audit logs and backups — which you cannot mutate in place without destroying the very integrity that made them evidence. Erasure is therefore an orchestration across heterogeneous stores, each with its own method, and the orchestrator's output is not a boolean but a certificate.

Click to zoom

Backups are the case that separates a real erasure design from a naive one. You cannot rewrite last month's snapshot, and restoring it must not resurrect an erased person. The durable technique is crypto-shredding: encrypt each Data Principal's data (or each data category) under a distinct data-encryption key held in your key-custody layer, and make erasure the destruction of that key. Every ciphertext copy — live, replicated, or frozen in a backup — becomes permanently unreadable at once, without touching the immutable store. Pair it with a restore-time re-erasure step, so that even a full recovery re-applies the tombstone set and never rehydrates data whose key is already gone. The method per store is what you record, because "we deleted it" is a claim and "we destroyed the only key that could read it, here is the log" is proof.

# Erasure orchestrator: fan out per store, then emit a signed certificate.
# The return value is evidence, not a boolean — one entry per store, method named.
def erase_principal(pid: str) -> dict:
    actions = []
    for store in data_map.stores_holding(pid):        # the data map, again
        if store.retention_hold(pid):                 # CERT-In / tax legal hold
            actions.append(defer(store, pid))         # withhold, re-queue at expiry
        elif store.mutable:
            actions.append(store.hard_delete(pid))    # rows, objects, index docs, cache
        else:                                         # backups, WORM audit logs
            actions.append(kms.destroy_dek(pid, store))  # crypto-shred: kill the key
    for proc in processors.for_principal(pid):        # accountable for sub-processors
        actions.append(proc.request_erasure(pid))     # erasure API -> signed ack

    cert = sign_certificate(pid=pid, actions=actions, at=utcnow())
    audit_log.append(cert)                            # immutable, in-India
    return cert                                       # what you show the Board

The Breach Workflow Is a State Machine on a Clock

A personal-data breach turns the same discovery machinery into an incident workflow with statutory deadlines. Section 8(6) and the Rules require that, on becoming aware of a breach, you notify each affected Data Principal without delay — in plain language, describing the breach, its likely consequences, the mitigation underway, and the safety measures they can take — and notify the Data Protection Board in two stages: an intimation without delay, followed by a detailed report within seventy-two hours (extendable only if the Board allows) covering the facts, the circumstances and cause, the mitigation, and the notifications made to affected principals. This is a state machine, and the states have clocks attached.

The step that decides whether the seventy-two hours is survivable is scoping: which Data Principals, and which categories of their data, were in the compromised store. That is the data map once more — the same registry that answers an access request answers "whose data was here" when a namespace is breached. Teams that built rights fulfilment first find breach scoping is already solved; teams that treated the map as paperwork discover, mid-incident, that they cannot enumerate the affected set inside the window. India's breach clock also runs alongside CERT-In's tighter six-hour cyber-incident duty, so a single event can start two timers at once — engineer for the tightest and the looser one is a superset.

# Breach workflow as an explicit, time-stamped state machine. Every transition
# is written to the in-India audit log, so the timeline itself is evidence.
states:
  - detected:                                  # from Falco/SIEM or a report
      on_enter: [open_incident, start_clocks]  # DPDP + CERT-In timers begin
  - scoped:                                    # WHO and WHAT — the data map
      action: enumerate_affected_principals    # reuse the rights discovery path
      records: [principal_set, data_categories]
  - board_intimated:                           # DPDP: "without delay"
      deadline: asap
      action: notify_board_initial
  - principals_notified:                        # DPDP: affected individuals, plain language
      deadline: asap
      action: notify_affected_principals
  - board_report_filed:                        # DPDP: detailed report
      deadline: PT72H                          # 72h from awareness
      action: file_detailed_report
      includes: [facts, cause, mitigation, notifications_made]
  - closed:
      action: post_incident_review
# CERT-In's 6h reportable-incident duty runs in parallel on the same detection.

The Exit Ramp: Own the Machinery, Not a Privacy SaaS

There is a thriving market in privacy-management SaaS that will offer to run your consent capture, rights intake, and breach register. The optionality question is sharp here: these systems become the authoritative record of your most consequential decisions — what people consented to, what you erased, when you notified a regulator — and that record is exactly what you must never lose custody of. A vendor that holds your consent ledger and rights-request history holds the evidence of your compliance, and its export format, retention, and availability during an incident are its choices, not yours. When the relationship ends, the audit trail should not end with it.

The self-hosted posture is not a rejection of every tool; it is a rule about the system of record. The consent ledger, the data map, the erasure orchestrator, and the breach audit log are platform services you own — typed, versioned, and portable — while a Board-registered Consent Manager or a workflow tool plugs in as an interface. The capability transfers, too: the same rights-and-erasure engine answers a GDPR Article 17 request or the EU frameworks' obligations with a different policy binding, because you built the machine rather than buying the checklist. That is what makes a second jurisdiction a configuration change instead of a second vendor.

The Long Game: Build the Rights Engine Before You Are Asked

The tempting read of a 13 May 2027 deadline is that there is time to wait. There is not — not because the date is close, but because the machinery is not the kind you can stand up in a sprint once the first request or breach arrives. Consent history you did not capture from day one cannot be reconstructed. A data map assembled under the pressure of a live erasure request will be incomplete in exactly the stores that matter. A breach workflow drafted after the breach is a post-mortem, not a control. The invariant beneath the DPDP Rules — as beneath the GDPR before them and whatever amends them after — is that a Data Principal's data must be findable, correctable, erasable, and accountable across every system that touches it. Build that capability as owned infrastructure and each regulatory turn is a policy binding on a machine you already run; treat it as a document to satisfy later and every request becomes an incident. The teams that will absorb 13 May 2027 without drama are the ones for whom consent, rights, and breach response are already three consumers of one well-kept map.