Your Cookie Banner Is Not Enough: How to Scan Storage and Access Technologies

A cookie banner is not proof of compliance.

It is only a user interface.

The real question is whether the browser behaves correctly before and after the user makes a consent choice.

That distinction became even more important after the UK ICO's April 2026 guidance on Storage and Access Technologies. The guidance makes clear that the relevant compliance scope is not limited to HTTP cookies. It includes cookies, tracking pixels, link decoration, local storage, device fingerprinting, scripts, and tags. The ICO also states that PECR applies where scripts and tags store or access information on a user's device, whether or not they are used together with cookies.

In practical terms:

A website can show a compliant-looking consent banner and still fail because tracking technologies fire before consent.

This article explains how to audit that properly.

1. The problem: banner compliance vs browser compliance

Most compliance checks still focus on the visible banner:

A scientific audit must compare declared behavior with observed behavior.

Declared behavior is what the CMP, privacy policy, or cookie list says.

Observed behavior is what actually happens in the browser: cookies, storage entries, network calls, scripts, tags, and device access.

The gap between those two is where many compliance failures appear.

2. What counts as storage and access technology?

The ICO's SAT guidance is intentionally broad. It covers technologies that store information on a device or access information already stored there. The ICO lists cookies, tracking pixels, link decoration and navigational tracking, local storage, device fingerprinting, scripts, and tags.

That means an audit should not be called a "cookie audit" unless it is only checking cookies.

A modern website audit should cover:

The ICO also explains that tags often use other technologies such as cookies, local storage, or fingerprinting techniques to record and track information about a user.

So the scanner must observe chains of behavior, not just isolated files.

3. The legal logic: prior consent and real choice

Under PECR, storing information on or accessing information from a user's terminal equipment generally requires clear and comprehensive information and consent, unless an exception applies. The ICO explains that non-exempt storage and access technologies must not be used before consent is obtained.

The EDPB's consent guidance under GDPR is also relevant because, where consent is required under ePrivacy-style rules, the GDPR standard of consent applies. The EDPB defines consent as freely given, specific, informed, and unambiguous. It also rejects consent by scrolling or continued browsing as valid consent.

For a scanner, this translates into concrete rules:

The key point: legal compliance depends on both interface design and technical enforcement.

4. The four consent states every scanner should test

A serious audit should not test only one browser state.

It should run controlled tests across at least four states.

For advanced audits, add two more:

This is important because many sites pass the first page-load test but fail after a state change.

Example:

1. The site loads cleanly before consent.
2. The user accepts all.
3. The user later withdraws consent.
4. The website stops setting new cookies but leaves localStorage tracking IDs active.
5. Third-party scripts continue firing because tag-manager rules were not updated.

That is not a banner problem. It is a consent-state enforcement problem.

5. What to capture during the scan

A good scanner should produce evidence, not only a pass/fail label.

5.1 Browser storage evidence

Capture storage before and after each consent action.

The scanner does not always need to expose full values in a public report. For privacy and security, values can be hashed or redacted. But the audit should still record enough evidence to prove that storage existed and when it appeared.

5.2 Network evidence

Network requests are often more important than storage.

A pixel can fire without leaving a persistent cookie. A script can send browser metadata before creating any visible storage entry. A tag can redirect through multiple domains before consent.

Capture:

This is where many "cookie-compliant" sites fail: no cookie appears, but tracking requests still happen.

5.3 Script and tag evidence

Scripts and tags are especially important because the ICO explicitly includes them where they store or access device information.

Capture:

Tag managers are common failure points because teams add new tags without updating CMP rules or legal inventories.

6. How to classify findings scientifically

Do not classify findings only by vendor name.

Classify them by observed behavior, purpose, timing, and consent state.

A useful finding model:

This prevents a common mistake: assuming a vendor is always compliant or non-compliant.

The same vendor may provide both necessary and non-necessary functions. The same script may support security, analytics, and advertising. The same cookie may be first-party but still used for advertising.

Purpose and timing matter more than labels.

7. Failure taxonomy: what your scanner should detect

Failure 1: Pre-consent tracking

Definition: A non-exempt technology fires before the user gives consent.

Examples:

Severity: High or critical, depending on purpose and data involved.

Failure 2: Reject does not block

Definition: The user clicks "Reject all", but analytics, advertising, or personalization technologies still run.

This is one of the strongest findings because it proves the interface and technical behavior are inconsistent.

Failure 3: Misclassified technology

Definition: A technology is classified as necessary or functional but performs analytics, advertising, personalization, or behavioral measurement.

Example:

Failure 4: Hidden vendor

Definition: A third-party domain appears in the browser but is missing from the cookie policy, CMP vendor list, or privacy notice.

This creates a transparency problem because users cannot make an informed choice if the real vendors are not disclosed.

Failure 5: LocalStorage bypass

Definition: Cookies are blocked, but persistent identifiers are written to localStorage or another browser storage mechanism.

This is exactly why audits must go beyond cookies.

Failure 6: Link decoration persistence

Definition: Campaign or click identifiers are stored or propagated after landing.

