When a regulator, a court or a data subject asks you to prove that someone consented, a tick in a database column is not evidence. GDPR Article 7(1) puts the burden on the controller to demonstrate consent, and that means being able to reconstruct who agreed, to which purposes, on which notice, by what action, and whether they later withdrew. This guide is about that evidence layer: designing a consent record schema, using the ISO/IEC TS 27560 consent record and receipt structure, protecting records against tampering, and deciding how long to keep them. It is written for privacy engineers, data protection officers and the security teams who run the systems that hold the records. Banner design, cookie categories and CMP selection are covered in the Consent Management Guide, and choosing a lawful basis in Consent vs Legitimate Interest; this page does not repeat them.
Key takeaways
- Evidence, not a flag. A consent record must link a person (or pseudonymous identifier) to a timestamped action, the exact notice version they saw, the purposes covered and every later change.
- ISO/IEC TS 27560 gives you a schema. The 2023 Technical Specification defines an extensible structure for consent records and receipts, so you can exchange consent between systems instead of inventing fields per product.
- Record and receipt are different things. The record is your internal, authoritative evidence; the receipt communicates that record (or its contents) to the person or to another party.
- Integrity is a security requirement. Records you cannot show are untampered are weak evidence, so use append-only storage, hashing and restricted write access.
- Retention follows the processing. The ICO advises keeping consent evidence for as long as you process on that consent; withdrawal and suppression records need their own justification and notice.
What the law asks you to prove
Consent under the UK GDPR and EU GDPR must be freely given, specific, informed and unambiguous (Article 4(11)). Article 7 adds four conditions that directly shape what a record must hold.
| Requirement | Source | What the record must allow you to show |
|---|---|---|
| Controller must be able to demonstrate consent | GDPR Art. 7(1), Recital 42 | That this person gave this consent, at this time, by this action |
| Request clearly distinguishable from other matters | Art. 7(2) | The notice and form version actually presented, separate from terms and conditions |
| Right to withdraw at any time, as easy to withdraw as to give | Art. 7(3) | The withdrawal event, its channel and time, and that processing stopped |
| Freely given, not bundled with a contract unless necessary | Art. 7(4), Recital 43 | Which purposes were optional and that refusal did not block the service |
| Explicit consent for special category data | Art. 9(2)(a) | An express statement or action, for example a confirming email or signed form |
| Parental consent for children's online services | Art. 8 | Who gave consent on the child's behalf and how that was checked |
The EDPB's summary of its consent guidelines (Guidelines 05/2020, adopted 4 May 2020) states plainly that data controllers are responsible for demonstrating that valid consent was obtained, and that once consent is withdrawn the related processing must stop. Neither the GDPR nor the EDPB prescribes a record format, which is where ISO/IEC TS 27560 helps.
The minimum record: the ICO's five questions
The ICO's guidance on recording consent lists what to keep, and it is a good test for any schema:
- Who consented: a name or other identifier such as an online username or session ID.
- When: a dated document, online timestamp, or a note of date and time for oral consent.
- What they were told: a master copy of the consent statement or form in use at the time, and any privacy notice, with version numbers and dates matching the consent. For oral consent, the script.
- How they consented: the signed form, or for online consent the submitted data with a timestamp linking it to the form version; a contemporaneous note for oral consent.
- Whether and when they withdrew.
The ICO also expects records to be granular, matching the scope of each consent. One boolean for "marketing" cannot show consent to email but not phone, or to one brand but not its affiliates.
ISO/IEC TS 27560: structure of a consent record
ISO/IEC TS 27560:2023, Privacy technologies: Consent record information structure, is a Technical Specification (edition 1, August 2023) from ISO/IEC JTC 1/SC 27. ISO describes it as a standardised, extensible format for recording consent, with three aims: giving individuals a record of their consent, enabling consent information to be exchanged between systems, and managing recorded consent through its lifecycle. As of November 2026 ISO marks it as published and due for future revision, so check for a new edition before committing to field-level details. It sits alongside ISO/IEC 29184:2020 on online privacy notices and consent, which covers how the notice is presented.
The standard text is paid for. The W3C Data Privacy Vocabularies and Controls Community Group (DPVCG) has published an implementation guide (a Final Community Group Report dated 15 February 2026, not a W3C Standard) that sets out the fields and maps them to the DPV vocabulary. The field groups below follow that guide.
| Group | Fields | Design notes |
|---|---|---|
| Record metadata (header) | Schema Version, Record Identifier, Data Subject, Additional Metadata | Use a stable, unique record ID and a pseudonymous subject identifier, not a raw email address |
| Notice | Notice, Notice Language | Reference an immutable, versioned copy of the consent notice, not a URL that changes |
| Processing | Process, Purpose, Personal Data (type, identifier, necessity, sensitive and special category), Processing Operations (data sources, storage, processing and geographic conditions), Data Controller(s), Legal Basis, Recipients, Consent Change and Withdrawal, Jurisdiction(s), Rights, Service(s), Code of conduct(s), Impact assessment(s) | One purpose per processing entry keeps consent specific; record recipients so withdrawal can be propagated |
| Parties (entity) | Name, Identifier, Role, Contact (postal address, email, phone), URL | Covers controllers, joint controllers and, where relevant, a parent or guardian expressing consent |
| Consent event | Consent Type, Consent State, Event Time, Event Duration, Expression by Entity, Expression Method | Each change is a new event; Event Duration lets you set expiry and trigger refresh |
Consent states
The DPVCG guide lists these states: ConsentRequested, ConsentGiven, RenewedConsentGiven, ConsentRefused, ConsentWithdrawn, ConsentExpired, ConsentTerminated and ConsentInvalidated. Only given and renewed consent permit processing. Modelling refusals and requests as well as grants matters: a refusal record shows the person was asked and declined, which you need to avoid repeatedly re-prompting, and an invalidated state lets you mark consents gathered on a defective form without deleting the history. Event times are recorded in ISO 8601 UTC.
Records versus receipts
In the guide's terms, a consent record documents a person's consent and the events around it, and is the primary internal evidence. A consent receipt communicates that a record exists or carries its contents. The receipt header holds Schema Version, Record Identifier, the Associated Consent Record and a Creation Timestamp; beyond the identifier and schema version, what the receipt contains is left to the implementer. The older Kantara Initiative Consent Receipt Specification (version 1.1.0, 2019) pursued the same idea and is a useful reference for teams with legacy receipts.
| Option | Suits | Trade-off |
|---|---|---|
| Internal record only, confirmation email to the person | Most organisations starting out | Lowest effort; the person holds no verifiable copy |
| Record plus human-readable receipt in the account area | Consumer services with logged-in users | Good transparency; receipt must stay in sync with withdrawals |
| Machine-readable signed receipt (JSON-LD) | Data sharing ecosystems, research consent, health | Interoperable and verifiable; needs key management and agreed formats among parties |
| Receipt held in the person's wallet | Emerging ecosystems using verifiable credentials | Strong user control; immature tooling and governance |
Designing the record store
- Version every notice: store each consent text, form and privacy notice as an immutable artefact with an ID and content hash. Records point at that ID. If the text changes, it is a new version, and the change may require fresh consent.
- Append, never update: each grant, refusal, withdrawal or renewal is a new event row. Current state is derived. The DPVCG guide describes linking each record version to its predecessor for exactly this reason.
- Pseudonymise the subject: the guide's own example uses a hashed email as the identifier and advises against using the email directly, as it does not suit data protection by design. Keep the lookup to the real identity in your customer system. See the Pseudonymisation Techniques Guide; use a keyed hash, since an unkeyed hash of an email is easily reversed by guessing.
- Capture the method: record expression method (checkbox, toggle, signed form, verbal script, API call from a partner) and the channel, plus enough context to show it was an affirmative action rather than a pre-ticked box.
- Keep sensitive data out: ISO/IEC TS 27560 recommends not placing sensitive information directly in records and receipts. Record "consented to processing of health data for purpose X", not the health data.
- Propagate state: publish consent changes as events to every system and recipient listed in the record, and log acknowledgement, so you can show processing stopped after withdrawal.
Protecting record integrity
Consent records are audit evidence, so they deserve the controls you apply to security logs. The DPVCG guide points to cryptographic hashes to show information has not changed, access control so only authorised modifications occur, and digital signatures on receipts where immutability and non-repudiation are needed.
- Write path: only the consent service writes events, through an authenticated API; no direct database writes by marketing tools or analysts.
- Tamper evidence: chain event hashes or anchor daily digests in a separate system, and use storage with object lock or WORM retention for the event log.
- Service identities: the CMP, CRM and partner integrations write consent with API keys or OAuth clients. Scope each to write only its own channel's events, rotate keys and log every call. A compromised integration key that can forge consent is a quiet way to manufacture lawful-looking processing.
- Read access: DPO, legal and the DSAR team need search; most staff need only the derived current state through an API.
- Clock integrity: timestamps are only as good as the server clock; use synchronised time and record server time, not client time.
Retention, refresh and withdrawal records
| Record type | Retention driver | Practice |
|---|---|---|
| Active consent and its event history | ICO: keep evidence for as long as you process on the consent | Retain the full chain while any processing relies on it |
| History after processing ends | Defence of legal claims, regulator enquiries | Set a fixed period in your retention schedule, then delete or anonymise; document the reason |
| Withdrawal and suppression entries | Need to honour the objection (for example not re-marketing) | ICO: no consent needed, but tell people you keep them, why, and your lawful basis; keep the minimum identifier |
| Notice versions | Needed to interpret any retained record | Keep as long as any record that references them |
Consent does not last forever in practice. The ICO recommends reviewing consents and refreshing them when processing or purposes change, and says that if in doubt you should consider refreshing every two years, more often for parental consent as a child grows. Use Event Duration to drive expiry and re-prompt workflows, and record the outcome as RenewedConsentGiven, ConsentRefused or ConsentExpired. Fold these periods into your Data Retention and Disposal Policy Template.
How to implement
- Inventory: list every place consent is collected (web, app, call centre, events, partners) and every system that stores a consent flag. Your Record of Processing Activities (ROPA) Template should show which processing relies on consent.
- Gap test: pick ten real customers and try to answer the ICO's five questions for each purpose. Most programmes fail first on "what were they told".
- Define the schema: adopt the ISO/IEC TS 27560 field groups, map existing data into them, and note fields you cannot backfill.
- Build the service: a central consent API with append-only storage, notice versioning and event publishing; pilot on one channel.
- Migrate and mark: import legacy consents with a provenance flag; where evidence is missing, mark records invalidated and plan re-permissioning rather than inventing data.
- Test: run withdrawal tests end to end (withdraw, then confirm downstream suppression within your target time) and sample-audit records monthly.
- Roll back: keep legacy flags read-only in parallel until reconciliation shows parity; never delete legacy evidence during migration.
A small organisation can meet the ICO's expectations with a well-designed table, versioned notices and a confirmation email. Receipts, signatures and cross-party exchange pay off where consent is shared between controllers, in research and health settings, or at high volume.
Detection and measurement
- Integrity alerts: any write to the event store outside the consent service, hash chain breaks, or bulk state changes from one integration.
- Drift: processing jobs that run against subjects whose derived state is not given or renewed.
| Metric | Target |
|---|---|
| Sampled records answering all five ICO questions | 100% |
| Consent records linked to an immutable notice version | 100% |
| Median time from withdrawal to downstream suppression | Defined and met (for example under 24 hours) |
| Consents past their refresh date still used for processing | Zero |
| Integrations with write scope limited to their own channel | 100% |
Framework mapping
| Area | NIST SP 800-53 Rev 5 | Other references |
|---|---|---|
| Obtaining and recording consent | PT-4 Consent, PT-2 Authority to Process Personally Identifiable Information | GDPR Art. 7; ISO/IEC TS 27560; ISO/IEC 27701 |
| Notice versions | PT-5 Privacy Notice | ISO/IEC 29184; GDPR Art. 13 |
| Record integrity and non-repudiation | AU-9 Protection of Audit Information, AU-10 Non-repudiation | ISO/IEC 27001:2022 A.5.33 Protection of records |
| Retention | AU-11 Audit Record Retention, SI-12 Information Management and Retention | GDPR Art. 5(1)(e); ISO/IEC 27001:2022 A.5.34 Privacy and protection of PII |
For the management system around this, see the ISO/IEC 27701 Privacy Information Management Guide.
Common failure patterns
- Overwriting state: a single "opted_in" column updated in place, so the original grant and its notice are lost the first time someone changes a preference.
- Notice by URL: records point at a privacy page that has since changed, so no one can show what the person actually saw.
- Bundled consent: one record for several purposes, which fails the specificity test and makes partial withdrawal impossible to evidence.
- Withdrawal stops at the CMP: the consent store updates but the CRM, email platform and ad audiences keep processing because state changes are not propagated.
- Backfilled evidence: legacy lists imported with an invented consent date, which looks worse under scrutiny than an honest invalidated flag.
- Raw identifiers everywhere: email addresses and phone numbers copied into every record and receipt, widening the breach impact of the consent store itself.
Practitioner checklist
- Map every consent collection point and every system holding consent state.
- Adopt the ISO/IEC TS 27560 field groups as your schema baseline.
- Version and hash every notice and form; link each record to the version shown.
- Store consent as append-only events with a derived current state.
- Use a keyed pseudonymous subject identifier in records and receipts.
- Restrict write access to the consent service; scope integration keys per channel.
- Propagate withdrawals to all recipients and measure time to suppression.
- Set expiry and refresh rules, and retention periods for history and suppression lists.
- Sample-audit records against the ICO's five questions every month.
Standards and references
- ISO: ISO/IEC TS 27560:2023 Privacy technologies, Consent record information structure
- EUR-Lex: Regulation (EU) 2016/679 (GDPR), Article 7 Conditions for consent
- ICO: How should we obtain, record and manage consent?
- EDPB: Guidelines 05/2020 on consent under Regulation 2016/679
- EDPB: Summary, consent under GDPR
- W3C DPVCG: Implementing ISO/IEC TS 27560 consent records and receipts with DPV
- ISO: ISO/IEC 29184:2020 Online privacy notices and consent
- Kantara Initiative: Consent Receipt Specification v1.1.0
Related NHI Mgmt Group resources: Consent Management Guide, Explicit vs Implied Consent, DSAR Guide: Handling Data Subject Requests, PECR Guide. This guide summarises GDPR consent record requirements and is not legal advice.