What should a store do when a vendor script ignores consent?
When a vendor script fires despite a reject choice, first prove it with a clean test: reject all, then watch the network tab for the vendor's requests. If it fires, contain it immediately with a blocking rule in your tag manager or consent tool, then take the evidence to the vendor. A script that ignores consent is a compliance liability you are hosting, and containing it is your responsibility even if the bug is the vendor's.
Prove it with a clean reject-all test
Open a fresh browser profile, load the store, reject all on the banner, and watch the network requests. Filter for the vendor's domains. If requests fire after a reject, you have a rogue script. Screenshot the network tab with the banner's reject state visible, and save the page's consent state from the consent tool's debug output. This is the evidence package for everything that follows.
Run the test twice: once with the vendor's tag firing through your tag manager, and once with any direct script include. The fix depends on which path the script takes, and vendors sometimes load through both.
Contain it at your layer first
Do not wait for the vendor to fix their script. Add a blocking rule: the vendor's tag must not fire until the relevant consent is granted. In most tag managers this is a consent condition on the tag or a trigger exception. For hardcoded scripts, wrap the include in the consent check your banner provides, or move the vendor into the tag manager where you can control it.
Re-run the reject-all test after containing it. Containment is only real if the network tab stays quiet. Some vendor scripts are persistent: they load secondary scripts or pixels from other domains, and blocking the first request does not stop the second. Watch for the full chain.
Escalate to the vendor with the evidence
Send the vendor the evidence package: the reject state, the network log, and the script URL. Ask for a written answer to two questions: does their script respect consent signals, and if so, which mechanism should a store use to gate it. Vague answers are an answer: the script does not respect consent, and you are now containing it permanently.
Keep the ticket. If the vendor later claims their script is consent-aware, your test history is the rebuttal. And if you are evaluating vendors, add consent behavior to the scorecard. A vendor that ignores reject-all is a vendor that creates liability on your domain.
Audit the rest of the stack while you are in there
One rogue script usually means the audit is overdue. Run the reject-all network test across the whole vendor stack: review widgets, chat tools, personalization, affiliate pixels. Vendors added through app installs are the usual suspects, because nobody gated them when they were added. A quarterly vendor consent audit turns this from an incident into a routine.
Put consent behavior in the vendor contract
Technical containment fixes this incident. Contract language prevents the next one. When signing or renewing a vendor, require that their scripts respect the consent signals your banner sets, and ask for documentation of how. Vendors that cannot answer do not get installed, or get installed behind your blocking rules permanently.
This is becoming standard diligence, not paranoia. Privacy regulators are moving toward holding the site operator responsible for what loads on their pages, regardless of whose script it is. A vendor questionnaire that covers consent behavior, data collection, and subprocessors belongs in every procurement process.