Skip to main content
DataRidge
Category: Legal Basis and Consent

Consent Receipt

Also known as: Consent Record, Proof of Consent
Simply put

A consent receipt is a record that captures what a person agreed to, when they agreed, and under which version of a policy or notice. It serves as evidence that consent was given for a specific processing purpose. It is typically issued or stored at the point where consent is collected and can be retrieved later to demonstrate what was agreed.

Formal definition

A consent receipt is a time-stamped, often tamper-evident record documenting a data subject's consent transaction, capturing the specified purposes of processing, the applicable policy or notice version, and, in some implementations, a verifiable hash for integrity. Operationally, receipts are generated at collection points and stored or retrieved via consent management systems (for example, through APIs that submit consent transactions or retrieve a receipt by identifier). A consent receipt functions as accountability evidence supporting a consent-based lawful basis; however, its existence does not by itself establish that consent was validly obtained, freely given, informed, or specific, nor that consent is the appropriate lawful basis for the processing in question. This definition addresses the record artifact and its typical contents only. It does not cover the substantive validity requirements for consent, the mechanics of withdrawal, jurisdiction-specific standards, retention obligations, or cross-border transfer considerations, which vary by legal regime and implementation.

Why it matters

Under accountability-oriented frameworks, an organization relying on consent as its lawful basis for processing generally needs to be able to demonstrate that consent was obtained, not merely assert it. A consent receipt provides a concrete, retrievable artifact capturing what a person agreed to, when, and under which version of a policy or notice, which supports that demonstrable evidence requirement. Without such a record, a controller may struggle to show what a data subject was told and agreed to at the moment of collection, particularly where policy text changes over time.

It is important to keep the record artifact separate from the substantive validity of consent. A consent receipt documents that a consent transaction occurred and what it referenced, but its existence does not by itself establish that the consent was freely given, specific, informed, or unambiguous, nor that consent was the appropriate lawful basis in the first place. Experts should avoid treating a stored receipt as proof of valid consent; it is evidence of the transaction, and the underlying collection mechanism must still meet the applicable legal standard. Similarly, a receipt does not address whether or how consent can be withdrawn, which is a distinct obligation.

Because treatment of consent differs across legal regimes, the value and required contents of a receipt depend on the jurisdiction and implementation context. A receipt should be understood as one accountability control among others rather than a compliance guarantee. It does not resolve retention, cross-border transfer, or jurisdiction-specific validity questions, all of which must be handled separately.

Who it's relevant to

Data Protection Officers and Privacy Leads
Those responsible for demonstrating accountability where consent is used as a lawful basis rely on consent receipts as retrievable evidence of what was agreed and under which policy version. They should be clear that a receipt evidences the transaction but does not by itself confirm the consent was valid, specific, or freely given, nor that consent was the correct basis for the processing.
Privacy Engineers and Consent Management Implementers
Teams building or integrating consent management systems handle the generation, storage, and retrieval of receipts, including submitting consent transactions from collection points and retrieving records by identifier. Where integrity matters, they may implement tamper-evident records with a verifiable hash, while recognizing that these controls address the record artifact rather than the substantive validity of consent.
Compliance and Information Governance Teams
Those maintaining evidence of processing activities and policy versioning use consent receipts to tie a documented agreement to a specific notice version at a point in time. They should treat receipts as one accountability control that must be paired with separate handling of withdrawal, retention, and jurisdiction-specific validity requirements, which the receipt itself does not cover.
Legal and Regulatory Advisors
Legal professionals assessing whether consent can be substantiated will examine receipts as documentary evidence, while scoping their analysis to the applicable regime. Because standards for valid consent and its documentation differ across jurisdictions, advisors should caution against treating the presence of a receipt as a compliance guarantee.

Inside Consent Receipt

Consenting party identifier
A reference to the data subject who provided consent, typically captured in a manner that allows the record to be linked to that individual without necessarily embedding unnecessary identifying detail. Note this record itself generally constitutes personal data and remains in scope of applicable data protection regimes.
Controller identity
Identification of the party acting as data controller who is relying on consent as a lawful basis, including contact details. Under the EU GDPR and UK GDPR the controller bears accountability for demonstrating that valid consent was obtained; treatment of the controller concept differs under regimes such as the CCPA and CPRA.
Purpose specification
A record of the specific processing purpose or purposes for which consent was given. Consent is generally expected to be tied to defined purposes rather than being open-ended, though the precise granularity requirements depend on the applicable regime and implementation.
Scope of data and processing
Details of the categories of personal data and, where relevant, whether any special category or sensitive data is involved, along with the processing activities covered. This entry does not address the additional conditions that typically apply to special category data.
Timestamp and version
The date and time consent was captured and, where applicable, the version of the notice, terms, or consent language presented at that moment, supporting the ability to reconstruct what the individual was shown.
Method of collection
A record of how consent was obtained, such as the mechanism or interface used and the affirmative action taken, supporting the position that consent was freely given, specific, informed, and unambiguous where those standards apply.
Withdrawal information
Information on how consent may be withdrawn. Where consent is the lawful basis, withdrawal is generally expected to be as easy as giving consent, and the receipt supports the individual's awareness of that ability.

