CIPA Compliance Checklist: 60 Items to Audit Before You Get a Demand Letter (2026)

In this guide:

• How to use this checklist
• Tier 1: quick exposure assessment — 10 questions
• Tier 2: full compliance checklist — 60 items across 6 workstreams
• What your gaps mean and where to go next

How to use this checklist

This checklist has two tiers designed for two different moments. If you are doing a first assessment and want to know whether you have a problem before committing to a full compliance project, work through Tier 1 — ten binary questions that identify confirmed gaps in about ten minutes. If you are building or auditing a compliance program, Tier 2 is your working document — sixty items organized across six workstreams, specific enough to assign to team members and track to completion.

One important note before you start: this checklist is an operational tool, not legal advice. It identifies technical and process gaps that require remediation. Engage privacy counsel for legal assessment of your specific situation — particularly for demand letter response, vendor contract negotiation, and evaluation of your defenses if a claim has already been made.

The checklist should be reviewed in full quarterly and after any deployment that changes your tracking stack, consent UI, or vendor integrations.

Tier 1: quick exposure assessment — 10 questions

Answer each question honestly. If you cannot answer with certainty, treat it as a gap. Each unchecked item is a confirmed compliance exposure that requires remediation.

• Q1 I know every third-party script currently executing on my website — verified by direct browser observation, not tag manager configuration alone.

Why this matters: Tag managers show what is configured to run, not necessarily what is actually running. Vendor SDK updates, hardcoded scripts, and tags firing from within tags can all introduce tracking your TMS does not reflect.

• Q2 I have tested my site in a fresh private browser and confirmed that no third-party tracking fires in the first 200 milliseconds — before a user can possibly see or interact with a consent banner.

Why this matters: This is the specific failure that CIPA demand letters are built around. If tracking fires before the banner resolves, the prior consent requirement is not satisfied regardless of what the banner says.

• Q3 When a user clicks "reject all" on my consent banner, I have confirmed — by watching network requests in real time — that the tracking tools in that category actually stop firing.

Why this matters: False positives — tracking that continues despite a user declining — are treated by courts as worse than no banner at all. They are an affirmative misrepresentation.

• Q4 My website detects Global Privacy Control signals and blocks all tracking for GPC-enabled users without requiring them to interact with a consent banner.

Why this matters: CPRA requires honoring GPC signals. Demand letters are increasingly citing GPC failures as an independent basis for CIPA claims.

• Q5 My consent management platform is technically integrated with my tag management system — meaning tags are blocked from executing by default and only fire after a positive consent signal is received.

Why this matters: The most common false compliance: a CMP that displays a banner but has no TMS integration. The banner records preferences. The tracking ignores them.

• Q6 I have executed data processing agreements in place with every third-party vendor receiving behavioral data from my website — not just offered, but signed.

Why this matters: A DPA that exists as a template but has never been executed for your account provides no legal protection.

• Q7 Those vendor agreements explicitly prohibit the vendor from using collected data for their own independent commercial purposes — advertising, model training, product benchmarking, or data monetization.

Why this matters: This is the specific provision that produces the tape recorder exception. Processor classification without this restriction is insufficient.

• Q8 My privacy policy names every third-party tracking vendor currently running on my site, and what it says my consent mechanism does matches what my technology actually does.

Why this matters: Policy-to-practice mismatches appear in virtually every CIPA demand letter. They complicate consent-based defenses and are treated as evidence of bad faith.

• Q9 A process exists that prevents new tracking tags from being added to my tag management system without a compliance review — including a risk assessment, an executed DPA, and a consent category assignment.

Why this matters: The most common mechanism by which compliant architectures degrade is organizational bypass: marketing adds a pixel before a campaign without going through review.

• Q10 I have server-side consent records for user interactions with my consent mechanism, queryable by date range for at least the past 12 months, without requiring engineering to retrieve them.

Why this matters: If a demand letter arrives alleging a violation from months ago, consent records for that period are your primary evidence of compliance. Client-side records that users can clear are insufficient.

If you checked fewer than 8 items: confirmed gaps exist that create active CIPA exposure. Proceed to Tier 2 and prioritize Workstream 3 (consent architecture) if Q2, Q3, Q4, or Q5 are unchecked.

