Consent setups don't stay fixed. Someone adds a tag without thinking about consent settings. A WordPress plugin injects a new script that creates cookies your CMP hasn't classified. The consultant who configured everything originally moves on, and the next person doesn't know what the intended design was.
None of this is unusual. It's how websites work. New tools get added, people change roles, vendors update their products. The question isn't whether your consent setup has drifted. It's whether you have a way to catch it when it does.
Here are 7 things that help. None of them require you to become a consent expert. Most take less than an hour.
1. Run your CMP's scanner regularly
Cookiebot, OneTrust, CookieYes, Usercentrics. They all scan your site and report on cookies. Most people configure this during setup and forget about it.
Run it quarterly at minimum. New cookies show up as "unclassified" in the scan results. Unclassified cookies in your consent banner mean visitors can't make informed choices about them. More practically, unclassified cookies from advertising vendors can put your Google Ads account at risk if you're serving EEA traffic under DMA requirements.
The scan takes minutes. Reviewing the results takes an hour. It's the single highest-return consent maintenance task you can do.
2. Check new tags for consent settings before publishing
GTM shows a warning badge when you try to publish if any tags have consent set to "Not set." It's easy to dismiss. Don't.
Every new tag needs a consent decision. Does it have Built-In consent from the template? If not, does it need Additional consent configured? Is it a third-party pixel that requires ad_storage? Making this decision at publish time takes 30 seconds per tag. Discovering the gap in an audit three months later, when you've lost data or created a compliance issue, takes much longer.
The GTM UI is doing you a favor with that warning badge. Treat it as a gate, not a nuisance.
3. Know which tags have Built-In consent and which don't
Google's native templates (GA4, Google Ads, Conversion Linker) have Built-In consent checks that are always active when consent mode is running. Custom HTML tags, community templates, LinkedIn Insight, Reddit Pixel, and most third-party tags have none.
The tags without Built-In protection are the ones that need your attention. A Custom HTML tag with consent set to "No additional consent required" has no consent gate at all. It fires unconditionally regardless of what the visitor chose on the consent banner.
If you're not sure what your tags have, Simo Ahava's consent settings post explains which templates include Built-In checks and which don't.
4. Audit your CMP cookie classifications annually
Cookies get misclassified. New cookies appear and default to "unclassified." Vendor cookies change behavior between versions. A cookie that was correctly classified as "Statistics" when you set up the CMP might be doing something different now.
Open your CMP dashboard once a year and review the classifications. Three things to look for:
Analytics or advertising cookies classified as "Necessary." This is the most common error. If _ga is in the Necessary category, GA4 cookies fire regardless of the visitor's consent choice. The CMP told the browser these cookies are essential, so consent mode was never invoked. Same applies to test_cookie from doubleclick.net or any advertising cookie in the wrong category.
Unclassified cookies that have accumulated. Every unclassified cookie is a decision that hasn't been made. Review them and assign the correct category.
Cookies from vendors you no longer use. If you removed a tool six months ago but its cookies are still in your CMP's classification list, clean them out. Stale entries make the real classifications harder to review.
5. Watch for scripts loaded outside GTM
Not every tracking script goes through GTM. WordPress plugins add scripts directly to the page template. Chat widgets inject their own tracking. Review tools, job boards, and embedded forms load their own pixels. These scripts create cookies that your GTM consent setup doesn't control.
When you add a new tool to your site, ask: does it load through GTM or directly in the page? If it's direct, does your CMP's autoblock feature cover it? If not, that script runs before consent and sets cookies regardless of the visitor's choice.
This isn't a reason to panic. It's a reason to check when you add new tools. Routing scripts through GTM is the most reliable fix, but not every script is compatible with tag manager deployment. For those that aren't, document them as a known gap and ensure they're at least classified in your CMP for display purposes.
6. Verify consent mode defaults haven't been overwritten
The consent('default', {...}) command sets the initial consent state, typically all consent types denied until the CMP reports the visitor's actual choice. This command has to fire before everything else, on the Consent Initialization trigger, with a waitForUpdate value of at least 500ms.
If someone adds a new tag or modifies the Consent Initialization trigger, the defaults can break without anyone noticing. After any significant GTM changes, open Preview mode and check the Consent tab. Defaults should show all consent types as denied before the CMP updates them. If they don't, something changed.
This takes two minutes to verify in Preview mode. It can take weeks to notice from the data side if it breaks.
7. Document your consent configuration
The most common consent drift scenario isn't technical. It's organizational. The person who set it up leaves. Nobody knows what the intended configuration was. New people make changes without understanding the original design. Six months later, the container has correct settings, incorrect settings, and redundant settings that nobody can tell apart.
A one-page document is enough. What CMP you use and where the dashboard login lives. What consent types map to what categories. Which tags use Built-In vs Additional consent. What the waitForUpdate setting is and why. What the CMP's cookie scan schedule is.
If the next person can read this document and understand the setup in 10 minutes, you've solved the hardest part of consent maintenance.
The habit, not the project
Consent isn't something you configure once and walk away from. It's a maintenance discipline, like backups or dependency updates. The good news is the maintenance is lightweight once you build the habit. Quarterly CMP scans, consent checks at tag publish time, an annual classification review, and a configuration document that stays current.
TagManifest checks your GTM tag consent settings as part of a container scan. It covers one layer of this list. For the full picture of where consent lives beyond GTM, the other six items matter too.