DAT-010 Consent Management
Description
Where consent is the legal basis for processing, a mechanism exists to obtain, record and withdraw consent. Consent is granular, freely given, specific, informed and unambiguous. Records of consent are maintained and withdrawal is as easy as granting. Consent is refreshed when processing purposes change. Where a consent request sits inside a wider written declaration, it is presented separately from the other matters, in an intelligible and easily accessible form and in clear and plain language. The individual is told of the right to withdraw before consent is taken.
Rationale
Consent without a management mechanism is not valid, and consent records are what demonstrate compliance and make withdrawal requests answerable. The presentation rules matter because a consent buried in terms of service is the commonest way a consent that looks recorded turns out to be invalid: the individual agreed to a document, not to the processing. Telling the individual about withdrawal before consent is taken is a precondition of the consent rather than a courtesy afterwards.
Applicability (9 profiles)
Framework Mappings (10)
| DSP-08 | Data Privacy by Design and Default | informative |
| DSP-08 | Data Privacy by Design and Default | informative |
| EU-AI-Art.60 | Real-World Testing — Plan, Registration and Informed Consent | informative |
| GDPR-Art.5.1a | Lawfulness, Fairness and Transparency of Processing | partial |
| GDPR-Art.7 | Conditions for Consent | full |
| PT-4 | Consent | full |
| MS-2.2-003 | Human Subject Evaluation Requirements | MS-2.2-003 | full |
| P2.1 | Choice and Consent | full |
| P3.2 | Explicit Consent for Sensitive Information | partial |
| P6.1 | Disclosure of Personal Information | partial |
Evidence (3)
Consent management platform configuration showing that consent is collected in a granular, freely-given manner with withdrawal mechanism in place.
Example: Consent Management Platform configuration export (OneTrust / Cookiebot / Usercentrics), showing consent categories, opt-in design (no pre-ticked boxes), withdrawal mechanism active, and consent version history enabled
Test: Review the CMP configuration and live consent banner. Verify: (1) consent is opt-in by default (no pre-ticked boxes), (2) consent categories are granular (at minimum: analytics, marketing, functional), (3) a withdrawal mechanism is accessible from within the product (not only at sign-up), (4) version history or consent audit log is enabled.
Consent records log demonstrating that individual consents are captured with timestamp, version, mechanism of consent, and withdrawal events.
Example: Consent audit log export from CMP or database for a sample of 50 users, showing user ID (pseudonymised), consent timestamp, consent version, categories consented to, and any withdrawal events with timestamps
Test: Request a sample consent audit log export. Verify: (1) each record includes a timestamp, consent version, and categories, (2) withdrawal events are recorded when users opt out, (3) consent version in records matches the published privacy notice version at the time of consent, (4) log is retained for the duration required by the retention schedule.
Walkthrough of the live consent flow where a consent request appears alongside terms of service or another written declaration.
Example: Walkthrough note, sign-up consent flow, web and mobile, 2026-08-06
Test: Walk through the live consent flow on each interface that takes consent. Verify: (1) the consent request is visually and textually separate from the other matters in the declaration, (2) the request states what is consented to without requiring a second document to be opened, (3) the right to withdraw and the route to exercise it are stated on the same screen before consent can be given, (4) withdrawal through that route takes no more steps than giving consent, (5) declining consent still allows the parts of the service that do not depend on it.
Questions (3)
Where consent is relied upon as the legal basis for processing, does your organisation use a consent management mechanism that records granular, freely given, specific and withdrawable consent?
Consent must be opt-in by default (no pre-ticked boxes). Withdrawal must be as easy as granting consent. Consent records should include timestamp, version, and categories consented to.
How is individual consent recorded and managed?
Options run from the strongest record to the weakest. A consent management platform and a mechanism built into the product are both acceptable, provided the record holds the individual, the timestamp, the consent version and the purposes agreed to; OneTrust, Cookiebot and Usercentrics are examples of the platform category. The test is whether a question about one person on one date can be answered from the record. Consent captured once at sign-up cannot be withdrawn for one purpose while the others stand.
Where a consent request sits inside a wider declaration such as terms of service, which of the following apply?
Options run from the most commonly in place to the least. Consent buried in terms of service is the commonest reason a recorded consent turns out to be invalid: the individual agreed to a document rather than to the processing. If no consent request is bundled into a wider declaration, answer against the standalone flow.