A useful CCPA review tests whether the organisation does what its privacy notices say. It follows personal information from collection to use, disclosure and deletion, and checks what actually happens when someone exercises a privacy right.
The term “CCPA audit” can describe different activities. A general compliance review is not the same as the formal cybersecurity audit required for certain businesses. A website scan is narrower still. Define the scope before treating any result as evidence of compliance.
This guide covers the CCPA as amended by the California Privacy Rights Act (CPRA), using the rules and compliance dates current on 19 September 2026.
Establish scope and applicability
Start with the legal entities, services and processing activities under review. Include websites, apps, customer systems, employment records and offline collection where relevant. California employees and business contacts are not covered by the former blanket exemptions, which expired at the end of 2022.
For the main business definition, assess whether a for-profit entity does business in California, determines the purposes and means of processing personal information, and meets at least one threshold:
- Annual gross revenue above $26,625,000, using the statutory preceding-calendar-year test.
- Annually buying, selling or sharing the personal information of 100,000 or more consumers or households.
- Deriving 50% or more of annual revenue from selling or sharing consumers’ personal information.
The revenue amount applies in 2025 and 2026. The volume threshold does not simply count website visits or everyone whose data is processed. Related-entity rules and exemptions also require assessment. Being outside California does not itself exclude a business. See the current statute, particularly §§ 1798.140 and 1798.145 and the Agency’s adjusted monetary thresholds.
Record why each entity and activity is included or excluded, who approved that decision, and which assumptions need revisiting.
Map actual collection and disclosure
Build an inventory that the teams responsible for the systems can validate. A cookie inventory alone misses account records, server transfers, customer-list uploads, support tools and offline data.
For each activity, record:
| Item | Practical question |
|---|---|
| Personal information | Which categories and identifiers are involved, including sensitive information? |
| Source and collection point | Does it come from a form, browser, app, employee, vendor or offline interaction? |
| Purpose | Why is each category needed, and is the use compatible with the disclosed purpose? |
| Recipient | Who receives it, for what purpose, and in what contractual role? |
| Rights handling | Which systems must change after an opt-out, correction or deletion? |
| Retention | What period or criteria apply, and which process enforces them? |
| Responsibility | Who can explain, change and test this activity? |
Compare the inventory with representative network traffic, configuration, vendor documentation and backend records. Treat vendor labels as something to verify. A paid service can still involve sale or sharing; a service-provider classification depends on the facts and required restrictions.
Check notices against those practices
Review the notice at collection where collection occurs, including forms, apps and relevant offline channels. Check that it arrives at or before collection and explains the applicable categories, purposes, sale or sharing, and retention periods or criteria.
Then compare the privacy policy with the inventory and consumer-facing processes. It should describe applicable rights and submission methods accurately, including correction, sale/sharing opt-outs, and limitations on sensitive information where applicable. Review the required disclosures about the preceding 12 months and update the policy at least every 12 months.
Check that links lead to the relevant information, that language is understandable, and that notices and controls are accessible. A notice copied from a generator still needs to match the organisation’s actual processing. The requirements are set out in CCPA regulations §§ 7003 and 7011–7016.
If a loyalty programme or other benefit qualifies as a financial incentive, include its notice, participation terms and value calculation in the review. Do not assume every discount has the same treatment.
Test opt-outs and sensitive-information controls
For sale or sharing, test the manual privacy-choice route and Global Privacy Control (GPC). A visible link or a stored preference is only part of the process: check the resulting disclosures to recipients.
Use test profiles to inspect:
- A first visit with GPC enabled, including associated pseudonymous profiles.
- A manual opt-out while signed out, followed by a return visit.
- An opt-out while signed in, including the known consumer’s associated information.
- Browser tags, app SDKs and server transfers after the request.
- Clear confirmation that the request was processed, supported by the observed behaviour.
- Whether the choice remains effective instead of being silently reset.
Do not require identity verification for a sale/sharing opt-out. Collect only information necessary to act on it. Review the conditions for any claimed exception to displaying an opt-out link; detecting GPC alone does not establish the frictionless-processing exception.
The right to limit sensitive personal information is not a universal prohibition on processing sensitive data. Assess the purposes and permitted uses under § 7027 before deciding which controls are required. Separately assess sale or sharing involving consumers known to be under 16, including parental authorisation for those under 13.
The Attorney General’s CCPA guidance explains these rights. For implementation detail, use our cookie banner guide and opt-out form review.
Follow consumer requests through to completion
Sample completed requests as well as submitting controlled test requests. Trace receipt, routing, verification where appropriate, system changes, recipient notifications and the final response. Include authorised-agent requests and documented reasons for any refusal or partial fulfilment.
Different requests have different deadlines:
| Request | Timing to check | Verification |
|---|---|---|
| Know, delete or correct | Confirm receipt within 10 business days. Respond within 45 calendar days of receipt; a necessary extension can add up to 45 calendar days with notice and an explanation. | Apply the relevant proportionate verification rules. Verification does not restart the clock. |
| Opt out of sale or sharing | Comply as soon as feasibly possible, no later than 15 business days after receipt. | Do not require a verifiable consumer request. |
| Limit use or disclosure of sensitive personal information | Comply as soon as feasibly possible, no later than 15 business days after receipt. | Do not require a verifiable consumer request. |
These are the requirements in §§ 7021, 7026 and 7027 of the regulations, not a recommended waiting period. ADMT requests have separate provisions discussed below.
Check deletion across systems and recipients, including the rules for backups and applicable retention exceptions. A closed support ticket is not evidence that deletion occurred. Retain request-and-response records securely for at least 24 months under § 7101, and ensure staff responsible for requests understand the process.
Review vendor roles and contracts
Match each recipient in the inventory to its actual processing and executed contract. Review service providers, contractors and third parties separately.
For service providers and contractors, check specific permitted purposes, restrictions on sale/sharing and other use, required privacy protections, assistance with consumer requests, and oversight and remediation rights. The contract must also address notification when the recipient can no longer meet its obligations. Assess restrictions on combining information and downstream providers.
For third parties receiving sold or shared information, review the separate contract requirements. A generic confidentiality clause does not establish CCPA compliance. Use §§ 7050–7053 of the regulations as the legal reference.
Validate the operational side too: can the recipient apply a deletion or opt-out instruction, and can the responsible team demonstrate the result?
Review retention and security
Compare documented retention periods or criteria with database settings, exports, archives and deletion jobs. Investigate records kept indefinitely because nobody owns the deletion process. Where an exception or legal hold requires retention, record its scope and restrict further use appropriately.
Review security measures appropriate to the information and processing: access permissions, authentication, encryption, patching, monitoring, incident handling and disposal. Sample evidence that controls operate, rather than accepting a policy statement alone.
The CCPA’s necessity, proportionality, retention and reasonable-security obligations appear in Civil Code § 1798.100. These obligations are distinct from the formal cybersecurity-audit requirements below.
Assess the newer audit and assessment obligations
The regulations effective 1 January 2026 introduced detailed cybersecurity-audit, risk-assessment and automated decisionmaking technology (ADMT) requirements, with different scopes and compliance dates. They do not make every business subject to an annual formal cybersecurity audit. See the Agency’s adoption announcement.
Formal cybersecurity audits
Under § 7120, the audit requirement covers businesses meeting the 50%-of-revenue sale/sharing threshold, or the statutory revenue threshold plus specified processing volumes: at least 250,000 consumers or households’ personal information, or 50,000 consumers’ sensitive personal information, in the preceding calendar year.
For businesses within scope, the initial schedule is:
| Annual gross revenue used for the schedule | First audit period | First report deadline |
|---|---|---|
| More than $100 million in 2026, assessed as of 1 January 2027 | 1 January 2027 to 1 January 2028 | 1 April 2028 |
| $50 million to $100 million in 2027, assessed as of 1 January 2028 | 1 January 2028 to 1 January 2029 | 1 April 2029 |
| Less than $50 million in 2028 | 1 January 2029 to 1 January 2030 | 1 April 2030 |
The audit must meet scope, independence and reporting requirements. An internal auditor is possible if the independence requirements are met. The Agency also requires a certification of completion; that is distinct from routinely submitting the full audit report. Check §§ 7120–7124 against the business’s circumstances.
Privacy risk assessments
Screen activities against § 7150. Triggers include selling or sharing personal information, processing sensitive personal information subject to a limited employment-related exception, ADMT for significant decisions, and specified profiling and technology-training activities.
For covered activities initiated from 1 January 2026, conduct and document the assessment before starting. Covered activities already underway before that date and continuing afterwards must be assessed by 31 December 2027. Review assessments at least every three years, and update them sooner for material changes within the prescribed timeframe.
The first submission of required risk-assessment information and an attestation, covering assessments conducted in 2026 and 2027, is due 1 April 2028. This later filing date does not postpone the duty to assess new processing. See §§ 7150–7157.
Automated decisionmaking technology
The Article 11 requirements apply to covered uses of ADMT for significant decisions, with compliance required from 1 January 2027. Assess the definitions, applicable exceptions, pre-use notices and access and opt-out processes. Do not treat every automated tool as within scope, or describe these rights as universally operational since 2023. The final rulemaking package provides the adopted text and supporting explanation.
Turn findings into verified corrections
For each finding, record the affected activity, relevant requirement, observed evidence, responsible owner and correction needed. Separate confirmed failures from questions requiring legal or technical investigation.
For example, if a test opt-out updates the preference centre but a server continues sending identifiers for cross-context behavioural advertising, trace the missing instruction through that transfer. Retest the same scenario after the correction and retain the result.
A useful review ends with clear scope and limitations. A CMP scan cannot establish how employment requests are handled, whether a vendor contract is adequate, or whether a mandatory cybersecurity audit meets independence requirements. Tools support the review; their scores do not certify compliance.
Frequently asked questions
Is a CCPA audit different from a CPRA audit?
CPRA amended the CCPA. A current compliance review should assess the amended law and applicable regulations. Treating correction, sensitive-information controls or retention as optional additions to an “original CCPA” review leaves gaps.
Must every business perform an annual CCPA audit?
There is no single annual general-review requirement for every business. Formal annual cybersecurity audits apply to the businesses within Article 9’s scope and phased schedule. Other obligations have their own timing, including privacy-policy updates and risk-assessment reviews. Set a general review schedule based on processing and change, and revisit affected controls when systems or purposes change.
Can a cookie scan complete the review?
No. It can help identify browser activity, but it does not establish the organisation’s complete data flows, contracts, request handling, retention or security practices. Combine scans with system evidence and input from responsible teams.
Where should a website team start?
Begin with notice at collection, privacy-choice routes, GPC handling and the actual transfers made before and after an opt-out. Our CCPA readiness assessment helps organise the wider review. For the website consent layer, request a free consent audit or discuss your US-state privacy setup.
