Consent Record-Keeping and the Burden of Proof

Not legal advice. A reference digest of consent record-keeping guidance and standards for deliverability practitioners. Consult qualified counsel for compliance decisions.

When consent is the lawful basis (or the deliverability defence) for a send, the sender carries the burden of proof. GDPR Art. 7(1): "the controller shall be able to demonstrate that the data subject has consented." The demand is not "did they consent?" but "can you evidence it, per address, years later, to a regulator or a blocklist analyst who assumes the worst?" This article is the operational answer: the specific data points to capture, the record-structure standards converging on a common schema, and a consent-record design an ESP can implement.

It complements three neighbours: EU ePrivacy + GDPR states when consent is required and the EDPB quality standard (the "Demonstrable" row); Consent Methods ranks how addresses are acquired; GDPR and Suppression Lists covers the withdrawal/erasure record. This one is about the proof artifact that sits under all three.

Why the proof matters twice

The consent record earns its keep in two very different rooms:

• Regulatory challenge — a DPA (ICO, CNIL, etc.) or a complainant asks the controller to substantiate a lawful basis. No record ≈ no consent; the EDPB is explicit that pointing at the current website configuration is insufficient (Guidelines 05/2020 ¶108) — you must reproduce what the person actually saw and did at the time.
• Blocklist / deliverability challenge — a spam-trap hit, an FBL complaint spike, or a Spamhaus listing triggers "where did this address come from?" Being able to produce a per-address acquisition trail (source, timestamp, IP, form version, opt-in event) is often the difference between a fast delisting and a stalled one, and it is the first thing a spam-trap incident investigation calls for.

The same record answers both. Build it once.

ICO: obtain, record, manage

The UK ICO's How should we obtain, record and manage consent? guidance is the most concrete regulator statement of what to keep. (Note: the ICO flags this guidance as under review following the Data (Use and Access) Act 2025.)

The five data points to record

ICO: "you must have an effective audit trail of how and when consent was given." The record must demonstrate all five of:

#	Data point	What ICO says to keep
1	Who consented	Name of the individual, or another identifier (online username, session ID).
2	When they consented	A dated document copy, or online records including a timestamp; for oral consent, a contemporaneous note of time and date.
3	What they were told at the time	A master copy of the document / data-capture form containing the consent statement in use at that time, plus any separate privacy policy or privacy information, with version numbers and dates matching the date consent was given. For oral consent, a copy of the script used then.
4	How they consented	For written: a copy of the relevant form. For online: the data submitted plus a timestamp linking it to the relevant version of the capture form. For oral: a note made at the time.
5	Whether they have withdrawn consent	And if so, when.

Two riders: consent must be specific and granular, so "your records also need to be specific and granular to demonstrate exactly what the consent covers" — one record per purpose, not a blanket flag. And for online consent, ICO suggests "an appropriate cryptographic hash function to support data integrity" — i.e. tamper-evidence over the stored record.

The load-bearing, most-often-missed item is #3: you must be able to reproduce the exact wording, form layout, and privacy-notice version the person saw, versioned and dated. A live form is not evidence of a signup from three years ago.

Manage: keep consent under review

ICO frames consent as "a dynamic part of your ongoing relationship," not a one-off tick-and-file:

• Preference-management tools / privacy dashboards are good practice — let people access and update their own consent settings.
• Keep consents under review; refresh when anything changes (new purpose, evolved processing → original consent may no longer be specific/informed).
• Refresh interval: "If in doubt, we recommend you consider refreshing consent every two years" — longer may be justifiable; parental consent may need refreshing more often as children age into self-consent.
• If not in regular contact, send occasional reminders of the right to withdraw and how.

This "every two years" default anchors a re-permission / sunset cadence for EU/UK consent-based lists.

Consent freshness is jurisdiction- and channel-specific — there is no single universal number. The regulators' figures differ by roughly 8x because they answer different questions:

Regulator	Figure	What it actually measures
ICO (UK/EU)	refresh every ~2 years if in doubt	how long a consent record stays reliable before re-permissioning
ACMA (Australia)	consent goes stale after ~3 months unless the terms say longer	decay of telemarketing consent specifically — Consent Guidance Updates
CNIL (France)	~6 months of non-solicitation as good practice	the gap before re-asking after a non-response, in the tracking-pixel recommendation — France CNIL

