DPDP-Compliant Engineering for Minors: The Full Spec

Q: What does DPDP Rule 10 actually require engineers to build?

Four subsystems, and most teams ship only a fraction of the first. Rule 10 of the DPDP Rules, notified in November 2025, requires the Data Fiduciary to adopt appropriate technical and organisational measures ensuring verifiable parental consent before processing a child’s personal data, including due diligence that the individual identifying as a parent is an identifiable adult, with DigiLocker-backed identity tokens among the named mechanisms. Translating that into engineering: first, a consent state machine with an explicit lifecycle — pending verification, granted, revoked, expired, and graduated-to-adult — persisted with timestamps, not a boolean column, because you must be able to demonstrate when consent was obtained, under which policy version, and by which verification method. Second, age assurance that produces a durable classification rather than a self-declared birthdate, propagated to downstream services as a synthetic age band in a signed token so no service handles a raw date of birth. Third, a revocation cascade: a parent-triggered deletion is a distributed job across your primary database, analytics warehouse, caches, search indexes, and object storage, with per-system completion tracking and resumability, because it will partially fail. Fourth, an audit trail that constitutes evidence — append-only, cryptographically signed, and protected at the privilege layer rather than only by a trigger. What Rule 10 does not require, and what separates compliant from safe, is any constraint on the recommendation engine: you can satisfy every one of these obligations and still serve a fourteen-year-old an engagement-optimised feed. Teams building for the long run gate the curation layer too.

Q: How do I make a consent audit log genuinely immutable in PostgreSQL?

Three layers, because the trigger everyone writes is necessary and nowhere near sufficient. Layer one, the trigger — a BEFORE UPDATE OR DELETE ... FOR EACH ROW trigger that raises an exception blocks the obvious modifications. The critical gap almost every implementation has: row-level triggers do not fire on TRUNCATE, so the entire audit table remains one TRUNCATE statement away from empty. Add a second trigger, BEFORE TRUNCATE ... FOR EACH STATEMENT, calling the same guard function. Layer two, privileges — a table owner or superuser can simply run ALTER TABLE ... DISABLE TRIGGER and then do whatever they like, so triggers cannot be the control. Revoke the capability instead: REVOKE UPDATE, DELETE, TRUNCATE ON consent_audit_logs FROM app_role, granting only INSERT and SELECT, and ensure the application role is not the table owner. This makes tampering require a privilege escalation rather than an ordinary statement. Layer three, tamper-evidence — the first two layers prevent casual modification but do not prove that modification did not occur. For evidence you need either hash-chaining, where each row stores a digest computed over its own content plus the previous row’s digest so any alteration breaks the chain detectably, or shipping the log to append-only storage with an object-lock or WORM retention policy outside the database entirely, or both. Pair this with per-event cryptographic signatures using a key held in an HSM or KMS, so an attacker with database write access still cannot forge a valid entry. The distinction that matters at audit: preventing edits is a guardrail; being able to prove no edit occurred is evidence, and only the third layer provides it.

Q: What should a consent event signature actually cover?

The entire event, canonicalised, minus the signature field itself — and getting this wrong is the most consequential mistake in a consent architecture, because it silently defeats the purpose of having signatures at all. The common shortcut is to compute HMAC over a few scalar fields: event ID, timestamp, user ID hash, and event type. That produces a signature that validates while leaving everything substantive unsigned — the consent details (including which verification method was used and against which policy version), the revocation metadata (including who requested it and which systems were targeted), and the event body. Anyone with write access to the log, or any buggy service in the pipeline, can change verificationMethod from a strong mechanism to a weak one, flip requestedBy from PARENT to SYSTEM_EXPIRED, or shorten the list of systems a purge claimed to have covered — and the signature still verifies, so the tampering is invisible and the record is worthless as non-repudiation evidence. The fix is to sign a canonical serialisation of the complete event object with the payloadSignature field removed. Canonicalisation matters as much as coverage: JSON object key order and number formatting are not guaranteed stable across languages and libraries, so a signature produced by one service may fail verification in another for reasons unrelated to tampering. Use RFC 8785 (JSON Canonicalization Scheme) so signer and verifier agree byte-for-byte. Hold the HMAC key in an HSM or KMS rather than in application configuration, so an application compromise does not yield signing capability. And update the schema documentation to describe the actual coverage — a description that understates what is signed will be copied into the next implementation.

