CCPA vs CPRA: What Changed and What You Need to Do

California voters passed the California Consumer Privacy Act in 2018, and it took effect in January 2020. Two years later, the California Privacy Rights Act amended and expanded it substantially. If you built your privacy program around CCPA and haven't revisited it since CPRA took effect in January 2023, you're operating with gaps.

The CCPA CPRA difference isn't just technical refinement. CPRA created new consumer rights, imposed stricter obligations on businesses, established an enforcement agency with real teeth, and introduced concepts like "sensitive personal information" that require distinct handling. I've watched organizations scramble to close these gaps after assuming CCPA compliance would carry them through, and the pattern is consistent: underestimating the scope of change leads to reactive firefighting.

This article walks through what changed, why it matters, and what you need to do about it from a CISO's perspective.

Why CPRA Exists: CCPA Wasn't Enough

CCPA was California's first major swing at comprehensive consumer privacy legislation. It gave consumers the right to know what personal information businesses collected, the right to delete that information, and the right to opt out of its sale. For 2018, that was significant.

But CCPA had enforcement problems. The California Attorney General's office handled enforcement alongside every other legal priority in the state. Resources were limited, and businesses knew it. The law also lacked precision in key areas—definitions were broad, sensitive data didn't receive special treatment, and the opt-out mechanism for selling data didn't address the broader universe of sharing arrangements.

CPRA addressed these weaknesses directly. It created the California Privacy Protection Agency, a dedicated regulator with a budget, staff, and a single mission. It introduced new rights, tightened definitions, and expanded the scope of what counts as regulated activity. The voters who passed CCPA in 2018 came back in 2020 and passed CPRA as Proposition 24, signaling that the first attempt wasn't sufficient.

The practical result: if your privacy program stopped at CCPA, you're missing enforceable obligations that became effective in January 2023.

New Consumer Rights Under CPRA

CPRA didn't just tweak CCPA's existing rights—it added new ones that require different technical and operational capabilities.

Right to Correct Inaccurate Information

Under CCPA, consumers could request deletion, but they couldn't request correction. CPRA changed that. Consumers now have the right to request that you correct inaccurate personal information you maintain about them.

This sounds straightforward until you consider the systems involved. Correction requires you to identify where the data lives, validate the consumer's claim, determine what constitutes "inaccurate" in context, make the change, and potentially propagate that change across systems. If you sold or shared that data with third parties, you're also required to notify them of the correction.

In my experience, businesses that struggle with this right are the ones that don't have strong data lineage visibility. They can locate personal information for deletion requests, but tracing how that information flows through downstream systems—and knowing which third parties received it—is harder. Correction requests expose those gaps quickly.

Right to Limit Use of Sensitive Personal Information

CPRA introduced a new category: sensitive personal information. This includes Social Security numbers, drivers' license numbers, financial account information, precise geolocation, racial or ethnic origin, religious or philosophical beliefs, union membership, genetic data, biometric data used for identification, health information, and information about sex life or sexual orientation.

Consumers have the right to limit your use and disclosure of their sensitive personal information to what's necessary to perform services or provide goods they reasonably expect. You can still collect it, but you can't use it for purposes beyond that narrow scope unless the consumer hasn't exercised their right to limit.

This creates a segmentation challenge. You need to identify which personal information qualifies as sensitive, track consumer choices about limiting its use, and enforce those limitations across systems that process the data. If your data classification efforts never went beyond "personal information" versus "not personal information," you're behind.

Expanded Opt-Out Rights

CCPA gave consumers the right to opt out of the sale of their personal information. CPRA expanded this to include sharing for cross-context behavioral advertising, a practice that wasn't clearly covered under the original law's definition of "sale."

The practical impact: if you share personal information with advertising platforms, data brokers, or analytics providers in ways that allow them to build profiles or target ads across different contexts, that's likely sharing under CPRA. Consumers can opt out, and you need a mechanism to honor that choice that's at least as easy as the mechanism you built for sale opt-outs under CCPA.

This also means revisiting vendor relationships. If you're sharing personal information with third parties for these purposes, you need contracts that allow you to stop sharing when a consumer opts out, and you need technical controls to enforce it.

The California Privacy Protection Agency Changes Enforcement

The biggest structural change CPRA made was creating the California Privacy Protection Agency. Before CPRA, enforcement lived with the Attorney General's office. After CPRA, California has a dedicated regulator with rulemaking authority, investigation powers, and a mandate to focus exclusively on privacy.

This matters because dedicated regulators develop expertise, build institutional knowledge, and prioritize enforcement in ways that generalist offices can't. The CPPA has published regulations, issued guidance, and begun accepting complaints. They're building case history and establishing patterns for what non-compliance looks like.

For businesses, this means enforcement risk is higher and more consistent. The Attorney General's office brought high-profile cases, but bandwidth was limited. The CPPA exists to enforce privacy law full-time. If you're operating in California and handling consumer personal information at scale, you're on their radar whether you know it or not.

