In Part 1 of this series, we outlined the basics of the California Consumer Privacy Act’s (CCPA) new cybersecurity audit requirement: who is covered, when audits are required, and the key obligations to keep in mind. In Part 2, we explored the mechanics and explained what the California Privacy Protection Agency (CalPrivacy) expects the cybersecurity audit to look like in practice, including what must be evaluated, who may conduct the audit, how thorough it must be, and what goes into the audit report.

Part 3 focuses on making this requirement practical. We draw on both the final regulatory text and CalPrivacy’s detailed responses to public comments, which reflect CalPrivacy’s intent to align the CCPA audit with risk-based “reasonable security” approaches, allow businesses to build on existing audits and frameworks, and establish a non-prescriptive but meaningful set of 18 components that auditors must consider “if applicable” to a covered business’s information systems. These 18 core components are the focus of this article: we examine how covered businesses can leverage existing cybersecurity frameworks, how these components fit within broader “reasonable security” expectations, and how each of the 18 is defined and applied in practice.

I. Using Existing Cybersecurity Audits as the Foundation

The CCPA cybersecurity audit is not designed to make businesses start from scratch. CalPrivacy has made clear that covered businesses may rely on cybersecurity audits, assessments, or evaluations prepared for other purposes, as long as those audits — alone or with reasonable supplementation — satisfy the CCPA’s requirements.

Commenters asked CalPrivacy to treat specific frameworks or certifications as a safe harbor, but CalPrivacy declined. In the final regulation text, only National Institute of Standards and Technology (NIST) CSF 2.0 is cited by name as an example of a prior-purpose audit that may be leveraged. Through its broader rulemaking materials, including the Regulatory Impact Assessment, CalPrivacy indicated that International Organization for Standardization (ISO)/IEC 27001, and Center for Internet Security (CIS) Controls each have “some overlap” with the 18 nonprescriptive CCPA cyber program components referenced in the regulations and that existing audits based on those frameworks may similarly serve as a starting point. In all cases, though, existing audit work must be checked against the CCPA’s requirements and supplemented where it falls short on scope, components, or documentation.

In practice, many organizations can use existing NIST-, ISO-, or CIS-based assessments as their foundation. The first step is getting the scope right. The CCPA cybersecurity audit is about how the business protects personal information and sensitive personal information, wherever that data lives, however it is processed, and across all information systems that touch or provide access to it, including third-party environments the business does not own. Existing audits need to be checked to confirm they cover those systems and the right time period.

From there, the business should then map existing audits against the CCPA’s requirements and the 18 cybersecurity program components that § 7123(c) of the final regulations identifies as areas the audit must consider to the extent applicable (we cover each of those components in detail in Section III below). Where an existing audit fully covers a component, that work can be reused. Where coverage is only partial or missing, the business should “top off” with additional testing, documentation, or analysis. The goal is a single, integrated audit built on prior work and supplemented where needed.

II. “Reasonable Security” in the Broader Legal Landscape

Data security regulation in the U.S. did not arrive fully formed. It evolved, and the CCPA cybersecurity audit requirement is emblematic of this evolution. Most U.S. data security laws fall into one of three models, each of which emerged and developed over time.

a. Three Approaches to Security Obligations – and How They Evolved

1. “Reasonable Security“. The first and most common model requires businesses to implement “reasonable” measures to protect personal information, appropriate to the nature of the data and the size and complexity of the business. Most U.S. laws follow this approach, including California’s data breach statute, the Federal Trade Commission (FTC) Act’s Section 5 unfairness authority, the Gramm-Leach-Bliley Act (GLBA) Safeguards Rule, and the Health Insurance Portability and Accountability Act (HIPAA)’s Security Rule. The standard is intentionally flexible, allowing businesses to calibrate their programs to their own risk profile. While “reasonable” is not defined with precision, businesses are not left without guidance. FTC and state AG settlements, and industry frameworks like NIST CSF and the CIS Controls, provide useful reference points for what regulators have expected in practice.

