Article 7(1): The Proof Burden Is the Whole Game

GDPR Article 7(1) says the controller shall be able to demonstrate that the data subject has consented to processing of his or her personal data. The word that matters is demonstrate. It is not enough to have collected consent. The controller has to be able to prove it, for a specific visitor, at a specific time, for specific purposes. The burden is on the controller, and it does not shift.

The banner is the easy part. A banner screenshot proves that a banner existed, and it proves nothing about any specific visitor. A regulator investigating a complaint will ask for the record of one visitor's consent, and the answer has to be a record, not a screenshot and not a policy. Most sites cannot produce one, and that is the failure the article is written for.

Demonstrate, not just collect

A consent record needs four things at minimum: a timestamp, the categories the visitor accepted, the banner version they saw, and the policy version in force at that time. The timestamp has to be trustworthy, which means the server clock has to be synced; clock skew breaks timestamps, and a timestamp a regulator cannot trust is worse than no timestamp, because it looks like evidence and is not.

The record should also hold the mechanism: the exact choice the visitor made, and whether it was accept all, reject all, or a granular selection. A record that says consent was given, without saying what was consented to, proves nothing about the purposes the site is actually processing for. The categories matter because the processing has to match them.

What the record must hold

The most common failure is storing the consent only in a cookie on the visitor's device. The visitor can delete it, the browser can clear it, and the record disappears with it. A consent record that lives only in a cookie is a record the controller cannot produce on demand, which is the opposite of what Article 7(1) requires. The record needs a server-side copy, tied to a pseudonymous identifier, not to a name.

The second failure is the vendor list changing without notice. The visitor consented to a list of vendors, and the site changed the list, and the record no longer describes what the visitor agreed to. Consent is tied to the purposes and the recipients the visitor saw. Change either one and the old consent does not cover the new processing.

Keep the record for as long as the processing continues, plus the limitation period for a claim in your jurisdiction. The record is the proof that the processing was lawful, and deleting it early deletes the proof. Deletion on request is the exception: when a visitor asks for their data to be deleted, the consent record goes too, or it is kept only as proof of the refusal, with the personal data removed.

Where records fail in practice

Check the retention period against the regulator's practice in your country, because it varies, and the variation is the point. A record kept for six months in a jurisdiction with a three-year limitation period is a record that disappears before the claim arrives.

Keep reading: How Much Does Your Consent Banner Weigh? Script Cost in Milliseconds, A/B Testing a Consent Banner Measures the Banner, Not Consent.

How long to keep it

Frequently asked questions

What does GDPR Article 7(1) require?

The controller must be able to demonstrate that the data subject consented to the processing. The burden of proof is on the controller.

What should a consent record contain?

A timestamp, the categories accepted, the banner version, and the policy version at the time of consent, plus the exact choice the visitor made.

Is a cookie enough proof of consent?

No, not on its own. The visitor can delete it, and it proves nothing to a regulator without a server-side record tied to a pseudonymous identifier.

How long should consent records be kept?

For as long as the processing runs, plus the limitation period for a claim in your jurisdiction. Check the local period, because it varies.