Service C

Cookie & consent review

We test what your site actually does before consent — at the network level — not what your consent platform's dashboard claims it does. The two differ more often than not.

Why configuration screens lie

Almost every consent platform lets you tag scripts by category. The problem is what sits outside that system: a marketing tag hard-coded into a template, an embedded video iframe that sets cookies on load, a chat widget added by the support team, a font or map request that leaks IP addresses to a third country. None of it appears in the CMP dashboard, and all of it fires before anyone clicks anything.

So we do not read your configuration. We load your pages with a clean profile, capture the network traffic, and list every request and storage write that happens before consent is given. Then we do it again after clicking “reject”.

What consent has to look like

Under the GDPR, valid consent is freely given, specific, informed and unambiguous, given by a clear affirmative action. In cookie-banner terms, and following EDPB guidance and national supervisory authority decisions, that means:

• Nothing non-essential fires first. Scrolling, continued browsing and mere page load are not consent.
• Refusing is as easy as accepting. If “accept all” is one click, so must refusal be — a reject option buried two layers into a settings panel is a recognised dark pattern.
• No pre-ticked boxes for any non-essential purpose.
• Purposes are specific, not one bundled “improve your experience” toggle.
• Withdrawal is available at any time and no harder than giving consent.
• Proof is retained. If you cannot show what a user consented to and when, you cannot demonstrate compliance.

The accessibility overlap

A cookie banner is a modal dialogue, and it is the first thing every visitor meets. If it traps keyboard focus, has no accessible name, or renders its reject control at 2.4:1 contrast, then you have simultaneously created an accessibility barrier and undermined the validity of the consent — because a user who cannot operate the reject button has not freely given anything. We test the banner as a component, which is why this review pairs naturally with an accessibility audit.

Deliverable

A findings report listing every cookie and storage item with its purpose, duration, controller and legal basis; a table of what fires pre-consent and post-reject; the banner UX and accessibility findings; and a prioritised fix list. Where your published cookie policy does not match observed behaviour — a very common finding — we flag each discrepancy so your policy can be corrected to match reality.