In Part 1 of this series, we walked through the basics of the California Consumer Privacy Act’s (CCPA) new cybersecurity audit requirement: which businesses are covered, when audits are required, and the high-level obligations to have on your radar.

Part 2 picks up from there and gets into the mechanics. It explains how the California Privacy Protection Agency (CalPrivacy) expects the cybersecurity audit to work in practice, with a focus on four core questions:

• What exactly is being audited? We unpack the purpose and scope of the audit, including the fact that it is fundamentally driven by California personal information and sensitive personal information and how that drives which systems, vendors, and environments come into scope. Because the audit is organized around legal definitions of “personal information” and “sensitive personal information” and their regulatory treatment, it is inherently a joint exercise for legal/privacy and security rather than something either function can realistically run in isolation.

• Who can perform the audit, and what does “independent” really mean? We walk through the “independent auditor” requirement, how it applies differently to internal and external auditors, and the reporting structures and role separation CalPrivacy may expect.

• What does “thorough” look like for both the business and the auditor? We outline the business’s obligation to be transparent and cooperative, the types of information and access that may be needed, and how to think about “thoroughness” as a two-way street.

• What must be documented and what do you do with the findings? We detail the evidence standards, required contents of the CCPA audit report, and the importance of having a realistic remediation roadmap so the business can show progress rather than the same issues persisting year after year.

In Part 3, we will pivot from how the audit works to what is “under the hood” of the cybersecurity program itself, including the 18 components CalPrivacy calls out in the regulations. We will also revisit the core point that, even with this added detail, CalPrivacy is aligned with widely accepted security principles: cybersecurity is, and should remain, risk based.

I. Purpose + Scope (Hint: It’s Personal-Information-Driven)

The CCPA cybersecurity audit is intended to evaluate the design and effectiveness of a covered business’s cybersecurity program. CalPrivacy has been clear on several points:

• The audit is not a checklist. The cybersecurity program components that the regulations identify are not a set of prescriptive controls that every business must implement.

• Audit findings must be evidence-based. A CCPA cybersecurity audit cannot rely solely on management assertions; instead, the auditor must support them with specific evidence such as documents, sampling and testing, and interviews.

• Cybersecurity remains risk-based and proportional. The question is whether the program is appropriate to the business’s size, complexity, nature, and scope of processing, and the cost and feasibility of controls.

Although the CCPA cybersecurity audit will often examine many of the same systems and controls as a traditional IT or cybersecurity audit, its organizing principle is different. The CCPA cybersecurity audit is fundamentally data-driven: it is concerned with how the business protects California personal information and sensitive personal information, not simply whether particular systems or assets are secure in the abstract. Two definitions from the regulations reinforce this point:

• “Information System”: the resources (e.g., network, hardware, and software) organized for the processing of personal information or that can provide access to personal information. The business’s information system includes the resources organized for the business’s processing of personal information, regardless of whether the business owns those resources.

• “Cybersecurity Program”: the policies, procedures, and practices that protect personal information from unauthorized access, destruction, use, modification, or disclosure, and that protect against unauthorized activity resulting in the loss of availability of personal information.

Reading these definitions together, we understand that the purpose of the CCPA cybersecurity audit is to assess how the organization protects personal and sensitive personal information in practice — wherever that data resides, however it is processed, and across all information systems that process or can provide access to that data, including third‑party environments the business uses but does not own.

This data‑driven approach distinguishes CCPA cybersecurity audits from many “general” cyber or IT audits that are primarily system or asset‑centric. A traditional IT audit might begin by identifying critical systems and infrastructure — networks, servers, databases, and applications — before asking whether those systems are reasonably protected from unauthorized access or disruption. Personal information is part of the picture, but it is often treated as one attribute of those systems rather than the primary driver of scope.

By contrast, a CCPA cybersecurity audit should begin with a map of the business’s California personal and sensitive personal information:

• What categories of personal and sensitive personal information are collected and processed in relation to California consumers? Businesses should pay close attention to how “personal information” and “sensitive personal information” are defined under the CCPA, as well as the various exemptions (for example, for certain Gramm‑Leach‑Bliley Act (GLBA)‑regulated or Fair Credit Reporting Act (FCRA)‑regulated data). Depending on the facts and the specific exemption, systems dealing purely with exempt data may fall partially or entirely outside the scope of a CCPA cybersecurity audit. In many organizations, this is a point where legal (e.g., privacy counsel, the CPO, and/or the GC’s office) must partner closely with security so that legal interpretations of those definitions and exemptions line up with how systems actually collect, store, and use the data.

