Scan rule · RSC-PRV-025
Reject has no effect — trackers still load
Clicks the detected “reject” control of the consent banner in the browser and observes whether tracking services are still contacted or tracking cookies still set afterwards — the differential scan that makes an existing banner actually mean something.
Why this matters
A consent banner is not an end in itself: its job is to make sure nothing is stored on the device and no tracking service is contacted without consent. § 25 TDDDG demands exactly that — and an explicitly refused consent is the clearest case in which nothing may load. Anyone who still loads Google Analytics, the Meta pixel or Hotjar after a click on “reject” does not lack a banner; they have a banner that does nothing.
In generated and quickly built apps this is the rule, not the exception: the consent tool is added because it belongs there — but the tracking snippets still sit in the page head and run regardless of what the visitor clicks. From the outside the banner looks correct, with accept and reject on the same level. Only the click reveals the difference, and that is exactly what this scan does.
Check it yourself: open the site in a private window, open the network tab, choose “reject” in the banner and filter the list afterwards for `google-analytics`, `facebook` or `hotjar`. Every hit after the click is the finding. The fix is wiring, not wording: load scripts only when the decision allows it — every consent tool offers a mode for that (blocking mode, consent mode, script gating).
Scan tier
How to fix it
Gate every non-essential script on the consent decision so that “reject” actually blocks it — and verify the click afterwards in the network tab.