Anchor cadence to the jurisdiction and channel at hand; do not treat any one of these as "the" universal freshness number.

Manage withdrawal (Art. 7(3))

Withdrawal must be as easy to give as to withdraw, "at any time" on the individual's own initiative — not opt-out-by-reply only. An "easily accessible one-step process," ideally via the same method used to consent. Good practice: offer both an anytime mechanism (dashboard) and opt-out-by-reply in every contact (the unsubscribe link / one-click header). ICO notes a third party may withdraw on the individual's behalf if authorised — the door to sectoral opt-out registers (e.g. the Fundraising Preference Service). Every withdrawal event feeds data point #5 and the suppression list.

The record-structure standards stack

A decade of work has converged on a common, machine-readable structure for a consent record. Knowing the lineage tells you which fields are considered load-bearing by consensus.

Layer	Artifact	Role
Predecessor	Kantara Consent Receipt Specification v1.1.0 (Kantara Initiative CISWG, 2017; archived rev. 13 Jun 2018)	First open JSON schema for a human-readable "receipt" of consent given. Now archived, but the direct input to the ISO work.
Notice + consent baseline	ISO/IEC 29184:2020 — Online privacy notices and consent	Requirements for the content of notices and for obtaining/withdrawing consent.
Record structure	ISO/IEC TS 27560:2023 — Privacy technologies — Consent record information structure	Technical Specification defining the field structure of a consent record and receipt; supersedes Kantara as the reference schema.
Interoperable implementation	W3C DPV (Data Privacy Vocabulary) — Consent Records and Receipts as per ISO/IEC TS 27560:2023 guide	Machine-readable vocabulary that operationalises 27560, mapping each field to a concrete term so records are interoperable/exchangeable.

ISO/IEC TS 27560:2023 (a Technical Specification, not yet a full International Standard) structures a consent record into four kinds of information: (1) the processing of personal data; (2) the privacy notice(s) where that information was provided; (3) how the data/consent was obtained; and (4) events related to consent (given, renewed, withdrawn). It separates two artifacts:

• Consent record (internal): "documentation of information about a data subject's consent… the details about the processing as well as the interactions related to consent." Held by the organisation to demonstrate validity — this is your burden-of-proof artifact.
• Consent receipt (external): "an authoritative document used to communicate the existence of a consent record or to provide information contained within it," handed to the individual. May contain all, some, or none of the record's content; 27560 mandates only a minimal header (record ID + schema version) for the receipt and says reuse record fields for the rest.

ISO/IEC 27560 field structure

Per the W3C DPV implementation guide, fields group into header, processing, and consent-event. Bold = mandatory (the standard allows profiles/schemas to change what is mandatory, e.g. an EU-GDPR profile):

Group	Mandatory fields	Optional fields
Header / metadata	Schema version (which profile applies) · Record identifier (unique, UUID-4) · Data subject identity (identifier of the individual)	Creator/publisher, creation/modification timestamps, provenance
Processing	Purpose(s) · Personal data categories · Data controller(s) · Recipients · Storage condition(s) (where/how long) · Jurisdiction(s) · Privacy notice (reference to the notice shown) · Notice language	Legal basis (beyond consent), data sources/collection methods, processing operations, processing locations, geographic restrictions, rights info, codes of conduct, DPIA, service description
Consent event	Event type (given/renewed/withdrawn) · Event state/status · Event timestamp · Validity duration (how long consent is valid) · Entity ID (who expressed consent)	Withdrawal/change method, expression method

Note how the mandatory set maps almost one-to-one onto the ICO five (who = data subject identity + entity ID; when = event timestamp; what-they-were-told = privacy notice + language; how = collection method + event type; withdrawn = event type/status/timestamp) — and adds the processing detail (purpose, data categories, controller, recipients, retention, jurisdiction) that makes the record specific and granular.

The Kantara receipt fields (predecessor reference)

