Consent Receipts: Why Proof of Consent Is the Real Compliance Asset

A consent receipt is an immutable record of a consent event: what the user was shown, what they chose, and when. It is the difference between "we have a banner" and "we can prove what happened," and under India's DPDP Act, proof is the entire game.

Most consent tooling stops at recording a choice. The DPDP era requires more: the ability to reconstruct, months or years later, exactly what a user saw and agreed to. That reconstruction problem is what receipts solve. This post explains what a receipt should contain, why versioning matters, and how to build consent records that survive an inquiry.

What a consent receipt records

A receipt is a snapshot of a consent event. The useful version contains:

1. The identity of the data fiduciary
2. The user's choice, per purpose
3. The exact notice or configuration version the user saw
4. A timestamp for the event
5. The mechanism of consent (banner, SDK, preference centre)
6. A reference that links the event to the user's installation or account

The critical piece is number three. A choice without the thing that was shown is half a record. "User accepted marketing" is meaningless unless you also know what the marketing notice said at that moment.

Why immutable matters

Consent configuration changes. You will add purposes, reword notices, and restructure your privacy surface. When that happens, every past consent event needs to stay pinned to the version that was live at the time.

If your records are mutable, you have a subtle corruption problem: a user who consented under the June notice is later recorded against the September notice, and nobody can tell. A regulator or a user challenging the record will ask what was shown, and "whatever the current config says" is not an answer.

Immutable receipts solve this by never rewriting history. Each consent event points at a published configuration snapshot, and that snapshot never changes. Old records stay readable and honest.

The DPDP angle

The DPDP Act's consent test, free, specific, informed, unconditional and unambiguous, is only enforceable if you can reconstruct what the user was informed of and chose. The Rules' notice and consent provisions point the same direction: demonstrate consent means produce the record.

Two practical consequences for product teams:

• Receipts are part of your defense, not paperwork. If consent is challenged, the receipt is the evidence. Its quality determines the outcome.
• Receipts should be privacy-preserving themselves. The ideal receipt stores no more personal data than needed. If a receipt is itself a personal data record, you have created a second compliance surface. Erasure's receipts, for example, do not require IP address, user ID, or fingerprinting for the core path.

Receipts and webhooks: consent as system state

A receipt is the record; enforcement is the action. A consent event should propagate: when a user withdraws marketing consent, your analytics and marketing systems need to stop processing for that purpose.

The mechanism is a webhook. Erasure's Accord sends signed (HMAC) consent.updated events so backend systems react to changes. This closes the loop: the receipt records what happened, and the webhook makes it true across your systems. A consent system without downstream enforcement is a banner with a database.

What to ask a consent vendor

When evaluating consent infrastructure, the receipt is the test. Ask:

• What exactly is stored for a consent event?
• Does the record include the configuration version that was shown?
• Can you export a single user's consent history?
• What happens to old receipts when you change configuration?
• Do consent changes reach backend systems, and how?
• How much personal data does the receipt itself contain?

A vendor that cannot answer these clearly does not have a receipt model; it has a checkbox model.

The evidence posture

Receipts are one part of an evidence posture. The same logic, prove what happened, extends to the rest of privacy operations: deletion jobs, data maps, breach response. That is why Erasure is a privacy operations platform rather than a banner tool: Accord for consent receipts, Rights for deletion case records, Data Maps for inventory, Evidence for exportable proof packages.

The consent under DPDP post covers the Section 6 conditions these receipts must satisfy, and the consent manager post explains the ecosystem these records will eventually interoperate with.

The bottom line

A consent receipt is the difference between compliance theatre and a defensible position. If your consent tool cannot reconstruct what a user saw, chose, and when, it is not a consent system. Build the record first; the banner is the easy part.

The DPDP compliance checklist puts receipts in the full operational context, and the product docs show how Accord structures receipts in practice.