ConsentXDPDPA is being phased in. Scan your site to see where you stand. Scan now
ConsentXDigital proof of what a user agreed to, when they agreed, and which notice they saw.
Think of it as digital proof of consent, like the receipt you get after a payment. It helps you show and audit consent, instead of relying on a simple "consent = true" value in a database or a screenshot of a banner. ConsentX stores these decisions as tamper-evident consent records and audit evidence.
This matters because privacy laws expect you to prove consent. Under GDPR, you must be able to demonstrate that a person consented. Under India's DPDP Act, a Data Fiduciary must be able to prove that notice was given and consent was obtained if its validity is questioned.
Think of a consent receipt as a digital proof of a consent decision.
For example, a visitor opens a website and chooses:
A useful consent receipt can preserve the decision together with the context needed to reconstruct it, such as:
The exact fields depend on the implementation, jurisdiction, and use case.
A consent banner only shows the interface presented to users. It does not necessarily prove what a particular user selected at a particular time.
A consent receipt provides an auditable representation of an individual consent transaction.
This is especially important when an organisation handles audits, complaints or data subject requests and needs to answer questions such as:
A strong consent-management system should therefore preserve enough evidence to reconstruct the relevant consent event.
The ICO's guidance recommends maintaining an effective audit trail and recording who consented, when they consented, what they were told, and how consent was obtained.
Consent evidence is the broader set of information an organisation maintains to demonstrate that consent was validly obtained and managed.
It may include:
A consent receipt can therefore be one component of a wider consent evidence and audit system.
A mature consent-management process should make it possible to answer an auditor or regulator's questions without manually reconstructing historical events.
For each relevant consent event, an organisation should ideally be able to determine:
This is the practical value of consent receipts.
The terms consent receipt and consent record are closely related but should not automatically be treated as identical.
A consent record is the underlying evidence maintained by an organisation or consent-management system.
It may contain detailed technical information about:
A consent receipt is a representation of that consent transaction that can be presented to or made available to the individual and used as evidence of the decision.
The Kantara Consent Receipt Specification describes a consent receipt as a record of authority granted by an individual to a controller for processing personal information and defines a human-readable representation that can also be represented in JSON.
A database may contain thousands of internal consent events, while a user-facing consent receipt may provide a clear representation of a particular individual's consent decision.
These are not the same thing.
| Consent Banner | Consent Receipt |
|---|---|
| User interface for collecting a decision | Record or representation of the decision |
| Appears before or during consent | Created from the consent event |
| Shows available choices | Records what was actually selected |
| Focuses on user interaction | Focuses on evidence and auditability |
| May change when the website design changes | Should preserve the historical consent context |
| Does not by itself prove an individual's choice | Can provide evidence of the individual's decision |
A screenshot of a consent banner can show what a website looked like.
A consent receipt should help demonstrate what a particular individual decided.
Cookie consent is a specific use case for consent management.
A website may collect consent for:
The consent receipt can preserve the resulting choices.
For example:
The underlying consent system should also maintain the relevant timestamp, notice version, and other evidence needed to interpret the decision.
A Consent Management Platform (CMP) is the technology used to collect, manage, enforce, and often record consent preferences.
A Consent Receipt is evidence or a representation of a particular consent transaction.
In simple terms:
system that manages consent.
evidence stored by the system.
representation of a consent decision.
A CMP can therefore generate or maintain consent receipts as part of its broader consent-management functionality.
There is no single universal field list that every organisation must use for every consent transaction.
However, a robust consent receipt should contain enough information to establish the context and substance of the decision.
A unique identifier allows the organisation to locate and reference a particular consent transaction.
The receipt should record when the consent decision occurred, ideally with appropriate timezone or UTC information.
The record should identify the relevant individual or device in a proportionate way.
Depending on the implementation, this could be an account identifier, pseudonymous identifier, session identifier, or another appropriate reference.
The receipt should show whether a particular purpose, category, or processing activity was:
A granular record is generally more useful than a single overall “accepted” value.
The receipt should identify what the consent covered.
For example:
Consent should not be represented as broader than the purposes for which it was actually obtained.
The organisation should be able to identify the privacy notice, consent notice, or other information presented when consent was obtained.
This is particularly important when notices change over time.
A record saying “user consented” is much weaker than one that can establish:
User → consent event → purpose → notice version → timestamp.
The receipt can record how consent was obtained, such as:
Where relevant, the receipt can identify the services, vendors, cookies, tags, or processing activities associated with the decision.
This is particularly useful for cookie consent and advertising technology environments.
Consent is not necessarily a permanent decision.
A consent-management system should therefore be able to associate later preference changes or withdrawals with the original consent history.
A strong implementation should be:
It should identify the purposes and processing covered by the decision.
The organisation should know when the decision occurred.
The receipt should be associated with the relevant user, session, or other appropriate identifier.
The organisation should be able to identify the notice or policy version presented at the time.
Where consent is collected separately by purpose, the evidence should preserve those individual choices.
Consent evidence should be protected against unauthorised access and alteration.
The organisation should be able to retrieve and interpret historical records.
Consent evidence can itself contain personal information and should therefore be handled appropriately.
GDPR requires demonstrable consent when consent is used as the lawful basis for processing, but it does not simply mandate a document called a “Consent Receipt” in every case.
Article 7(1) requires the controller to be able to demonstrate that the data subject consented to processing. The practical implication is that organisations need reliable evidence of consent.
A consent receipt can be an effective way of representing that evidence, but organisations should distinguish between:
This distinction is important for accurate GDPR compliance content.
For consent to be useful as a GDPR lawful basis, the underlying consent must meet the applicable requirements.
A consent receipt does not make invalid consent valid.
For example, a receipt cannot fix a consent mechanism that:
The receipt proves the decision that occurred. It does not replace the requirement to collect valid consent in the first place.
The ICO, the regulator for the UK GDPR, recommends keeping records that demonstrate:
The organisation should also retain sufficient information to demonstrate the consent decision for as long as it is relying on consent as the basis for processing.
This makes notice versioning particularly important.
For example:
The precise implementation can differ, but the evidence should be meaningful and reconstructable.
The Digital Personal Data Protection Act, 2023 (DPDP Act) uses the terminology Data Principal and Data Fiduciary rather than GDPR's “data subject” and “controller” terminology.
Section 6 provides that consent must be free, specific, informed, unconditional and unambiguous, given through clear affirmative action and limited to the personal data necessary for the specified purpose.
Importantly, where consent is the basis for processing and its validity is questioned, the Data Fiduciary must prove that the required notice was given and consent was obtained in accordance with the Act and applicable rules.
The final DPDP Rules also contain specific requirements for registered Consent Managers. A Consent Manager must maintain records of consents given, denied or withdrawn, notices preceding or accompanying consent requests, and certain sharing of personal data. The rules also provide for Data Principal access to those records and machine-readable availability on request, with specified retention requirements.
This makes consent evidence particularly relevant to ConsentX's India-focused compliance content.
A tamper-evident consent receipt is designed so that unauthorised changes to the evidence can be detected.
This can involve techniques such as:
The purpose is not to make a consent record magically “legal proof,” but to improve the integrity and auditability of the evidence.
For example, a hash chain can link successive consent records so that unauthorised modification of an earlier record can be detected.
ConsentX uses tamper-evident consent records and describes its implementation as using a SHA-256 hash chain. The current ConsentX glossary page specifically positions this as a mechanism for making consent evidence independently verifiable and difficult to backdate.
Usually, a screenshot alone is weak evidence.
A screenshot can demonstrate what a consent interface looked like at a particular point in time, but it generally does not establish that a particular individual made a particular selection.
Stronger evidence can connect:
individual or identifier + timestamp + consent decision + purposes + notice version + collection method.
This is why consent records and receipts are important for audit readiness.
A typical consent-receipt workflow looks like this:
The organisation presents the relevant privacy or consent information.
The user makes a clear choice for one or more purposes.
The system records the decision and relevant contextual information.
A human-readable representation of the consent event is generated.
The organisation securely stores the consent record and associated metadata.
The user's choice is applied to relevant cookies, trackers, processing activities, or other technologies where applicable.
If the user changes or withdraws consent, the system records the subsequent event.
The organisation can retrieve the relevant record for audits, compliance reviews, data-rights requests, disputes, or regulatory enquiries.
Withdrawal should be treated as part of the consent lifecycle.
A useful consent system should preserve:
For example:
This creates a much clearer audit trail than simply overwriting the original value.
A consent receipt can contain identifiers, timestamps, and preferences, so it is personal data too. Good consent evidence should prove the decision without collecting more data than needed.
To keep consent receipts privacy-friendly:
Consent evidence also needs integrity. A consent record that can be quietly edited or deleted proves very little, so receipts should be protected against unauthorised changes and stay understandable and traceable over time, so the record still makes sense when it is checked months or years later.
ConsentX keeps consent evidence secure with tamper-evident consent records and audit evidence, so you can prove consent while protecting user privacy.
A Boolean value does not explain what the individual agreed to, when they agreed, or what they were told.
If the privacy notice changes, the organisation may struggle to establish which version was presented when consent was obtained.
Refusals and withdrawals can be just as important as positive consent decisions.
Replacing an old consent state with a new value can destroy useful audit history.
A receipt documents a consent event. It does not make an otherwise invalid consent mechanism compliant.
Recording “marketing consent withdrawn” is not enough if the organisation continues sending marketing communications based on that consent. The same applies on a website: you need to block scripts before consent, not just record the choice.
The interface is not the same as the user's individual decision.
Consent records can contain personal information and should be protected accordingly.
ConsentX is designed to help organisations collect, manage, enforce, and prove consent across privacy and consent workflows.
For consent evidence, ConsentX provides Consent Records & Audit Evidence, allowing organisations to maintain a structured record of consent decisions and their supporting context.
The current ConsentX implementation also describes tamper-evident consent records using a SHA-256 hash chain, designed to make unauthorised changes easier to detect and provide stronger auditability.
This can help organisations move from:
to:
“Here is the record showing what the user consented to, when, and under which consent context.”
ConsentX records when consent was given, what purpose it covered, and which notice version the user saw. Each record is protected with a SHA-256 hash chain, helping privacy teams maintain tamper-evident evidence of what was agreed.
Explore ConsentX