The agency's rulemaking authority also means the regulatory landscape will continue evolving. The CPPA can clarify ambiguous requirements, add detail to broad obligations, and adjust expectations as technology and business practices change. Staying compliant isn't a one-time project—it's ongoing monitoring of regulatory developments from an agency that's still defining its approach.

Sensitive Personal Information: A New Compliance Layer

The introduction of sensitive personal information as a distinct category is one of the most operationally challenging aspects of the CCPA CPRA difference. It's not just a definition—it's a separate compliance layer with its own consumer rights, disclosure requirements, and risk profile.

CPRA defines 11 categories of sensitive personal information. Some are obvious: Social Security numbers, financial account credentials, precise geolocation. Others require interpretation: what counts as "philosophical beliefs" or information about "sex life"? The law doesn't provide bright-line tests for every scenario, which means you need defensible classification logic.

Once you've identified sensitive personal information in your systems, you need to handle it differently. Consumers can limit its use and disclosure. Your privacy notice must separately disclose what sensitive personal information you collect, why you collect it, and whether you use or disclose it for purposes beyond providing requested services. If you use or disclose it for additional purposes, consumers must be able to limit that use.

In my experience, the businesses that handle this well are the ones that already had strong data classification programs for other reasons—HIPAA, CMMC, or contractual obligations. If you're used to tagging data by sensitivity level and enforcing use restrictions based on those tags, adding CPRA's sensitive personal information categories is an extension of existing discipline. If you're starting from scratch, it's a heavier lift.

The technical implementation challenge is similar to what you face with privacy controls more broadly: you need to track consumer preferences, enforce those preferences across systems, and produce audit evidence that you're doing it correctly. The difference is that sensitive personal information adds another preference layer and another set of system requirements.

Contractual and Vendor Management Changes

CPRA tightened requirements for service providers and introduced a new category: contractors. Both process personal information on behalf of businesses, but the contractual obligations differ.

Service providers process personal information as directed by the business and are prohibited from using it for purposes outside the business relationship. Contractors are similar but have more flexibility—they can use personal information to improve or develop their services, provided those improvements are compatible with consumer expectations.

The distinction matters because you need different contract language depending on which category applies. Service provider agreements must include specific restrictions and audit rights. Contractor agreements need similar provisions but with adjusted scope. If you're using CCPA-era contracts that don't reflect CPRA's definitions and requirements, you have a gap.

I've seen this play out in vendor assessments where the business assumes their existing contracts are sufficient because they addressed CCPA, but the vendor's actual practices fit the contractor definition under CPRA, and the contract doesn't include the required provisions. It's not a showstopper, but it's a remediation project that requires legal review, vendor negotiation, and contract amendments across potentially dozens or hundreds of relationships.

The risk isn't theoretical. If a vendor mishandles personal information and your contract doesn't meet CPRA's requirements, you're exposed. The CPPA has authority to investigate both the business and its vendors, and inadequate contracts signal weak oversight.

Data Retention and Minimization Under CPRA

CPRA introduced an explicit requirement that businesses not retain personal information for longer than reasonably necessary for the disclosed purposes for which it was collected. CCPA implied this through its definition of "business purpose," but CPRA made it direct.

This ties to regulatory compliance more broadly: retention obligations exist across multiple frameworks, and they often conflict. HIPAA requires you to retain certain records for six years. Federal contractors face retention requirements under FAR and DFARS. Financial institutions have recordkeeping obligations under various banking regulations. CPRA says don't keep personal information longer than necessary.

Reconciling these requires documented retention policies that account for all applicable requirements, justify retention periods based on legal obligations or legitimate business needs, and include mechanisms for deletion once those periods expire. It also means being able to prove you're following those policies—auditors and regulators will ask for evidence.

The businesses I see struggling with this are the ones that never formalized retention in the first place. Data accumulates, nobody deletes anything because storage is cheap, and suddenly you're subject to a regulation that requires you to justify why you're holding three-year-old customer records you're not using. Building a defensible retention program after the fact is harder than building it correctly from the start, but it's necessary if you want to avoid exposure under CPRA.

Risk-Based Assessments and Cybersecurity Audits

CPRA requires businesses to conduct regular cybersecurity audits and risk assessments if they process personal information that presents significant risk to consumers' privacy or security. The law doesn't define "significant risk" with precision, but it's clear that high-volume processing, sensitive personal information, and activities that could lead to substantial harm fall within scope.

This isn't a new concept for organizations operating under other regulatory frameworks. If you're a healthcare entity subject to HIPAA, you're already conducting risk assessments. If you're a defense contractor subject to CMMC, you're already auditing your cybersecurity posture. But CPRA adds a California-specific overlay with its own expectations and definitions.

The pattern I see in organizations getting this wrong is treating the audit requirement as a checkbox exercise. They hire a third party to run a vulnerability scan, produce a report, and file it away. That's not what CPRA expects. The regulation anticipates risk assessments that identify privacy and security risks specific to your processing activities, document mitigations, and inform your security program on an ongoing basis.

