What evidence does a cookie-consent audit need?
A cookie-consent audit needs reproducible records of what a real visitor's browser received: whether the banner appeared, which choices it offered on the first screen, which cookies and third-party trackers were set before any choice, what changed after accepting or rejecting, screenshots of each state, and timestamps with integrity protection. Witnio's Consent & Cookie Check produces those records from a real Android phone on a real SIM. It observes as a visitor outside the EU, not as a visitor located in the EU, and it is supporting evidence, not a legal opinion.
Updated September 25, 2026
The four states an audit has to capture
Consent is a sequence, and the evidence has to follow it. The first state is the page before any interaction: which cookies exist and which third-party requests have already fired. This is where most problems appear, because a tag manager or an advertising pixel can load before the banner does.
The second state is the banner itself: whether it appears, and which options are visible on its first layer, in particular whether a reject option exists there or only an accept button and a settings link. The third and fourth states are the page after accepting and after rejecting. Comparing them shows whether the choice actually changes what the site sets.
What makes the evidence usable
Evidence is useful when someone else can rely on it later. That requires the exact URL, the date and time, the device and browser used, and the network context the visit came from. It also requires screenshots tied to the cookie lists they illustrate, so a reviewer does not have to trust a summary.
Two technical details decide whether a cookie list is trustworthy. The browser profile must not carry cookies from unrelated accounts, or they will be miscounted as the site's own. And a banner must be detected by its buttons, not by any link that mentions privacy, or a footer link will be reported as a consent banner.
Where the visit comes from matters
Many consent platforms show different banners, or none, depending on where the visitor appears to be. A run from a real SIM outside the EU shows what a visitor outside the EU receives. It does not show what a visitor located in the EU receives, and it should not be presented as an EU-visitor audit.
That limit is still useful. Pixels that fire before consent for one audience often fire for every audience, and a missing reject option is a design decision that tends to travel. But the finding must be reported with its vantage point, and a conclusion about EU visitors needs an EU vantage point.
How Witnio measures it
You provide a domain or URL and a run frequency. On each run a physical Android phone loads the page and records banner presence, the visible options, cookies before and after consent, relevant changes between runs and screenshots. A baseline of pre-existing profile cookies is excluded so only the site's own cookies are counted.
Each run produces a signed evidence record and a client report in JSON and PDF, built only from stored data. Screenshots are kept 60 days on Founder and 90 days on Standard. One finding documented during backtests: the pilot store then offered no reject option and set Facebook cookies before consent.
Consent & Cookie Check never states that a site is legally compliant. It records what happened on a real device so that your legal team, your auditor or your privacy lead can draw that conclusion with better material.
Frequently asked questions
- Does a Consent Check run prove GDPR compliance?
- No. It is supporting evidence of what a real device observed. Compliance is a legal conclusion that belongs to your counsel or auditor.
- Does it show what EU visitors see?
- No. Runs are made from a real SIM outside the EU. Banners that target EU visitors by location may not appear from there.
- Why use a real phone instead of a headless browser?
- Some sites treat automated browsers differently, and mobile layouts change which banner appears. A real phone records what a mobile visitor receives.