Consent Under DPDPA Is Not a Checkbox: Architecting a Consent Lifecycle That Survives Audit

The blanket "I agree" tick-box is finished. Section 6 of the Digital Personal Data Protection Act requires consent that is free, specific, informed, unconditional and unambiguous, given through clear affirmative action, limited to the data necessary for the stated purpose, and withdrawable as easily as it was given.

Every one of those adjectives is an engineering requirement. This is how to build a consent lifecycle that produces evidence rather than assertions, with full compliance due on 13 May 2027.

Deconstructing Section 6, Adjective by Adjective

Lawyers read Section 6 as a standard. Engineers should read it as a specification, because each term constrains the implementation.

Free. Consent must not be a condition of receiving a service that does not require the data. Making newsletter consent mandatory for account creation fails this test. Implementation consequence: the consent capture UI must permit refusal of non-essential purposes without blocking the primary transaction.

Specific. Consent attaches to a purpose, not to an organisation. One affirmative action per purpose. Implementation consequence: your consent record is a set of per-purpose entries, not a single boolean on the user row.

Informed. The notice accompanying the request must describe the personal data sought, the purpose, how to exercise rights, and how to complain to the Board - and the Act contemplates availability in English or any language in the Eighth Schedule. Implementation consequence: notices are versioned content objects with language variants, and the consent record references the exact version and language shown.

Unconditional. No bundling, no pre-ticked boxes, no consent inferred from continued use.

Unambiguous, by clear affirmative action. Silence, inactivity and scrolling are not consent. Implementation consequence: the event you record is a deliberate user action with a timestamp, not a page view.

Limited to necessary data. Data minimisation is part of the consent test, not a separate principle. Collecting a date of birth for a purpose that does not need it invalidates the consent for that field.

Withdrawable as easily as given. If consent took one click to give, it takes one click to withdraw. Implementation consequence, and the hardest one: withdrawal must propagate to every downstream system, including vendors and any model trained on the data.

Certain Legitimate Uses: Get the Terminology Right

Section 7 sets out grounds where processing may proceed without consent. A note on terminology matters here, because it causes real design errors.

The 2022 draft bill used the term deemed consent and drew the grounds broadly. The enacted 2023 Act replaced that construct with certain legitimate uses, and narrowed it. Programmes designed against the older draft consistently over-claim, treating the ground as a general-purpose alternative to consent in the way GDPR's legitimate interests operates. It is not, and there is no general legitimate-interests basis in the DPDP Act.

The grounds include voluntary provision of data by the Data Principal for a specified purpose where they have not indicated objection, performance of State functions and provision of benefits and services, compliance with legal obligations and court orders, responding to medical emergencies and threats to life, measures during epidemics and disasters, and specified employment-related purposes including safeguarding the employer from loss and providing services to employees.

Two design implications:

Employment is a ground, but a bounded one. It covers employment purposes, protection from loss or liability, and provision of services or benefits to the employee. It does not convert the employment relationship into a general licence to process employee data for any purpose the employer finds useful. Employee monitoring justified as "an employment purpose" without a defensible link to those grounds is exposed.

Voluntary provision is narrower than it reads. It applies where the Data Principal has voluntarily provided data for a specified purpose and has not indicated objection. It does not cover secondary use for purposes they never contemplated.

The Consent Record: What Audit Actually Asks For

When the Data Protection Board or an auditor asks you to demonstrate valid consent for a specific Data Principal, an assertion that your flow is compliant is not evidence. The record is.

A defensible consent receipt contains:

The last row is what separates a consent system from a consent database. Recording that someone withdrew is trivial. Proving that the withdrawal reached the CRM, the analytics warehouse, three vendors and the training dataset is the obligation.

Children's Data: Verifiable Parental Consent

Section 9 requires verifiable parental consent before processing a child's personal data, and prohibits tracking, behavioural monitoring, and advertising directed at children.

The operative word is verifiable. A checkbox stating "I am over 18" verifies nothing, and a checkbox stating "I am this child's parent" verifies less. The Rules give shape to acceptable approaches, which broadly rest on either reliable identity details already held by the Data Fiduciary or verification through an authorised digital identity or token issued by an entity entrusted with that function.

Design considerations that catch teams out:

• Age assurance precedes consent capture. You cannot know whether parental consent is required until you have made an age determination, and that determination is itself processing that needs a basis.
• The parent and the child are two Data Principals. The parent's verification data is personal data with its own purpose, lawful basis and retention.
• Re-verification on majority. A child who reaches adulthood should transition to their own consent. Build the trigger at design time.
• The advertising prohibition is absolute for children. No consent, parental or otherwise, unlocks behavioural advertising directed at a child. Consent architecture cannot solve a prohibited-purpose problem.

Consent Managers and Revocation Propagation