Q: Why do TypeScript and PostgreSQL enums drift, and why does it matter?

They drift because they are two hand-maintained copies of one state machine, authored at different times by different people, and nothing in the toolchain diffs them — and it matters because every write using a divergent value fails at runtime, often in the consent path where failures are least acceptable. The concrete failure looks like this: a Postgres type defines the statuses as PENDING_VPC, GRANTED, REVOKED, EXPIRED, and GRADUATED_ADULT, while the TypeScript enum written weeks later emits UNVERIFIED, PENDING_VPC, CONSENT_GRANTED, CONSENT_REVOKED, and GRADUATED_ADULT. Three of those values do not exist in the database type, so any insert or update carrying them raises an invalid input value error, and one database value (EXPIRED) has no application representation at all, so expiry cannot be recorded. The bug typically survives unit tests, which mock the database, and surfaces in integration or production. Three mitigations, in increasing order of robustness. Minimum: keep the two definitions adjacent in the codebase with a comment stating they must mirror exactly, and add an integration test that iterates every application enum value and attempts a write, which catches drift immediately. Better: generate the TypeScript type from the database schema as part of the build, using a schema-introspection codegen tool, so the application type cannot diverge because it is not hand-written. Best for critical state machines: treat the enum as a versioned contract with its own migration process, so adding a state requires a deliberate change in both layers reviewed together. Whichever you choose, the underlying principle is that a state machine expressed twice will diverge unless something mechanical prevents it.

Q: What does a proper consent revocation cascade look like?

A tracked, resumable distributed job with per-system status — not a database update — because the data you need to erase is never in one place and the deletion will partially fail. When a parent revokes consent, the obligation is to erase the child’s personal data, and in a typical production system that data has propagated to a primary transactional database, an analytics warehouse, one or more caches, a search index, object storage for uploaded media, log aggregation, backups, and possibly third-party processors. Deleting the primary row and returning success is not erasure; it is a compliance failure that will surface at the first audit that follows the data. The working design: a revocation job record enumerating target systems explicitly as a list, tracking which have completed, capturing per-system errors, with an overall status covering requested, cascade-in-progress, completed, and partial-failure. Each target system gets an idempotent purge worker so retries are safe. The job is resumable, because a worker will crash halfway through and restarting from the beginning must not be destructive or duplicative. Failures are surfaced and alerted rather than swallowed — a partial-failure state that nobody looks at is worse than no state at all. Two practical complications worth designing for up front. Immutable and columnar stores (append-only warehouses, backups with retention locks) often cannot support row deletion within a reasonable window, and the accepted alternative is crypto-shredding: encrypt each data subject’s data under a per-subject key and destroy the key, rendering the ciphertext unrecoverable. And the audit trail itself must not be purged — it records that erasure happened and is the evidence of compliance, so it holds hashed identifiers rather than personal data precisely so it can be retained.

Q: How should age context flow through a microservice architecture?

As a synthetic age band inside a signed token, issued once at the authentication boundary and consumed as a claim by every downstream service — never as a raw date of birth passed from service to service. The reasoning is straightforward data minimisation applied to a system-design problem. Downstream services do not need to know when a user was born; they need to know what treatment applies — whether to suppress advertising, route to a chronological feed, skip telemetry initialisation, or restrict a feature. That is an authorisation decision, and authorisation decisions should be driven by claims. A birthdate propagated through a dozen microservices is a dozen places it can be logged, cached, leaked in an error trace, or written to an analytics event; an age band is a low-sensitivity classification that reveals almost nothing if it escapes. The implementation: at authentication, resolve the user’s age classification once from the verified consent record, and mint a JWT carrying a minor flag and an age band claim. Downstream services validate the token signature and authorise on the claim. Two design details matter. Prefer a band over a bare boolean — a binary is_minor flag cannot express that a sixteen-year-old and a six-year-old warrant different treatment, and the AADC’s developmental banding is the direction regulation is heading, so a band is the more durable choice even if you initially map every band to the same behaviour. And keep the token lifetime short enough that an age transition (a user turning eighteen, or consent being revoked) takes effect promptly, or add a revocation check on sensitive paths, because a long-lived token asserting a stale classification is exactly the kind of gap an auditor finds.

