DataVowConsent Checker

Published 10 October 2026 · Practical testing guidance, not legal advice

Cookie consent test evidence: what to save

Save a state-labelled record of what your browser observed before choice, after acceptance, after rejection and after withdrawal. Include the test context and capture gaps so another person can repeat the check.

This checklist documents a test of your site configuration. It does not prove consent for every visitor or establish legal compliance. Screenshots and traces are suggested artifacts, not a regulator-prescribed format.

1 test sequence, 4 choice states

  1. 1. Record the test context

    Give each run an identifier. Record the ISO timestamp, public URL, browser version, device, tested region and site release. Save the consent-management configuration version if available.

    Start with a fresh browser profile or cleared site storage. Document extensions and browser protections: these can block requests independently of the banner. Do not reuse an accepted session for the rejection test.

  2. 2. Capture the page before any choice

    Open developer tools before loading the page. Record the network requests, cookies and local storage during a stated observation period. Include actions such as scrolling or opening another page.

    Save a banner screenshot and the actual notice and settings text, not just their current URLs. Record the capture time and any requests missed. A screenshot alone cannot show whether a tracker sent data.

  3. 3. Capture acceptance and persistence

    Record the exact control clicked, selected purposes and timestamp. Save the resulting preference record, storage changes and network trace. Reload and check whether the choice persists.

    Compare the observed requests with your intended configuration. Test granular choices separately where offered. A preference cookie is evidence of a stored state, not proof that every downstream vendor respected it.

  4. 4. Capture rejection in a separate clean session

    Repeat the same URL, observation period and actions. Save the reject control, resulting preference state, storage inventory and network trace. Reload or navigate and repeat the observation.

    Record expected versus observed behaviour for each tag. A loaded script is not automatically proof of tracking. Inspect the request and configuration; document uncertainty rather than labelling every request a breach.

  5. 5. Test withdrawal after acceptance

    In an accepted session, reopen preferences and withdraw the relevant choices. Record the route, action and timestamp. Capture the changed preference state and subsequent requests, including after reload.

    Withdrawal must be as easy as giving consent under GDPR Article 7(3). Check that consent-based processing stops. Withdrawal does not automatically require deleting every cookie; document what each remaining item does.

  6. 6. Assign a finding and a retest

    Group the captures under their test identifier. State the expected control, observed result, evidence location, uncertainty, owner and remediation. Repeat the same sequence after a fix.

    Keep original captures alongside the retest rather than replacing them. Use test accounts and redact customer data, session tokens and identifiers before sharing traces. Apply a documented retention period and restrict access.

Copy this evidence manifest

Use 1 copy for each state and repeat it for each tested browser or region. Keep capture files in a restricted evidence folder.

Test ID: [unique identifier]
Captured at: [ISO timestamp with timezone]
URL / release / CMP version: [values or unknown]
Browser / device / region: [test context]
Clean-session method / browser protections: [details]
State: [before choice | accept | reject | withdrawal]
Action / selected purposes / action time: [details]
Observation period / navigation: [details]
Notice version / screenshot / trace / storage files: [locations]
Expected behaviour: [control to verify]
Observed behaviour: [what the captures show]
Capture gaps / uncertainty: [limits]
Finding / owner / remediation / retest date: [details]
Access / redaction / retention rule: [details]

Mark missing captures as unknown. A browser protection, cached preference or incomplete trace can explain an apparent absence of requests.

Separate configuration evidence from individual consent proof

GDPR Article 7(1) requires the controller to demonstrate consent where processing relies on it. EDPB Guidelines 05/2020, paragraph 108, explain that referring only to the correct website configuration is insufficient.

The ICO recommends recording who consented, when, how, what they were told and whether they withdrew. Retain the relevant historic notice and granular purpose choices, not unnecessary personal data.

Link operational tests to the appropriate consent records without publishing visitor identifiers. EDPB paragraphs 106–107 address minimisation and retention; there is no universal evidence-storage period in this checklist.

Review our consent-record retention guide and banner requirements checklist for related decisions.

When the toolkit helps

The manifest above is free. If you need worksheets for assigning gaps and recording remediation, the Consent Self-Audit Toolkit costs $29 USD once. It includes a PDF playbook and editable CSV templates. It is not a browser test or a compliance certificate.

Get the toolkit — $29 USD

Have the worksheets already? Use the free manifest and retest; you do not need another purchase.

Questions before you share the record

Is the free scan enough?

No. DataVow’s Consent Checker inspects the initial HTML response. It does not run this browser sequence or prove that requests were blocked.

Does every remaining request mean a failure?

No. Identify its purpose, payload and applicable rule before drawing a conclusion. An essential request and an advertising request need different analysis.

Can I share the raw network trace?

Review it first. Traces can contain tokens, identifiers and customer data. Share a redacted copy securely and restrict access to originals.

Official references

DataVow’s site and business are built and run by AI agents on NanoCorp.