2. Prescriptive Requirements. A second wave of laws moved from flexible standards to specific mandates. Massachusetts, New York State Department of Financial Services DFS, and the amended FTC Safeguards Rule each enumerate concrete controls, including a qualified chief information security officer (CISO), multifactor authentication (MFA), encryption, or penetration testing. There is less flexibility and less room for interpretation. That clarity can be valuable, but it also creates operational challenges. Businesses may find themselves required to implement controls that do not align with their actual risk profile, or that become outdated as the threat landscape evolves.

3. “Carrot, Not the Stick”. A third approach, adopted by states like Ohio, Utah, and Connecticut, offers an affirmative defense or cap on punitive damages to businesses that follow a recognized framework like NIST CSF or ISO/IEC 27001. No mandate, just an incentive. The theory is that market-driven adoption of strong security practices is more effective than top-down mandates, and that businesses already investing in recognized frameworks should not face the same litigation exposure as those that are not.

b. Where the CCPA Audit Fits

The CCPA audit requirement is firmly in the “reasonable security” camp: flexibility and risk-based judgment remain central. What CalPrivacy has added is an audit mechanism and a set of specific program components that auditors must consider “if applicable.” That makes California’s “reasonable security” expectation more concrete and auditable than many comparable “reasonable security” laws and likely signals the benchmark CalPrivacy will use in enforcement.

The result is a set of cybersecurity requirements that avoids the rigidity of a fully prescriptive regime while being more concrete and auditable than most “reasonable security” laws.

That approach is worth pausing on. California regulators have historically looked favorably on the CIS Controls as a baseline for “reasonable security” — the state attorney general (AG) cited them in the 2016 Data Breach Report as the standard businesses should meet to avoid liability under California’s breach statute. One might have expected CalPrivacy to lean on that foundation here. Instead, CalPrivacy took a different path. Rather than pointing to any single framework as the answer, it identified its own set of 18 program components grounded in what the audit must evaluate (to the extent applicable). Those components are more descriptive than prescriptive — they tell auditors what areas to examine, not exactly how a business must address them. Whether a given control is appropriate still depends on the business’s size, complexity, and risk profile.

Because the 18 components now represent CalPrivacy’s own articulation of what a cybersecurity program should look like, they are likely to serve as the benchmark the agency uses in enforcement — not just for businesses subject to the audit requirement, but potentially for all businesses subject to existing reasonable security obligations in California.

III. The CCPA’s 18 Cybersecurity Program Components

The 18 cybersecurity program components are the most scrutinized part of the new regulations — and for good reason. They are where CalPrivacy comes closest to defining, in practical terms, what “reasonable” cybersecurity may look like for covered businesses.

The components fall into four groups:

• Identity and access management: multifactor authentication, strong passwords, least-privilege access, restricting privileged accounts, account creation, restricting physical access to personal information;

• Data and systems protection: encryption of personal information, secure configuration, vulnerability management, audit-log management, network monitoring and defenses, antivirus and anti-malware, network segmentation, port and protocol management;

• Program and asset management: data and asset inventories, secure development and coding, vendor and third-party risk management, data retention and disposal; and

• Response, resilience, and culture: incident response, cybersecurity awareness, cybersecurity education and training, business continuity and disaster recovery.

a. Evaluation Points, Not a Rigid Checklist

Early drafts raised concerns that the 18 components would function as a mandatory checklist, forcing businesses to adopt each control and document any deviation in writing. Commenters pushed back, particularly on behalf of smaller organizations.

CalPrivacy responded by revising the text and clarifying in its rulemaking materials that the audit must assess the components the auditor deems applicable to the business’s information systems and may address others not on the list. The list is expressly framed as “if applicable,” acknowledging that not every component will be relevant for every business.

CalPrivacy also amended earlier draft language that would have required the audit report to explain, component by component, why each was or was not implemented. Businesses still need to make thoughtful, risk-based decisions, but they do not need to reproduce that reasoning verbatim in the report.

The bottom line is that the 18 components are evaluation points, not a compliance checklist. Section III(b) walks through each one briefly, with nuances from CalPrivacy’s rulemaking materials that are worth paying attention to.

b. A Closer Look at the 18 Components

1. Authentication: § 7123(c)(1). Includes multifactor authentication, phishing-resistant MFA for employees and contractors, and strong password practices. The password sub-component applies only if the business actually uses passwords or passphrases, so organizations that have moved to password-less authentication are not penalized. An earlier draft included “zero trust architecture” as a standalone evaluation criterion; CalPrivacy deleted it entirely in the final regulations.

