CCPA Compliance Checklist and CPRA Readiness Assessment

CCPA compliance checklist and CPRA readiness assessment: a CTO companion guide

In May 2025, the California Privacy Protection Agency fined Todd Snyder, Inc. $345,178 for CCPA violations. In March 2025, the CPPA also brought a case against Honda that focused on opt-out UX and friction, not just policy text. And in February 2025, the CPPA sought a $46,000 fine against National Public Data for late data broker registration under the Delete Act. These aren’t edge cases. They’re a preview of where enforcement is going: show me it works in production, not that you wrote it down. See the enforcement details in Mayer Brown’s 2025 enforcement roundup and the Honda dark pattern discussion.

This guide explains how to use The Art of CTO’s CCPA/CPRA Compliance tool as a practical CPRA readiness assessment. It also gives a CCPA compliance checklist that maps to engineering work, team ownership, and release gates.

What the CCPA/CPRA Compliance tool does, and what “ready” means

The Art of CTO CCPA/CPRA Compliance tool is a consumer rights and data handling readiness check for California privacy law. It scores whether a company can meet California privacy law requirements across consumer rights, opt-out signals, and day to day data handling. It also flags gaps that regulators and plaintiffs can test in minutes.

It’s tuned for the stuff that breaks in real systems:

Data inventory and flows. Where personal data lives, and where it goes.
Consumer rights operations. Intake, verification, fulfillment, and records.
Opt-out enforcement. “Do Not Sell or Share,” GPC signals, and ad tech suppression.
Sensitive personal information controls. Limits on use and disclosure.
Vendor contracts. Service provider and contractor terms that match CPRA.
Retention and deletion. Keeping data only as long as needed.

A definition you can actually align a team around:

CPRA readiness means a consumer can opt out in one session, and the system stops sharing identifiers across every downstream path.

That matches what enforcement is testing. Regulators look at what a user can do, then they look at what the network traffic shows. The Privado playbook calls this “consent enforced,” not “consent collected.”

California privacy law requirements: what CTOs must build, not just write

Most Series A teams already have a privacy policy. The hard part is making the product and data stack behave like the policy says it does.

A practical CCPA compliance checklist for product and engineering

Use this as the baseline checklist, then run the tool to score readiness and prioritize.

Applicability check. Confirm if the business meets the thresholds.
Data inventory. Systems, data categories, purposes, retention, recipients.
Notice at collection. What is collected, why, and who gets it.
Rights intake channels. At least two methods, and a clear workflow.
Verification rules. Different levels for access, deletion, correction.
Response timelines. Acknowledge and respond within required windows.
Records. Keep request logs for 24 months.
Opt-out mechanisms. “Do Not Sell or Share” and “Limit use” where needed.
GPC support. Detect and honor Global Privacy Control.
Vendor contracts. CPRA terms for service providers and contractors.

The timelines aren’t trivia. They shape your system design and your staffing model. The Web Standards Commission lists a common operational set: acknowledge within 10 business days, respond within 45 calendar days, and keep records for 24 months in their California guide. The 45 day response window also shows up in DSAR guidance that compares GDPR and CCPA in Captain Compliance’s DSAR timing overview.

The enforcement trap: UX friction and “dark patterns”

A lot of CTOs still treat opt-out like a legal page plus a banner. That’s not where enforcement is landing anymore. It’s landing in UI and flow design.

Red Clover describes the Honda case as a design problem. The opt-out path took more clicks than the accept path, and the CPPA treated that as a dark pattern in their 2025 enforcement lessons. If you’re reviewing consent UI, you need to review it like you’d review checkout funnel changes.

A simple internal rule works well:

One step to accept means one step to opt out.

If the product team wants “one more confirmation,” fine. Put it after the opt-out is honored, not before.

The engineering trap: GPC is read, but not enforced

Global Privacy Control is easy to detect. The pain is propagation.

The failure mode I see most often looks like this:

The consent tool reads GPC.
The frontend stops firing one analytics tag.
The server side event pipeline still sends identifiers to ad partners.

