Summary: California has adopted a new cybersecurity audit requirement under the CCPA. Businesses that meet the revenue or data volume thresholds must have an independent auditor verify 18 control areas, with the first reports due April 1, 2028, and the first audit period opening January 1, 2027. An existing SOC 2 or ISO 27001 report can be a starting point but rarely satisfies the rule on its own.
California’s new cybersecurity audit requirement takes effect on a phased schedule, with the first reports due April 1, 2028. If your business meets the thresholds below, an audit-ready security program should be in place well before that date. The rule builds in no grace period for businesses that start late.
The requirement comes from Article 9 of the California Consumer Privacy Act (CCPA) regulations, adopted by the California Privacy Protection Agency. It moves cybersecurity from self-attestation to an independently audited requirement for businesses handling personal information, similar to a SOC 2 or ISO/IEC 27001 examination.
Does this apply to your business?
Your business needs a cybersecurity audit if either of the following were true in the preceding calendar year:
- Revenue from data sales: Your business derived 50% or more of its annual company revenue from selling or sharing California consumers’ personal information.
- Revenue plus data volume: Your business had more than $25 million in annual gross company revenue, and you processed personal information for 250,000 or more consumers or households or sensitive personal information for 50,000 or more consumers.
These thresholds cover consumer, employee, and business-to-business data alike. A company that sells only to other businesses can still trigger the requirement through employee and vendor contact data if the volume is high enough.
Key deadlines by revenue tier
| Annual gross revenue | First audit report due | Audit period covered |
|---|---|---|
| More than $100 million (as of Jan. 1, 2027) | April 1, 2028 | Jan. 1, 2027 to Jan. 1, 2028 |
| $50 million to $100 million (as of Jan. 1, 2028) | April 1, 2029 | Jan. 1, 2028 to Jan. 1, 2029 |
| Less than $50 million (as of Jan. 1, 2029) | April 1, 2030 | Jan. 1, 2029 to Jan. 1, 2030 |
Table 1: Audit report deadlines by revenue tier
After the first cycle, the audit becomes an annual, rolling requirement tied to whether your business still meets the thresholds every January 1st.
What the audit checks
This is not a policy review. Therefore, an independent auditor must find evidence that each of the 18 control areas listed work as intended, and not just that a document describing it exists. The following table covers all 18 control areas, what each address, and what evidence typically looks like.
| Control area | What it covers | What evidence looks like |
|---|---|---|
| 1. Authentication | How users and vendors verify identity before reaching systems with personal information, including MFA and password strength. | MFA enrollment reports across employee and vendor accounts, as well as password policy settings. |
| 2. Encryption | Protecting personal information at rest and in transit. | Config exports showing encryption on production databases and scans confirming secure connections. |
| 3. Account management and access controls | Limiting access to personal information to those who need it, restricting admin accounts, and controlling physical access. | Role-based access permissions, user access reviews, and evidence that terminated employee access is removed upon termination. |
| 4. Inventory and management of personal information and the information system | Knowing what personal information exists, where it lives, and what hardware and software touch it. | A current data inventory or map, asset listings of devices, and approved software. |
| 5. Secure configuration | Keeping systems patched, testing changes before deployment, and securing cloud environments, including masking sensitive data outside production. | Patch compliance reports, secure hardware and/or cloud configuration settings, and samples of tested and approved change requests. |
| 6. Vulnerability scanning, penetration testing, and disclosure | Actively finding weaknesses through scans, hands-on testing, and a channel for outside researchers to report issues. | Penetration test reports and vulnerability scan results with remediation status. |
| 7. Audit log management | Keeping a reliable, centralized record of system activity for investigation. | A log management dashboard showing sources and retention periods. |
| 8. Network monitoring and defenses | Watching network traffic for attacks and blocking malicious activity in real time. | Intrusion detection system configurations and alerts, including records of the security team’s response. |
| 9. Antivirus and antimalware | Protecting company devices from malicious software. | A report on endpoint protection coverage across company devices. |
| 10. Segmentation | Separating systems that hold personal information from the rest of the network. | Network diagrams and firewall rules showing boundaries. |
| 11. Limitation and control of ports, services, and protocols | Disabling unnecessary technical entry points to reduce what an attacker can exploit. | A scan comparing open ports and services against the approved baseline. |
| 12. Cybersecurity awareness | Whether the business tracks emerging threats relevant to its industry, beyond training staff. | Records of threat advisories reviewed and any resulting changes to defenses. |
| 13. Cybersecurity education and training | Making sure personnel with system access understand security basics, at hire, annually, and after an incident. | Training completion records by employee and their corresponding hire date. |
| 14. Secure development and coding | Building security into software from the start, including code review and testing. | Secure development requirements, code review records, and security testing results from a sample of releases. |
| 15. Oversight of service providers, contractors, and third parties | Making sure vendors touching personal information meet the same security bar. | Vendor risk assessments and contracts with required data protection terms. |
| 16. Retention schedules and disposal | Deleting or destroying personal information once it is no longer needed. | A retention schedule and deletion records for disposed data. |
| 17. Incident response management | Having a tested plan to detect, contain, and recover from a security incident. | The incident response plan and records from a tabletop exercise, as well as records from actual incidents (if any), including notification and remediation. |
| 18. Business continuity and disaster recovery | Keeping the business running and data recoverable if systems go down. | BC/DR plans, backup success reports, and results from a recent restore test. |
Table 2: Comprehensive list of 18 components
Where SOC 2 and ISO 27001 often fall short
Many businesses assume an existing SOC 2 Type II report or ISO/IEC 27001 certification already covers this requirement. If your program is mature enough to pass a SOC 2 or ISO audit, most of the controls in the table above likely already exist in some form. The question is not whether to keep doing that work, but what needs to be added to satisfy the CCPA specifically.
Gaps often come up in the following:
- First, the audit period. The regulation ties the audit to the calendar year, meaning January through December. A SOC 2 report on an April to March cycle, even one issued every year without a gap, does not automatically satisfy a January to December requirement. In addition, ISO 27001 is a point-in-time audit and will not satisfy the requirement either.
- Second, scope. A SOC 2 report is built around the Trust Services Criteria (TSC) a business chose to include, such as Security, and sometimes Availability, Confidentiality, Processing Integrity, or Privacy. Those categories are broad and do not map one-to-one onto the CCPA’s 18 components. A SOC 2 report scoped to Security alone often has thin coverage of business continuity and disaster recovery, since that work usually falls under Availability. ISO 27001 has a similar issue: certification confirms a management system exists and that Annex A controls were considered, but a company’s Statement of Applicability can mark individual controls as “not applicable.” The CCPA’s 18 components do not leave that option open to a business that meets the audit thresholds.
- Third, report content. The regulation requires elements most SOC 2 reports do not include by default: a named list of gaps and remediation timelines, a signed executive certification, and, where applicable, a sample of breach notifications made during the audit period.
None of these means starting over. The efficient path builds on the SOC 2 or ISO 27001 work that is already in place: map each existing control explicitly to the CCPA’s 18 components, confirm the audit period lines up with the calendar year, and add the evidence and reporting elements the CCPA requires on top of the work already done. This can be accomplished via SOC 2 + CCPA report or a CCPA specific attestation, assuming it covers the right audit period.
Final thoughts: what to do now
2026 and 2027 are the preparation years for the first deadline group. Waiting until the audit period opens leaves no time to close control gaps or fix an audit period mismatch.
Aprio’s Risk Advisory & Assurance practice helps businesses confirm whether they meet the thresholds, assess existing SOC 2 or ISO 27001 work against the 18 required components, and close gaps before the audit period starts. Contact your Aprio advisor to schedule a readiness assessment today.
This article is for general informational purposes only and reflects the CCPA cybersecurity audit regulations in effect as of September 2026. It is not legal advice. Confirm how these requirements apply to your business with your Aprio advisor.
