"Demonstrate" Needs a Shape

Article 7(1) of the GDPR puts the burden on you: where processing relies on consent, you have to be able to demonstrate that the person consented. Plenty of teams log something, a timestamp, an IP, a "true" in a database. The trouble comes when you need to compare records across systems, hand one to a user, or migrate to a new consent tool. A log with no agreed structure is hard to audit and harder to move.

That's the gap a standard fills. ISO/IEC 27560 defines what a consent record should contain and how to package it as a receipt, so proof of consent becomes a defined object rather than a bespoke row in whatever database you happened to use. It builds on the record-keeping we cover in proof of consent under GDPR.

Two Standards, Two Jobs

Two ISO standards work as a pair, and it's worth knowing which does what.

ISO/IEC 29184:2020 covers the notice: how you present information and ask for consent online, so the request is clear and specific.
ISO/IEC 27560:2023 covers the record: how you structure the consent that was given, and how you provide it back to the person as a receipt.

27560 is a Technical Specification (the "TS" in its name), which is guidance rather than a certifiable requirement like ISO 27001. Its lineage runs back to the Kantara Consent Receipt Specification v1.1, an earlier community effort that first framed the idea of a portable receipt.

TS Versus IS

ISO/IEC 27560 is a Technical Specification, not a full International Standard, so you don't get "certified" to it. Treat it as an authoritative field set to model your records on, not a badge to chase. The value is interoperability, not a certificate on the wall.

What a Consent Record Contains

27560 organises a consent record around four kinds of information:

The processing, what personal data is used, for which purposes.
The notice, a reference to the privacy notice where that information was provided, so the record is tied to what the person actually saw.
How consent was obtained, the method and context of collection.
Consent events, the give, the withdraw, the expiry, each with its own timestamp.

Around those sit concrete fields: a record identifier, the controller's identity, the specific purposes, the categories of data, the jurisdiction, the consent type, and any expiry. The point of pinning these down is that two systems can read the same record and mean the same thing.

Record Versus Receipt

The standard draws a line the earlier Kantara work blurred. The organisation generates and holds the consent record. A receipt is a snapshot of that record handed to the data subject, evidence they can keep of what they agreed to. Because the record is machine-readable, typically JSON, it can be exchanged between systems and issued to the user without re-keying anything. Here's a stripped-down illustration of the shape (not the full specification, just the idea):

1 {
2   "record_id": "c1f2-9a7b-4e3d",
3   "timestamp": "2026-07-02T09:14:22Z",
4   "pii_controller": {
5     "name": "Example Ltd",
6     "contact": "[email protected]"
7   },
8   "notice_reference": "privacy-notice-v4",
9   "collection_method": "consent-banner",
10   "purposes": [
11     { "id": "analytics", "consent": true },
12     { "id": "advertising", "consent": false }
13   ],
14   "jurisdiction": "EU",
15   "events": [
16     { "type": "given", "timestamp": "2026-07-02T09:14:22Z" }
17   ]
18 }

A Receipt Isn't a Magic Wand

A well-formed receipt proves what happened; it doesn't fix what happened. If the underlying banner used a dark pattern, buried the reject option, or pre-ticked boxes, a tidy record just documents an invalid consent in a standard format. Get the collection right first, then the receipt is worth something.

Why Bother With a Standard At All?

Three practical payoffs. Portability: a structured record survives a change of consent platform, so consent history keeps its meaning when you migrate rather than turning into an opaque export you can't interpret. Auditability: a consistent field set is far quicker to search and produce when a regulator asks, because every record answers the same questions in the same places. Interoperability: standardised records slot into data-rights tooling and vocabularies like the W3C's Data Privacy Vocabulary without custom mapping for every system, and they line up with the direction EU rules are heading, including the consent and data-sharing mechanisms the Data Governance Act introduced.

When and How to Issue a Receipt

The record is something you keep; the receipt is something you give. You don't have to email a receipt after every banner interaction, and doing so would be noise. Issue one where the person has a reason to want proof: on request (for example as part of a data-subject access request), at the moment of an important consent decision, or when someone withdraws and wants confirmation the change took effect. Because the receipt is derived from the same structured record, generating it is a formatting step rather than a data-gathering scramble. Keep the record authoritative and treat receipts as views onto it, so the two never drift apart. If a user later disputes what they agreed to, you produce the record; the receipt they hold should match it field for field.

Applying It Without Boiling the Ocean

You don't need to chase full conformance to get value. Adopt the field set as the schema for your consent log, make sure every consent event is captured with its timestamp and purpose breakdown, and be able to render a record back to a user as a receipt on request. Start with the fields that matter most in a dispute (the purposes, the timestamp, the notice version, and the give-or-withdraw event) and add the rest as you go. That's most of the benefit for a fraction of the effort, and it lines up with what we recommend in consent logging and audit requirements.

Structured Consent Logs, Ready to Produce

CookieBeam's consent logs capture the who, what, when, and how of each consent event, the purpose-level choices, the timestamp, and the state at the moment of collection. That's the substance a 27560-style record needs. When someone asks you to demonstrate consent, or you're moving platforms, a structured log means the proof travels with you instead of being trapped in one vendor's format.