Machine-readable consent records and receipts as defined by ISO/IEC TS 27560:2023, implemented using the W3C Data Privacy Vocabulary (DPV). Build consent systems that are interoperable, auditable, and compliant with GDPR, DPDP, and global privacy regulations.
The W3C Data Privacy Vocabulary (DPV) — developed by the Data Privacy Vocabularies and Controls Community Group (DPVCG) and now at version 2.3 — defines the core concepts for representing consent in machine-readable form. The DPV framework distinguishes between two related but distinct concepts:
The internal documentation of a data subject's consent for processing of their personal data. Includes metadata, processing details, involved parties, and event provenance. Required for demonstrating compliance under regulations like GDPR Article 7.
An authoritative copy of a consent record provided to another entity — typically the data subject. Analogous to a shopping receipt. Enables data subjects to track what they consented to and exercise their rights.
ISO/IEC TS 27560:2023 is the international standard that specifies an interoperable, open, and extensible information structure for consent records and receipts. The DPV profile for 27560 (dpv-27560) provides a complete implementation schema using DPV concepts. This approach is jurisdiction-agnostic — the same information structure works across GDPR, India's DPDP Act, Brazil's LGPD, and Canada's PIPEDA.
A consent record under ISO/IEC TS 27560:2023 contains four sections. Fields in bold are mandatory.
dpv-27560:recordDPV defines a structured lifecycle for consent states, enabling systems to track and verify consent validity over time. The lifecycle below follows the model from the DPV-27560 guide:
Information is provided to the data subject via a consent notice. DPV relation: dpv:hasNotice with dpv:ConsentNotice.
Consent is solicited from the data subject. DPV status: dpv:ConsentRequested.
Data subject grants consent. DPV status: dpv:ConsentGiven. A consent record is created. A receipt may be issued to the data subject. Processing may begin.
Consent validity is re-affirmed. The status remains dpv:ConsentGiven but the record is updated with a new confirmation event and timestamp.
Consent ends for any of: withdrawal (dpv:ConsentWithdrawn), expiry, termination by controller, or invalidation by authority. Processing must stop.
Source: DPV Consent Lifecycle as defined in the DPV-27560 Consent Records and Receipts Guide.
The DPV provides the following core concepts and relations for modelling consent. These are the building blocks for implementing the ISO 27560 information structure.
| DPV Concept | Type | Description |
|---|---|---|
| dpv:Consent | Legal Basis | Consent as a legal basis for processing. Extended by ExpressedConsent, ExplicitlyExpressedConsent. |
| dpv:ConsentStatus | Status | Current stage of consent. Includes ConsentRequested, ConsentGiven, ConsentWithdrawn. |
| dpv:ConsentRecord | Measure | Documentation of consent information per ISO 27560. An organisational measure for accountability. |
| dpv:ConsentReceipt | Measure | Authoritative copy of a consent record provided to another entity. |
| dpv:ConsentNotice | Notice | The notice shown to the data subject when requesting consent. |
dpv:hasLegalBasis Associates processing with consent as its legal basis.
dpv:hasConsentStatus Indicates the current status of consent.
dpv:hasIndicationMethod How consent was expressed (click, biometric, signature).
dpv:isIndicationTime Timestamp when consent was given or withdrawn.
dpv:hasDataSubject Identifies the individual who gave consent.
dpv:hasConsentControl Mechanism for withdrawal (e.g., WithdrawConsent).
The DPVCG defines four standard profiles for implementing ISO/IEC TS 27560:2023, each under the dpv-27560 namespace:
Consent Records conforming to ISO 27560. Contains all mandatory fields: schema version, record identifier, data subject, purpose, personal data, controller, storage, recipients, jurisdiction, consent type, state, event time, duration, withdrawal method.
Extends the base record with GDPR-specific requirements including: lawful basis, processing operations, data source, automated decision-making, retention period, and supervisory authority information.
Consent Receipt providing a copy of the consent record. Includes receipt identifier, associated consent record reference, schema version, and creation timestamp plus any subset of record fields.
GDPR-specific consent receipt that includes all information required by GDPR Articles 13 and 14 to be provided to the data subject.
DPV achieves jurisdiction-specific compliance through extensions. Each law or regulation has a dedicated namespace that extends the core DPV model with jurisdiction-specific concepts.
Extension: legal/eu/gdpr
Concepts for consent under GDPR Article 4(11), Article 7, and Recital 42. Includes explicit consent, withdrawal, records of consent, and supervisory authority interactions.
Extension: legal/in/dpdp (proposed, v2.4)
Concepts for India's Digital Personal Data Protection Act: consent managers, data fiduciaries, significant data fiduciaries, legitimate uses, children's data, and grievance redressal. See DPV Issue #438.
Extension: legal/br
Lei Geral de Proteção de Dados — consent, legitimate interest, data subject rights, and ANPD (authority) concepts. Mapped via DPV legal extensions framework.
Extension: legal/ca
Personal Information Protection and Electronic Documents Act — meaningful consent, purpose specification, and accountability principles aligned with DPV core concepts.
A production consent management system built on DPV and ISO 27560 should address the following architectural layers:
Persistent storage for consent records with schema validation against the dpv-27560 profile. Each record tracks the full lifecycle — initial grant, updates, re-confirmations, and withdrawal. Records are immutable append-only logs with cryptographic integrity.
Versioned consent notices with language support. Each notice is referenced by the consent record via dpv:hasNotice. Changes to notices are tracked so consent validity can be evaluated against the notice that was shown at the time of consent.
State machine managing transitions: requested → given/refused → given/re-confirmed → withdrawn/expired/invalidated. Each transition generates a consent event recorded in the store.
Consent receipts are issued to data subjects. Shared Signals events (via OpenID SSF) propagate consent changes — withdrawal, expiry, scope updates — to all data consumers in the ecosystem in real time.
We use analytics tools to understand how our website is used and improve your experience. This may involve the processing of your personal data, including your IP address and browsing behavior. You can choose to accept or reject this processing. Withdrawing consent does not affect the lawfulness of processing based on consent before its withdrawal. For more details, please read our Privacy Policy.
By accepting, you consent to the processing of your personal data for analytics purposes as described above. You may withdraw consent at any time by clicking the preference icon in the footer.