The Kantara v1.1.0 JSON (still the most concrete field list many tools implement) — a record of authority granted by a PII Principal to a PII Controller:

Field	Captures
version	Schema version, e.g. KI-CR-v1.1.0
jurisdiction	Applicable jurisdiction(s)
consentTimestamp	When consent was obtained (Unix time)
collectionMethod	How consent was gathered
consentReceiptID	Unique receipt ID (SHOULD be UUID-4)
publicKey	Key for verifying receipt integrity
language	Receipt language (ISO 639-1)
piiPrincipalId	Identifier of the person consenting
piiControllers[]	Controller identity: piiController, contact, address (streetAddress, addressCountry), email, phone
policyUrl	Link to the privacy policy in force
services[] → purposes[]	Per purpose: purpose, purposeCategory, consentType (EXPLICIT/IMPLICIT/N/A), piiCategory, primaryPurpose (bool), termination (when consent ends), thirdPartyDisclosure (bool), thirdPartyName
sensitive / spiCat[]	Whether special-category data is involved, and which categories

What the research says (arxiv 2405.04528)

Pandit, Lindquist & Krog, Implementing ISO/IEC TS 27560:2023 Consent Records and Receipts for GDPR and DGA (2024), is the reference implementation study. Findings relevant here:

• 27560's abstract structure is not, by itself, machine-interoperable — two organisations can produce 27560-conformant records that don't exchange. The paper closes that gap by mapping every field to the W3C DPV vocabulary, yielding records/receipts that are genuinely interoperable and validatable.
• It aligns 27560 (record structure) with ISO/IEC 29184 (notice/consent content) and GDPR obligations, showing the notice-version reference (ICO data point #3) is a first-class field, not an afterthought.
• It extends the same machinery to the EU Data Governance Act, i.e. the record structure generalises beyond marketing consent to data-sharing/altruism scenarios.

Practical takeaway for an ESP: adopt the 27560 field set as your record schema and DPV terms as the wire format if you need records that survive controller-to-processor handoff or a regulator's tooling. If you only need internal proof, the field set alone is enough.

An ESP-implementable consent-record schema

Synthesising ICO's five points, the 27560 mandatory fields, and deliverability's own needs, a per-consent-event record an ESP (or its customer, the controller) should persist:

Field	Source of requirement	Example
record_id	27560 header (UUID-4)	a6f58318-72e6-46a2-bfd7-f36d795e30cd
schema_version	27560 header	esp-consent-v1
subject_id	ICO #1 / 27560	email hash or account ID + raw email
consent_event	27560 event type	given | renewed | withdrawn
consent_status	27560 event state	active | withdrawn | expired
timestamp (UTC)	ICO #2 / 27560	2026-01-14T09:31:07Z
purpose (one row per purpose)	ICO granularity / 27560	newsletter, product_updates, third_party_offers
consent_type	Kantara / EDPB	explicit | soft-opt-in
collection_method	ICO #4 / 27560	web_form_double_opt_in | checkout_checkbox | api
source_url / form ID	deliverability	https://…/signup
notice_ref + notice_version + notice_date	ICO #3 (load-bearing)	privacy-policy@v7, 2025-11-02
form_snapshot_ref	ICO #3	hash/pointer to stored HTML of the exact form + consent wording
submitted_data	ICO #4	the field values the user actually submitted
ip_address + user_agent	deliverability proof	203.0.113.9
double_opt_in_confirmed_at + confirming IP	anti-subscription-bombing	2026-01-14T09:44:12Z
controller_identity	27560 / Kantara	ESP customer legal name + contact
jurisdiction	27560	GB, DE, …
withdrawn_at + withdrawal_method	ICO #5 / Art. 7(3)	2026-06-01T…, one_click_unsubscribe
integrity_hash	ICO (crypto hash)	SHA-256 over the frozen record

Design notes:

• One record per (subject, purpose, event). A renewal or a withdrawal appends a new event row; never overwrite — the history is the audit trail. Consent state at any moment is the latest event per (subject, purpose).
• Freeze the notice, don't reference the live one. Store the versioned form/notice snapshot (or a content hash of it) so #3 is reproducible. Version privacy policies and consent copy as immutable artifacts.
• Double opt-in produces the strongest record: the confirmation click yields a second timestamp+IP proving the address-holder acted, which simultaneously defeats subscription-bombing, keeps spam traps off the list, and is the consent method regulators treat as proof (Germany effectively requires it).
• Multi-tenant: the ESP holds the record on behalf of the controller (its customer). Under GDPR the customer is the controller and must be able to retrieve/export it — align this with the processor obligations and the contract-end handoff in GDPR and Suppression Lists.

Retention

• Keep proof as long as you process on that consent (ICO), and a defensible period after, to answer late complaints and limitation-period claims — but "no longer than needed" (EDPB). Set an explicit retention rule per record class rather than keeping forever.
• Withdrawal ≠ delete the record. After withdrawal you stop processing for that purpose, but the consent-and-withdrawal record is itself needed to prove you honoured the withdrawal and to keep the address suppressed. This is the erasure-vs-suppression tension resolved in GDPR and Suppression Lists: the suppression/withdrawal record is retained on a distinct legal basis (compliance/accountability), separate from the marketing consent.
• Separate the two clocks: active-consent proof retention (while processing) vs. withdrawal/suppression retention (indefinite-until-address-dead, to prevent re-mailing).

Consent-record retention by jurisdiction

Distinct from consent freshness (the re-permission cadence reconciled above): this row is about how long to keep the proof-of-consent artifact itself. No regime sets a fixed clock for the record — each ties retention to the duration of processing plus a defence/limitation tail. Anchor to the jurisdiction at hand:

Regime	What it implies for how long to keep proof-of-consent
GDPR / UK ICO (EU ePrivacy + GDPR, UK PECR)	Keep proof for as long as you process on that consent, plus a defensible period after to answer late complaints and limitation-period claims — but "no longer than needed." No fixed number.
France / CNIL (France CNIL)	Same principle (Art. 7(1)): retain evidence for the whole period the data are used, and long enough afterward to respond to an audit. No fixed number.
Canada / CASL (CASL)	No prescribed period; the onus of proof is on the sender and express consent does not expire. The CRTC's record-keeping advisory plus the 3-year limitation period for proceedings mean records should be kept while consent is relied on and for at least ~3 years beyond last reliance.
US / CAN-SPAM (CAN-SPAM)	Opt-out regime — no consent to prove, so no consent-record retention. The artifact to retain instead is the opt-out/suppression record, kept indefinitely so the address stays suppressed (see GDPR and Suppression Lists).

The through-line: consent-record retention is principle-based (retain while processing + a limitation/defence tail), not a fixed duration; CASL's 3-year limitation window is the one concrete anchor.

Producing evidence on demand

When a DPA, complainant, or blocklist asks "prove consent for x@example.com":

1. Resolve subject_id → pull the full event history for that address (given, renewals, withdrawal).
2. Return, for the relevant event: who (subject_id), when (timestamp, and double-opt-in confirmation timestamp), what they were told (the frozen notice_version + form_snapshot), how (collection_method + submitted_data + IP/UA), and withdrawal status.
3. For a blocklist / trap-hit, add the acquisition context: source_url, campaign, the opt-in and confirmation IPs, and where the address sits in the suppression/hygiene lifecycle.
4. Verify integrity_hash to show the record wasn't altered.

If any of who/when/what-told/how/withdrawn is missing, you cannot meet the burden of proof — which is the operational reason to capture all five at signup, not reconstruct them under challenge. A record you have to rebuild after the fact is not evidence.

Related

• EU ePrivacy + GDPR — Email Marketing — when consent is required; the EDPB "Demonstrable" (Art. 7(1)) and "Withdrawable" (Art. 7(3)) standard
• Consent Methods and the List-Quality Spectrum — how addresses are acquired; why double opt-in yields the strongest record
• GDPR and ESP Suppression Lists — the withdrawal/erasure record and the retain-to-suppress resolution
• ESP Processor Obligations — controller/processor split for records held on a customer's behalf
• Right to Object & Erasure · Suppression-List Architecture · Spam-Trap Incident Response