Q: What is feed gating and why is it not legally required?

Feed gating means routing minor accounts away from the recommendation engine entirely — serving a chronological feed of content from accounts the minor explicitly follows, with no algorithmic ranking, no ad units injected, autoplay disabled, and hard pagination instead of infinite scroll. It is not legally required in India because Section 9 of the DPDP Act regulates data processing (consent, tracking, targeted advertising) and says nothing about content curation, so a platform can satisfy every statutory obligation while running an engagement-optimised feed at a fourteen-year-old. It matters because that feed is where the actual harm originates. A recommendation engine optimising for retention needs no personal data and no age knowledge to converge on high-arousal content within a single session, using only real-time engagement signals like dwell time on a thumbnail. Disabling tracking does not slow it down. The implementation is straightforward once decided: the API gateway inspects the age-band claim in the token and routes the feed request to a chronological resolver rather than the vector-retrieval and ranking pipeline, the ad-insertion middleware returns an empty array for minor accounts, the client defaults autoplay off, and engagement notifications generated overnight are queued rather than delivered. The engineering cost is modest; the product cost is that minors generate less engagement, which is precisely why no platform does it voluntarily and why it will eventually need to be mandated. Building it now is a bet that regulation moves toward the UK’s design-led model (high-privacy defaults, profiling off, nudge constraints), which is where the direction of travel points — and in the meantime it is the difference between a system that passes audit and one a parent would actually let their child use.

Q: What are the most common defects in DPDP consent implementations?

Six, and they cluster around treating compliance as a data model rather than a system. First, retaining raw verification identifiers — teams keep Aadhaar numbers, PAN, or government tokens "for audit purposes," creating exactly the honeypot that makes a breach catastrophic; store an HMAC of the transaction identifier and nothing else. Second, an audit log that is not actually immutable: the row-level trigger everyone writes does not fire on TRUNCATE, and a table owner can disable triggers, so without privilege revocation and hash-chaining the log is not evidence. Third, a signature that covers only scalar fields, leaving consent details and revocation metadata unsigned and therefore forgeable — the defect that most directly defeats the purpose of having signatures. Fourth, enum drift between the application and the database, where two hand-maintained copies of the same state machine diverge and every write with a divergent value fails at runtime. Fifth, consent without a working revocation cascade — deleting from the primary database while analytics warehouses, caches, search indexes, and object storage retain the data, which is a compliance failure waiting for the audit that follows the data rather than the schema. Sixth, defaults implemented in application logic rather than in the schema, so a code path that misses the check writes a public profile for a minor; DEFAULT FALSE on the column does not miss. Underlying all six is a single mistake: treating the requirement as a checkbox to satisfy rather than a lifecycle to operate. Consent has states and transitions, erasure is a distributed job, and an audit trail is evidence with adversarial requirements. Systems designed as data models fail at the first audit that probes any of those three.

Satyam Kumar

Back to Blog

ai-architecture

Building DPDP-Compliant Systems for Minors: Consent Engine, Feed Gating, and an Audit Trail That Holds

By Satyam KumarJuly 26, 202613 min read

dpdp compliance rule 10 verifiable parental consent consent management audit trail postgresql json schema data privacy engineering child safety engineering privacy by design immutable logs hmac rfc 8785 data erasure india tech law 2026

Building DPDP-Compliant Systems for Minors: Consent Engine, Feed Gating, and an Audit Trail That Holds

Frequently Asked Questions

Share this article

Twitter LinkedIn WhatsApp

Satyam Kumar

Founder & AI Architect, AppScale LLP

AI & Cloud Architect. Helping teams build systems that scale to millions.

LinkedIn GitHub

Building DPDP-Compliant Systems for Minors: Consent Engine, Feed Gating, and an Audit Trail That Holds

Frequently Asked Questions

Share this article

Comments

Leave a comment