# Consent Record-Keeping and the Burden of Proof

> What to capture and retain to prove consent to a regulator or blocklist: the ICO's obtain/record/manage data points, the emerging record structure standards (Kantara Consent Receipt → ISO/IEC 29184 → ISO/IEC TS 27560 → W3C DPV), and an ESP-implementable consent-record schema with retention and evidence-production guidance.

Source: emailmarketing.net — https://emailmarketing.net/learn/compliance/consent-record-keeping

> **Not legal advice.** A summary of guidance and standards on keeping consent records, for deliverability practitioners. Consult qualified counsel for compliance decisions.

If you rely on consent as the lawful basis for a send, or as your defence when deliverability is questioned, **you carry the burden of proof.** GDPR Art. 7(1) says: "the controller shall be able to demonstrate that the data subject has consented." The question is not only whether the person consented. It is whether you can prove it, for each address, years later, to a regulator or to a blocklist analyst who assumes the worst.

The sections below set out the specific data points to capture, the standards for record structure that are converging on a common schema, and a consent record that an ESP can implement.

[EU ePrivacy + GDPR](https://emailmarketing.net/learn/compliance/eu-eprivacy-and-gdpr-email-marketing) explains when consent is required and the quality standard of the European Data Protection Board (EDPB), including the "Demonstrable" row. [Consent Methods](https://emailmarketing.net/learn/list-management/consent-methods) ranks the ways addresses are acquired. [GDPR and Suppression Lists](https://emailmarketing.net/learn/compliance/gdpr-and-suppression-lists) covers the record of withdrawal and erasure. The **proof record** described here sits under all three.

## Why the proof matters twice

A consent record is tested in two very different settings:

- **A regulatory challenge.** A data protection authority (DPA) such as the ICO or the CNIL, or a complainant, asks the controller to show its lawful basis. Without a record, there is effectively no consent. The EDPB states explicitly that pointing to the current configuration of the website is not enough (Guidelines 05/2020 ¶108): you must reproduce what the person actually saw and did at the time.
- **A blocklist or deliverability challenge.** A [spam-trap hit](https://emailmarketing.net/learn/reference/spam-traps), a [spike in feedback loop (FBL) complaints](https://emailmarketing.net/learn/list-management/complaint-feedback-loops) or a Spamhaus listing raises the question "where did this address come from?" A record of how each address was acquired (source, timestamp, IP address, form version, opt-in event) often makes the difference between a fast [delisting](https://emailmarketing.net/learn/reference/spamhaus-listings-deep-dive) and a stalled one. It is also the first thing a [spam-trap incident](https://emailmarketing.net/learn/esp-operations/spam-trap-incident-response) investigation asks for.

The same record answers both. Build it once.

## ICO: obtain, record, manage

The UK Information Commissioner's Office (ICO) guidance *How should we obtain, record and manage consent?* is the most concrete statement by a regulator of what to keep. The ICO notes that this guidance is under review following the Data (Use and Access) Act 2025.

### The five data points to record

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

| # | Data point | What the ICO says to keep |
|---|---|---|
| 1 | **Who consented** | The individual's name, or another identifier (an online username, a session ID). |
| 2 | **When they consented** | A dated copy of the document, or online records that include a **timestamp**. For oral consent, a note of the time and date made at the time. |
| 3 | **What they were told at the time** | A **master copy** of the document or data-capture form containing the consent statement in use at that time, together with 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 at the time. |
| 4 | **How they consented** | For written consent, a copy of the relevant form. For online consent, **the data submitted** and a timestamp linking it to the relevant version of the capture form. For oral consent, a note made at the time. |
| 5 | **Whether they have withdrawn consent** | And if so, **when**. |

Two further points apply. Consent must be specific and granular, so "your records also need to be specific and granular to demonstrate exactly what the consent covers": keep one record for each purpose, not a single blanket flag. For online consent, the ICO suggests "an appropriate cryptographic hash function to support data integrity", which makes any tampering with the stored record detectable.

The item that matters most, and is most often missed, is **#3**. You must be able to reproduce the exact wording, form layout and privacy notice version that the person saw, with versions and dates. A live form is not evidence of a signup from three years ago.

### Manage: keep consent under review

The ICO describes consent as "a dynamic part of your ongoing relationship," not something you collect once and file away:

- **Preference management tools and privacy dashboards** are good practice. They let people see and update their own consent settings.
- **Keep consents under review, and refresh them when anything changes.** A new purpose or a change in processing can mean the original consent is no longer specific or informed.
- **Refresh interval:** "If in doubt, we recommend you consider refreshing consent **every two years**." A longer interval may be justifiable. Parental consent may need refreshing more often, as children grow old enough to consent for themselves.
- If you are not in regular contact with people, send **occasional reminders** of their right to withdraw and of how to do it.

This default of "every two years" sets a basis for how often to ask for permission again, or to apply a [sunset policy](https://emailmarketing.net/learn/operations/list-hygiene-and-sunset-policies), for consent-based lists in the **EU and UK**.

**How long consent stays fresh depends on the jurisdiction and the channel. 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 and EU) | refresh **every ~2 years** if in doubt | how long a consent record stays reliable before you ask for permission again |
| **ACMA** (Australia) | consent goes stale after **~3 months** unless the terms say longer | how **telemarketing** consent decays, specifically. See [Consent Guidance Updates](https://emailmarketing.net/learn/compliance/consent-guidance-updates#australia--acmas-2024-statement-on-consent-expectations) |
| **CNIL** (France) | **~6 months** without asking again, as good practice | the gap before asking again after someone does not respond, in the recommendation on tracking pixels. See [France CNIL](https://emailmarketing.net/learn/compliance/france-cnil-email#collecting-pixel-consent) |

Set your cadence for the jurisdiction and channel in question. Do not treat any one of these figures as the universal freshness number.

### Manage withdrawal (Art. 7(3))

Withdrawing consent must be **as easy as giving it**, "at any time" and on the individual's own initiative, not only by replying to a message. The ICO asks for an "easily accessible one-step process," ideally using the same method the person used to consent. Good practice is to offer both a mechanism available at any time (such as a dashboard) **and** a way to opt out in every message (the [unsubscribe link](https://emailmarketing.net/learn/list-management/list-unsubscribe) or the one-click header). The ICO notes that a third party may withdraw consent on the individual's behalf if authorised, which opens the way to sector-wide opt-out registers such as the Fundraising Preference Service. Every withdrawal event feeds data point #5 and the [suppression list](https://emailmarketing.net/learn/esp-operations/suppression-list-architecture).

## The standards for record structure

Ten years of work have produced a common, machine-readable structure for a consent record. Knowing how the standards developed tells you which fields there is consensus on.

| Layer | Document | Role |
|---|---|---|
| Predecessor | **Kantara Consent Receipt Specification v1.1.0** (Kantara Initiative CISWG, 2017; archived rev. 13 Jun 2018) | The first open JSON schema for a human-readable "receipt" for consent given. Now archived, but the direct input to the ISO work. |
| Baseline for notices and consent | **ISO/IEC 29184:2020**, *Online privacy notices and consent* | Requirements for the content of notices and for obtaining and withdrawing consent. |
| Record structure | **ISO/IEC TS 27560:2023**, *Privacy technologies — Consent record information structure* | A Technical Specification that defines the field structure of a consent **record** and **receipt**. It replaces Kantara as the reference schema. |
| Interoperable implementation | **W3C DPV** (Data Privacy Vocabulary), guide *Consent Records and Receipts as per ISO/IEC TS 27560:2023* | A machine-readable vocabulary that puts 27560 into practice. It maps each field to a concrete term, so that records can be exchanged between systems. |

**ISO/IEC TS 27560:2023** is a *Technical Specification*, not yet a full International Standard. It organizes a consent record into four kinds of information: (1) the processing of personal data; (2) the privacy notice or notices through which that information was provided; (3) how the data or consent was obtained; and (4) events related to consent (given, renewed, withdrawn). It distinguishes two documents:

- **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." The organisation keeps it to show that consent is valid. This is the record that meets your burden of proof.
- **Consent receipt** (external): "an authoritative document used to communicate the existence of a consent record or to provide information contained within it," given to the individual. It may contain all, some or none of the record's content. 27560 requires only a minimal header for the receipt (the record ID and the schema version) and says to reuse record fields for the rest.

### ISO/IEC 27560 field structure

According to the W3C DPV implementation guide, the fields fall into three groups: **header**, **processing** and **consent event**. Bold marks a mandatory field. The standard allows profiles or schemas to change which fields are mandatory, for example a profile for the EU GDPR.

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

The mandatory set maps almost one to one onto the ICO's five data points. "Who" is the data subject identity and the entity ID. "When" is the event timestamp. "What they were told" is the privacy notice and its language. "How" is the collection method and the event type. "Withdrawn" is the event type, status and timestamp. The standard adds the processing detail (purpose, data categories, controller, recipients, retention, jurisdiction) that makes the record specific and granular.

### The Kantara receipt fields (the earlier reference)

The Kantara v1.1.0 JSON schema is still the most concrete list of fields that many tools implement. It records the authority that a **PII Principal** grants 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 the receipt's 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[]` | For each purpose: `purpose`, `purposeCategory`, `consentType` (EXPLICIT, IMPLICIT or 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 study on implementation. Its relevant findings:

- The abstract structure of 27560 does not, on its own, make records machine-interoperable. Two organisations can produce records that conform to 27560 and still cannot exchange them. The paper closes that gap by mapping every field to the **W3C DPV** vocabulary, which produces records and receipts that are truly interoperable and can be validated.
- It aligns 27560 (the record structure) with **ISO/IEC 29184** (the content of notices and consent) and with GDPR obligations. This shows that the reference to the notice version (ICO data point #3) is a core field, not an afterthought.
- It applies the same approach to the EU **Data Governance Act (DGA)**, which shows that the record structure works beyond marketing consent, for data sharing and data altruism.

In practice for an ESP: adopt the **27560 field set as your record schema, and DPV terms as the exchange format**, if your records must survive a handoff between controller and processor or be read by a regulator's tools. If you only need proof for internal use, the field set alone is enough.

## A consent record schema an ESP can implement

Combining the ICO's five points, the mandatory fields of 27560 and what deliverability work needs, an ESP (or its customer, the controller) should store this record for each consent event:

| 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, plus the raw email address |
| `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` or form ID | deliverability | `https://…/signup` |
| `notice_ref`, `notice_version` and `notice_date` | ICO #3 (essential) | `privacy-policy@v7`, `2025-11-02` |
| `form_snapshot_ref` | ICO #3 | a hash of, or pointer to, the stored HTML of the exact form and consent wording |
| `submitted_data` | ICO #4 | the field values the user actually submitted |
| `ip_address` and `user_agent` | proof for deliverability | `203.0.113.9` |
| `double_opt_in_confirmed_at` and the confirming IP address | defence against [subscription bombing](https://emailmarketing.net/learn/esp-operations/subscription-bombing) | `2026-01-14T09:44:12Z` |
| `controller_identity` | 27560, Kantara | the ESP customer's legal name and contact details |
| `jurisdiction` | 27560 | `GB`, `DE`, … |
| `withdrawn_at` and `withdrawal_method` | ICO #5, Art. 7(3) | `2026-06-01T…`, `one_click_unsubscribe` |
| `integrity_hash` | ICO (cryptographic hash) | SHA-256 over the frozen record |

Design notes:

- **Keep one record per combination of subject, purpose and event.** A renewal or a withdrawal adds a new event row. Never overwrite a row, because the history is the audit trail. The consent state at any moment is the latest event for that subject and purpose.
- **Freeze the notice instead of referring to the live one.** Store the versioned snapshot of the form and notice (or a hash of its content) so that data point #3 can be reproduced. Keep versions of privacy policies and consent wording as documents that never change.
- **Double opt-in produces the strongest record.** The confirmation click gives a second timestamp and IP address, which prove that the holder of the address acted. The same step defeats [subscription bombing](https://emailmarketing.net/learn/esp-operations/subscription-bombing), keeps [spam traps](https://emailmarketing.net/learn/reference/spam-traps) off the list, and is the [consent method](https://emailmarketing.net/learn/list-management/consent-methods) that regulators accept as proof (Germany effectively requires it).
- **Multi-tenant platforms:** 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 or export the record. Align this with the [processor obligations](https://emailmarketing.net/learn/compliance/esp-processor-obligations) and with the handoff at the end of the contract described in [GDPR and Suppression Lists](https://emailmarketing.net/learn/compliance/gdpr-and-suppression-lists).

## Retention

- **Keep the proof for as long as you process data on that consent** (ICO), and for a defensible period afterwards to answer late complaints and claims within limitation periods, but "no longer than needed" (EDPB). Set an explicit retention rule for each class of record rather than keeping everything forever.
- **Withdrawal does not mean deleting the record.** After a withdrawal you stop processing for that purpose, but you need the record of consent and withdrawal itself, to prove that you honoured the withdrawal and to keep the address suppressed. [GDPR and Suppression Lists](https://emailmarketing.net/learn/compliance/gdpr-and-suppression-lists) resolves this tension between erasure and suppression: the suppression or withdrawal record is kept on a separate legal basis (compliance and accountability), apart from the marketing consent.
- **Keep the two clocks separate.** One is how long you keep proof of active consent (while you process). The other is how long you keep the withdrawal or suppression record (indefinitely, until the address no longer exists, to prevent mailing it again).

### Consent-record retention by jurisdiction

This is different from how long consent stays fresh (the cadence for asking permission again, compared above). It is about how long to keep the **proof of consent itself**. No regime sets a fixed period for the record. Each ties retention to the duration of processing, plus a further period for defence or limitation. Follow the rule for the jurisdiction in question:

| Regime | What it implies for how long to keep proof of consent |
|---|---|
| **GDPR / UK ICO** ([EU ePrivacy + GDPR](https://emailmarketing.net/learn/compliance/eu-eprivacy-and-gdpr-email-marketing), [UK PECR](https://emailmarketing.net/learn/compliance/uk-pecr-email-marketing)) | Keep proof for as long as you process data on that consent, and for a defensible period afterwards to answer late complaints and claims within limitation periods, but "no longer than needed." No fixed number. |
| **France / CNIL** ([France CNIL](https://emailmarketing.net/learn/compliance/france-cnil-email)) | The same principle (Art. 7(1)): keep evidence for the whole period the data are used, and long enough afterwards to respond to an audit. No fixed number. |
| **Canada / CASL** ([CASL](https://emailmarketing.net/learn/compliance/casl)) | No prescribed period. The burden of proof is on the sender, and express consent does not expire. The record-keeping advisory of the Canadian Radio-television and Telecommunications Commission (CRTC), together with the **3-year limitation period** for proceedings, means you should keep records while you rely on the consent and for at least ~3 years after you last rely on it. |
| **US / CAN-SPAM** ([CAN-SPAM](https://emailmarketing.net/learn/compliance/can-spam)) | An opt-out regime: there is no consent to prove, so no consent record to keep. Keep the **opt-out or suppression** record instead, indefinitely, so that the address stays suppressed (see [GDPR and Suppression Lists](https://emailmarketing.net/learn/compliance/gdpr-and-suppression-lists)). |

The common thread is that retention of consent records follows a principle (keep them while you process, plus a period for limitation or defence), not a fixed duration. The 3-year limitation period under CASL is the one concrete figure.

## Producing evidence on demand

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

1. Look up the `subject_id` and retrieve the full event history for that address (given, renewals, withdrawal).
2. For the relevant event, return **who** (subject_id), **when** (the timestamp, and the timestamp of the double opt-in confirmation), **what they were told** (the frozen `notice_version` and `form_snapshot`), **how** (collection_method, submitted_data, IP address and user agent), and the **withdrawal status**.
3. For a blocklisting or a trap hit, add the context of acquisition: source_url, the campaign, the opt-in and confirmation IP addresses, and where the address stands in the [suppression](https://emailmarketing.net/learn/esp-operations/suppression-list-architecture) and hygiene lifecycle.
4. Verify the `integrity_hash` to show that the record was not altered.

If any of who, when, what they were told, how, or withdrawal is missing, you cannot meet the burden of proof. That is the practical reason to capture all five at signup rather than reconstruct them when challenged. A record you have to rebuild after the fact is not evidence.

## Related articles

- [EU ePrivacy + GDPR — Email Marketing](https://emailmarketing.net/learn/compliance/eu-eprivacy-and-gdpr-email-marketing), including the EDPB standards "Demonstrable" (Art. 7(1)) and "Withdrawable" (Art. 7(3))
- [Consent Methods and the List-Quality Spectrum](https://emailmarketing.net/learn/list-management/consent-methods), including why double opt-in gives the strongest record
- [GDPR and ESP Suppression Lists](https://emailmarketing.net/learn/compliance/gdpr-and-suppression-lists)
- [ESP Processor Obligations](https://emailmarketing.net/learn/compliance/esp-processor-obligations), on records held for a customer
- [Right to Object & Erasure](https://emailmarketing.net/learn/compliance/right-to-object-and-erasure)
- [Suppression-List Architecture](https://emailmarketing.net/learn/esp-operations/suppression-list-architecture)
- [Spam-Trap Incident Response](https://emailmarketing.net/learn/esp-operations/spam-trap-incident-response)