Complying isn't enough, you have to be able to prove it
Most of the GDPR tells you what to do. One principle tells you to keep the receipts. Article 5(2), the accountability principle, says the controller is responsible for the other data-protection principles and must be able to demonstrate compliance with them. Article 24 backs it up, requiring you to put appropriate measures in place and to review and update them.
For cookies, this changes the whole exercise. A banner that works is necessary but not sufficient. You also have to be able to show, on demand, that it works and why your setup is lawful. When a supervisory authority opens a cookie investigation, the first move is usually some form of "show us," and "we have a banner" is not an answer. Accountability is what turns a UI into an evidence file.
The documentation stack for cookie accountability
Demonstrating compliance for cookies means keeping a connected set of records, each covering a different obligation. Missing pieces are where audits go wrong.
- A cookie inventory or audit. What cookies and scripts run, their purposes, the vendors behind them, and their lifespans. You can't be accountable for what you never mapped. See how to audit your website's cookies.
- Records of processing (Article 30). The tracking you carry out, its purposes, the categories of data and recipients, any transfers, and retention periods. Covered in records of processing for cookies.
- Proof of consent (Article 7(1)). Per-purpose, versioned, append-only consent logs that reconstruct what a specific visitor was shown and chose. See proof of consent documentation.
- A DPIA where required. For high-risk tracking, the assessment itself is part of your accountability file. See when cookies need a DPIA.
- A cookie policy that matches reality. The policy has to describe the cookies you actually set, not a generic template. See writing a cookie policy that matches your cookies.
- Processor contracts. Data processing agreements with the vendors that handle data on your behalf. See DPAs for website owners.
Compliance you can't evidence is, to a regulator, non-compliance
This is the uncomfortable core of accountability. A perfectly configured banner that blocks every non-essential cookie until consent, but keeps no records, is indistinguishable from a broken one the moment someone audits it. If you can't produce the consent log, the cookie inventory, and the reasoning behind your categorization, the regulator has no way to tell a compliant site from a lucky one. The evidence is not paperwork you do for its own sake. It's the only thing that lets you prove the good behavior actually happened.
Accountability covers every principle, consent included
It's easy to read Article 5(2) as being about proving consent, because that's the part cookies make most visible. It's broader. You have to be able to demonstrate compliance with all of the Article 5(1) principles, and several apply squarely to tracking. Purpose limitation means you can point to the specific reason each cookie exists. Data minimization means you can show you're not collecting more than the purpose needs, truncating IP addresses in analytics is a classic example. Storage limitation means your cookies and the data behind them have defined lifespans rather than running indefinitely. For each of these, the accountability question is the same. Doing it isn't enough. You have to be able to show it.
Picture how a real investigation opens. A supervisory authority asks you to produce the consent record for a named visitor on a specific date, the cookie inventory as it stood that day, and, if your tracking was high risk, the DPIA that preceded it. A team that designed for evidence answers in minutes with an export. A team that treated documentation as optional spends weeks reconstructing what it can and guessing at the rest. The difference isn't how good your banner looks. It's whether the records were there before anyone asked.
Privacy by design is part of it
Accountability connects directly to Article 25, data protection by design and by default. For cookies, the default that matters is simple: no non-essential cookies before consent. A site that loads analytics and ad tags on arrival and asks permission afterward has the default backwards, and no amount of documentation fixes that. Getting the default right is itself an accountability measure, because it's the design choice you'll be asked to justify.
Regulators have made this a live enforcement area rather than a theoretical one. The EDPB's cookie banner taskforce and national sweeps by authorities like France's CNIL have gone site by site, checking real banners against the rules. The sites that come through cleanly are the ones that treated evidence as a first-class requirement instead of an afterthought.
Your cookie accountability file
A current cookie inventory
What runs, its purpose, vendor, and lifespan, kept up to date as the site changes.
Records of processing for your tracking
Purposes, data categories, recipients, transfers, and retention under Article 30.
Per-purpose, versioned, append-only consent logs
Enough to reconstruct what a named visitor saw and chose.
A DPIA where the tracking is high risk
Done before processing, not backfilled after a complaint.
A cookie policy that matches the actual cookies
Not a generic template that lists cookies you don't set.
Signed DPAs with your processors
Article 28 contracts for every vendor handling data on your behalf.
Where CookieBeam does the heavy lifting
Some of this file is yours to maintain by hand: the ROPA, the DPIA judgment, the written policies. Those need human decisions. The part that's hardest to produce manually, and easiest to get wrong, is the machine-generated evidence, and that's what CookieBeam is built to capture.
The scanner gives you the live cookie and script inventory, so the "what runs on our site" question has a current answer instead of a stale spreadsheet. Consent is recorded per purpose in append-only logs with timestamps and jurisdiction, which is the proof-of-consent layer regulators actually ask to see. And because non-essential scripts are blocked until consent, the privacy-by-default posture is enforced in the runtime rather than asserted in a document. Read this alongside the GDPR cookie compliance checklist and the deeper piece on consent logging and audit requirements to see how the evidence pieces fit together.