• Where that data resides (e.g., in on‑premises systems, cloud services, SaaS platforms, end‑user devices, and backups), and which information systems (e.g., networks, hardware, software, remote access solutions, and similar resources) are organized to process that data or can provide access to it.

• How that data flows among internal systems and across third‑party relationships, including service providers and contractors whose systems form part of the business’s information system for CCPA purposes because they are used to process or access California personal information.

That data map — ideally repurposed from existing classification schemes and prior data‑mapping exercises rather than recreated from scratch — then informs and drives the audit scope. Systems, applications, and vendors come into scope because they process or provide access to California personal and sensitive personal information, not simply because they are “important IT assets.” For example, a SaaS tool holding large volumes of California consumer records may be central to the CCPA cybersecurity audit, while a mission‑critical operational system that never touches personal information may be largely outside the audit’s focus.

Third‑party processing is also evaluated through this data‑driven lens. The cybersecurity audit is not simply concerned with whether vendors are secure; it is focused on which service providers and contractors actually process California personal or sensitive personal information, how those relationships are governed contractually (remember, CCPA has specific requirements for service provider and vendor contracts), and whether the controls at those providers are appropriate to the type and volume of data they handle.

One way to conceptualize the difference is as follows:

	Traditional Cyber / IT Audit (System-centric)	CCPA Cybersecurity Audit (Data-centric)
Primary Scope Driver	Critical systems and infrastructure (e.g., ERP, networks, databases, applications)	Processing of California personal and sensitive personal information and the information systems (including third‑party resources) that process or provide access to that information
Key Question	Are our systems and assets reasonably protected from unauthorized access or disruption?	Is our cybersecurity program appropriate and effective in protecting personal and sensitive personal information, wherever it resides or flows?
Components	Administrative, physical, and technical	Policies, procedures, and practices
Role of Data	Data is one factor in assessing system criticality	Personal and sensitive personal information are the central scoping and risk variables

At a practical level, getting clear on exactly what you are auditing is step one. Once you have mapped your California personal and sensitive personal information and identified the information systems (internal and third‑party) that process or provide access to that data, it is worth memorializing that analysis in a short memo that spells out what systems, business units, and vendors are in scope, what is out of scope, and — critically — why. That contemporaneous explanation can be just as important as the testing itself if CalPrivacy later reviews the cybersecurity audit report and asks how you drew the lines around your cybersecurity program and its coverage.

II. The Independent Auditor Requirement

The CCPA requires a qualified, objective, and independent auditor to conduct cybersecurity audits and to be familiar with both cybersecurity and how to audit a cybersecurity program. This concept of an independent auditor is not new; similar independence and competency requirements are common across well-known frameworks and regulations (e.g., New York Department of Financial Services (NYDFS) Cybersecurity Regulations, System and Organization Controls (SOC) 2, etc.). In practice, that means the auditor should:

• Have both technical cybersecurity expertise and enough CCPA knowledge to understand what the law regulates and requires; and
• Use procedures and standards accepted in the auditing profession (e.g., those provided or adopted by American Institute of Certified Public Accountants (AICPA), Public Company Accounting Oversight Board (PCAOB), Information Systems Audit and Control Association (ISACA), or Information Systems Audit and Control Association (ISO)‑related standards).

The regulations allow either internal or external auditors to perform audits. Independence is the constraint that matters. Regardless of who you use, the auditor must be able to:

• Exercise objective and impartial judgment, free from management influence; and
• Avoid participating in activities that would compromise independence (e.g., the auditor cannot be the same person who designed or implemented the cybersecurity program).

Accordingly, whether the cybersecurity audit is performed by an internal or external auditor is less important than whether the business can demonstrate separation from the people and decisions being audited. The practical difference between using an internal versus an external auditor lies in how the business establishes and documents that independence in each case.

