Almost every CCPA and CPRA compliance engagement for a California business begins with a question that sounds trivial and turns out not to be: what personal information does this company actually hold, where is it, and who has it been given to?
Very few companies can answer. Privacy programmes fail on the inventory long before they fail on the legal analysis, you cannot delete, disclose, restrict or secure data you have not located.
Do CCPA and CPRA compliance obligations apply to your California business?
Not to every California business. The thresholds are specific, annual gross revenue above a defined level, buying, selling or sharing the personal information of a defined number of California consumers or households, or deriving a defined share of revenue from selling or sharing it. Meeting any one brings you in scope.
Three things catch companies out:
- The revenue threshold is total revenue, not California revenue. A company with modest California activity can be in scope on the strength of its overall size.
- "Personal information" is broad under California law, device identifiers, IP addresses, geolocation, browsing history, and inferences drawn about a consumer all count.
- Employee and applicant data is fully in scope since CPRA. This is the point at which most B2B companies discover the law applies to them after all, having concluded it did not because they have no consumer customers.
You are probably "sharing" already
This is the single most common misunderstanding in California privacy work, and it has direct consequences.
"Sale" and "share" are defined broadly enough to capture disclosures for cross-context behavioural advertising, even where no money changes hands. Standard advertising and analytics implementations (conversion pixels, audience matching, remarketing tags) routinely meet the definition.
So a company that is entirely confident it does not sell data discovers during data mapping that its marketing stack does, and that an opt-out mechanism, a notice, and recognition of opt-out preference signals should all have been in place. This is found in a large majority of first assessments.
What compliance actually requires
Beyond the privacy notice, which is the part everyone does and the least of it:
- A verifiable consumer request process covering access, deletion, correction, opt-out of sale or sharing, and limitation of sensitive personal information use, with defined response timeframes and identity verification proportionate to what is being requested
- Data minimisation and purpose limitation, collecting and retaining only what is necessary for a disclosed purpose, which conflicts directly with most companies' default of retaining everything indefinitely
- Defined retention periods, disclosed and actually enforced in the systems rather than stated in a policy
- Statutorily compliant contract terms with service providers and contractors
- Opt-out mechanisms, including recognition of opt-out preference signals
- Risk assessments for processing presenting significant risk
- Reasonable security, because the private right of action attaches to breaches of unencrypted, unredacted personal information caused by a failure to maintain it
The vendor contract gap
The most common finding in these assessments, and the one with the clearest consequence.
CCPA imposes specific contractual requirements on agreements with service providers and contractors. Standard commercial terms almost never contain them. Absent the required terms, a disclosure to that vendor may be treated as a sale rather than a service provider relationship, with all the opt-out and disclosure obligations that follow.
Remediation is a contract amendment exercise across the material vendor population, prioritised by data sensitivity. It is tedious, it takes months because it depends on counterparties responding, and it should be started early rather than left until a regulator or a customer asks.
Data mapping: where the work actually is
Every obligation above depends on the inventory. Building it takes longer than clients expect and it runs through more places than anyone lists at the start:
- Systems and databases
- SaaS applications, discovered through expense analysis and SSO logs, because asking produces an incomplete answer every time
- Marketing and analytics tooling, which is where the undisclosed sharing lives
- HR and payroll systems, now fully in scope
- Support ticketing, which accumulates more personal information than anyone intends
- Backups and archives
- Spreadsheets and exports on individual laptops, which no formal inventory captures
For each: what is collected, why, on what basis, how long it is kept, who it is disclosed to, and where it physically resides.
The exposure, in order of when it arrives
Commercially, first. Enterprise customers and health systems now include privacy terms in vendor agreements and ask for evidence during procurement. Most companies encounter the cost of non-compliance as a lost or delayed deal well before any regulator makes contact.
Litigation, second. The private right of action for breaches of unencrypted, unredacted personal information caused by failure to maintain reasonable security is the route that produces class actions.
Regulatory, third. Enforcement by the California Privacy Protection Agency and the Attorney General, with per-violation penalties that multiply across affected consumers.
Companies tend to plan for the third and get hit by the first.
A sensible sequence
Establish applicability across every regime that might apply. CCPA and CPRA, GDPR if you have EU data subjects, HIPAA if a business associate agreement has been signed, and the growing set of other state laws. Then map the data. Then gap-assess against all applicable regimes at once and design one programme rather than parallel efforts, because the mechanisms overlap heavily even where the legal structures differ.
Then operationalise: rights request handling, retention enforcement, vendor terms and breach procedures with named owners. A privacy programme that exists only as documents fails at its first real request. The data privacy service page covers how these engagements are structured.
Javed Peeran
Licensed by the California Board of Accountancy and the author of every article published here. Thirty years of practice covering external audit of banks, insurers and mortgage companies, fifteen years as CFO and Corporate Controller inside technology companies, and IT governance and security compliance work spanning SOX 404, SOC 1 and SOC 2, ISO 27001, FISMA, FedRAMP, PCI DSS, HIPAA/HITECH, CCPA and GDPR, plus Oracle ERP migrations and, more recently, generative-AI audit automation.
