Under GDPR Art. 7(1), what must a consent record hold so a controller can later demonstrate valid consent?
answer
- the burden of proof is on the controller
- who, when, how, what they saw
- a configuration is not proof
- keep it only as long as needed
basics
~20 sUnder GDPR Art. 7(1), the controller must be able to prove consent. A record should show who consented, when, how, what information and wording they saw, for which purposes, and any later withdrawal, without collecting more data than that proof needs.
solid answer
~50 sUnder GDPR `Art. 7(1)`, where processing is based on consent, *the controller shall be able to demonstrate* that the data subject consented; the burden of proof is the controller's. The GDPR does not prescribe a format. EDPB Guidelines 05/2020 (paras. 106-108) say the controller should be able to show **how** and **when** consent was obtained and **what information** was provided at the time, and that its workflow met the validity criteria; online, that can mean the session in which consent was given, documentation of the consent workflow then, and a copy of the information shown. Merely pointing to a correct website configuration is **not sufficient**. A useful record therefore holds a subject reference, timestamp, purposes, the notice and wording version, the capture method, and withdrawal events. The duty lasts as long as the processing, and proof should then be kept no longer than strictly necessary for legal obligations or claims (para. 107).
code
json · 17 lines{
"eventId": "c0a8012e-7f3d-4b8e-9d51-2f6a1e4b9c20",
"subjectRef": "user-48213",
"controllerRef": "controller-main",
"eventType": "GRANTED",
"timestamp": "2026-09-25T08:14:03Z",
"purposes": {
"newsletter": true,
"audience-analytics": true,
"personalised-advertising": false
},
"noticeVersion": "privacy-notice-v7",
"uiTextVersion": "signup-consent-v3",
"captureMethod": "unticked-checkbox-selected",
"interface": "web-signup-form",
"withdrawalInfoShown": true
}go deeper
Recall that under Art. 7(1) the controller must be able to prove consent, so a record of who agreed to what and when is required.
List the fields a record needs (who, when, how, which wording and purposes, withdrawals) and explain why a current configuration is not proof.
Design an append-only, versioned consent log that stays minimal, supports withdrawal timing and follows the EDPB retention guidance.
Make consent evidence a shared platform service so every product captures the same fields and wording versions, instead of each team inventing its own flag.
## The obligation `Art. 7(1)` of the GDPR (Regulation (EU) 2016/679) is one sentence: *where processing is based on consent, the controller shall be able to demonstrate that the data subject has consented to processing of his or her personal data.* Recital 42 repeats it. EDPB Guidelines 05/2020 on consent (paras. 104-108) state the consequence plainly: the **burden of proof** is on the controller. Because every condition of valid consent must hold, the record must support each one: - **freely given**: the choice was separate and optional; - **specific**: the purposes consented to are identified; - **informed**: the information shown at the time is known; - **unambiguous**: the affirmative act and its method are captured; - **withdrawable**: the person was told about withdrawal, and any withdrawal is recorded. ## What the EDPB says a record should show The guidelines leave the method to the controller but set the content: 1. **How** consent was obtained (para. 108). 2. **When** it was obtained (para. 108). 3. **What information** was provided to the data subject at the time (para. 108). 4. That the person was **informed** and that the controller's **workflow met all relevant criteria** for valid consent (para. 108). 5. Online, the controller *could retain information on the session in which consent was expressed, together with documentation of the consent workflow at the time of the session, and a copy of the information that was presented* (para. 108). 6. It *would not be sufficient to merely refer to a correct configuration of the respective website* (para. 108). ## Designing the record A consent event log usually carries these fields: | Field | Why it is needed | |---|---| | Subject reference | Links the consent to the person without copying their whole profile | | Timestamp | Shows when consent was given, and orders later changes | | Purposes and choices | Shows specificity: which purposes were accepted, which refused | | Notice and wording version | Shows what the person was told; points to an archived copy | | Capture method and interface | Shows the affirmative act and where it happened | | Controller identity | Shows who asked, especially where several controllers are named | | Withdrawal events | Shows when processing had to stop under `Art. 7(3)` | | Parental authorisation evidence | For children under `Art. 8`, shows what verification was done | Two design rules make the record trustworthy: - **Append-only events.** Recording each grant and withdrawal as a new event preserves history; overwriting a boolean loses the evidence of what applied when. - **Versioned wording.** Store the version identifier of the text and UI shown, and keep the archived versions, since a record that says only "consented: true" proves nothing about what was agreed. ## Not more than needed The EDPB also limits the record: the duty to demonstrate *should not in itself lead to excessive amounts of additional data processing*, and controllers should have enough data to show a link to the processing but *shouldn't be collecting any more information than necessary* (para. 106). A consent log does not need a full device fingerprint or a copy of the user's profile. ## How long to keep it - The obligation to demonstrate consent exists **as long as the processing activity lasts** (para. 107). - After the processing ends, proof of consent should be kept *no longer than strictly necessary* for compliance with a legal obligation or for the establishment, exercise or defence of legal claims, in line with `Art. 17(3)(b)` and `(e)` (para. 107). ## Consent does not last forever The GDPR sets no fixed expiry for consent. The EDPB says its duration depends on context, scope and the person's expectations; if processing operations change or evolve considerably, the original consent is no longer valid and new consent is needed (para. 110). It recommends, as best practice, refreshing consent at appropriate intervals (para. 111). The record should therefore make it possible to see which consents were given under which version of the processing. ## Common mistakes - Storing only a boolean flag with no timestamp, wording or method. - Relying on "our banner was configured correctly" as proof. - Overwriting the old state when a user changes their mind. - Logging far more personal data than the proof requires.
- Under EDPB Guidelines 05/2020, is a screenshot of the current consent form enough to demonstrate past consents?No. The record must show what was presented to that person at the time and how their consent was captured. Para. 108 says merely referring to a correct configuration of the website is not sufficient; the controller should keep session information, documentation of the workflow at the time and a copy of the information shown.
- Under the GDPR, how long should a controller keep proof of a consent?For as long as the processing based on it lasts, since the duty to demonstrate exists throughout. After processing ends, EDPB para. 107 says proof should be kept no longer than strictly necessary for a legal obligation or for legal claims, referring to `Art. 17(3)(b)` and `(e)`.
saying these in an interview costs you the question
- A boolean consent flag on the user row is enough proof.
- The supervisory authority must prove that consent was not given.
- Showing the banner is configured correctly today proves past consents.
- Consent records should capture as much device data as possible.
- A change of mind should overwrite the earlier consent record.