The audit requirement also ties to accountability. If the CPPA investigates your organization after a breach or a consumer complaint, they'll ask what assessments you've conducted, what risks you identified, and what you did about them. "We ran a scan once" is not a strong answer.

Automated Decision-Making and Profiling

CPRA introduced requirements around automated decision-making, though less prescriptive than GDPR's approach. Businesses must disclose whether they use personal information for profiling, respond to access requests that include information about profiling, and allow consumers to opt out of profiling in furtherance of decisions that produce legal or similarly significant effects.

The key phrase is "legal or similarly significant effects." This is narrower than GDPR, which covers any automated decision-making with significant effects. CPRA focuses on decisions that have consequences comparable to legal determinations—credit decisions, employment decisions, housing decisions, access to essential services.

If your business uses algorithms or machine learning models to make these kinds of decisions based on consumer personal information, you need to disclose it, track it, and provide opt-out mechanisms. You also need to understand how the models work well enough to respond to consumer requests for information about profiling.

This is where organizations using third-party platforms face challenges. If you're using a vendor's black-box scoring model to make credit or underwriting decisions, you may not have visibility into how it uses personal information or whether it qualifies as profiling under CPRA. Vendor due diligence needs to include these questions, and contracts need to require vendors to support your compliance obligations.

What You Need to Do: A CISO's Checklist

If you're responsible for privacy compliance in an organization subject to CPRA, here's what closing the CCPA CPRA difference looks like in practical terms.

Classify sensitive personal information. Review your data inventory and identify which personal information falls into CPRA's sensitive categories. Update your data classification scheme to tag sensitive personal information separately, and ensure your processing systems can enforce use limitations based on consumer choices.

Implement correction capabilities. Build the technical and operational processes to handle consumer requests to correct inaccurate personal information. This includes identifying where data lives, making corrections, and notifying third parties who received the data if required.

Expand opt-out mechanisms. If you're sharing personal information for cross-context behavioral advertising or other purposes covered by CPRA's expanded opt-out right, implement mechanisms for consumers to opt out of sharing in addition to sale. Test those mechanisms to ensure they're at least as easy to use as your existing sale opt-out process.

Update contracts with vendors. Review service provider and contractor agreements to ensure they meet CPRA's requirements. Update contracts that don't include the required provisions, and flag vendors whose practices don't align with the contract language.

Formalize retention policies. Document data retention periods for each category of personal information you process, justify those periods based on legal obligations or legitimate business needs, and implement deletion processes to ensure data doesn't outlive its purpose.

Conduct risk-based assessments. If your processing activities present significant risk to consumers, implement regular cybersecurity audits and risk assessments that meet CPRA's expectations. Document findings, track mitigations, and use assessment results to inform your security program.

Disclose automated decision-making. If you use personal information for profiling in furtherance of decisions with legal or similarly significant effects, update your privacy notice to disclose it and implement opt-out mechanisms for consumers who don't want their information used this way.

Monitor CPPA activity. Subscribe to CPPA updates, review published guidance and regulations, and adjust your program as the agency clarifies expectations. Privacy compliance under CPRA isn't static—it's a moving target that requires ongoing attention.

None of these are optional. CPRA is enforceable law with a dedicated regulator and penalties that scale with the scope of violations. The businesses that treated CCPA as a one-time project and never revisited their programs are the ones facing compliance gaps now.

Strategic Implications for CISOs and Privacy Leaders

The CCPA CPRA difference is ultimately about maturity. CCPA established baseline consumer rights and business obligations. CPRA raised the bar, introduced more nuance, and created enforcement infrastructure that makes violations costlier.

For CISOs and privacy leaders, this means privacy compliance is no longer a project—it's a program. You can't build it once and move on. You need ongoing monitoring of regulatory developments, regular assessment of your practices against evolving requirements, and continuous improvement as your business and the regulatory landscape change.

The organizations that do this well treat privacy as a strategic function, not a legal checkbox. They invest in data classification and governance because it enables compliance across multiple frameworks, not just CPRA. They build technical capabilities for consumer rights requests because those capabilities also support incident response, data quality, and operational efficiency. They view privacy regulation as one input into a broader risk management discipline.

The organizations that struggle treat privacy as a burden to minimize. They do the minimum required under the law, resist investment in infrastructure that would make compliance easier, and hope they don't get caught in the gaps. That strategy worked better when enforcement was limited and regulators were stretched thin. With the CPPA operational and state privacy laws proliferating, it's a losing approach.

If you're building or refining a privacy program under CPRA, the goal isn't just to avoid penalties. It's to build something durable that scales as your business grows and adapts as regulations evolve. That requires upfront investment in classification, controls, and governance—but it pays off in reduced risk, lower long-term compliance costs, and the ability to respond quickly when requirements change.

CPRA won't be the last word on consumer privacy in California, and California won't be the last state to pass comprehensive privacy legislation. The businesses that treat each new law as an isolated project will spend the next decade retrofitting systems and scrambling to close gaps. The ones that build strong foundations now will handle future requirements as extensions of existing discipline.