Build a consent-state test matrix before release

Write the jurisdiction and product scope first

Consent behavior cannot be evaluated as a single global yes-or-no state. Start the matrix with the jurisdictional rule set selected by counsel or the responsible privacy owner, the user's region signal, the product surface, device, authentication state, and applicable vendor list. Record the policy version and test environment. This prevents a functional test in one region from being presented as universal legal approval.

Primary regulator guidance can bound technical questions without replacing legal analysis. UK ICO guidance explains that consent-dependent storage or access should follow an affirmative choice in its scope, while the EDPB's technical guidance discusses the reach of an EU ePrivacy provision. Neither source proves that a site's complete implementation is compliant. Translate approved requirements into observable expected behavior, and keep a legal-review status column.

Jurisdiction labels are test profiles, not legal conclusions.

Source notes: How do we manage consent in practice? · Guidelines 2/2023 on the technical scope of Article 5(3) of the ePrivacy Directive

Enumerate transitions, including failure states

Test initial visit with no stored choice, accept all, reject optional purposes, granular choices, withdrawal, expired choice, a materially changed vendor list, signed-in and signed-out transitions, and an unavailable consent service. Include back navigation, a second tab, embedded media, and a return visit. Each row should start from a clean, documented browser state so an old identifier does not contaminate the result.

For each transition, state what the interface should show, what storage may be written, which network requests may occur, what downstream signal should be sent, and how the user can revise the choice. Do not mark a test passed solely because a banner appeared. The functional question is whether page behavior follows the recorded state, including components loaded before the choice and vendors introduced after it.

Source notes: How do we manage consent in practice?

Capture evidence at the interface, storage, and network layers

Save a screenshot or accessibility-tree note for the interface, a storage diff, a network log filtered by known vendor domains, and the consent string or equivalent state passed downstream. Redact personal data and secrets before attaching evidence. Use a vendor register to map domains and scripts to purpose, owner, contract, and expected state; unexplained requests become findings rather than being casually labeled necessary.

A useful row has one expected and one observed statement. For example: after rejecting optional measurement under the selected profile, the optional analytics request is expected to remain absent; the observed network log contains no request during the defined test window. That is a bounded functional result. It does not establish that every page, device, jurisdiction, or future vendor configuration behaves the same way.

Replace expected behavior with requirements approved for the scoped jurisdiction.

Source notes: Guidelines 2/2023 on the technical scope of Article 5(3) of the ePrivacy Directive

Triage findings and retain a release record

Classify findings by exposure: optional calls before choice, withdrawal ignored, state lost across pages, interface inaccessible, unknown vendor, or evidence gap. Give each an owner and retest case. A release decision should identify which jurisdiction profiles were tested, which were excluded, which browsers and templates were sampled, and who accepted remaining gaps. Do not turn an untested row green by inference.

Retest when the consent platform, tag manager, vendor list, template loader, authentication flow, or policy changes. Keep the matrix small enough to run at every material release, then schedule broader sampling. The durable asset is the mapping from an approved requirement to observable behavior and evidence—not a permanent compliance badge.

• Reset browser state for every case.
• Verify keyboard and screen-reader access to choices.
• Compare storage and network activity before and after each transition.
• Record unknown domains as findings.
• Require scoped privacy or legal review before interpreting results.