The California Consumer Privacy Act (CCPA) and its amendment, the California Privacy Rights Act (CPRA), give California residents specific rights over their personal data. If your software product serves California residents and meets certain thresholds, you are legally required to comply. Unlike GDPR, which gets most of the attention, CCPA has enforcement teeth in the United States and affects a massive market: nearly 40 million people in a state with a GDP larger than most countries.
We have helped multiple clients navigate CCPA compliance in their software products. This is not a legal guide (consult a lawyer for that), but it is a practical engineering guide to what CCPA means for your product, your data, and your code.
Who Needs to Comply
CCPA applies to for profit businesses that collect personal information from California residents and meet at least one of these thresholds:
- Annual gross revenue over $25 million
- Buy, sell, or share personal information of 100,000 or more California residents, households, or devices per year
- Derive 50% or more of annual revenue from selling or sharing personal information
That 100,000 threshold is lower than it sounds. If your web application gets 300,000 unique visitors per year and a third of them are from California (not unreasonable for a US focused product), you are likely covered. Device identifiers, IP addresses, and cookies count as personal information under CCPA, so this is not limited to registered users.
Even if you are below the thresholds today, building CCPA compliant systems from the start is significantly cheaper than retrofitting later. Privacy laws are expanding, not contracting. Colorado, Connecticut, Virginia, and other states have passed similar legislation. Building privacy into your architecture now is a strategic investment.
What CCPA Requires from Your Product
The law grants California residents several rights that translate directly into technical requirements:
Right to know. Users can request a copy of all personal information you have collected about them in the past 12 months. Your product needs the ability to export a user's complete data profile in a portable format (usually JSON or CSV). This means you need to know where every piece of user data lives across your databases, analytics tools, third party services, and logs.
Right to delete. Users can request deletion of their personal information. Your product needs a deletion workflow that removes user data from your primary database, backups (within a reasonable timeframe), third party services you have shared data with, and analytics platforms. This is harder than it sounds. Data lives in more places than most teams realize: database tables, search indexes, CDN caches, log files, analytics tools, email marketing platforms, and payment processors.
Right to opt out of sale or sharing. If you sell or share personal information (and "sharing" has a broad definition under CPRA that includes cross context behavioral advertising), users must be able to opt out. Your product needs a "Do Not Sell or Share My Personal Information" link and the technical plumbing to honor that preference across all data flows.
Right to correct. Users can request correction of inaccurate personal information. Your product needs a mechanism for users to update their data or request corrections.
Right to limit use of sensitive personal information. If you collect sensitive data (precise geolocation, race, health information, financial account numbers), users can limit how you use it. Your product needs granular consent controls for sensitive data categories.
Technical Implementation
Compliance is not just a privacy policy update. It requires real engineering work across your stack.
Data inventory and mapping. Before you can respond to any user request, you need a complete map of where personal data lives. Every database table, every third party service, every log file. We recommend building this as a living document that gets updated with every new integration or schema change. On the full stack applications we build, we maintain a data flow diagram that tracks every piece of personal information from collection to storage to deletion.
User data export. Build an endpoint or admin tool that generates a complete export of a user's personal data. This should pull from every data source in your inventory and produce a machine readable format. The 45 day response window sounds generous until you realize you need to verify the requester's identity, locate data across multiple systems, compile it, and deliver it.
Deletion workflows. A user delete is not just a database DELETE statement. You need to cascade deletion across related tables, remove data from search indexes, dequeue any pending jobs that reference the user, notify third party services to delete their copies, and handle the fact that some data (like financial transaction records) may have legal retention requirements that override the deletion request. We have seen teams spend weeks building compliant deletion workflows because data was spread across 15 different services with no central coordination.
Consent management. Your application needs to collect, store, and enforce user consent preferences. This means a consent banner or preference center, a database table tracking what each user has consented to, and middleware that checks consent before processing data. This is similar to what we described in our GDPR compliance guide, but with CCPA specific requirements around the opt out mechanism.
Audit logging. You need to log every data access request, every deletion, and every consent change. If the California Attorney General or the new California Privacy Protection Agency comes knocking, you need to demonstrate that you processed requests within the required timeframes and actually deleted what you said you deleted.
Vendor management. CCPA requires you to have contracts with service providers that process personal data on your behalf. Every third party tool in your stack that touches user data, your analytics provider, your email service, your payment processor, needs a Data Processing Agreement (DPA) that includes CCPA compliant terms.
Common Compliance Mistakes
Assuming it does not apply to you. The thresholds are lower than most teams think, especially the 100,000 devices threshold when you count cookies and analytics tracking.
Treating it as a legal only problem. Your legal team writes the privacy policy. Your engineering team builds the systems to honor it. If those two efforts are not coordinated, you end up with promises you cannot technically deliver.
Forgetting about third party data. If you use Google Analytics, Segment, Mixpanel, Intercom, or any other tool that processes user data, that data is part of your CCPA obligations. Deletion requests need to reach every service that has a copy.
Ignoring data in backups. CCPA does not require you to delete data from backups in real time, but regulators expect that deleted data does not get restored from backups into production. Your backup restoration process needs to account for CCPA deletion records.
No identity verification on requests. You are required to verify the identity of anyone making a CCPA request to prevent unauthorized data access. Simply accepting requests by email without verification creates a new security vulnerability.
CCPA vs GDPR
If you are already GDPR compliant, you are most of the way to CCPA compliance, but there are differences. GDPR requires opt in consent for data processing. CCPA uses an opt out model (you can collect data until someone says stop). GDPR applies to all EU residents regardless of company size. CCPA has revenue and data volume thresholds. GDPR fines can reach 4% of global revenue. CCPA penalties are up to $7,500 per intentional violation, which adds up fast at scale.
The practical engineering work, data mapping, export tools, deletion workflows, consent management, overlaps significantly. If you are building for both, start with GDPR's stricter requirements and layer CCPA specific features (like the "Do Not Sell" mechanism) on top.
Start Before You Are Required To
If you are building software that handles personal data from US users, building CCPA compliant architecture from the start is dramatically cheaper than retrofitting it later. The core principles (data minimization, purpose limitation, user control, audit logging) are just good engineering practice regardless of legal requirements.
The cost of non compliance is not just fines. It is the engineering scramble to retrofit privacy features into a system that was never designed for them, plus the business risk of operating without legal cover in the largest consumer market in the United States.
If you are evaluating how to handle compliance in your product, whether you are building from scratch or need to retrofit an existing system, talk to our team about building it into your architecture from the start.