Reporting
What a consent record actually has to prove
Article 7(1) asks you to demonstrate that one person consented to one thing at one moment, and an aggregate acceptance rate can’t do that.
Reporting 6 min read The UserGuard team

- Article 7(1) requires you to demonstrate that one person consented to one purpose at one moment. Showing that a banner was displayed isn’t enough.
- An aggregate acceptance rate describes a population and is self-reported by the system under suspicion, so it can’t tell valid consent from a broken gate.
- A record needs five fields: pseudonymous subject, purposes accepted and refused, timestamp, banner version and region. With only four, it can’t stand on its own.
The burden of proof sits with you
Article 7(1) of the GDPR is one sentence long, and it puts the entire burden on you. Where processing rests on consent, the controller must be able to demonstrate that the data subject consented. Showing that a banner was displayed, or that consent was probably given, isn't enough. You have to demonstrate it for that person and that purpose. What follows is how we think about evidence and isn't legal advice, and your counsel decides what your records need to contain.
In practice, demonstrate means having something you can produce months later, when nobody on the team remembers what the banner looked like in March. Regulators and claimants look at records, and they don't audit intentions. If your log can't answer for this visitor, this purpose and this day, you don't have consent evidence.
The record has to hold up against a prior opt-in standard. Under the GDPR and ePrivacy rules, nothing non-essential fires before the visitor opts in. Rejecting must be as easy as accepting, an equal-prominence expectation that comes from regulator guidance and EDPB opinion and isn't in the GDPR text itself. Withdrawing must be as easy as giving consent. In the UK the pairing is UK GDPR and PECR, now diverging through the Data (Use and Access) Act 2025, which lifts PECR fines to UK GDPR levels.
Does an acceptance rate prove consent?
No. Most consent dashboards open with a single number, say eighty-four percent accepted. It's a comfortable number that moves in a direction you can report on, and it's worth almost nothing as evidence. An acceptance rate describes a population, while enforcement deals with an individual, such as the complaint on someone's desk from one person about one afternoon in February.
The number is also self-reported by the system under suspicion. A rate can't tell valid consent apart from a banner that logged a dismissal as an accept, or from tags that fired before anyone clicked anything. A suspiciously healthy percentage could mean excellent design or a broken gate, and you can't tell which from the percentage alone.
The Todd Snyder penalty in 2025 had roughly that shape. It was $345,178, traced to a misconfigured banner, and nobody was disagreeing with a policy. Aggregate metrics would have looked fine the entire time. Per-event records are what surface the visitor whose choice never registered, and that's also the only view that lets you fix it before someone outside the company finds it.
What fields does a consent record need?
A record needs to say who, what, when, which version and where. With all five answers it can stand on its own, and with four it can't. The who doesn't have to be a name. A pseudonymous identifier you can join back to a request when someone asks is usually the better choice, because you don't want your consent log turning into a second pile of personal data.
The what is the field most implementations flatten. Purposes need to be granular, and refusals should be stored as carefully as acceptances. For Google advertising and measurement features covering EEA and UK users, Consent Mode v2 has been required since March 2024 and carries four signals: ad_storage, analytics_storage, ad_user_data and ad_personalization. If a record says accepted without saying which of the four were set, you can't reconstruct what ran.
Teams tend to discover which version and where only when those fields are missing. Banners get edited constantly, with new copy, new categories or a moved button. Region matters because the rule being applied differs by it. Without both on the event, all you can prove is that someone clicked something, sometime, under a design you can no longer describe.
- Subject: pseudonymous ID, plus every purpose accepted and refused
- Moment: timestamp, the action taken, and the banner version that produced it
- Place: the region resolved at request time, and any GPC signal received
Why records need to be exportable
If you can view a consent log but can't export it, you don't control that evidence. You need to get records out of the tool in a format a lawyer, an auditor or a spreadsheet can open, which in 2026 still means CSV. UserGuard is designed so every consent event is tied to the site, the banner version, the region and the timestamp, and exports as CSV. It's newly launched, and it's neither a Google-certified CMP nor IAB TCF validated. TCF is on the roadmap.
What goes into the record matters as much as what comes out. UserGuard's scanner applies an evidence gate, so something is recorded as a cookie only when there's a Set-Cookie header, an HTTP-only record, or a document.cookie value. Everything else is kept as labeled context. An inventory padded with guesses looks fine until someone asks you to prove what fires before consent.
The same records help with US questions too. CCPA and CPRA are an opt-out regime with notice at collection, a Do Not Sell or Share My Personal Information mechanism, and mandatory honoring of Global Privacy Control, and they aren't a consent-banner law. As of 2026, nineteen or more comprehensive state laws are in force, twelve of them requiring universal opt-out signals, with Indiana, Kentucky and Rhode Island among the recent additions. Ask counsel which ones reach you. Sephora's $1.2 million in 2022 and Healthline's $1.55 million in 2025 both turned on what happened after the signal arrived.
Consent logs make good design data
A useful side effect of per-event logging is that it also produces product data. That includes reject rate by banner version, by region, by landing page and by device, and withdrawal rate in the weeks after a change. These are ordinary conversion metrics that also happen to matter legally.
Read them carefully, though. If a new banner version lifts acceptance twelve points and nobody can explain why, it's often because rejecting got harder to find, and that's the behavior the equal-prominence expectation exists to catch. Version-stamped records let you see the lift and its cause in the same query, before someone outside the company sees only the cause.
Accessibility crosses over too. A banner a keyboard user can't dismiss is hard to call freely given consent, and it fails WCAG 2.1 AA, the working benchmark and the one EN 301 549 leans on for the European Accessibility Act, which has applied since June 2025. No widget makes a site ADA compliant, and the FTC's 2025 overlay-vendor order is the cautionary tale. UserGuard includes an accessibility widget with every site at $10 a month, applies volume discounts automatically, and never puts GPC or geo-targeting behind a tier.
Go deeper: consent analytics and CSV export
Keep reading