Common questions

Answers to the questions practitioners most commonly ask about Consent Receipt.

Does issuing a consent receipt guarantee that our processing is compliant?
No. A consent receipt is a record documenting that consent was requested and captured at a point in time; it is evidence, not a guarantee of compliance. In most jurisdictions, compliance depends on whether the consent itself met the applicable validity conditions (for example, being freely given, specific, informed, and unambiguous under the EU GDPR), whether consent was the appropriate lawful basis at all, and how the processing is subsequently carried out. A receipt supports the accountability principle by providing demonstrable evidence, but it cannot cure defective consent or substitute for a proper legal analysis of the processing.
Is consent the lawful basis we should rely on whenever we generate a consent receipt?
Not necessarily. Consent is only one of several lawful bases for processing, and a consent receipt is only relevant where consent is genuinely the basis being used. Relying on consent when another basis is more appropriate can create problems, because consent generally must be as easy to withdraw as to give, and withdrawal typically obliges the controller to stop the relevant processing. A consent receipt does not convert other processing into consent-based processing, and it does not by itself establish that consent was the correct or defensible basis to choose.
What information is typically captured in a consent receipt?
Implementations vary, but a consent receipt generally aims to record enough to demonstrate the circumstances of the consent: the identity of the party relying on the consent, what the individual was told, the specific purposes agreed to, the categories of data involved, and the time the consent was captured. The goal is a durable record that reflects what the individual actually saw and agreed to. This entry does not prescribe a mandatory field set, and any specific schema requirements would depend on the framework or standard your organisation chooses to align with.
Where should consent receipts sit in relation to the controller's other records?
A consent receipt is typically maintained by the party relying on the consent, generally the data controller in most frameworks, as part of its accountability evidence. It is distinct from, though it may feed into, broader governance records. Note that a records of processing activities obligation is not the same as a consent receipt log, and neither is equivalent to a data inventory tool. Consent receipts document individual consent events, while those other records serve different governance and documentation purposes.
How should consent receipts handle later changes or withdrawal of consent?
Because consent can generally be withdrawn, and the terms or purposes may change over time, receipts are typically treated as point-in-time records rather than a single mutable state. Many implementations retain the original receipt as evidence of what was agreed and generate new records for subsequent changes or withdrawals, so the history remains reconstructable. This entry does not cover the specific retention periods that should apply to consent records, which depend on jurisdiction, purpose, and your own retention rules.
Does storing consent receipts require particular security controls?
Consent receipts generally contain personal data and evidence about an individual's choices, so they fall within the scope of the information security controls the organisation applies to personal data more broadly, addressing confidentiality, integrity, and availability. Governance and security overlap here: governance defines who owns and is accountable for the receipts and how they are used, while security protects them. Applying encryption or tokenization to receipts does not make their contents non-personal. This entry does not specify particular technical controls, which should be determined through your own risk assessment.

Common misconceptions

A consent receipt proves compliance and guarantees that processing is lawful.
A consent receipt is evidentiary documentation of a consent event; it supports, but does not by itself guarantee, compliance. Validity still depends on whether the underlying consent met the applicable standards and whether consent was the appropriate lawful basis. Consent is only one of several lawful bases, and it should not be conflated with the others.
Issuing a consent receipt takes the consent record out of scope for data protection law.
The receipt itself generally contains personal data linking an individual to a consent event and therefore typically remains in scope of applicable regimes. It is a record about processing, not a means of anonymizing or removing the individual from protection.
A consent receipt is a universal, uniformly required artifact across all privacy regimes.
The concept and any expectation to retain consent evidence arise primarily where consent is used as a lawful basis and accountability must be demonstrated, as under the EU GDPR and UK GDPR. Treatment differs across regimes such as the CCPA and CPRA, HIPAA, and standards like ISO/IEC 27701 or the NIST Privacy Framework; a consent receipt is not mandated identically everywhere.

Best practices

Capture and retain the specific purpose, timestamp, version of the notice presented, and method of collection for each consent event so the record can be reconstructed as demonstrable evidence rather than a stated assertion of compliance.
Treat the consent receipt as personal data and apply appropriate security controls and retention limits to it, keeping in mind that information security controls do not substitute for the governance decisions about ownership and retention of these records.
Confirm that consent is the appropriate lawful basis for the processing before relying on a receipt, since consent should not be defaulted to where another lawful basis is more suitable.
Record and support the ability to withdraw consent, ensuring the mechanism is as accessible as the mechanism used to obtain it where the applicable regime requires this.
Where special category or sensitive data is involved, document that fact and address the additional conditions separately, rather than assuming a standard consent receipt covers those heightened requirements.
Scope claims about the receipt's role to the applicable regime, and avoid presenting it as evidence of compliance with cross-border transfer, retention, or enforcement obligations that it does not address.