Examples include advertising click IDs, affiliate IDs, campaign IDs, and user journey parameters. Link decoration can be part of attribution and tracking, so it should be inspected under storage/access and transparency rules.

Failure 7: Consent withdrawal failure

Definition: The user changes their choice from accept to reject, but existing tracking remains active or new tracking continues.

This is often missed because many audits test only the first page load.

Failure 8: Deceptive consent design

Definition: The interface manipulates the user into accepting.

The EDPB's deceptive design pattern guidance treats misleading, detrimental, or manipulative interface behavior as relevant to fairness, transparency, accountability, and data protection by design.

Examples:

8. A practical scan methodology

Here is a practical step-by-step method for compliance teams and scanner builders.

Step 1: Start from a clean browser profile

Use a fresh context with:

Run separate tests for desktop and mobile because banners, ad stacks, and video players often differ across devices.

Step 2: Capture initial page state

Before clicking anything:

1. Take screenshot of banner.
2. Capture all cookies.
3. Capture localStorage and sessionStorage.
4. Capture network requests.
5. Capture third-party scripts.
6. Record timestamp.
7. Detect CMP and consent categories if available.

This is the most important stage. Anything non-exempt that runs here is a likely pre-consent issue.

Step 3: Classify initial findings

For each detected item, classify:

Avoid overclaiming. If purpose is uncertain, mark it as unknown vendor/purpose requiring review, not automatically illegal.

Step 4: Click "Reject all"

After rejection:

1. Capture storage again.
2. Capture network activity for a fixed window.
3. Reload the page.
4. Capture storage and network again.
5. Navigate to another page type.
6. Compare with pre-consent state.

A strong reject test should answer:

Step 5: Click "Accept all"

This creates the positive baseline.

Capture:

The accept state helps distinguish technologies that are genuinely consent-gated from those that fire regardless of choice.

Step 6: Test granular choices

For example:

Many CMPs fail here because categories are visually granular but technically bundled.

Step 7: Test withdrawal

After accepting all:

1. Open privacy settings.
2. Change to reject all.
3. Save choice.
4. Reload.
5. Capture storage and network.
6. Confirm non-essential tools no longer fire.

Withdrawal is important because GDPR consent must be withdrawable, and PECR compliance depends on ongoing control where consent is the basis for storage/access.

Step 8: Compare page types

One page is not enough.

Test at least:

A site can pass on the homepage and fail on video, checkout, or article pages.

9. What the report should show

A useful compliance report should be readable by legal, engineering, and marketing.

Executive summary

Evidence table

Technical appendix

Include:

For stronger evidence, generate timestamped reports and hash the raw audit artifacts.

10. How to avoid false positives

A scientific scanner must be careful.

Not every cookie is unlawful. Not every script is tracking. Not every third-party request is advertising. Some storage may be strictly necessary.

Examples of legitimate or lower-risk technologies:

The scanner should flag uncertain cases as review needed rather than pretending legal certainty.

A good report separates:

This distinction increases trust.

11. Remediation: how to fix common issues

Problem: Tags fire before consent

Fix:

1. Move tags behind CMP consent checks.
2. Configure tag-manager triggers by consent category.
3. Block default firing until consent is known.
4. Test in clean browser state.
5. Retest reject and withdrawal.

Problem: localStorage identifiers appear before consent

Fix:

1. Identify the script creating the key.
2. Classify its purpose.
3. Delay script execution until consent.
4. Remove or rotate identifiers after withdrawal.
5. Add storage checks to regression tests.

Problem: Vendor list is incomplete

Fix:

1. Export all third-party domains from scans.
2. Map domains to vendors.
3. Update CMP/vendor disclosure.
4. Remove unused vendors.
5. Repeat scan after deployment.

Problem: Reject button exists but tracking continues

Fix:

1. Validate CMP event callbacks.
2. Check tag-manager consent mode.
3. Confirm categories are not bundled.
4. Test after reload and page navigation.
5. Add automated reject-state monitoring.

Problem: Consent banner uses dark patterns

Fix:

1. Make accept and reject equally accessible.
2. Remove preselected optional choices.
3. Use clear labels.
4. Avoid misleading category names.
5. Provide easy privacy settings access.

12. A simple scanner checklist

Use this checklist for each audited URL.

Conclusion

A cookie banner is only the surface layer of compliance.

The real compliance question is whether non-exempt storage and access technologies are technically controlled across real user choices.

A modern scanner must therefore test:

1. cookies,
2. localStorage,
3. sessionStorage,
4. pixels,
5. scripts,
6. tags,
7. link decoration,
8. fingerprinting signals,
9. network requests,
10. consent state transitions.

The ICO's 2026 SAT guidance makes this broader audit model difficult to ignore. PECR is not limited to cookies, and neither should your compliance testing be.

The practical standard for 2026 is:

Do not trust the banner. Test the browser.

Sources

1. ICO, Guidance on the use of storage and access technologies.
2. ICO, About this guidance: what does it cover?
3. ICO, What are storage and access technologies?
4. EDPB, Guidelines 05/2020 on consent under Regulation 2016/679.
5. EDPB, Guidelines 03/2022 on deceptive design patterns in social media platform interfaces.