Proving Valid Consent Under India's DPDP Act

A Data Protection Board inquiry, or a data principal disputing what they agreed to, does not ask whether an organization owns a consent management tool. It asks for the one thing that tool exists to produce: proof that a specific person, at a specific time, agreed to a specific purpose, on terms they could reverse as easily as they accepted. Most consent databases can produce a timestamp and a checkbox state. Under India's Digital Personal Data Protection (DPDP) Act, that is not the same as evidence.

What valid consent requires under the DPDP Act

India's DPDP Act sets a demanding bar for what counts as consent. A request for consent has to be free, specific, informed, unconditional, and unambiguous, given through a clear affirmative action — no default-checked boxes, no consent folded into a broader terms-of-service click-through, no purpose written broadly enough to cover whatever a data fiduciary later decides to do with the data.

The request has to be accompanied by a notice in plain language that states, item by item, which personal data is collected for which purpose. And the mechanism for withdrawing consent has to be at least as easy as the mechanism used to give it.

Four things a consent record has to prove

Meeting that standard at the moment of collection is necessary but not sufficient. An organization also has to be able to reconstruct, later, that the standard was met — for its own governance, for a Board inquiry, or for a data principal who disputes what they agreed to. That reconstruction rests on four kinds of evidence.

What the Act requires	What has to be proven later
Free, specific, informed, unconditional, and unambiguous consent	The exact notice and purpose shown to the person at the moment of the affirmative act, not a paraphrase reconstructed after the fact.
Itemized notice	The specific purpose and data items on record for that consent event, tied to a version of the notice text.
Withdrawal as easy as consent	A withdrawal event captured on the same channel, at comparable effort, to the original consent.
An evidentiary record	A record a third party — a regulator, an auditor, the data principal — can check without taking the platform's word for it.

The MeitY Electronic Consent Framework as the reference model

India already has a template for what a machine-checkable consent record should look like. The Ministry of Electronics and Information Technology (MeitY), through its Electronic Consent Framework (ECF), defines a structured, signed artefact that separates the data fiduciary, the data processor, the purpose, and the data items being consented to, so the record can be checked independently of the platform that issued it.

ConsentIQ builds its consent record as a signed artefact modelled on the ECF: the collector, the data consumer, the purpose, the data items, and the identifier — held as a keyed one-way hash rather than the plaintext email or phone — wrapped in a cryptographic signature. It ships as a MeitY-aligned JSON profile, legible to the audiences the ECF was designed for: auditors, a Data Protection Board, and the data principal themselves.

Verifying a consent record in real time

A consent record is only useful as evidence if it can be checked without trusting the platform that produced it. ConsentIQ exposes a public verify endpoint that confirms on request whether a record is intact or has been altered. Each artefact can also carry a portable signature, verifiable against a public key ConsentIQ publishes, so a regulator, an auditor, or a counterparty can confirm a receipt is genuine without an account and without asking ConsentIQ to vouch for it.

The same real-time check runs the other way, for the organization doing the asking. A Data Protection Officer confirming whether a person consented, and to what, searches by email or phone in the console; the DPO gets a verified match in real time, without the plaintext identifier being read out of storage.

Capturing withdrawal on the same terms as consent

The requirement that withdrawal be no harder than consent is where most legacy consent tools fall short: consent is one tap on a banner, withdrawal is an email to an inbox nobody monitors. ConsentIQ's data-principal self-service portal puts withdrawal on the same channel as collection — a person can see what they agreed to, on which property, and withdraw it directly, in the same session. The withdrawal becomes a new signed entry in the same consent trail as the original grant, not a side note logged somewhere else.

A tamper-evident trail that survives scrutiny

Every artefact ConsentIQ issues is chained into a tamper-evident audit log; altering a past record breaks the chain and the console flags the mismatch. Records also export in formats the frameworks around the ECF already expect: a human-readable PDF receipt, a W3C Verifiable Credential for machine verification, and a Kantara Consent Receipt for portability across systems that were never built to talk to each other.

Proof that holds regardless of who is asking

A consent record that only stores a timestamp answers one question: did this person click something once. It does not show whether the click met the DPDP Act's bar for free, specific, informed, unconditional, and unambiguous consent, whether the itemized notice on file matches what was actually shown, or whether withdrawal was ever made available on equal terms. A signed, independently verifiable artefact, chained into a tamper-evident log, answers all four to whoever is asking — not only to the platform that issued it.

ConsentIQ's consent artefacts are independently verifiable by anyone holding the published key, without an account and without ConsentIQ's involvement. See how ConsentIQ proves consent under India's DPDP Act in your own environment: book a ConsentIQ demo and proof of concept.