The Act contemplates a Consent Manager - a registered entity through which a Data Principal may give, manage, review and withdraw consent, accountable to the Data Principal and interoperable across Data Fiduciaries. The registration framework becomes operative in the November 2026 phase.

For an enterprise, the strategic implication is that consent may arrive from outside your own interface. Your consent architecture must therefore be able to ingest and honour a consent decision made elsewhere, and to accept a withdrawal instruction from a third-party intermediary. Designing consent as a purely first-party, in-application concern is designing for an architecture the Act does not assume.

Revocation propagation is the engineering core of the whole system. A workable design:

1. Withdrawal is an event, not a field update. Publish it to a durable event bus rather than updating a row.
2. Every consuming system subscribes and acknowledges. Consumers include applications, the data warehouse, the CRM, marketing platforms, vendors with API integrations, and ML feature stores.
3. Acknowledgement is recorded per consumer. An unacknowledged propagation is an open compliance incident with an owner and an SLA.
4. Vendors without event support are handled by scheduled reconciliation. Nightly delta files, with the reconciliation result logged.
5. Training datasets are treated as consumers. This is the step almost universally missed, and it is discussed below.
6. The whole chain is testable. A synthetic Data Principal that you can consent, withdraw, and then trace through every system on demand.

The Hard Problem: Consent Withdrawal and Trained Models

If personal data was used to train a model and the Data Principal withdraws consent, deleting the row does not remove the influence of that data from the model's weights.

There is no complete technical solution to this today, and any vendor claiming otherwise deserves scepticism. What there is instead is a set of defensible positions:

• Avoid the problem at ingestion. Prefer aggregated, anonymised or synthetic data for training wherever the use case permits, so that withdrawal has nothing to reach.
• Bind training datasets to consent state at build time. Record which consent identifiers contributed to which dataset version, which contributed to which model version. Without this lineage you cannot even scope the problem.
• Set a retraining trigger. Define a threshold - a proportion of withdrawn records, or a fixed interval - at which the model is retrained from a refreshed dataset that excludes withdrawn data.
• Suppress at the output layer meanwhile. Ensure the withdrawn individual's data cannot be surfaced through retrieval, personalisation or lookup, even while their historical contribution remains in the weights.
• Document the position. A written, risk-assessed rationale reviewed by the DPO is a far better audit posture than silence.

The organisations that will handle this well are the ones that record dataset-to-consent lineage now, before they need it. Reconstructing it retrospectively across several model generations is not realistically possible.

Technical Architecture

Pulling it together, the reference shape:

Consent service. Owns notices, purposes, receipts and state transitions. Exposes an API for capture, query and withdrawal. It is the single source of truth; no application stores its own copy of consent state.

Immutable log. Append-only, cryptographically hashed, with tamper-evident chaining. Consent records are evidence, and evidence that can be silently edited is not evidence.

Purpose registry. The controlled vocabulary of purposes. Every processing activity in the RoPA references a purpose identifier from this registry, which is what makes purpose limitation enforceable rather than aspirational.

Policy enforcement point. A gateway or library that checks consent state before processing. Enforcement in application code alone is enforcement that drifts.

Event bus and acknowledgement ledger. Carries withdrawal events and records per-consumer acknowledgement.

Integration adapters. Per-vendor connectors for CRM, ERP, marketing and analytics platforms, each mapping the internal consent model to the vendor's own.

Conclusion

Consent under the DPDP Act is a system, not a screen. The legal text specifies behaviour that only an architecture can deliver: per-purpose granularity, versioned notices, immutable receipts, one-click withdrawal, and propagation that reaches every consumer including the ones your team does not think of as consumers.

Organisations that treat this as a front-end task will pass a cursory review and fail the first real one, because the first real question is not "show me your consent screen" but "show me that this specific person's withdrawal reached this specific vendor on this specific date."

Actionable recommendations:

• Model consent per purpose from the start. Retrofitting granularity onto a single boolean means rebuilding every collection point and reconciling historical records with no reliable source.
• Make the receipt immutable and complete. Notice version, language, timestamp, method and data categories. If it is not in the receipt, you cannot prove it later.
• Design withdrawal propagation before consent capture. Capture is easy and gets built first, which is why so many programmes discover the propagation problem after the architecture is fixed.
• Record dataset-to-consent lineage today. It is the only thing that makes the trained-model withdrawal problem tractable, and it cannot be reconstructed after the fact.
• Assume consent will arrive from a Consent Manager. Build ingestion and third-party withdrawal handling rather than assuming a first-party-only world.

Centralise consent records and prove propagation. Immutable receipts, per-purpose granularity, automated withdrawal propagation with per-consumer acknowledgement, and audit-ready logs in one click. See how Dedups.ai turns consent from a screen into an evidenced control.