In this guide:
- Why most CMP evaluations miss the CIPA-specific requirements
- The five-capability evaluation framework
- How to structure your vendor evaluation
- How PieEye performs against the framework
- Frequently asked questions
What makes a CMP CIPA-compliant? Not banner design. Not cookie categorization UI. Not the size of the vendor's compliance team. A consent management platform is CIPA-compliant if it technically prevents tracking from executing before consent is received — enforced at the tag execution level, not recorded in a database somewhere. The gap between a CMP that records consent and a CMP that enforces it is the gap between a UI element and a legal defense.
If you are evaluating consent management platforms for CIPA compliance specifically — not CCPA, not GDPR — this guide gives you the five technical capabilities that determine whether a CMP can actually protect you, and a framework for assessing any platform against them before you commit.
Why most CMP evaluations miss the CIPA-specific requirements
Most CMP evaluation processes are designed around GDPR and CCPA requirements. These are real compliance requirements and they matter. They are not what CIPA compliance requires.
CIPA has one core technical requirement: no interception before prior consent. That requirement is satisfied or not satisfied at the moment a tracking script attempts to execute in a user's browser. A CMP that displays a banner, records a preference, and stores that preference in a consent database has done everything GDPR requires and nothing CIPA requires. CIPA doesn't care what's in the consent database. It cares whether the tracking script fired before the database entry was made.
The evaluation criteria that matter for CIPA — TMS integration depth, default state configuration, script loading sequence, GPC implementation, server-side consent enforcement — are often not covered in standard CMP evaluation frameworks because they require technical assessment rather than feature checklist comparison.
The five-capability evaluation framework
Assess every platform you evaluate against all five. A platform that scores well on four and fails on one has a gap that will be visible to every automated scanning tool that crawls your site.
Capability 1: Pre-consent blocking — is tracking technically prevented from executing before consent is received?
What to look for: the CMP must integrate with your TMS at the script execution level. The integration must produce a default-denied state for all non-essential tags — the absence of a consent signal must be treated as no consent rather than pending consent.
How to test it: load your site in a fresh private browser with network monitoring open. Before interacting with the banner, observe outbound network requests. Any requests to third-party tracking domains before banner interaction confirm that pre-consent blocking is not working.
Questions to ask vendors: How does your platform integrate with GTM specifically? What is the default state for ad_storage and analytics_storage before a consent signal is received?
Red flags: vendors who describe banner loading time or consent record completeness when asked about pre-consent blocking are describing a recording architecture, not an enforcement architecture.
Capability 2: GPC detection — does the platform detect Global Privacy Control signals before the banner renders?
What to look for: GPC detection must happen at CMP initialization — reading navigator.globalPrivacyControl before the banner renders. The result must propagate to the consent state immediately, producing a denied state before GTM initializes.
How to test it: enable GPC in Firefox or install the GPC Chrome extension. Load your site in a fresh private session. No tracking requests should appear and no banner should appear.
Questions to ask vendors: At what point in the page initialization sequence does your platform read the GPC signal?
Red flags: vendors who describe GPC as a banner configuration option rather than a pre-initialization detection are implementing it incorrectly.
Capability 3: Server-side consent records — does the platform generate consent records on the server, queryable by date range?
What to look for: every consent interaction should generate a server-side record containing: consent ID, timestamp, consent state per category, banner version, signal source, browser type, device type, page URL. Records must be queryable by date range without engineering involvement and retained for at least three years.
How to test it: interact with the banner across multiple sessions. Ask the vendor to demonstrate retrieval by date range without engineering involvement.
Red flags: vendors who describe consent records as "available in your dashboard" without specifying server-side storage and direct legal team access are likely describing client-side records — not litigation-ready records.
Capability 4: TMS integration depth — how does the platform integrate with your tag management system, and what is the failure behavior?
What to look for: native GTM Consent Mode v2 integration with explicit default state commands (analytics_storage: denied, ad_storage: denied) that execute before GTM initializes. Failure behavior should be no tracking, not fallback tracking.
How to test it: in GTM's preview mode, verify that consent state is set before any tag fires. Test with browser extensions that delay JavaScript to simulate timing failures.
Red flags: vendors who describe their GTM integration as "compatible with Consent Mode" without specifying native default state configuration.
Capability 5: Server-side consent enforcement — does the platform offer server-side proxy enforcement?
Client-side consent enforcement has inherent reliability limitations. Browser extensions, ad blockers, JavaScript errors, and race conditions can all produce situations where client-side enforcement fails silently and tracking fires for users who should be blocked. For high-traffic sites and complex MarTech stacks, server-side enforcement through a consent proxy provides the reliability that client-side enforcement cannot guarantee — intercepting outbound tracking requests at the network level and evaluating consent state independently of what happened in the browser.
This capability — a consent proxy that intercepts outbound tracking requests and evaluates consent state server-side — is the architecturally complete answer to making consent enforcement reliable rather than merely intended. It eliminates the browser-side failure modes that affect client-only consent implementations.
What to look for: a proxy that intercepts outbound tracking requests, evaluates consent state server-side, and blocks requests for non-consented and GPC-enabled users regardless of client conditions. Coverage should include all major advertising pixels, analytics platforms, and session replay tools.
Questions to ask vendors: Does your platform currently offer server-side proxy enforcement? Which vendors are covered? Is it available in the current product or on the roadmap?
What to know about PieEye: server-side consent enforcement is currently in development at PieEye. Design partners who want early access can join the waitlist at pii.ai. The current platform covers Capabilities 1–4 in full.
How to structure your vendor evaluation
Run every platform through all five capabilities using the testing methods above — not the vendor's demonstration environment, your actual site. Build a scoring matrix: fully capable, partially capable, or not capable. A single "not capable" is a gap.
Ask vendors for reference customers who have used the platform specifically for CIPA compliance. Request and review the vendor DPA before contracting.
How PieEye performs against the framework
Pre-consent blocking: PieEye integrates with GTM through native Consent Mode v2 with default states set to denied at initialization. No outbound tracking requests appear before consent is received.
GPC detection: GPC detection runs at PieEye initialization, before banner rendering, reading navigator.globalPrivacyControl and propagating the result before GTM evaluates any firing conditions.
Server-side consent records: PieEye generates server-side consent records for every consent interaction with full metadata. Records are retained for three years and queryable by date range without engineering involvement.
TMS integration depth: PieEye's GTM integration uses native Consent Mode v2 with explicit default state commands executed before GTM initialization. In degraded conditions, the result is no tracking rather than unconstrained tracking.
Server-side consent enforcement: Currently in development. Design partners can join the waitlist at pii.ai for early access.
The free compliance scan runs against your live site and tells you where your current implementation falls short — which tools are firing before consent, whether GPC is being honored, whether false positives exist. Run it before your CMP evaluation so you know precisely what gaps you're solving for.
Frequently asked questions
Is OneTrust CIPA compliant?
OneTrust can be configured to meet CIPA's prior consent requirements in some deployments, but the configuration is not automatic and requires engineering work beyond the standard implementation. Organizations using OneTrust for CIPA compliance should audit their specific implementation against the five capabilities in this guide.
What is the difference between a GDPR CMP and a CIPA CMP?
A GDPR CMP records consent. A CIPA-adequate CMP enforces it — technically preventing tracking from executing before consent is received at the tag execution level. Most GDPR CMPs are recording architectures. CIPA compliance requires an enforcement architecture.
Do I need a separate CMP for CIPA and GDPR?
No. One platform can serve both if correctly implemented. CIPA's prior consent enforcement and GDPR's consent recording are compatible requirements that can be satisfied simultaneously by a correctly configured CMP.
How long does CIPA-compliant CMP implementation take?
For a business with an existing GTM deployment, typically two to four weeks of engineering work: CMP installation, Consent Mode v2 configuration, default state implementation, GPC pathway, tag firing conditions, consent record validation, and cross-browser testing.
What should I do if my CMP is failing the pre-consent blocking test?
Diagnose the specific failure: pre-banner firing indicates script loading sequence or missing default state issues; post-banner-appearance firing indicates CMP-to-TMS timing issues; GPC failures indicate missing initialization-level detection. The CIPA compliance guide covers remediation for each pattern.
The evaluation bottom line
Five capabilities. Each one verifiable through browser testing in under ten minutes. No vendor should be selected for CIPA compliance without demonstrating all five — or clearly disclosing which capabilities are in development and on what timeline.
The infrastructure answer
The free PieEye compliance scan shows you where your current implementation stands against all five capabilities before you begin your vendor evaluation.
Run a free PieEye compliance scan — it takes minutes, requires no code changes to initiate, and tells you exactly what a plaintiffs' attorney's scanning tool would find if it looked at your website today.