Tier 2: full compliance checklist — 60 items across 6 workstreams

Complete working checklist for compliance teams building or auditing a CIPA program. Each item is a discrete, verifiable action. Use this as a living document — revisit it quarterly and after any significant website or vendor change.

Workstream 1: Technology audit and inventory

Goal: Complete, current, accurate knowledge of every tracking tool running on every page.

• Complete technology inventory produced from direct browser observation — not from tag manager configuration alone
• Inventory documents: tool name, vendor, data category captured, pages it fires on, domain receiving the data, date last verified
• Consent timing verified in fresh private browser: no third-party requests in first 200ms before user interacts with consent banner
• Consent signal enforcement verified in Chrome: decline/reject all tested with network monitoring — no false positives confirmed
• Consent signal enforcement verified in Safari: decline tested — no false positives — ITP behavior confirmed not bypassing enforcement
• Consent signal enforcement verified in Firefox: decline tested — no false positives confirmed
• Mobile consent behavior verified: banner renders correctly and enforcement works on iOS Safari and Android Chrome
• GPC signal detection verified: GPC-enabled browser (Firefox or Brave) loads site with no tracking and no consent banner appearing
• Audit conducted across all significant page types: homepage, product/content pages, checkout or sign-up flow, support and chat pages
• Compliance gap inventory produced: each gap documented with tool name, CIPA section implicated, risk level, and remediation action required
• Audit date recorded; next scheduled audit date confirmed in team calendar
• Audit repeated after most recent deployment; results compared against prior audit to identify regressions

Workstream 2: Tracking stack risk assessment and decision log

Goal: A documented, deliberate decision for every tool in the stack.

• Four-factor risk score completed for each tool: data capture depth, vendor data independence, consent gateability, contractual restrictability
• Risk tier assigned to each tool: High / Medium / Low
• Decision documented for each tool: keep and remediate / keep and accept residual risk / remove
• Rationale recorded for each decision — minimum 1–2 sentences explaining the basis
• Compliance owner assigned for each retained tool
• Advertising pixels (Meta Pixel, TikTok Pixel, Pinterest Tag) explicitly flagged: tape recorder exception unavailable — consent mechanism documented as sole defense for each
• Decision log dated and version-controlled; update process confirmed with named owner
• Decision log reviewed and updated after any tool addition, removal, or vendor term change

Workstream 3: Consent architecture — technical implementation

Goal: Pre-consent blocking verified at script execution level, GPC pathway operational, consent records complete and retained.

• CMP selected with verified pre-consent blocking capability — confirmed by documentation of TMS integration, not by banner presence alone
• CMP initialization script positioned before TMS initialization script in document head — verified in page load waterfall
• TMS configured to wait for consent signal before evaluating any tag firing conditions on page load
• All non-essential tags set to blocked by default — default state is no execution, not execution until declined
• Every tag assigned to the correct consent category in the TMS — no tag left uncategorized
• Tag firing conditions configured per category: analytics tags require analytics_storage consent, advertising tags require ad_storage consent
• GTM Consent Mode v2 enabled (if GTM is the TMS) — all tags updated to respect consent type checks natively
• GPC signal detection implemented at CMP initialization — reads navigator.globalPrivacyControl before banner renders, not as a banner configuration option
• GPC pathway tested: GPC-enabled browser loads site, no banner appears, no tracking fires in network requests
• Consent state stored in first-party context — tested to persist correctly in Safari after 7-day ITP window
• Consent state persists correctly across page navigation within a session in all tested browsers
• Consent records generated server-side with full metadata: user ID (consent ID, not PII), timestamp, consent state per category, banner version, signal source, browser type, device type, page URL
• Consent records retained server-side for minimum 3 years
• Consent records queryable by date range by legal team without engineering involvement
• Post-deployment testing protocol in place: consent timing and signal enforcement re-verified after every deployment touching tag management, consent UI, or vendor integrations

Workstream 4: Vendor contract review

Goal: Every vendor receiving behavioral data has an executed DPA with the three required provisions.

