What a Consent Audit Finds Inside the Tag Manager
A consent audit that stops at the banner misses the failure that matters. Inside the tag manager, the recurring findings are tags with no consent check at all, triggers that fire on page view before the consent state exists, and duplicate containers left over from an agency handover, each one loading the other one's mistakes.
Tags that never ask the consent state
Every tag in the container should sit in one of two groups: it checks the consent state before it fires, or it is genuinely exempt because it sets nothing and reads nothing. In real containers the second group is small and the first group is where the audit spends its time. Marketing pixels added during a campaign rush tend to fire on all pages with no consent condition attached, because the person adding them was measured on launch date, not on compliance.
The audit method is mechanical. Export the container, list every tag with its trigger and its consent settings, and sort by the ones with no consent check. Then load the site with consent denied and watch the network tab. Anything that still phones home is a finding with a screenshot attached, and the screenshot is what turns an argument about settings into a fix on the backlog.
Trigger timing is a consent bug
A tag can have the right consent condition and still fire too early. If the trigger runs on page view and the consent tool writes the consent state a moment later, the tag evaluates against an empty state and the default decides the outcome. Where the default is granted, the tag fires. Where the setup is sound, the default is denied until the stored choice loads, and the tag waits for the consent update event instead.
Copied containers carry this bug between sites. A container exported from a property where the consent tool loads in the head gets imported into a property where it loads late, and every timing assumption silently changes. The audit should record the consent tool load position alongside the container version, because the pair, not either one alone, determines what actually fires. See also The Consent Record Export Test Every Team Should Run Once a Quarter for how we test the denied state end to end.
The findings that repeat across audits
Three findings show up often enough to check first. A legacy analytics tag and its replacement both firing, doubling collection under one consent. A chat or video embed loading its own trackers outside the container entirely, invisible to the tag audit and visible in the network tab. And test tags from a staging container published to production during a late fix, still firing months later because nobody owns the container after the agency leaves.
Close the audit with ownership, not just fixes. One named person approves container publishes, the export is archived with each release, and the denied state test reruns after every publish. Consent tooling drifts the moment publishing becomes unowned, and the drift always moves in one direction: more collection than the notice describes.
Keep reading: The Consent Record Export Test Every Team Should Run Once a Quarter When Purposes Change, Consent Has to Be Asked Again Dark Pattern Consent Banners: The Designs Regulators Name in Complaints.
Frequently asked questions
How often should a tag manager consent audit run?
Run the full audit quarterly and the denied state network test after every container publish. Publishes are when tags and triggers change, and a five minute denied state check catches the class of bug that quarterly audits otherwise find months late.
What is the fastest way to find tags firing without consent?
Load the site fresh with consent denied and record the network requests, then compare the hosts against the vendor list in your privacy notice. Any host not on the list, or listed but firing before a choice, is a finding. The container export then tells you which tag or embed produced it.
Can a tag with correct consent settings still fire too early?
Yes. If the trigger evaluates before the consent state loads, the default value decides. Sound setups default to denied and fire consent dependent tags on the consent update event, so timing cannot turn a missing state into a granted one.
Who should own container publishing?
One named person or role, with publishes archived and reviewed. Agency access is fine, unowned access is not. Most repeat findings trace back to containers that several teams could publish to and no team was responsible for checking.