2. Encryption of personal information: § 7123(c)(2). Includes encryption of personal information both at rest and in transit. When prompted by commentators to adopt a specific encryption standard, CalPrivacy declined, explaining that they wanted to preserve flexibility across different factual scenarios and industries and to accommodate variations among businesses.

3. Account management and access controls: § 7123(c)(3). Includes least privilege access, limiting and monitoring privileged accounts, restricting access to personal information to those who need it, and restricting physical access to personal information. The final regulations added “account” and “application” to the sub-elements, expanding scope beyond traditional infrastructure hardening to cover application-level and account-level configuration. Additionally, CalPrivacy emphasized that including restrictions on and monitoring of “physical access to personal information” aligns with other cybersecurity frameworks and stressed that these requirements, including those related to physical access security, are meant to provide businesses with flexibility in how they meet the cybersecurity audit requirements.

4. Inventory and management of personal information and the business’s information system: § 7123(c)(4). Includes maintaining an inventory of personal information, data flows, hardware, and software. The scope extends to all systems through which personal information is processed or accessible, including cloud environments and third-party systems the business does not own or operate. This is broader than many standard framework assessments, which typically focus on systems within the organization’s direct control.

5. Secure configuration of hardware and software: § 7123(c)(5). Includes hardening of systems, patch management, change management, and masking of sensitive personal information where appropriate, for both on-premises and cloud environments.

6. Vulnerability scanning and penetration testing: § 7123(c)(6). Includes internal and external vulnerability scans, penetration testing, and processes for vulnerability disclosure and reporting, such as bug bounty and ethical hacking programs. 

7. Audit-log management: § 7123(c)(7). Includes centralized storage, retention, and monitoring of logs.  

8. Network monitoring and defenses (§ 7123(c)(8)). Includes defenses to detect unauthorized access, destruction, use, modification, or disclosure of personal information. Bot-detection, intrusion-detection, and intrusion-prevention tools are listed as examples, not mandates. The component evaluates whether the detection and defense function is present and effective, not whether the business uses any specific technology.

9. Antivirus and anti-malware protections: § 7123(c)(9). Includes deployment and maintenance of antivirus and anti-malware solutions.

10. Segmentation of an information system: § 7123(c)(10). Includes segmentation of information systems, for example via properly configured firewalls, routers, and switches.

11. Port and protocol management and protection: § 7123(c)(11). Includes limitation and control of ports, services, and protocols to reduce attack surface.

12. Cybersecurity awareness: § 7123(c)(12). Includes how the business maintains current knowledge of evolving cybersecurity threats and appropriate countermeasures. An earlier draft treated awareness and training as a single component; CalPrivacy split them into two in the final regulations. A robust training program may not satisfy this component on its own.

13. Cybersecurity education and training: § 7123(c)(13). Includes training for employees, independent contractors, and anyone granted access to the business’s information systems, whether at onboarding, annually thereafter, and/or following a personal information security breach.

14. Secure development and coding practices: § 7123(c)(14). Includes secure coding standards, code reviews, and security testing as part of the software development lifecycle.

15. Oversight of service providers, contractors, and third parties: § 7123(c)(15). Includes oversight of vendors and contractors to ensure compliance with the business’s cybersecurity program obligations. Because the regulation’s scope language expressly encompasses third-party environments, this component intersects with virtually every technical component on the list. A vendor processing California personal information on the business’s behalf is within the audit’s reach, and existing vendor risk programs may need to be re-scoped with that consumer-data lens in mind.

16. Retention schedules and proper disposal of personal information: § 7123(c)(16). Includes retention schedules and secure disposal of personal information that is no longer needed, by shredding, erasing, or otherwise making it unreadable or undecipherable. Existing retention schedules should be reviewed to confirm they are scoped to California personal information and sensitive personal information, not just general records.

