CCPA became CPRA: why it matters more than you think
The California Consumer Privacy Act (CCPA) took effect in January 2020 as the most significant US privacy law in decades. Three years later, the California Privacy Rights Act (CPRA) — passed by ballot initiative as Proposition 24 — substantially amended it. CPRA amendments took effect on January 1, 2023, with full enforcement by the California Privacy Protection Agency (CPPA) beginning July 1, 2023.
If you've been coasting on CCPA compliance built in 2020, you're missing material obligations. The CPRA added a new consumer right (correction), created an entirely new category of protected data (sensitive personal information), mandated a new opt-out mechanism, required Global Privacy Control (GPC) signal support, and added GDPR-adjacent data minimisation and retention rules. It also replaced the California AG as enforcer with the new CPPA — a dedicated privacy regulator with subpoena power, rulemaking authority, and enforcement resources.
Who CCPA/CPRA applies to
CCPA/CPRA applies to for-profit businesses that do business in California and meet at least one of three thresholds:
- Annual gross revenues over $25 million
- Buy, sell, receive, or share the personal information of 100,000 or more consumers or households per year
- Derive 50% or more of annual revenues from selling or sharing consumers' personal information
The second threshold catches most SaaS companies with meaningful California user bases. If you have 100,000 California users, you're in — regardless of revenue. Note that the threshold covers "receiving" PI (not just selling), which includes receiving data from third parties about consumers.
Non-profit exemption: CCPA/CPRA applies only to for-profit entities. Non-profits are exempt.
The 7 CPRA changes that most affect SaaS
1. Sensitive Personal Information (SPI) — the biggest CPRA change
CPRA created a new subcategory called "sensitive personal information" with special rules. SPI includes:
- Social Security, driver's licence, state ID, or passport numbers
- Financial account, debit or credit card number with security/access code
- Precise geolocation
- Racial or ethnic origin, religious or philosophical beliefs, union membership
- Contents of mail, email, or text messages not intended for the business
- Genetic data
- Health information, sex life, or sexual orientation
- Biometric information used for identification
If you collect any SPI beyond what's necessary to provide the requested service, you need a "Limit the Use of My Sensitive Personal Information" link on your homepage — the SPI equivalent of the "Do Not Sell or Share" link. Users clicking it must be able to restrict your use of their SPI to only what's needed to provide the service.
For most SaaS companies: review whether you collect precise geolocation, health data, or financial card data. If yes, you need the link and the backend controls to honour it.
2. Global Privacy Control (GPC) — now required
GPC is a browser-level signal (like a cookie opt-out built into the browser) that consumers can use to opt out of sale and sharing across all websites in a single setting. CPRA regulations require businesses to detect and honour the GPC signal as a valid opt-out of sale and sharing — without requiring the consumer to take additional action.
This is a technical implementation requirement. You need to:
- Detect the
Sec-GPC: 1header on HTTP requests - Or detect
navigator.globalPrivacyControl === truein JavaScript - Treat it as an opt-out of sale and sharing — no cookies, pixels, or data transfers to third parties for that user
- Not require the consumer to click any additional button or banner
As of 2026, CPPA has signalled that GPC compliance is an active enforcement focus. If you run any third-party analytics, advertising pixels, or behavioural tracking, you need this.
3. Right to Correction (§1798.106) — new in CPRA
Original CCPA didn't include a right to correct inaccurate PI. CPRA added it. Consumers can now request correction of inaccurate personal information you hold, and you must take "commercially reasonable steps" to correct it and direct your service providers and contractors to do the same.
For SaaS: your user-facing account settings should already enable self-service correction of basic profile data. What CPRA adds is the obligation to handle correction requests for data the user can't edit themselves — like data in your analytics systems, CRM, or derived inferences — and to propagate corrections to downstream processors.
4. Data Minimisation (§1798.100(a)(3)) — GDPR-like principle
CPRA added GDPR-adjacent data minimisation: you can only collect PI that is "adequate, relevant, and limited to what is necessary" for the disclosed purpose. You can't collect PI "just in case" it becomes useful.
Practical impact:
- Audit your data collection against disclosed purposes
- Remove fields that don't serve a documented purpose
- Review analytics integrations — are you collecting more than you need?
- Document your minimisation decisions (regulators may ask)
5. Storage Limitation (§1798.100(a)(3)) — retention must be disclosed
CPRA requires that PI is not retained beyond what is "necessary" for disclosed purposes, and that retention periods are disclosed in your privacy policy or notice at collection.
This means your privacy policy can't just say "we retain data as long as necessary." You need to disclose actual retention periods (or the criteria for determining them) for each PI category. And then you need to actually enforce those periods.
6. Privacy Risk Assessments — required for high-risk processing
CPRA regulations require privacy risk assessments for certain high-risk processing activities, including: selling or sharing PI, processing SPI beyond permitted purposes, using automated decision-making with significant effects, and large-scale profiling of consumers.
Assessments must be submitted to the CPPA upon request. Unlike GDPR DPIAs, there's no requirement to proactively register or publish them — but they must be conducted and documented before the high-risk processing begins.
7. CPPA as dedicated enforcer — higher enforcement risk
Under the original CCPA, enforcement was by the California Attorney General. CPRA created the CPPA — a five-member board with its own staff, subpoena power, rulemaking authority, audit power, and a mandate to enforce California privacy law. The CPPA has a larger budget and more focused mandate than the AG's privacy team.
Civil penalties: $2,500 per unintentional violation / $7,500 per intentional violation. The private right of action for data breaches (§1798.150) allows $100–$750 per consumer per incident without proving actual damages. For a company with 100,000 California users, even a small breach could theoretically expose $75M+ in private right of action claims.
CCPA vs CPRA: what changed — summary table
| Obligation | CCPA (Original) | CPRA (2023+) |
|---|---|---|
| Right to correction | ❌ Not included | ✅ Added (§1798.106) |
| Sensitive PI category | ❌ Not included | ✅ New SPI category + limit-use right |
| GPC signal requirement | ❌ Not required | ✅ Required — must detect and honour |
| Data minimisation | ❌ Not included | ✅ GDPR-like minimisation rule added |
| Retention limitation | ❌ Not included | ✅ Must disclose + enforce retention periods |
| Privacy risk assessments | ❌ Not required | ✅ Required for high-risk processing |
| Opt-out of sharing | Only sale | Sale AND sharing for behavioural advertising |
| Enforcement body | Attorney General | California Privacy Protection Agency (CPPA) |
The "sale" vs "sharing" distinction matters
Original CCPA required opt-out of the "sale" of PI. Many SaaS companies concluded they didn't "sell" PI because they didn't receive money in exchange. CPRA closed this loophole by adding "sharing" — defined as disclosing PI to a third party for cross-context behavioural advertising, regardless of monetary consideration.
If you use Facebook Pixel, Google Analytics, LinkedIn Insight Tag, or any other third-party tag that passes user data to an advertising network for retargeting or behavioural advertising — you're "sharing" PI under CPRA. You need the "Do Not Sell or Share" link, GPC support, and contracts with those third parties.
CCPA vs GDPR: what's different for SaaS
If you've already built GDPR compliance, here's what CCPA/CPRA adds (and what's different):
- Consent model vs opt-out model: GDPR requires consent or legitimate interest before processing. CCPA/CPRA is opt-out — you can process PI unless the consumer objects. This is a fundamentally different architecture for consent banners and marketing.
- "Do Not Sell or Share" link: GDPR doesn't require a dedicated homepage link. CCPA/CPRA does. This must be on the homepage.
- GPC signal: No GDPR equivalent. This is California-specific and requires a technical implementation.
- Private right of action: CCPA §1798.150 creates a private right of action for data breaches. GDPR has no direct consumer right of action (enforcement is through supervisory authorities).
- No data processing agreements: GDPR requires DPAs with processors. CCPA/CPRA requires service provider contracts with specific terms — similar but not identical to DPAs.
Minimum viable CCPA/CPRA compliance for SaaS
If you're starting from scratch, here's what to prioritise:
- Update your privacy policy: Add all CCPA/CPRA required disclosures — PI categories, purposes, third-party sharing, all consumer rights, and now retention periods.
- "Do Not Sell or Share My Personal Information" link: Homepage, clearly visible. Links to a mechanism to opt out.
- GPC signal detection: Technical implementation to detect and honour the GPC browser signal.
- "Limit Use of My Sensitive Personal Information" link: If you collect any SPI categories — this is now required.
- Consumer request process: At least two methods (toll-free phone + web form or email). 45-day response window. Identity verification.
- Service provider contracts: Update vendor agreements to include CCPA/CPRA required terms (purpose limitation, no secondary use, deletion obligations).
- Reasonable security: Not optional — this is the basis for private right of action in data breaches. Document your security programme.
Use the free CCPA/CPRA Compliance Checklist Generator to assess your current posture across all nine obligation areas and generate a gap analysis report. For the actual privacy notice required by CCPA, use the Privacy Policy Generator. If you also handle EU users, see the GDPR Compliance Audit Generator.