10 Steps for CCPA Compliance in 2026

These are the steps to follow in a CCPA compliance checklist:

1. Confirm that CCPA applies and define scope
2. Map personal information and data flows
3. Refresh the privacy notice and the notice at collection
4. Build a consumer rights request process
5. Manage sales, sharing and targeted advertising
6. Put contracts in place with service providers and contractors
7. Apply security safeguards and retention limits
8. Assign ownership and train the team
9. Handle sensitive personal information and minors’ data carefully
10. Document evidence, monitor and improve

The California Consumer Privacy Act, as amended by the California Privacy Rights Act, gives California consumers rights over their personal information and places obligations on the businesses that collect it. It is enforced by the California Privacy Protection Agency and the California Attorney General.

A CCPA compliance checklist is not a privacy notice with a few extra clauses. It requires knowing what personal information you collect, why, who receives it, how consumers exercise their rights and what evidence shows the programme works. The official text should be read alongside the California Attorney General’s CCPA page and the regulations issued by the California Privacy Protection Agency.

The order below is the one we use with clients. Each step maps to a requirement, an owner and a piece of evidence, so the programme can be operated and demonstrated rather than assembled once.

10-step CCPA compliance checklist

1. Confirm that CCPA applies and define scope

CCPA applies to for-profit businesses that do business in California and meet at least one threshold: annual gross revenue above the adjusted figure (currently in the region of $26 million), buying, selling or sharing the personal information of 100,000 or more consumers or households, or earning 50% or more of revenue from selling or sharing personal information.

The analysis should also place each entity in its correct role. A business determines the purposes of processing, while a service provider or contractor acts on its behalf under contract. Groups often include both, so the scope should be documented entity by entity.

Employee and business-to-business data are within scope, which is the point most companies miss. Write down the reasoning, because it drives everything that follows.

2. Map personal information and data flows

The inventory should cover the categories CCPA names, from identifiers and commercial information to internet activity, geolocation, sensitive personal information and inferences.

For each category, record where it is collected, why it is used, which systems hold it, who receives it and how long it is kept. Include marketing platforms, support tools, analytics and any vendor that touches consumer data.

A useful inventory connects to a wider data privacy and security programme rather than being rebuilt for California alone. Most of the fields are the same ones a GDPR record of processing would use.

3. Refresh the privacy notice and the notice at collection

The privacy policy must list the categories collected, the purposes, the sources, the third parties that receive them, the consumer rights available and the retention periods. It also has to reflect activity from the previous twelve months.

The notice at collection is separate and must appear at or before the point of collection, stating the categories and purposes for that specific collection.

A generic template becomes a liability when it does not match what the business actually does. A well structured privacy policy should be generated from the data inventory, not written independently of it.

4. Build a consumer rights request process

CCPA gives consumers the right to know, access, delete and correct personal information, to opt out of sale or sharing, to limit the use of sensitive personal information and not to be discriminated against for exercising those rights.

The process should define how requests arrive, how identity is verified, who handles them and how responses are approved. Businesses must respond within 45 days, with a possible extension, and keep records of requests for at least 24 months.

Requests must be honoured across production systems, archives, backups, marketing tools and supplier platforms, beyond the primary database.

5. Manage sales, sharing and targeted advertising

Where personal information is sold or shared, the business must provide a clear “Do Not Sell or Share My Personal Information” link and respect opt-outs. Sharing for cross-context behavioural advertising counts, which brings many marketing and analytics setups into scope.

Opt-out preference signals such as the Global Privacy Control must be honoured where the regulations require it. Honouring an opt-out means applying it downstream, across ad platforms, tags and partners.

This is the step where marketing, data and legal teams have to agree on what happens when a consumer opts out, and how quickly it takes effect.

6. Put contracts in place with service providers and contractors

Personal information may pass to a service provider or contractor only under a contract that limits processing to the specified purposes, prohibits sale or sharing, requires compliance with CCPA and provides for audit and deletion.

The contract should also flow the same terms down to subprocessors. A vendor that is not under the right contract is treated as a third party, which changes the risk and the disclosure obligations.

7. Apply security safeguards and retention limits

CCPA requires reasonable security measures for the personal information a business holds, proportionate to the nature of the data. Access control, encryption, logging, incident response and vendor oversight all count. Many of these are the same controls an ISO 27001 programme already documents.

Retention should follow a defined schedule and be disclosed. Data kept without a purpose creates exposure with no benefit. The privacy risks that SaaS companies overlook usually surface here, in forgotten tools and integrations.

8. Assign ownership and train the team

One named owner should be accountable for the programme, with support from legal, security, product, marketing and engineering. Responsibility that is spread informally across teams tends not to produce evidence when it is requested.

Training should be matched to role. Support staff need to recognise a rights request, marketers need to understand sale and sharing, and engineers need to know access, logging and retention expectations. A reusable security awareness training module can satisfy several frameworks at once.

9. Handle sensitive personal information and minors’ data carefully

Sensitive personal information, such as precise geolocation, health data, credentials and information about race or sexual orientation, can be limited at the consumer’s request. Businesses should know where it is processed and be able to restrict its use.

Selling or sharing the data of consumers under 16 requires prior opt-in consent: from the consumer if aged 13 to 15, and from a parent or guardian if under 13.Products aimed at younger audiences should review notices, consent flows and retention together.

10. Document evidence, monitor and improve

The programme should produce a traceable evidence set: the risk or gap assessment, the inventory, the notices, the request log, opt-out records, contracts, training records and security evidence. Since 1 January 2026, CPPA regulations require risk assessments for processing that presents significant risk to consumers, with an attestation submitted to the Agency by 1 April 2028.

Reviews should be triggered by new products, new vendors, changes in purpose, incidents and new regulations. A programme that is reviewed only on a calendar tends to drift from what the business actually does.

