Skip to main content
ComplicerAUDIT GRADE
MethodologyUse casesEU AI ActPricingBlogDocsSign inSTART FREE AUDIT
METHODOLOGY

How Complicer verifies consent.

Most tools check whether a cookie banner exists. We test whether it actually works — and we only claim it works when the evidence proves it. When we cannot prove behaviour, we tell you exactly why instead of overclaiming.

REJECT + ACCEPT·4 SIGNALS·70-RULE ENGINE·SEALED EVIDENCE
THE VERIFICATION GATE — PASS 1 · A BANNER THAT WORKSAUTO-DEMO
01
Click RejectRUNNING
first-level reject_all
banner_disappeared
consent_storage_changed
cmp_api_changed
success_message
02
Click Accept—
accept_all · both paths required
banner_disappeared
consent_storage_changed
cmp_api_changed
success_message
GATE — BOTH CLICKED · EACH CONFIRMED BY ≥1 SIGNAL—
VERDICT
…
sha256:9af3…2c41
demo · sample data
Illustrative demo with sample data.
THE ONLY THREE THINGS A REPORT WILL EVER CLAIM
✓Verified

Both the reject and accept paths were exercised and confirmed by at least one signal.

→Cannot verify — here’s why

The banner is present but we could not prove behaviour. We name the exact reason.

✗Not proven

A claim that the banner works is never made on absence of evidence alone.

01 — THE FOUR SIGNALS

After the click, we watch for observable proof.

After we click a consent control, we look for observable proof that the site acted on the choice. Any one of these four signals confirms a path. Select a signal to see what it proves.

01 — banner_disappeared

After we click, the consent banner is gone from the page. The site acted on the choice instead of re-prompting.

02 — THE RULE

Verification is granted only when Reject and Accept were both clicked — and each is confirmed by at least one signal.

An accept-only banner cannot be verified. A click with no confirming signal cannot be verified. Undefined or missing confirmation fails the gate — silent absence is not consent. The rule is enforced in code, identically for every audit, so the same evidence always produces the same verdict.

Silence is not consent.
THE GATE, IN CODE ORDER — FIRST FAILURE BECOMES THE RECORDED REASON
01
A consent banner was found on the pageELSE → banner_not_found
02
The banner is reachable — not inside an iframe or shadow DOM, not anti-bot blocked, served to our regionELSE → banner_inaccessible
03
One control is clearly the reject button — no guessing between look-alikesELSE → ambiguous_reject
04
One control is clearly the accept buttonELSE → ambiguous_accept
05
Reject was actually clickedELSE → reject_not_clicked
06
Accept was actually clickedELSE → accept_not_clicked
07
Each click was confirmed by at least one signal — undefined or missing confirmation failsELSE → post_click_not_confirmed
✓
All checks passVERDICT → VERIFIED
03 — WHEN WE CANNOT PROVE IT

Every reason we say “cannot verify”.

When the rule is not met, we never fall back to a vague pass or fail. Each audit records exactly one of these reasons so you — and your regulator — know what was and was not proven. Select a reason to see the exact report wording.

WHY WE STOP HERE

We did not detect a consent banner on the page. There was nothing to interact with, so consent effectiveness was not tested.

WHAT THE REPORT SAYS — VERBATIM
No consent banner detected on this page. Consent effectiveness was not tested.
No vague pass. No vague fail. Each audit records exactly one of these reasons, so you — and your regulator — know what was and was not proven.
Report phrases are the renderer's exact wording; variable fields shown with sample values.
04 — SEALED EVIDENCE

How the evidence is sealed.

Every verdict ships with a tamper-evident evidence bundle. The chain proves the evidence is authentic, unaltered, and existed at audit time — retained for seven years.

01 — SHA-256→
Content hash

Every screenshot, snapshot, and result is hashed with SHA-256 at capture time. Any later change to a single byte breaks the hash.

02 — Ed25519→
Digital signature

The hash is signed with our Ed25519 key, binding the evidence to Complicer and proving it was not altered after signing.

03 — RFC 3161
Trusted timestamp (optional)

When an RFC 3161 Time-Stamping Authority is configured, it countersigns the bundle, proving when the evidence existed — independently verifiable by a regulator. Otherwise the bundle carries a local timestamp, and the report states which was used.

✓ EVIDENCE IS IMMUTABLESHA-256 · Ed25519 · OPTIONAL RFC 3161 TSA · 7-YEAR RETENTION

See it on your own site.

Run a free audit and get the verdict — Verified, cannot-verify with the reason, or not proven — backed by signed evidence.

VIEW PRICINGRUN A FREE AUDIT →
ComplicerAUDIT GRADE

Outcome-driven GDPR compliance — banners that actually work, evidence you can show your auditor.

GDPR-ALIGNED · SHA-256 · Ed25519 · EU-W1
PRODUCT
Free scanUse casesMethodologyEU AI ActPricingDocsBlog
COMPANY
ContactSecurity
LEGAL
PrivacyTermsComplaint
EVIDENCE CHAIN INTACT · SHA-256 · Ed25519 · RFC 3161-READY© 2026 COMPLICER