OneTrust is excellent software. It's also the most expensive consent management platform on the market by a meaningful margin, and the cost gets justified to the budget approver by a single argument: "this makes us compliant." That argument is half true. OneTrust gives you the platform that makes compliance possible. It does not, by itself, make you compliant — and the gap between those two things is where every company we audit has work to do.
This isn't a critique of OneTrust. The platform is correctly built; the gap exists because compliance isn't really a software problem. It's an implementation, configuration, and ongoing-maintenance problem, and OneTrust is one input into that work rather than a substitute for it. Here's the gap we see consistently, what it actually costs, and what closing it looks like in practice.
The thing OneTrust does that's worth paying for
Credit where it's due. OneTrust handles the parts of consent management that genuinely need an enterprise platform: multi-jurisdiction rule sets (GDPR, CCPA, LGPD, PIPEDA, and dozens of others), geolocation-aware banner serving, multilingual templates, the audit-ready consent receipt database with change history, automated cookie discovery scanning, and integration APIs that connect to the broader privacy and data governance work most enterprises do alongside cookie consent. For a company operating across multiple regions with legal or compliance teams that need real audit trails, this is the work OneTrust does well, and a smaller platform genuinely couldn't.
That capability is what shows up in the proposal and what gets approved. What doesn't show up in the proposal is everything that has to happen after the contract is signed for the platform to actually deliver the compliance it enables.
What "implementation" actually means
The phrase "implement OneTrust" suggests a discrete project with a beginning and an end. In practice, real OneTrust implementation has at least five components, and skipping any of them produces a paper-compliant site that wouldn't survive a real audit.
Cookie inventory and classification. Every cookie and tracker on the site has to be identified, categorized, and mapped to a consent rule. The OneTrust scanner finds most cookies but misses scripts that load conditionally, on certain page types, or behind logins. The inventory has to be completed manually for the parts the scanner can't see. Classification is judgment work — a tracking pixel categorized as "functional" when regulators would categorize it as "marketing" is a real gap, regardless of what the OneTrust admin panel says.
Tag stack integration. The site's tag manager, hard-coded scripts, plugin-loaded scripts, theme assets, and any other source of tracking has to be routed through a consent-respecting layer. Anything that bypasses that layer fires regardless of consent. Most sites we audit have multiple bypasses they didn't know about.
Geolocation and rule configuration. Different jurisdictions require different consent models, and OneTrust serves the right model based on visitor location. The geolocation rules, banner templates, and consent models for each region all have to be configured deliberately. Get the geolocation wrong and you're delivering the wrong consent flow to the wrong audience, which is its own kind of non-compliant.
Testing under real conditions. The OneTrust preview mode shows you what the banner looks like. It doesn't tell you whether trackers actually wait for consent when a real user denies it. The only way to confirm enforcement is to test the live site with real network monitoring, on real pages, in real browsers — and to do this routinely, not just at launch.
Ongoing audit and maintenance. New plugins get installed. Marketing teams add new pixels. OneTrust updates its category structure. Regulations evolve. A consent system that was clean six months ago has usually accumulated gaps. Without a regular audit cadence — at minimum quarterly — the implementation degrades while everyone assumes it's still working. This is the same pattern we see across infrastructure work — digital infrastructure matters more than design alone precisely because what's underneath has to be actively maintained, not just installed.
What we actually find in audits
The patterns repeat. The audits we run on existing OneTrust implementations find the same handful of gaps with frustrating regularity.
Hard-coded tracking pixels in the theme that bypass consent entirely. Tag manager triggers built on outdated category names that don't match OneTrust's current configuration. Unclassified cookies allowed by default because the setting was never changed to "Block until classified." Custom banners that look correct but don't actually call OneTrust's consent API on click. Geolocation rules that serve the US banner to EU visitors because the CDN is masking the real IP. Marketing pixels added through page builder modules that the consent layer never sees. Cached pages serving consent configurations from before the last update.
None of these are exotic. Each is a known failure mode with a known fix. They persist because nobody is actively looking for them, and OneTrust is correctly assumed to be "working" because the visible parts work.
The compliance cost of partial implementation
The exposure isn't theoretical. GDPR enforcement actions have explicitly cited insufficient cookie consent enforcement as the basis for penalties, and the trend in 2026 is toward more aggressive enforcement, not less. CCPA and CPRA enforcement in California has followed the same direction. The defense "we installed OneTrust" doesn't address the regulator's actual concern, which is whether the consent rules were enforced on actual visitor traffic.
Beyond regulatory exposure, there's a quieter cost: marketing tagging that doesn't behave consistently is hard to trust. Analytics data that includes pre-consent traffic mixes consented and non-consented users in ways that distort everything downstream. Attribution gets unreliable. Audience building for advertising gets compromised because the consent state the ad platform thinks it has doesn't match what the user actually granted. The system works in theory and produces bad data in practice.
Why this gap exists in nearly every implementation
It's worth being honest about why this is so common, because the cause shapes the fix. Consent management platforms are usually deployed by marketing or web teams without involving privacy experts at the implementation level. Scripts get added directly to tag managers without checking consent rules. The launch deadline rewards getting the banner live over getting the enforcement airtight. Nobody owns the system after launch, so drift accumulates.
The pattern isn't malicious or even careless. It's the predictable result of treating a complex, ongoing implementation as a one-time project handed off between teams. Closing the gap means treating it differently.
What closing the gap actually looks like
The shape of a real implementation engagement, in our experience:
Start with an audit of the current state — what's installed, what's configured, what's actually enforced, where the gaps are. Document the gap analysis honestly so the business knows what it's working with. Build the inventory of cookies and scripts properly, including the conditionally-loaded ones the scanner misses. Standardize the tag stack so everything routes through a consent-respecting layer. Configure geolocation rules and verify them with real test traffic. Test enforcement end-to-end under real conditions, not just preview. Establish the maintenance cadence and assign clear ownership.
This is a project with a beginning, but it doesn't have an ending — the maintenance phase is the system's permanent state. Treating it that way is how OneTrust delivers on the compliance it enables.
Where Lion Ridge fits
Closing the implementation gap is exactly what we do for clients who have OneTrust installed but aren't confident it's actually working as a compliance system. The work is technical, ongoing, and specific enough that most agencies and freelancers can't do it well. Treating it as part of strategic maintenance rather than a one-time setup is how it actually stays compliant — the same discipline we describe in our broader WordPress development guide.
If you've bought OneTrust and aren't sure whether your implementation matches what your compliance team thinks it does, an audit is the right first step — and we'd rather tell you "everything's fine" honestly than find gaps that don't exist. Tell us what you're working with and we'll give you a straight read.
