Start With What You Already Run
California’s cybersecurity audit rule requires an independent assessment of 18 control areas. It does not require you to adopt a new named standard, stand up a parallel “CCPA security program,” or throw out the SOC 2, ISO 27001, or NIST CSF work you already do.
That is by design. The CPPA wrote a risk-based rule, not a catalog. Auditors work under recognized auditing standards. Covered businesses map the 18 components to the controls they already operate, then supplement what those programs do not cover.
The CPPA’s own impact analysis estimated roughly a 30% first-year cost reduction for businesses that already operate under a recognized framework. The work is mapping, filling California-specific gaps, and proving operating effectiveness over a 12-month period.
Two Layers, Not One Framework
Most of the confusion comes from mixing up two different layers.
Auditing standards govern how the auditor works: independence, evidence, sampling, documentation. The regulation expects a qualified, objective, independent professional using standards from bodies such as AICPA, PCAOB, ISACA, or ISO.
Control frameworks govern what is already in the environment: access, encryption, logging, incident response, vendor oversight. That is where NIST CSF 2.0, SOC 2, ISO 27001:2022, and CIS Controls v8.1 live.
You need both. A SOC 2 report is not automatically a CCPA cybersecurity audit. An ISO 27001 certificate is not automatically a CCPA cybersecurity audit. Either can become the backbone of one if the 18 components, the audit period, the report contents, and independence rules are satisfied.
How Existing Frameworks Line Up
NIST CSF 2.0 is the closest official nod. Section 7123(f) of the regulation notes that an audit conducted under NIST CSF 2.0 would likely satisfy the CPPA’s requirements if the 18 components are met on their own or through supplementation. It covers the full govern-identify-protect-detect-respond-recover lifecycle, and it is already the language many boards and insurers understand.
SOC 2 Type II is the most common starting point for SaaS. Trust Services Criteria cover a large share of the 18 components, especially access, change management, logging, incident response, and vendor management.
ISO 27001:2022 is equally usable. Annex A maps well to most technical components, and the ISMS gives you the governance and continuous-improvement story auditors want. A surveillance audit is not automatically a CCPA cybersecurity audit. Scope, period, and the California-specific components still have to be addressed.
CIS Controls v8.1 is a solid technical baseline, particularly for smaller teams, but it is not an audit framework on its own. Pair it with a recognized audit methodology.
The practical rule is supplement, do not replace. Existing audits can be used if every required component is covered. Where they are not, the auditor tests the missing pieces rather than re-performing the entire program.
Where Mature Programs Still Fall Short
Crosswalks from audit firms and law firms keep landing on the same short list. These are the areas SOC 2 and ISO 27001 programs most often do not fully satisfy as written.
1. A California personal information inventory, not a generic asset list. CCPA wants PI and sensitive PI inventoried by CCPA categories, with storage locations, data flows, and third-party access (including cloud). A CMDB of laptops and SaaS apps is not that. Neither is a GDPR RoPA copied over without CCPA category tagging.
2. Phishing-resistant MFA across the people who can actually reach PI. Employees and contractors are in scope as an explicit audit criterion. Service provider authentication is evaluated based on risk. SMS and basic push MFA will get questions. Privileged access without a PAM story will get more.
3. A vulnerability disclosure process. Annual pen tests and quarterly scans are necessary and not sufficient. The component includes how the business receives and handles vulnerability reports, which for many organizations means a published vulnerability disclosure policy, and for some a VDP or bug bounty. Almost no SOC 2 report covers this on its own.
Close behind those three:
- Retention schedules and disposal of PI that no longer needs to be kept, using CCPA definitions.
- Contract language that lets you oversee (and, when needed, pull into the audit) service providers and third parties that process California PI.
- Breach notification samples and an incident file that will survive a five-year retention ask.
- Awareness as a distinct activity from annual security training.
How We Audit It
We do not pick a single framework and force the environment into it. We take a multifaceted approach:
Use the program you already have as the control catalog. If you run SOC 2, we map Trust Services Criteria. If you run ISO 27001, we map Annex A and the ISMS. If you run NIST CSF 2.0, we map the functions and categories. Mixed environments are normal. One control can satisfy several components.
Audit under recognized standards. Fieldwork follows ISACA or ISO auditing methodology: independence, evidence, sampling, and a signed statement that the review was not based primarily on management assertions. That is the “how.” The “what” is the 18 components, not a second GRC stack.
Supplement only the California-specific layer. PI inventory by CCPA category, MFA scope, vulnerability disclosure, retention and disposal, third-party audit cooperation, and breach-notification samples. Those are the items that turn “we already have SOC 2” into a finding.
Pull from the program you already operate. A continuously running SOC 2 or ISO program already produces evidence across the year. The CCPA audit reaches into that same operating period. You are not waiting on a separate evidence window.
Independence still applies. If we designed or currently maintain the program, we prepare it and a different firm signs. If we did not, we can be the auditor of record. That split is covered on the CCPA Cybersecurity Audit page.
If you are still confirming whether the rule applies, start with the requirements overview. If you already know you are in scope and want the mapping or the audit itself, that is the service engagement.
