Technical Architecture and Implementation

A DPDP-ready architecture connects legal and product decisions to system behaviour and evidence. It is not one consent banner, one database or one vendor. Current status, verified 29 August 2026: most substantive DPDP obligations are notified but scheduled to commence around May 2027. Engineering teams can use the lead time to establish clean interfaces, migrate fragmented state and test failure recovery.

Make five decisions first. Define the authoritative registry for purposes, data categories, legal-basis decisions, notice versions and retention rules. Choose the source of truth for consent and preference state. Standardise an append-only event model for grants, refusals, withdrawals, corrections and administrative changes. Decide where policy is enforced before optional processing begins. Define the evidence needed to reconstruct what happened for one person, purpose, channel, policy version and time.

A practical stack has layers. Experience channels present versioned notices and choices. An identity layer resolves the person, account, device and, where relevant, parent or guardian. A policy service resolves the current purpose and permitted state. A consent or preference service writes idempotent events to an auditable ledger. Enforcement connectors gate SDKs, APIs, marketing tools, analytics, warehouses and processor workflows. Rights orchestration locates, corrects, restricts or erases data across those systems. Observability detects stale state, failed propagation, missing acknowledgements and unauthorised fallbacks.

Design identifiers and contracts before UI polish. Use stable purpose_id, notice_id, notice_version, actor_id, subject_id, channel, locale, decision, effective_at, source_event_id and correlation_id fields. APIs should reject ambiguous purposes, support idempotency keys and return the authoritative decision version. Webhooks need authentication, replay protection, retry policy, dead-letter handling and reconciliation. Fail closed for optional processing when authoritative consent is unresolved, while preserving carefully defined essential-service flows.

Build security and evidence into the same design. Limit access to consent and rights records, encrypt sensitive fields, separate operational state from immutable evidence, record administrative changes and monitor privileged queries. Processor integrations should acknowledge restrictive changes and expose completion evidence. Backup and disaster-recovery plans must preserve event ordering and avoid resurrecting withdrawn states.

Migration is a product programme. Inventory legacy checkboxes, CRM flags, cookies and offline records; map only defensible states into the new model; tag provenance and uncertainty; decide whether a new notice or consent is needed; dual-write during transition; reconcile outputs; and define rollback rules. Measure propagation latency, stale-state rate, unclassified events, reconciliation drift, processor acknowledgement and evidence-query success.

Use the linked specialist pages as modules: the consent-ledger guide owns the end-to-end reference architecture; the token guide owns runtime claims and validation; the schema guide owns storage; the server-side preference-centre guide owns APIs and synchronisation; and the event-taxonomy guide owns analytics naming. This hub is the decision map joining those implementation paths.