CCPA Requirement / Consideration	Internal Auditor	External Auditor
Objective and impartial judgment; free from management influence	The business must be able to show that the internal audit function has enough independence from the security/IT teams it is assessing.   The business should document reporting lines, escalation paths, and how audit planning and conclusions are insulated from day-to-day cybersecurity management decisions.	Independence is generally easier to demonstrate, provided the firm has not designed or operated the cybersecurity program.   Engagement terms and scope should avoid blurring the line between independent audits and consulting on the same controls (similar to how in incident response, engagement terms for containment and restoration are intentionally kept separate).
No participation in activities that compromise independence (e.g., cannot design, implement, or maintain controls they audit)	The business must ensure internal auditors are not also drafting policies, implementing security tools, or creating procedures that they later audit.   May require formally scoping internal audit out of certain “first-line” security projects to preserve independence.	Easier to manage via engagement scope: the CCPA cybersecurity audit team should not be the same team that helped design key controls or the overall program.   If the firm has done prior advisory work, you may need to show that audit personnel were walled off from design implementation work.
Reporting structure for auditors	If the auditor is internal, the highest‑ranking auditor must report directly to a member of the executive management team who does not have direct responsibility for the business’s cybersecurity program.   That executive (without cybersecurity program responsibility) should also conduct the auditor’s performance reviews (if any) and set their compensation. In other words, the CISO (or similar) should not be in the auditor’s reporting chain or responsible for their evaluation or pay.	The external auditor reports through the engagement relationship, not into your internal org chart.   The CCPA independence concerns are addressed more through contract, scope, and avoiding conflicting roles than through internal reporting structures.
Practical pros/cons (speed, cost, familiarity)	Deep familiarity with internal systems and records can make evidence collection faster and less disruptive.   Lower incremental cost if you already have an internal audit or IT audit team with cyber expertise.   But you must be able to demonstrate structural independence and avoid conflicts with their other responsibilities.	Often brings specialized cyber‑audit experience and a “fresh eyes” perspective.   May be perceived as more independent by regulators.   Higher direct cost and some ramp‑up time to understand internal systems and nuances of your environment.

One important point that is easy to miss and worth underscoring: the person who evaluates the auditor’s performance or sets their compensation likewise should not be an executive management team member who is responsible for the business’s cybersecurity program. This separation is deliberate. It reduces the risk of subtle pressure on the auditor to soften findings or align too closely with management’s preferred narrative.

Regardless of whether a business uses an internal or external auditor, some level of internal preparation will almost always be necessary before the audit begins, which can be supplemented with external support. That preparation typically requires coordinated effort between security/IT, privacy, and legal so that technical realities, data-mapping, and CCPA interpretations stay aligned throughout the audit. The goal is to identify and address gaps in the cybersecurity program in advance, rather than having the auditor be the first to surface them in a formal report that may be reviewed by regulators. Practically, this can include conducting pre-audit readiness assessments, updating policies and procedures, and ensuring that required documentation is complete, accurate, and well organized. Companies may also choose to engage outside counsel, consultants, and technical experts to help with this pre-audit work and, where appropriate, structure it under legal privilege so that candid assessments of deficiencies and remediation plans are not first exposed — and memorialized — in the official audit record.

III. Thoroughness: A Two-Way Obligation

Under the CCPA, “thorough” does not just describe how deeply the auditor tests a business’s controls. It also describes a business’s transparency and willingness to cooperate. In effect, thoroughness is a two-way obligation between the business and the auditor.

The regulations make clear that a business must do more than simplify “make itself available” for an audit. Among other things, the business must:

• Make available all information the auditor requests that is relevant to the cybersecurity audit including specifically, information the auditor needs to determine the scope of the audit (e.g., which systems are in or out of scope) and the criteria the auditor will apply (e.g., which framework);
• Make good-faith efforts to disclose all facts relevant to the audit; and
• Not mispresent any fact relevant to the audit.

In practice, this may require businesses to provide system inventories, data maps, policies, procedures, and even outward‑facing security materials (for example, statements that the company follows National Institute of Standards and Technology (NIST) or other frameworks), along with any other documents the auditor reasonably identifies as relevant.

During rulemaking, commenters asked CalPrivacy to make clear that, even with this broad cooperation obligation, businesses are not required to give auditors attorney‑client privileged materials. CalPrivacy declined to add that language, explaining that it was unnecessary because the regulations do not, on their face, require production of privileged documents. That matters because it effectively puts the burden on businesses to draw the line: you must cooperate and supply all relevant, nonprivileged information, but you are expected to exercise judgment about what you do not turn over, so you do not inadvertently waive privilege.

IV. Evidence and Audit Report Content