Building a practical CCPA programme with PrivaLex

CCPA compliance is rarely a standalone exercise for a technology company. Organisations often need to manage CCPA requirements alongside the CPRA amendments, the GDPR, customer security commitments and contractual obligations imposed by enterprise clients. The main challenge is preventing each framework from becoming a separate collection of partially accurate policies, inventories and workflows.

The first step is to confirm whether the organisation falls within the CCPA’s scope and how it operates under the law. This may require reviewing whether it acts as a business, service provider or contractor, whether it sells or shares personal information, and whether it processes sensitive personal information. The organisation should also identify the systems, products, websites, applications and business units involved.

At PrivaLex, we begin with a scope and gap assessment covering the privacy policy, notice at collection, data inventory, consumer-request process, opt-out mechanisms, supplier contracts, retention practices and security safeguards. The result is a prioritised plan that separates legal gaps from operational weaknesses and missing evidence.

The data inventory is a central part of that work. It should identify the categories of California consumers whose information is processed, the information collected, the sources, the purposes, the systems involved, the recipients and the retention period. It should also show where information is sold, shared, disclosed to service providers or used for targeted advertising. PrivaLex can help connect this inventory with a wider privacy compliance readiness assessment so that the same underlying information supports CCPA, GDPR and customer due-diligence requirements.

Consumer-rights workflows must then be connected to the systems that hold the data. Depending on the organisation’s activities, this may include requests to know, delete or correct information, requests to limit the use of sensitive personal information, opt-outs from sale or sharing, and signals received through Global Privacy Control. The workflow should define identity verification, authorised-agent requests, internal ownership, response approvals, exceptions and evidence of completion.

We also review whether the privacy policy and notice at collection accurately describe the organisation’s real practices. This includes the categories of information collected, purposes of use, disclosures, retention periods, sale or sharing activities and available consumer rights. A notice should not promise controls that the organisation cannot operate, and it should not omit processing performed through analytics tools, advertising platforms, cloud services or customer-support systems.

Supplier and contract management is another important part of CCPA readiness. Service-provider and contractor terms should reflect the actual data flows and restrict the provider’s use of personal information appropriately. The organisation should be able to distinguish between a service provider, a contractor and another third party, while also documenting deletion, assistance with consumer requests, confidentiality, security and audit expectations.

Security and retention controls should support the privacy programme rather than operate separately. Access restrictions, vulnerability management, logging, encryption, incident response and deletion procedures should be assessed against the personal information the organisation actually holds. PrivaLex’s risk-assessment approach for ISO 27001 and NIS2 can help connect privacy exposure, security controls, risk ownership and supporting evidence.

Where the organisation operates across the United States, Europe and other jurisdictions, we map shared controls once while keeping the differences visible. For example, a single data inventory may support both CCPA disclosures and GDPR records, but the consumer-rights workflow, legal terminology, opt-out requirements and notice content may still need to remain specific to California.

The final programme should give the organisation a practical way to monitor changes, review new products, onboard suppliers, respond to consumer requests and demonstrate compliance. It should also provide evidence that policies are implemented, requests are handled, opt-outs are respected, contracts match the data flows and security measures are reviewed.

The aim is not to assemble another folder of templates for a single review. It is to build a CCPA operating model that the team can use day to day and explain clearly to a regulator, customer, auditor or business partner.

The evidence that serves CCPA and other frameworks

Most of what a CCPA review asks for is the same evidence a wider privacy programme already produces. Building it once reduces duplicated work across frameworks.

Evidence	What it demonstrates	Also supports
Privacy notice and notice at collection	Transparency and consumer rights	GDPR transparency
Data inventory and processing map	What is collected, why and where	GDPR records of processing
Consumer request log	Requests handled within the required timelines	GDPR data subject requests
Opt-out and preference signal records	Sale and sharing opt-outs honoured	Wider privacy preference signals
Service provider contracts	Contractual limits and flow-down	GDPR processor agreements
Risk assessments	Significant-risk processing evaluated	GDPR impact assessments
Retention schedule	Data kept no longer than necessary	GDPR storage limitation
Security control evidence	Reasonable security in place	ISO 27001 and SOC 2
Training records	The team understands the obligations	All frameworks
24-month request records	Statutory record keeping	CCPA specific

The items at the bottom are the ones teams forget, because they do not sit in a privacy folder. They need a named owner and a review cycle of their own.

CCPA and GDPR: one programme with two regimes

A CCPA compliance checklist drawn up in isolation tends to duplicate privacy work that already exists for the GDPR appeal. The two regimes share a foundation but differ in important ways.

CCPA is built around opt-out rights, especially for the sale and sharing of personal information, while the GDPR is built around lawful bases and, in many cases, opt-in consent. The GDPR also adds a controller and processor distinction, data protection officers, transfer rules and impact assessments that CCPA approaches differently. Individual rights overlap but are not identical.

For a European company that does business in California, both can apply at once, and the practical answer is one programme with the framework-specific duties made explicit. A team already working on privacy programme maturity for the GDPR is most of the way to a CCPA foundation. The same records are what let a team prove that the programme works rather than simply asserting it. The GDPR text remains the reference for the European side.

The goal is a single inventory, a single request workflow and a single evidence set, with a short, visible list of the points where California and Europe require different treatment.

Conclusion

CCPA compliance is a programme, not a document. It starts with scope and an inventory, runs through notices, consumer rights, opt-outs, contracts and security, and ends with evidence that a regulator can follow.

The efficient approach is to build the shared privacy foundation once and keep the California-specific obligations, such as opt-out preference signals and 24-month request records, clearly visible on top. Companies that do this answer a CCPA request and a GDPR request from the same records.

Frequently Asked Questions (FAQs)