When someone says "audit your consent setup," they usually mean GTM. Check the tags, make sure consent types are configured, verify the CMP is connected. That covers one part of it. Consent compliance touches at least four systems that operate independently, and a misconfiguration in any one of them can undermine the others. A container with perfect tag-level consent settings can still have compliance gaps if the CMP dashboard classifies cookies incorrectly, or if server-side cookies bypass the entire client-side stack.
This piece maps where consent lives, what each part controls, and what falls between the gaps. Not a framework. Just the full surface area, organized so you know where to look.
GTM tag consent settings
The part most people audit first, and for good reason. Each tag in GTM can have consent settings that determine whether it fires normally, fires in degraded mode (cookieless pings), or stays silent based on the visitor's consent state.
There are two consent mechanisms in GTM and they work independently. Built-In consent checks are embedded in Google's native tag templates. GA4 tags automatically check analytics_storage. Google Ads tags check ad_storage, ad_personalization, and ad_user_data. These are template-enforced, not editable, and always active when consent mode is running on the page. When consent is denied, native tags fire in a cookieless mode that sends anonymized pings to Google for conversion modeling without setting cookies or transmitting identifiers.
Additional consent checks are configured by whoever manages the container. They can add a hard gate on top of Built-In consent, or specify consent requirements for tags that don't have Built-In protection. Custom HTML tags, LinkedIn Insight tags, Reddit Pixels, and community templates have no Built-In consent. For those tags, Additional consent is the only thing standing between the tag and unconsented data collection.
This layer is what a GTM container audit covers. It's the right place to start, and for many containers it's where the most actionable findings are. But it's not the whole picture.
CMP cookie classification
Your consent management platform (Cookiebot, OneTrust, CookieYes, Usercentrics) does two jobs. It collects the visitor's consent choice through the banner, and it communicates that choice to GTM through consent mode commands. But the CMP also maintains a dashboard where every detected cookie on your site is classified into a consent category: Necessary, Statistics, Marketing, Preferences.
This classification is upstream of GTM. It determines what the consent banner tells the browser about each cookie. If your CMP classifies _ga (Google Analytics) as "Necessary," the browser treats that cookie as essential. It sets regardless of what the visitor chose on the consent banner, and regardless of what GTM's tag-level consent settings say. The CMP told the browser this cookie doesn't need consent, so consent mode never gets a chance to intervene.
The same applies to advertising cookies. If test_cookie from doubleclick.net is classified as "Necessary" in your CMP dashboard, that Google Ads cookie fires without consent. Your GTM consent configuration for Google Ads tags is irrelevant because the CMP has already told the browser the cookie is exempt.
The CMP dashboard is where cookies get mapped to consent categories, and those mappings drive the actual consent behavior. If the mappings are wrong, the consent banner tells the browser the wrong thing. Cookiebot's GTM deployment docs and CookieYes's consent mode setup guide cover the integration mechanics, but the classification accuracy is a manual review task that no integration can automate.
Consent mode defaults
Before any tags fire, the gtag('consent', 'default', {...}) command declares the initial consent state. Typically this sets all consent types to "denied" until the CMP reports the visitor's actual choice. The wait_for_update parameter tells GTM how long to wait for the CMP to deliver that choice before tags proceed with the denied defaults.
This has to execute before everything else. In GTM, consent default tags should fire on the Consent Initialization trigger, which runs before all other triggers. If the CMP tag fires on All Pages or DOM Ready instead, there's a timing window where tags make consent decisions before the CMP has set the state. In advanced consent mode, that window means lost cookieless pings. In basic mode, tags may briefly fire with no consent state at all.
The waitForUpdate setting is the one most commonly misconfigured. At 0 (the default if not explicitly set), GTM doesn't wait for the CMP. Tags make their fire-or-don't-fire decision immediately, and the CMP catches up afterward. Bounteous's consent mode mistakes guide covers this and several other timing-related issues. Google's consent mode setup documentation specifies 500ms as the recommended value.
This sits between the CMP and GTM's tag-level settings. It's easy to get right, easy to miss, and invisible from the outside. You can't tell from looking at a consent banner whether waitForUpdate is configured correctly. You have to check the GTM container or use Preview mode.
What sits outside GTM entirely
Two categories of things that affect consent compliance but that no GTM audit can see.
Server-side cookies. Cookies set in HTTP response headers by the web server rather than by JavaScript running in the browser. UTM cookies, session identifiers, custom tracking parameters. These are set before any client-side code executes, which means they bypass GTM, the CMP, and consent mode entirely. A CMP scanner can detect them and classify them in the consent banner for display purposes, but the CMP can't actually block them. Blocking a server-side cookie requires a server-side code change, which is a different team, a different codebase, and a different conversation. Usercentrics's server-side consent guide covers the architecture. For the legal perspective on what this means for compliance, JD Supra's overview is a useful starting point.
Third-party scripts loaded outside GTM. Scripts hardcoded in the page template, injected by WordPress plugins, loaded by third-party embeds. Chat widgets, review platforms, job board integrations, analytics tools installed by a developer rather than through GTM. These scripts load directly when the page renders, often before the consent banner appears, and they set cookies that no GTM consent setting controls.
The fix for third-party scripts is either routing them through GTM (so they're subject to consent settings), enabling CMP autoblock features (which attempt to block script execution until consent is granted), or documenting them as a known gap. Routing through GTM is the most reliable approach, but it requires the script to be compatible with tag manager deployment, which isn't always the case.
What to do with this
No single tool or audit covers all of this. That's not a limitation to work around. It's just how consent works. The systems are separate, maintained by different people, and need to be checked independently.
A practical sequence:
- Audit your GTM tag consent settings. Check that tags use the correct consent types, that Built-In and Additional consent are configured appropriately, and that the CMP is wired to GTM correctly. TagManifest checks this layer as part of a container scan.
- Review your CMP cookie classification. Open the CMP dashboard and check that cookies are categorized correctly. Look specifically for analytics or advertising cookies classified as "Necessary" and for unclassified cookies that have accumulated since the last review.
- Verify consent mode defaults. Check that the consent default command fires before your tags, that it runs on the Consent Initialization trigger, and that
waitForUpdateis set to at least 500ms. - Run a CMP scan. Cookiebot, OneTrust, and CookieYes all offer automated site scans that detect cookies from all sources, including server-side and third-party scripts that GTM can't see. The scan results tell you what's on your site. The classification review tells you whether those cookies are categorized correctly.
- Document what sits outside your control. Server-side cookies that need backend changes, third-party scripts that can't be routed through GTM, embeds from platforms you don't control. Documenting these as known gaps is better than pretending they don't exist.
If you want to go deeper on the GTM layer specifically, the consent and compliance category reference covers all 12 consent rules. How to tell if your consent setup is doing what you think walks through the verification process. And for the foundations of how consent mode works, where to start with GTM consent covers the concepts from the ground up.