• Vendor contract inventory produced: every tracking tool vendor listed with agreement type, execution date, and DPA status
• For each vendor: independent data use restriction present and explicit — language covers advertising, model training, benchmarking, and data monetization
• For each vendor: carve-outs to the independent data use restriction identified, documented, and assessed by counsel
• For each vendor: processor classification provision present — vendor designated as data processor acting on your instructions, not as independent controller
• For each vendor: DPA executed and signed — not merely offered or available for download
• For each vendor: change notification obligation present — vendor must notify before altering data collection practices, SDK behavior, or data use terms
• Advertising pixel vendors assessed separately: tape recorder exception confirmed as unavailable — consent mechanism documented as sole CIPA defense for each pixel
• Chat and conversational tool vendor agreements reviewed for AI and ML training carve-outs — opt-out of AI training data use confirmed where available via account settings or contractual addendum
• Session replay vendor: enterprise agreement confirmed — free-tier terms reviewed and assessed if enterprise agreement is unavailable
• Annual vendor contract review scheduled — calendar entry created with named owner

Workstream 5: Privacy policy and disclosure alignment

Goal: Policy accurately describes every tool, every vendor, every consent control — and matches what the technology actually does.

• Side-by-side alignment completed: every tool in the technology inventory has a corresponding disclosure in the privacy policy — no tools in the tech stack absent from the policy
• Every third-party vendor named specifically by name in the policy — not described by category alone
• Consent mechanism described accurately: what accepting means technically, what declining means technically, what each consent category controls
• GPC acknowledgment present: policy states that GPC signals are honored and describes what a GPC-enabled user can expect — no banner, no tracking
• Banner-to-policy consistency verified: category names are consistent across banner UI text, privacy policy text, and TMS consent category configuration
• Policy-to-technology behavior verified: declining each consent category in the banner produces the behavior the policy describes for that category
• Policy update trigger in place: any deployment that changes the tracking stack triggers a policy review within 5 business days — process and owner confirmed
• Quarterly full policy review scheduled — calendar entry created with named owner

Workstream 6: Ongoing operations and organizational governance

Goal: Compliance maintained continuously — with clear ownership, documented cadences, and a complete retrievable audit trail.

• Compliance ownership assigned: legal owns policy and vendor contracts — engineering owns technical implementation and tag audit — marketing owns tool inventory and deployment discipline
• Tag governance policy in place: no third-party tag may be added to the TMS without a risk assessment, an executed DPA, and a consent category assignment — all three completed before deployment
• Fast-track list maintained for pre-approved low-risk tool categories — enables marketing to move quickly on known tools while standard review applies to new vendors
• Monthly tag audit scheduled, assigned, and producing dated written output — automated or manual
• Quarterly consent mechanism test scheduled and assigned — cross-browser, cross-device, with screenshots and network captures documented
• Annual vendor contract review scheduled and assigned to named owner
• Demand letter response protocol documented: who is notified within 24 hours, who engages counsel, what the emergency technology audit procedure is, what the 30-day response timeline looks like
• CIPA-experienced litigation counsel identified and relationship established — before a letter arrives, not after
• Compliance audit trail complete and retrievable: dated records of all audits, consent mechanism test results, and vendor contract reviews retained for minimum 3 years
• Checklist last reviewed: ____________ | Next review scheduled: ____________

What your gaps mean and where to go next

Two items in this checklist catch the most organizations off guard — not because they are obscure, but because they involve a gap between what appears to be in place and what is technically actually working.

The first is Workstream 3, items 1–4. The most common compliance failure in the market is a CMP that displays a banner but has no real TMS integration behind it. The banner records user preferences. The tracking ignores them. Identifying this failure requires watching network requests in a fresh browser — not reading configuration documentation. If Q2, Q3, Q4, or Q5 in Tier 1 are unchecked, start here before anything else.

The second is Workstream 4, item 2. Businesses frequently assume their vendor DPAs contain the independent data use restriction because a DPA exists. Many DPAs are processor classification only, with carve-outs for product improvement, security, or AI training that substantially undermine the tape recorder defense. The provision must be read, not assumed. A DPA that does not explicitly prohibit independent data use does not support the defense regardless of how many other provisions it contains.