The CCPA cybersecurity audit requirement is explicitly evidence‑driven. Findings cannot rest on “management says so.” The auditor must ground these findings in proof, including documents, testing results, and interviews.

In practice, that means the audit program should standardize what “good” evidence looks like, so you are not reinventing the wheel every year. Common examples include:

• Current, approved policies and standards that have been communicated to relevant personnel.
• System configurations and screenshots showing actual control settings in production (e.g., MFA enforcement, encryption at rest, logging enabled).
• Logs and reports, such as access logs, vulnerability scans and remediation reports, SIEM alerts, DLP reports.
• Tickets and workflow records, including access requests, change management, incident handling, and exception approvals.
• Training completion records for security awareness and role‑based training.
• Third‑party documentation such as SOC 2 reports, penetration test reports, and security certifications, where the auditor relies on them.

Using evidence as a foundation, the auditor must produce a written CCPA cybersecurity audit report. The regulations outline the core elements, which can be summarized as:

1. A description of the business’s information systems and cybersecurity program that were assessed, including:
   • The policies, procedures, and practices evaluated;
   • The criteria used for the audit (e.g., internal standards, regulatory requirements);
   • The specific types of evidence examined; and
   • Why the above justify the auditor’s findings.

2. A description of the applicable cybersecurity components (and relevant policies and procedures) and how the business implements and enforces compliance with those components.

3. The status of any gaps or weaknesses identified in the cybersecurity components, policies, and procedures.

4. The business’s plan to address the identified gaps and weaknesses, including the timeframe in which it will resolve them.

5. Any corrections or amendments to prior cybersecurity audit reports, if needed.

6. The identity of up to three qualified individuals responsible for the business’s cybersecurity program.

7. The auditor’s name, affiliate, and relevant qualifications.

8. A signed statement from the highest‑ranking auditor certifying that they completed an independent, evidence‑based review of the business’s cybersecurity program.

9. A sample or description of any data breach notifications to individuals or agencies issued during the audit period, if such notifications were provided.

Although the auditor must remain impartial, the audit report itself is a key business record that regulators or plaintiffs’ counsel may later scrutinize in enforcement or litigation. When selecting auditors and discussing expectations for the report, businesses should emphasize that conclusions need to be tied to facts and that the auditor must clearly support those conclusions with evidence, rather than by unexplained charts, heat maps, or severity labels (for example, “critical,” “red”) that lack context. In that sense, the business should approach CCPA cybersecurity audit reports much as it approaches forensic reports: the reports should remain factual, disciplined, and grounded in the underlying record.

It will not always be easy to strike the right balance between providing input on the report and preserving the auditor’s independence. For businesses that use external auditors, it can be helpful to ask for examples of prior reports and clear documentation of what the firm typically delivers, so expectations are aligned up front. Some businesses may also consider a structured draft review process, clearly labeling draft reports as such. Having verbal discussions with the auditor to explain comments or feedback, and providing additional supporting documentation where appropriate, is arguably part of the business’s “two-way” obligation to ensure the audit is thorough, so long as the auditor retains independent judgment over the final conclusions.

It is also worth emphasizing that the CCPA does not require that all of this work be “net new.” Businesses can, in principle, use an audit or assessment that they or a third party prepared for another purpose (for example, a broader enterprise cyber review or a framework-based assessment) as their CCPA cybersecurity audit, so long as it meets the CCPA’s specific requirements. In practice, that means making sure the existing audit:

• Was performed by a qualified, objective, independent auditor;
• Covers the correct time period and the processing that triggered the CCPA audit obligation (think back to this being a personal-information-driven exercise); and
• Includes (or is supplemented to include) the required CCPA report elements.

If an otherwise solid cybersecurity audit stops short on those points, you can often “top it up” with targeted procedures and documentation rather than starting from scratch.

For each calendar year in which a business must conduct a cybersecurity audit, it must also submit a written certification of completion to CalPrivacy by April of the following year. That certification must be signed, under penalty of perjury, by a member of the executive management team who is directly responsible for cybersecurity audit compliance, has sufficient knowledge of the audit to provide accurate information, and has authority to submit the certification on the business’s behalf. Importantly, the audit report itself is not automatically filed with CalPrivacy, but it can request or subpoena it in connection with an investigation or enforcement action. How CalPrivacy may use those audits and certifications in investigations and enforcement — and what that means for accountability at the executive level — will be the focus of Part 4 in this series.