17. Security-incident response management: § 7123(c)(17). Includes the business’s incident response program, documented procedures, response capabilities, and testing, as well as a review of actual security incidents that occurred during the audit period. Two things are worth flagging. First, CalPrivacy narrowed the definition of “security incident” to require that the threat to personal information be “imminent” rather than merely “potential,” limiting what must be counted to near-term, concrete threats rather than every low-confidence alert. Second, the review expressly covers breach notifications sent to California consumers or agencies with privacy jurisdiction in California during the period, meaning the audit creates a structured, documented record of the business’s California breach notification history that could surface in enforcement or litigation.

18. Business-continuity and disaster-recovery planning: § 7123(c)(18). Includes BC/DR plans, data-recovery capabilities, and backups, as well as testing of those capabilities to ensure availability of personal information during disruptions.

Finally, consistent with the nonprescriptive nature of these elements, the regulations include a catchall provision stating that nothing prevents a cybersecurity audit from evaluating aspects of a cybersecurity program beyond the 18 specified components. As a result, additional components within a business’s environment may still be subject to review if the auditor determines they are relevant to a cybersecurity program.

IV. A Practical Roadmap: Leveraging Frameworks and “Topping Off” for CCPA

Taken together, these points suggest a practical four-step approach for covered businesses subject to the CCPA cybersecurity audit requirement.

1. Inventory Existing Audits and Assessments

Most organizations already have security assessments of some kind: NIST CSF-aligned risk assessments, ISO/IEC 27001 certification audits, or CIS Controls gap analyses. Start by identifying which are recent, comprehensive, and most closely aligned with the systems and processes involved in handling California personal information.

CalPrivacy’s own Regulatory Impact Assessment acknowledged that all four of those frameworks have “some overlap” with the 18 components but also estimated that leveraging an existing framework reduces compliance costs by only about 30%, signaling that meaningful supplementation is expected in every case. Existing audits are a starting point, not a finish line.

2. Re‑Scope Through the CCPA Lens

Next, apply a CCPA-specific scoping lens:

• System and data scope. Does the existing work cover the systems, applications, and environments where California personal information and sensitive personal information is stored or accessible, including cloud and third-party environments? This is one of the most common places existing assessments fall short.

• Time scope. Does the period examined align with the CCPA audit period?

If the answer to any of these is “not fully,” additional scoping and testing will be needed before the existing work can carry its weight in the CCPA audit.

3. Map to the 18 components and identify gaps

With scoping done, map existing audit work to each of the 18 components to the extent they are applicable to the business’s information systems. Where existing coverage is solid, that work can be reused. Where the mapping reveals gaps, design additional procedures to close them. The component-level overview in Section III(b) is a useful reference for places where existing work may be narrower than CalPrivacy expects, even where a component looks covered on the surface.

4. Ensure Independence and Governance Requirements Are Satisfied

Leveraging an existing audit does not relax any of the CCPA’s requirements around who conducts the audit and how results are handled. As we covered in Part 2, those requirements, including auditor qualifications and independence, the internal auditor reporting structure, the auditor’s signed independence certification in the report, and delivery of the report to the executive with direct cybersecurity responsibility, apply regardless of whether the audit is built on prior framework work.

As part of the governance process, businesses should test whether the evidence supporting the audit will hold up under scrutiny. Not all evidence is equal. The strongest proof is current, system‑generated, and clearly tied to the specific control — such as logs, telemetry, configuration exports, scan results, and remediation tickets that show not just that an issue was found, but how, when, and by whom it was fixed.

Policies, procedures, interview notes, and screenshots can still help, but they are less persuasive on their own because they usually show what is supposed to happen, or what was visible at one moment in time, rather than how the control actually operated over the audit period. Problems also arise when tickets lack closure details, exceptions are handled informally, third‑party reports do not cover the right systems or time frame, or the file does not clearly show who tested what, when, and against which criteria. These gaps can make an otherwise solid audit look weak if regulators or opposing counsel take a close look. Part 5 will take a closer look at the regulatory enforcement and litigation implications for the cybersecurity audit.

One governance point worth flagging separately: the executive who submits the annual certification to CalPrivacy must attest under penalty of perjury not only that the audit was completed, but that the business has not made any attempt to influence the auditor’s decisions or assessments. That attestation creates personal exposure for the signing executive beyond simply certifying completion, a point we will return to in Part 4.