Privado calls out this exact pattern and suggests verifying with network inspection. Load the site with GPC enabled and inspect outbound calls. Any identifier sent to an ad partner after the signal is present is a testable failure in their 2026 playbook.

That’s why the tool asks about downstream systems, not just the banner.

CPRA readiness assessment: a step by step plan for a 10 to 100 engineer company

A CPRA readiness assessment fails when it turns into a spreadsheet nobody owns. It works when it’s a short program with named owners and proof artifacts you can hand to someone new without a two hour walkthrough.

The “Proof, Pipes, People” framework

Use this framework to run the assessment and turn it into work.

Proof. Evidence regulators can test and you can show.
Pipes. Data flows, event pipelines, SDKs, and vendor handoffs.
People. Ownership, training, and on call style response for rights requests.

Most compliance guides stop at “here are the requirements.” This fills the missing piece: how to run it like an engineering program.

Proof: the artifacts to produce in 30 days

Aim for a small set of artifacts that survive leadership changes.

Data map. Systems of record, processors, and key flows.
Rights request runbook. Intake, triage, verification, fulfillment.
Opt-out test evidence. Screenshots plus network logs for GPC and “Do Not Sell or Share.”
Vendor contract list. Which vendors act as service providers, contractors, or third parties.

Sirion’s checklist is a good baseline for what auditors expect, including data inventory, request workflows, and GPC handling in their 2026 checklist.

Store these artifacts where you store incident docs. Treat them like living runbooks, because that’s what they are.

Internal link: pair this with our guide to blameless incident postmortems at /tools/incident-postmortem, since privacy misses often start as “small” production changes.

Pipes: map the real data paths, not the org chart

By Series A, most startups have at least five data paths:

Web analytics and product analytics
Marketing site pixels
Mobile SDKs
Data warehouse loads
Customer support tooling

Your CPRA readiness assessment should name each path and name the suppression control. If you can’t point to the control, you don’t have one.

A practical table helps teams spot gaps fast.

Data path	Typical tools	Opt-out control	Proof to keep
Browser tags	Tag manager, analytics	Consent state and GPC gating	Network capture, tag audit
Server events	Segment style pipeline	Server side suppression list	Event logs, unit tests
Mobile SDKs	Attribution, crash, ads	SDK config per consent	Build config, runtime logs
Warehouse loads	ETL, reverse ETL	Downstream access rules	Query logs, access reviews
Support systems	CRM, ticketing	Field level access, retention	Role audit, retention policy

This is where engineering leaders earn their keep. The goal isn’t “compliant by policy.” The goal is “no identifiers leave the system after opt-out.”

Internal link: this work fits well with architecture documentation that stays current using /tools/archimate.

People: treat rights requests like a support queue with SLOs

Consumer rights requests behave like incidents. They show up at random times, they cross team boundaries, and they get messy if nobody’s on point.

The Web Standards Commission lists a 45 day response window, with a possible extension to 90 days with notice in their response timeline table. That’s an SLO, whether you call it one or not.

A simple operating model works for 10 to 100 engineers:

Single queue. One intake system that routes work.
Two owners. Legal or privacy owns policy, engineering owns execution.
Weekly review. Open requests, aging, and blockers.
Release gate. Any new tracking or SDK needs an opt-out plan.

Internal link: track this work like any other program in Command Center at /command-center, with risks, owners, and due dates.

Does CCPA/CPRA apply to your business, and what changes under CPRA

CCPA and CPRA apply to for-profit businesses that collect California residents’ personal information and meet one threshold. The common thresholds include revenue over $25 million, processing personal information of 100,000 or more consumers or households, or earning 50 percent or more revenue from selling or sharing personal information. Service providers and contractors also pick up duties through contracts.

You should confirm the current threshold numbers with counsel, since they can change over time. But the engineering work often starts before you hit the threshold. Data stacks don’t shrink, and retrofitting suppression into a mature pipeline is a bad time.

What is the difference between CCPA and CPRA

CPRA amended and expanded CCPA, with full effect starting in 2023. It added sensitive personal information controls, expanded consumer rights, and created the CPPA as a dedicated enforcement agency.

The differences that hit engineering teams in practice:

Sensitive personal information. New limits and disclosures.
“Sharing” focus. Not just selling. Ad tech flows matter.
More rights. Correction and limits on sensitive data use.
Stronger enforcement posture. No default cure period.

Usercentrics notes that CPRA removed the 30 day cure period that existed under CCPA, which changes risk math for startups that plan to “fix it later” in their CPRA enforcement overview.

Vendor contracts are now a product risk

Generic data protection language won’t cut it. Enforcement actions have called out vendor contracts that lack CCPA and CPRA specific terms.

Red Clover describes cases where vendor contracts used generic language and staff lacked training for rights requests in their enforcement lessons. The Herzog CPRA vs CCPA playbook also lists concrete contract duties, like limiting use to business purposes and giving the business rights to remediate misuse in their PDF playbook.

Internal link: this is a good time to use our Build vs Buy Matrix at /tools/build-vs-buy-matrix for consent platforms and DSAR tooling. Vendor choice becomes a compliance choice.

A lot of Series A companies have both California users and EU users. Teams often assume GDPR work covers CCPA and CPRA. It doesn’t.

A practical comparison for mid market companies:

GDPR uses opt-in consent for many cases.
CCPA and CPRA use opt-out for sale and sharing.
GDPR DSAR deadline is one month, with a possible two month extension.
CCPA and CPRA give 45 days, with a possible 45 day extension.

PrivacyCache summarizes these differences in a clear table, including effective dates and fine models in their GDPR vs CCPA comparison.

The CTO implication is straightforward. You need two playbooks:

Consent and tracking playbook for California opt-out and GPC.
Legal basis and consent playbook for EU opt-in and lawful basis.

If you try to force one model across both, you’ll ship bugs and confuse users. Usually both.

CTO recommendations: how to run CCPA and CPRA work without stalling product

Immediate actions

Run a GPC smoke test. Enable GPC and capture outbound network calls. Save the evidence and open tickets for any identifier leakage. Privado’s guidance on network proof is a good standard here.
Inventory tracking and SDKs. List every pixel, tag, SDK, and server side destination. Owners must be named for each.
Stand up a rights request queue. One intake form plus an email channel meets the “two methods” expectation listed by the Web Standards Commission here.
Review opt-out UX for friction. Compare clicks for accept vs opt-out. The Honda case shows regulators care about this as discussed by Red Clover.

Policy framework

Ownership map. Product owns consent UI, data owns pipelines, security owns access controls, legal owns notices. Put names next to each.
Evidence retention. Keep request logs for 24 months and keep opt-out test evidence per release. The recordkeeping expectation appears in multiple checklists including WSC.
Vendor contract standard. Add CPRA service provider and contractor clauses as a default. Use the Herzog playbook list as a starting point PDF.

Architecture principles

Central consent state. One source of truth for consent and opt-out, readable by web, mobile, and server.
Downstream suppression. Every destination needs a suppression control, not just the tag manager.
Data minimization by default. Do not send identifiers to vendors unless a clear purpose exists and opt-out is honored.

Internal link: measure the delivery impact of this work with our Engineering Metrics Dashboard at /tools/engineering-metrics-dashboard. Compliance work dies when it turns into invisible toil.

Bigger picture: California is the test bed for US privacy enforcement

California has a dedicated privacy regulator, and it’s building a public record of what “good” looks like. The Mayer Brown enforcement roundup shows the CPPA using fines and corrective orders, and also pushing on adjacent laws like the Delete Act here. Red Clover also describes multi state coordination, like a joint investigation into honoring GPC signals here.

That matters because the same controls show up across other state laws. Falcon Rappaport and Berkman describe the “patchwork” problem and call out opt-out mechanics, GPC, and documented assessments as recurring work across states in their e-commerce playbook.

Here’s the question I ask teams: what happens when a growth team adds a new pixel on Friday, and it bypasses opt-out suppression?

The answer isn’t a policy update. It’s a release gate and a test that fails the build.

Use the tool to turn that into a plan, then run it like any other reliability program.

Use the tool: CCPA/CPRA Compliance

CCPA/CPRA Compliance Guide: A CTO Companion to a CCPA Compliance Checklist and Readiness Assessment