The California Consumer Privacy Act (CCPA) and its amendment, the California Privacy Rights Act (CPRA), require businesses to implement "reasonable security procedures and practices." That phrase does an enormous amount of work in California privacy law, and the statute never defines what it actually means. This gap between legal obligation and technical implementation is where most engineering teams get stuck.
This guide breaks down the CCPA and CPRA security requirements from an engineering perspective. We will cover what the law actually says, how courts and regulators have interpreted "reasonable security," and what your team needs to build, configure, and test to stay on the right side of both the statute and the California Privacy Protection Agency (CPPA).
Who the CCPA and CPRA Apply To
The CCPA applies to for-profit businesses that collect personal information from California residents and meet any one of the following thresholds:
- Annual gross revenue exceeds $25 million. This is the most commonly triggered threshold. If your company generates more than $25 million in annual revenue, the CCPA applies regardless of how much consumer data you handle.
- You buy, sell, or share the personal information of 100,000 or more consumers or households annually. The CPRA raised this number from the original 50,000 threshold in the CCPA. If your application has 100,000 or more California users, you likely meet this criterion even if you are not selling data.
- You derive 50% or more of annual revenue from selling or sharing consumer personal information. This targets data brokers and ad-tech companies, but it also catches some SaaS companies whose business models involve data monetization.
The CPRA also introduced the concept of a "business" that performs annual processing of "sensitive personal information" of 100,000 or more consumers. Sensitive personal information includes Social Security numbers, financial account details, precise geolocation, racial or ethnic origin, biometric data, health information, and the contents of email or text messages.
Important for startups: Even if you do not meet these thresholds today, your Series A or B growth trajectory might put you over the line within 12 months. Building CCPA-compliant architecture now is significantly cheaper than retrofitting it later. If you are processing data from California residents at scale, start planning for compliance before you are legally required to have it.
The "Reasonable Security" Standard: What It Actually Means
Section 1798.150 of the CCPA creates a private right of action for consumers whose "nonencrypted and nonredacted personal information" is breached as a result of a business's failure to "implement and maintain reasonable security procedures and practices appropriate to the nature of the information." That is the entire security requirement in the statute. No checklist. No framework reference. Just "reasonable."
So what does reasonable mean in practice? Courts and regulators have provided some guidance, and a pattern has emerged.
The California Attorney General's 2016 Data Breach Report
The former California Attorney General Kamala Harris published a data breach report in 2016 that explicitly stated: "The 20 controls in the Center for Internet Security's Critical Security Controls identify a minimum level of information security that all organizations that collect or maintain personal information should meet. The failure to implement all the Controls that apply to an organization's environment constitutes a lack of reasonable security."
This is the closest thing to a concrete definition that exists. The CIS Controls (now in version 8) provide the de facto baseline for what California considers reasonable security. If you are not implementing the CIS Controls that apply to your environment, you are exposed to both regulatory action and private lawsuits.
How Courts Have Interpreted Reasonable Security
In CCPA-related litigation, courts have looked at several factors to determine whether a business maintained reasonable security:
- Industry standards and practices. What are comparable businesses doing? If your competitors implement multi-factor authentication and encryption at rest, and you do not, that gap is evidence of unreasonable security.
- The sensitivity of the data. Financial records and health information require stronger controls than email addresses. The more sensitive the data, the higher the bar for what qualifies as reasonable.
- The cost of security measures relative to the risk. Courts apply a cost-benefit analysis. But the cost of basic controls like encryption, access management, and regular testing is well-established and affordable, so arguing that security is too expensive rarely succeeds.
- Whether known vulnerabilities were left unpatched. This is one of the most common bases for finding unreasonable security. If you knew about a vulnerability (or should have known about it through regular testing) and failed to remediate it, courts treat that as a failure of reasonable security.
The practical takeaway: Reasonable security is not a static standard. It is measured against what the industry considers normal at the time of the breach. If you are not keeping pace with standard security practices, including regular penetration testing, vulnerability management, encryption, and access controls, you are below the bar.
CCPA vs. GDPR: Key Differences for Engineering Teams
If your organization already complies with GDPR security requirements, you have a significant head start on CCPA and CPRA compliance. But the two frameworks are not identical, and the differences matter for how you architect your systems.
CCPA / CPRA
Opt-out model: consumers must affirmatively opt out of data sales and sharing. Businesses can collect and process data by default. The "Do Not Sell or Share My Personal Information" link must be prominently displayed. Enforcement through the CPPA and private right of action for data breaches. Applies to California residents regardless of where the business is located.
GDPR
Consent model: businesses generally need affirmative consent before collecting and processing personal data. Lawful basis required for all processing activities. Data Protection Impact Assessments mandatory for high-risk processing. Enforcement through national DPAs with fines up to 4% of global revenue. Applies to EU/EEA residents and businesses established in the EU.
What This Means for Your Architecture
The opt-out model versus consent model distinction has direct engineering implications. Under GDPR, you need consent management infrastructure that gates data collection. Under CCPA, you need opt-out infrastructure that processes consumer requests to stop selling or sharing their data after collection. Both require the ability to identify, tag, and control data flows at a granular level, but the trigger mechanisms are different.
The CPRA also introduced the concept of "sensitive personal information," which requires a separate "Limit the Use of My Sensitive Personal Information" link. This means your data classification system needs to distinguish between regular personal information and sensitive personal information, and your access controls need to enforce different handling rules for each category.
Technical Security Requirements
While the CCPA does not prescribe specific technologies, the "reasonable security" standard, combined with the CIS Controls reference and enforcement actions, establishes clear expectations for what your engineering team needs to implement.
Encryption
The CCPA's private right of action specifically applies to "nonencrypted and nonredacted" personal information. This is one of the clearest signals in the statute: if consumer personal information is encrypted and a breach occurs, the private right of action does not apply. Encryption is not optional.
- Encryption at rest: All personal information stored in databases, file systems, backups, and archives must be encrypted. Use AES-256 for symmetric encryption. Ensure your key management system separates keys from the data they protect.
- Encryption in transit: TLS 1.2 or higher for all data in transit. This includes internal service-to-service communication, not just external-facing endpoints. Disable TLS 1.0 and 1.1 entirely.
- Field-level encryption: For sensitive personal information (Social Security numbers, financial account numbers, biometric data), consider field-level encryption in addition to volume encryption. This provides defense in depth and limits exposure if database access controls are bypassed.
Access Controls
Access control failures are one of the most common findings in CCPA enforcement actions. Your access control implementation needs to cover several areas:
- Principle of least privilege: Users and services should have the minimum access necessary to perform their function. This applies to database access, API permissions, cloud IAM roles, and administrative interfaces.
- Multi-factor authentication: MFA on all accounts that access personal information. This includes employee accounts, administrative panels, cloud console access, and API credentials used in production. SMS-based MFA is better than nothing, but hardware tokens or authenticator apps are the standard expectation.
- Role-based access control (RBAC): Implement RBAC that maps to job functions. Customer support agents should not have the same database access as engineering leads. Sales teams should not be able to export bulk consumer data without controls.
- Regular access reviews: Quarterly reviews of who has access to what. Offboarding processes must revoke access immediately when employees leave or change roles.
Data Inventory and Mapping
You cannot protect data you do not know you have. The CPRA's requirements for consumer rights fulfillment (access, deletion, correction) are impossible to implement without a comprehensive data inventory. Your data map needs to answer:
- What personal information do you collect, and from whom?
- Where is that data stored (databases, caches, logs, backups, third-party systems)?
- Who has access to it (internal teams, vendors, partners)?
- How long do you retain it?
- What is the lawful business purpose for each data element?
- Which data qualifies as "sensitive personal information" under the CPRA?
This is not a one-time exercise. Data flows change as you ship features, integrate vendors, and scale infrastructure. Your data inventory needs to be a living document that is updated as part of your development process.
Consumer Rights and Their Engineering Implications
The CCPA and CPRA grant California consumers several rights over their personal information. Each of these rights has direct engineering implications that affect your database design, API architecture, and operational processes.
Right to Know (Access Requests)
Consumers can request that you disclose what personal information you have collected about them, the categories of sources, the business purpose for collection, and the categories of third parties with whom you share it. You must respond within 45 days.
Engineering implications: You need an API or workflow that can query all data stores where a consumer's personal information exists, aggregate the results, and deliver them in a portable format. This is straightforward if you have a single database. It becomes complex if consumer data is spread across a primary database, analytics systems, log aggregators, CRM platforms, and third-party integrations.
Right to Delete
Consumers can request deletion of their personal information. You must delete it and direct your service providers to delete it. There are exceptions for data needed to complete transactions, detect security incidents, comply with legal obligations, and several other scenarios.
Engineering implications: Deletion is harder than it sounds. You need to identify every location where a consumer's data exists, including backups, replicas, caches, log files, and analytics systems. Soft deletes are generally not sufficient; regulators expect actual removal. You also need to propagate deletion requests to third-party service providers and verify that they comply.
Right to Correct
Added by the CPRA, consumers can request that you correct inaccurate personal information. You must use "commercially reasonable efforts" to correct the data.
Engineering implications: Your systems need to support updates to consumer records across all data stores, not just the primary database. If consumer data is replicated to analytics systems, data warehouses, or third-party services, corrections need to propagate to those systems as well.
Right to Opt Out of Sale and Sharing
Consumers can opt out of the sale or sharing of their personal information. The CPRA expanded this to include sharing for cross-context behavioral advertising. You must honor this request and provide a "Do Not Sell or Share My Personal Information" link.
Engineering implications: You need a signaling mechanism that propagates opt-out preferences across your data pipeline. When a consumer opts out, every downstream system that would otherwise sell or share their data needs to respect that flag in real time. This includes ad-tech integrations, analytics platforms, and data partnerships. The Global Privacy Control (GPC) browser signal must also be honored as a valid opt-out request.
Right to Limit Use of Sensitive Personal Information
Added by the CPRA, consumers can direct you to limit the use of their sensitive personal information to what is necessary to perform the services or provide the goods they expect. You must provide a "Limit the Use of My Sensitive Personal Information" link.
Engineering implications: Your data classification system needs to tag sensitive personal information separately, and your processing logic needs to enforce use limitations when the consumer exercises this right. This requires granular controls on data processing pipelines, not just access controls on storage.
Implementation reality check: Meeting all of these consumer rights requirements within the 45-day response window requires automation. Manual processes break down at scale. Invest in building self-service workflows and automated data discovery tools early, because the cost of manual fulfillment grows linearly with your user base.
Data Mapping and Classification Requirements
The CPRA regulations require businesses to maintain a data inventory that documents the categories of personal information collected, the purposes for collection, and the data flows between systems and third parties. This is not just a compliance exercise. It is the foundation for every other CCPA requirement.
Building Your Data Map
A functional data map for CCPA compliance needs to cover:
- Collection points: Every form, API endpoint, SDK integration, cookie, and pixel that collects personal information from consumers.
- Storage locations: Primary databases, data warehouses, caches (Redis, Memcached), log aggregators, backup systems, and file storage services.
- Processing activities: What you do with the data after collection, including analytics, personalization, model training, reporting, and marketing.
- Third-party sharing: Every vendor, partner, and service provider that receives consumer personal information, including the contractual basis for sharing.
- Retention schedules: How long each category of data is retained and the process for deletion when the retention period expires.
- Cross-border transfers: Whether personal information is transferred outside the United States, and if so, what safeguards are in place.
Classifying Personal Information vs. Sensitive Personal Information
The CPRA draws a clear line between personal information and sensitive personal information. Your classification system needs to enforce this distinction because the rights and obligations differ.
Personal information includes identifiers (name, email, IP address), commercial information (purchase history), internet activity (browsing history, search history), geolocation data, professional or employment information, and inferences drawn from the above.
Sensitive personal information includes Social Security and driver's license numbers, financial account credentials, precise geolocation (within 1,850 feet), racial or ethnic origin, religious beliefs, union membership, contents of mail, email, or text messages, genetic and biometric data, health information, and information about sex life or sexual orientation.
Your database schemas, logging configurations, and data pipelines need to tag data elements according to this classification. Without accurate classification, you cannot enforce the differential handling required by the CPRA.
Annual Security Audits and Risk Assessments Under the CPRA
The CPRA introduced two new requirements that directly affect engineering teams: annual cybersecurity audits and regular risk assessments for businesses whose processing presents "significant risk to consumers' privacy or security."
Cybersecurity Audits
Section 1798.185(a)(15)(B) of the CPRA authorizes the CPPA to issue regulations requiring businesses that process personal information in ways that present significant risk to consumer privacy to perform annual cybersecurity audits. The CPPA's draft regulations have indicated that these audits should be "thorough and independent" and should assess whether the business's security practices are "appropriate to the nature and scope of the processing."
What this means in practice: An annual cybersecurity audit under the CPRA is expected to cover your security program holistically. This includes network security, application security, access controls, incident response capabilities, vendor security, and employee security awareness. The audit should be conducted by an independent, qualified assessor.
Risk Assessments
The CPRA also requires businesses to submit risk assessments to the CPPA for processing activities that present "significant risk to consumers' privacy." The CPPA's proposed regulations define significant risk to include processing that involves selling or sharing personal information, using sensitive personal information, using personal information for automated decision-making with significant legal effects, and processing the personal information of children.
Risk assessments must weigh the benefits of the processing against the risks to consumer privacy and identify the safeguards in place to mitigate those risks. If the risks outweigh the benefits, the processing should not proceed, or additional safeguards must be implemented.
Practical guidance: If your business performs any of the high-risk processing activities described above, start building your risk assessment methodology now. The CPPA is actively finalizing regulations, and the requirement will be enforced. Document your processing activities, the risks they create, the safeguards you have in place, and the business justification for each activity.
CPPA Enforcement Actions and Penalties
The CPRA created the California Privacy Protection Agency (CPPA), the first dedicated state-level privacy enforcement body in the United States. The CPPA has enforcement authority that goes beyond what was available under the original CCPA, which relied solely on the Attorney General.
Administrative Fines
The CPPA can impose administrative fines of up to $2,500 per violation and $7,500 per intentional violation or violation involving a minor's personal information. These fines are assessed per consumer, per incident. A data breach affecting 100,000 consumers could result in fines ranging from $250 million to $750 million in the worst case.
Private Right of Action
The CCPA's private right of action allows consumers to sue for statutory damages of $100 to $750 per consumer, per incident for data breaches resulting from a failure to maintain reasonable security. Consumers can also seek actual damages if they exceed statutory damages. Class action lawsuits under this provision have resulted in multi-million-dollar settlements.
Notable Enforcement Trends
Early CPPA enforcement actions and AG settlements have targeted several recurring failures:
- Failure to honor opt-out requests: Companies that collected opt-out signals but did not actually stop selling or sharing consumer data.
- Inadequate data deletion: Companies that acknowledged deletion requests but failed to purge data from backup systems, analytics platforms, and third-party services.
- Dark patterns in privacy interfaces: Interfaces designed to make it difficult for consumers to exercise their rights, such as requiring multiple steps to opt out while making it easy to opt in.
- Lack of reasonable security: Breaches resulting from unpatched systems, missing encryption, weak authentication, or failure to conduct regular security testing.
The trend is clear: the CPPA is not issuing warnings and waiting. It is pursuing enforcement actions against companies of all sizes, and the security-related provisions are a primary focus area.
How Penetration Testing Demonstrates Reasonable Security
Penetration testing is one of the most direct ways to demonstrate that your organization maintains "reasonable security procedures and practices" under the CCPA. Here is why it matters from a legal and compliance perspective.
Testing Validates Your Controls
Having encryption, access controls, and monitoring in place is necessary but not sufficient. You need evidence that those controls actually work. A penetration test provides independent, third-party validation that your security controls are effective against real-world attack techniques. If a breach occurs and litigation follows, a recent pentest report showing that your controls were tested and validated is strong evidence of reasonable security.
Testing Identifies Unknown Vulnerabilities
The "reasonable security" standard requires businesses to address known vulnerabilities. Regular penetration testing is how you discover vulnerabilities you did not know about. Without testing, you cannot claim that you were not aware of security gaps. Courts have consistently held that businesses are responsible for vulnerabilities that routine testing would have identified.
Testing Creates a Defensible Record
In the event of a breach and subsequent litigation or enforcement action, your legal team will need to demonstrate that your security program was reasonable at the time of the breach. A history of annual penetration tests, with documented findings and remediation, creates a defensible record that shows your organization was actively identifying and addressing security risks. This record is significantly more persuasive than policies and procedures alone.
What Your Pentest Should Cover for CCPA Compliance
A penetration test aligned with CCPA compliance should specifically focus on:
- Systems that store personal information: Databases, file storage, caches, and any system where consumer personal information resides.
- Consumer-facing applications: Web applications, mobile apps, and APIs that collect personal information from consumers.
- Data access controls: Testing whether access controls actually enforce least privilege, including role separation and privilege escalation testing.
- Consumer rights workflows: Testing the security of data access, deletion, and opt-out request processing to ensure these workflows cannot be exploited.
- Third-party integrations: Testing the security of data flows to and from third-party service providers.
- Encryption implementation: Verifying that encryption at rest and in transit is properly implemented and that keys are securely managed.
Practical Checklist for CCPA and CPRA Compliance
This checklist covers the technical and operational measures your engineering team should have in place to meet the CCPA and CPRA security requirements.
Data Protection and Encryption
- AES-256 encryption at rest for all personal information in databases and file storage.
- TLS 1.2+ enforced for all data in transit, including internal service-to-service communication.
- Field-level encryption for sensitive personal information (SSN, financial accounts, biometric data).
- Encryption key management with separation of keys from encrypted data.
- Secure backup encryption with tested restoration procedures.
Access Controls and Authentication
- Multi-factor authentication on all accounts with access to personal information.
- Role-based access control mapped to job functions with least privilege enforced.
- Quarterly access reviews with documented results.
- Automated deprovisioning integrated with HR offboarding processes.
- Privileged access management for administrative and database access.
Data Inventory and Consumer Rights
- Comprehensive data map documenting all collection points, storage locations, and third-party sharing.
- Data classification system distinguishing personal information from sensitive personal information.
- Automated consumer rights fulfillment for access, deletion, correction, and opt-out requests.
- Global Privacy Control (GPC) signal detection and honoring.
- Data retention schedules enforced programmatically with automated purging.
- Deletion verification across all systems, including backups and third-party services.
Security Testing and Monitoring
- Annual penetration testing by an independent, qualified third party.
- Regular vulnerability scanning with documented remediation timelines.
- Security monitoring and logging for systems that process personal information.
- Incident response plan with defined roles, escalation procedures, and breach notification workflows.
- Annual cybersecurity audit covering the full scope of your security program.
- Risk assessments for processing activities that present significant risk to consumer privacy.
Vendor and Third-Party Management
- Service provider agreements with CCPA-compliant data processing terms.
- Vendor security assessments before onboarding and periodically thereafter.
- Contractual requirements for vendors to honor consumer deletion and opt-out requests.
- Data sharing inventory documenting every third party that receives consumer personal information.
Start with what matters most: If you are early in your CCPA compliance journey, prioritize encryption, access controls, and a data inventory. These three areas address the most common enforcement targets and provide the foundation for everything else. Then add regular security testing and consumer rights automation as you mature your program.
Where CCPA Compliance Connects to Your Broader Security Program
CCPA and CPRA compliance does not exist in isolation. The security requirements overlap significantly with other frameworks your organization may already be implementing. If you have GDPR controls in place, you already have much of the technical foundation for CCPA compliance. The data inventory, encryption, access control, and consumer rights infrastructure serve both frameworks.
Similarly, if you are pursuing SOC 2, ISO 27001, or NIST CSF alignment, the security controls you build for those programs directly support CCPA's "reasonable security" standard. The key is to build your security program once and map it to multiple frameworks rather than treating each compliance requirement as a separate project.
The organizations that handle CCPA compliance most efficiently are the ones that treat it as a component of a mature security program rather than a standalone legal exercise. When your engineering team builds security controls that satisfy the CIS Controls baseline, implements robust data governance, and validates everything through regular testing, CCPA compliance becomes a natural outcome rather than a separate workstream.
Demonstrate Reasonable Security Under CCPA
Regular penetration testing is one of the strongest signals of reasonable security under California privacy law. Our reports are structured for legal and compliance review, and our testing methodology covers the systems and controls that CCPA enforcement targets.
View Pentest Services Book a Consultation
