How do you prove a visitor gave consent
You prove it with a consent record: a stored entry showing who consented, when, what they agreed to by category, how they gave it, and which version of the notice they saw. Article 7(1) puts that burden on you. Regulators do not ask to see your banner; they ask you to produce one record, for one visitor, on one date.
A banner is not evidence
The burden is to demonstrate that consent was given, and that word demonstrate is doing all the work. It is not satisfied by showing that a banner exists, or by a screenshot of the one on your site this morning. Both describe your current configuration. Neither says anything about what a particular visitor saw on a particular Tuesday in March, which is the only thing anybody actually asks about.
Article 7(1) is the line that matters, and the published checklists quote it accurately. Where they thin out is on the other half of the job. They are detailed on capture, listing the fields a log should hold, and largely quiet on retrieval: how you pull one visitor's entry, what it has to survive, and whose name is on it. Capture is the half that comes with the product. Retrieval is the half you find out about under pressure.
The five fields, and the one everybody forgets
Who, when, what, how, and under which notice. The first four are on most published lists. The fifth turns the record into evidence, and it is the one most often absent.
Consider what a record without it says: this session accepted analytics and advertising at this timestamp. It does not say what they were told they were accepting. If your banner text changed over the year, and it almost certainly did, a record with no notice version attached cannot establish that the person agreed to anything in particular.
The who field sounds like a problem and is not: you record a pseudonymous session reference rather than a name, because collecting more identifying data to prove you asked permission to collect data would be a strange outcome. The requirements walkthrough covers where this sits among the other obligations.
The retrieval test
Run this once. It is the only way to know whether your consent log is evidence or decoration.
Pick a real date and a real visitor
Not a test session. Choose an ordinary day from a few weeks ago and pick one visitor from it, the way a request would arrive. It only tells you something if the record has already been through your normal retention and whatever your platform does to old data. A record you can find for this morning proves little.
Retrieve the record from your consent platform
Open your consent tool and find that visitor's entry. Time yourself. This is the step that tends to stall, either because the interface reports in aggregate and offers no per person lookup, or because lookup needs an identifier nobody captured. Both are the same finding: the log exists, the retrieval does not.
Check the record answers all five questions
Who, when, what, how and under which notice. A stored entry that says a visitor accepted, with no record of which banner version they saw or which categories they agreed to, does not demonstrate anything about what they actually agreed to. The notice text is the field most often missing, and it is the one that makes the rest meaningful.
Confirm who is named as controller on it
Read the record and see whose name is on it. If you are an agency running consent for clients, this field decides whose obligation you are holding. It stays the client's, whatever the banner is branded, and a record naming the wrong party looks settled when it is not.
Export it before you need it
Ask for a full export in a format you can read without the vendor: a file, not a dashboard view. Do it now, while the account is active. An export you have never run is a feature you are assuming exists, and the moment you most need the log is the moment you are least likely to still have access to it.
The three failures that look like success
Every one of these leaves an installation that passes review. The tool is present, the banner works, the dashboard fills with accept rates, and the thing you would need on the day is not there.
No retrieval. The platform is built for reporting rather than lookup. You can see what share of visitors accepted last month and cannot answer a question about one of them. This is the most common of the three and the easiest to miss, because the dashboard looks like proof.
The wrong controller. This one belongs to agencies, and it is quiet. A record naming the agency rather than the site owner does not move the obligation, it just makes the paperwork disagree with the law. Whose name sits on the record, where the log lives, and whether it leaves with the client are covered in the note on running consent under your own brand.
No export. A log you can only read inside a dashboard is one you can lose to a cancelled plan, a migration, or an account you no longer have. The changeover is exactly where proof tends to disappear.
Proving it and passing it are different jobs
Two things get run together. The record proves consent was given. It says nothing about whether your tags then behaved as the visitor asked, which is a different layer and the subject of the signal verification walkthrough. A site can hold immaculate records and still leak on a decline. You need both, and they fail independently.
Velo logs every consent decision as an immutable event and returns a receipt id for each one, which is the part that makes a later lookup possible at all. Velo is in early access, so treat the admin side as still filling in. The mechanism is on the product page.
Common questions
What people ask about this topic.
How do you prove a visitor gave consent?
With a consent record you can retrieve on demand: a stored entry showing who consented, when, what they agreed to by category, how they gave it, and which version of the notice they saw. The accountability principle in the GDPR puts the burden on the controller to demonstrate that consent was given, so the test is not whether you have a banner but whether you can produce one visitor's record for one date.
What does a consent record need to contain?
Five things. Who, meaning a pseudonymous identifier tying the record to a session rather than naming a person. When, a timestamp for the choice and for any later change. What, the categories granted and refused rather than a single yes. How, the mechanism used. And under which notice, meaning the version of the banner text on screen at the time. That last field is what turns the other four into evidence.
How long do you have to keep consent records?
The law does not name a number, which is why published guidance says appropriate retention rather than a duration. The reasoning most teams settle on is that the record has to outlive the processing it authorised, plus whatever window a complaint could realistically arrive in. Deleting the record the moment a visitor withdraws is the trap: you then cannot show the consent was valid while you were acting on it. Take the actual duration from your own legal advice, not from a vendor default.
Who owns the consent records when an agency runs the banner?
The client, in almost every case, because the controller is whoever decides why and how the data is processed, and that is the site owner rather than the agency configuring the tool. The practical question is where the records live and whether they leave with you. If the log sits in an agency owned account, an offboarding can strand a client's proof of consent inside a tenancy they cannot reach.
What happens to your consent log if you switch consent platforms?
It stays behind unless you deliberately move it, and the new platform starts from zero. Your obligation to demonstrate consent covers the period before the switch as firmly as after it, so export the old log before you cancel the old account and note the changeover date.
Your banner, your consent,
your data — all in one place.
