The conversation usually starts on Slack.
A data leader is two weeks into evaluating a vendor that will handle a chunk of external data acquisition for the company. The contract is sitting in legal review. And then comes the message: “Can we sync on CCPA before we move on this?” Sometimes it’s a paragraph. Sometimes it’s a paste of a clause with three question marks next to it. Either way, the data program just hit a compliance gate, and the conversation about California Consumer Privacy Act (CCPA) compliance is no longer hypothetical.
This guide is for that moment. Not the lawyer who already knows §1798.140 by memory, but the data leader translating between legal and engineering — figuring out what CCPA actually requires when the personal information arrived from outside the company’s perimeter, and how to turn the law into vendor questions, contract clauses, and pipeline controls.
A note on scope first. This is not “is web scraping legal” — that question gets its own treatment in Is Web Scraping Legal? What Data Laws Mean for Your Pipeline, which lays out the broader legal landscape of web data acquisition. This guide narrows in on the California regime specifically: CCPA as amended by CPRA (Proposition 24), as it operates in 2026, and how it lands on an external-data program.
The short version. CCPA gives California residents five enforceable rights over their personal information regardless of how you obtained it. “Sale” and “sharing” are defined broadly enough that most external data acquisition triggers disclosure obligations. The service-provider-versus-contractor-versus-third-party classification of your vendor is determined by the written contract, not by your business model. Four operational primitives — data minimization, consumer-rights response, audit trail, and downstream-flow control — carry most of the compliance load. 2026 layers in three new regimes (Automated Decisionmaking Technology rules, mandatory privacy risk assessments, and cybersecurity audits) plus a live universal-deletion platform called DROP. Enforcement is up: Disney’s $2.75M settlement in 2025 is the largest CCPA action to date.
The rest of this guide unpacks each of those pieces.
What CCPA actually regulates when the data came from outside
The instinct, when a CCPA question lands on a data team, is to treat it as a problem about what you collect from your own customers. That’s the wrong starting point.
CCPA regulates the handling of personal information about California residents. The obligations attach the moment your program ingests data that identifies, relates to, or could reasonably be linked with a California consumer or household, regardless of source. A B2B firmographic enrichment containing the work email of a California-based VP triggers CCPA. A scraped public profile that maps to a California resident triggers CCPA. A licensed dataset where 18% of records describe California consumers triggers CCPA on those records.
The next question — does the law apply to my business at all — has a clearer answer. Under California Civil Code § 1798.140(d), CCPA applies to any for-profit business that does business in California and meets at least one of three thresholds: (a) gross annual revenue over $25 million in the preceding calendar year, (b) annually buys, sells, or shares the personal information of 100,000 or more California consumers or households, or (c) derives 50% or more of annual revenue from selling or sharing personal information. Hit one of those, and you are a “business” for CCPA purposes.
One threshold change worth flagging for enterprise teams. The B2B partial exemption — which once carved out personal information collected in business-to-business communications — sunsetted on January 1, 2023, when the legislature declined to extend AB 1355. California residents in their capacity as business contacts now hold the full set of CCPA rights, just like any other consumer. The work email of a California-based decision-maker in a firmographic dataset is personal information, full stop.
Two carve-outs deserve a second read because most teams overestimate them.
The “publicly available” carve-out is narrower than it sounds. The statute exempts information lawfully made available from federal, state, or local government records, and information made available by the consumer or by someone the consumer has authorized to disclose. But information that is merely observable in public — a social media profile, a directory listing — remains personal information unless the consumer deliberately made that specific disclosure public. And the moment you combine public information with other data to re-identify someone, the carve-out disappears.
The sector-specific federal preemption carve-out is similarly narrow. HIPAA, GLBA, FCRA, and the Driver’s Privacy Protection Act each exempt the data they regulate. They do not exempt a HIPAA-covered entity’s marketing list, a bank’s prospect database, or any other dataset that sits outside the regulated scope. If you license data from an entity operating under a sector-specific regime, the question to ask is which records in that dataset are covered by the federal preemption, not whether the source is regulated.
The five consumer rights, translated into pipeline obligations
CCPA gives California residents an enumerated set of rights over their personal information. Naming them is the easy part. The harder part is translating each right into an operational capability your pipeline needs to provide.
| Right | Statutory response window | What the pipeline must support | What your vendor must support |
|---|---|---|---|
| Know (categories, sources, sharing) | 10 business days to acknowledge; 45 calendar days to respond, extendable to 90 | Per-record lineage: source, ingestion timestamp, downstream consumers | Vendor-side lineage that matches yours |
| Delete | 10 / 45 / 90 | Identifier-keyed deletion; propagation to downstream systems | Vendor-side delete plus audit confirmation |
| Correct | 10 / 45 / 90 | Update API with propagation | Re-ingestion or in-place update of corrected records |
| Opt-out of sale / sharing | Up to 15 business days; honor GPC signal | Suppression list keyed by consumer identifiers; signal honored at extraction layer if applicable | Vendor respects upstream opt-outs |
| Limit use of sensitive PI | Same as opt-out | Tag and constrain processing of sensitive PI categories | Same |
A non-discrimination obligation runs alongside all five rights. A business cannot deny services, charge different prices, or provide a different level of service because a consumer exercised CCPA rights. In external-data contexts this usually surfaces in a subtler way: if a consumer’s deletion request hollows out your enrichment record, you cannot retaliate against them in some downstream product surface.
A useful corner of the regulations: deletion does not require immediate purging of backups. Personal information may persist in backups until the backup is restored, at which point the deletion obligation re-attaches to the restored records (CCPA Regs § 7022(b)(2)). The practical implication is that your runbook needs a post-restore deletion replay, not a real-time deletion of the backup itself.
Two practical observations on the 45-day window. First, it runs in calendar days, not business days — Saturdays count. Second, the verification step happens inside the window, not before it starts. A request that arrives unverified still starts the clock; the clock only pauses if you reasonably request additional information for verification, and then only for the time needed to respond.
Sale vs sharing — and why external data extraction often counts
Two definitions in CCPA decide whether you owe disclosures. Both are broader than the common-English versions of the same words.
A “sale” is any disclosure of a consumer’s personal information by a business to another business or third party in exchange for monetary or other valuable consideration. The “other valuable consideration” language is load-bearing. A barter trade of data for data is a sale. An exchange of data for analytics access is a sale. A free data sample provided to drive a procurement decision can be a sale.
“Sharing” was added by CPRA and applies specifically to disclosures of personal information for cross-context behavioral advertising — that is, advertising based on a consumer’s activity across distinct businesses, websites, or services. A narrower category, but with its own opt-out and disclosure obligations.
Here is the under-discussed reality. Under the revised CCPA regulations, a third party that scrapes consumer information from a website may, depending on facts and consideration, qualify as a sale of that personal information by the source business — triggering the source business’s obligation to disclose the sale and provide a “Do Not Sell or Share My Personal Information” path. The analysis from practitioner sources is consistent on this point: the framing the regulators have adopted treats scraping with downstream commercial use as a disclosure with consideration, not a passive collection.
For the buyer of external data, the mirror image matters more. Receiving personal information without a properly-structured service-provider contract turns the transfer to you into a sale — even if no money changed hands in that specific transaction — and consumers retain their CCPA rights against you for that disclosure. The “Do Not Sell” link on the source business’s website does not insulate you. The consumer’s right to opt-out runs to every business holding their personal information.
What this means in practice: any time personal information moves between distinct legal entities, ask three questions. Was there consideration? (Almost always yes, when the data has commercial value.) What’s the written contract between sender and receiver? Does the consumer have notice and an opt-out path? The shape of those three answers decides whether the disclosure is a sale, a service-provider transfer, or something else.
For the broader legal and ethical framework around web data acquisition — robots.txt, terms of service, court precedent, and the cross-jurisdictional picture — see Forage AI’s legal and ethical web scraping framework.
Service provider vs contractor vs third party — the contract IS the classification
This is the most consequential single decision in your external-data program. It is also the decision most often gotten wrong.
CCPA classifies anyone receiving personal information from a business into one of three buckets, each with a different liability profile.
| Service Provider | Contractor | Third Party | |
|---|---|---|---|
| Purpose | Processes PI on behalf of the business for a defined business purpose | Receives PI from the business without processing on behalf of | Anyone who is neither of the above |
| Contract required | Yes, hitting every § 7051 statutory requirement | Yes, hitting comparable requirements | None mandated |
| Is the transfer a sale or sharing? | No | No | Presumptively yes |
| Consumer opt-out applies to the transfer? | No | No | Yes |
| Audit rights for the business? | Yes, required in contract | Yes, required in contract | Not by statute |
| Sub-processor flow-down | Required in contract | Required in contract | Not regulated |
The mental model that earns the section: without a written contract that hits every statutory requirement, the entity on the other end of the data transfer is a third party by default, and the disclosure looks like a sale. That is not a flourish; it is the regulators’ working position, echoed across the practitioner consensus from IAPP, Practical Law, and the major privacy-bar advisories. Until the contract exists and meets the statutory bar, the relationship is what the statute presumes.
What the service-provider contract has to do, per CCPA Regs § 7051:
- Specify the limited and specified purposes for which personal information is processed
- Prohibit the service provider from selling or sharing the personal information
- Prohibit retaining, using, or disclosing PI for any purpose other than the business purposes specified in the contract, including a prohibition on combining PI received from the business with PI from other sources
- Require the service provider to comply with applicable CCPA obligations
- Grant the business the right to take reasonable and appropriate steps to ensure the service provider’s use of PI is consistent with CCPA
- Require notice on intended sub-processor engagement and flow-down of the obligations
- Provide for the return or deletion of PI at the end of the relationship
Three failure modes show up in real procurement. The contract describes the vendor as a “service provider” in the recitals but the operative language permits the vendor to use the data for product improvement or aggregated analytics — that is the combining-data prohibition violated; the vendor is not actually a service provider under CCPA, regardless of label. The contract is silent on sub-processors — CCPA does not allow silence here; flow-down has to be explicit. The contract does not grant audit rights — without them, the business has no ability to satisfy its own diligence obligation, and the regulator’s view of “reasonable steps to ensure compliance” is not met.
The label is cheap. The contract is the classification.
Four operational primitives for a CCPA-aware external-data program
Compliance discussions tend to live in legal vocabulary. Operations needs a different vocabulary. Every CCPA requirement, translated into the language of a data pipeline, decomposes into one of four primitives. Build all four, and most of the law’s operational surface is covered.
1. Data minimization at extraction. The first lever, and the most under-used. Extract what the business purpose requires; leave the rest. If the use case is firmographic enrichment, you do not need direct-dial phone numbers. If the use case is market signal monitoring, you do not need named individuals attached to the signal. A pipeline that minimizes at the source is dramatically easier to defend in a privacy risk assessment than one that hoovers everything and filters later.
2. Consumer-rights response capability. The pipeline must answer four questions about any individual on demand: do we have a record on this consumer; where did it come from; what have we done with it; can we delete or correct it in hours rather than weeks? That capability presupposes per-record lineage indexed by stable identifiers, plus an integration layer that propagates rights actions through every system holding the record.
3. Audit trail at the record level. Each record carries its provenance: source URL or system, ingestion timestamp, extraction context, any consent signal present at collection, and the chain of transformations applied. This is the artifact a regulator’s investigation will ask for, and the same artifact your customer’s compliance review will ask for. The two audiences ask the same question in different vocabulary. For a deeper discussion of provenance and freshness controls in third-party datasets, see data observability for third-party datasets. For the broader picture of how external data extraction services fit into enterprise data strategy, see Forage AI’s modern data extraction services guide.
4. Downstream-flow control. You know, by contract and by log, every party you have transferred personal information to. Deletions and corrections propagate to them. Opt-out signals propagate to them. The flow is not a one-way valve; it is bidirectional, and the bidirectionality is part of the compliance posture.
What this looks like in production: one publicly traded financial-data enterprise rebuilt its external-data program around these four primitives explicitly because compliance review had become the rate-limiting step in vendor procurement. The decision was to make the four primitives non-negotiable at the platform layer, then let the legal and procurement teams trace any audit question back to a pipeline answer rather than a contract footnote. The four primitives turned a recurring back-and-forth into a one-time engineering investment.
What changes in 2026: ADMT, audits, DROP
(As of January 2026.)
Three regulatory developments are live or imminent and belong in any current operating picture.
Automated Decisionmaking Technology (ADMT) regulations. Effective January 1, 2026. If external data feeds an automated decision that significantly affects a consumer — employment, housing, credit, education, insurance, healthcare access, essential goods — three new obligations attach: pre-decision notice to the consumer, an opt-out right (with statutorily defined exceptions), and a documented privacy risk assessment before processing begins. For external-data programs that feed scoring, ranking, or eligibility models, this is the biggest 2026 change.
Privacy Risk Assessments. Required before initiating any processing that presents a “significant risk” to consumer privacy, including selling or sharing personal information, processing sensitive personal information, using ADMT for significant decisions, and training certain ADMT or biometric technologies. The risk assessment is documented, retained, and producible on regulator request. It is not a one-time exercise; material changes to processing trigger a refresh.
Cybersecurity Audits. Independent and mandatory for businesses meeting specified revenue and data-volume thresholds. First certifications phase in across 2028–2030 based on size, but the audit substrate — security program documentation, incident logs, processor controls — needs to exist now to be auditable later.
Running in parallel is the California Delete Act regime (SB 362), which interacts with CCPA enforcement and matters specifically for external data. The Delete Request and Opt-out Platform — DROP — went live for California consumers on January 1, 2026. Beginning August 1, 2026, every registered data broker must process DROP requests every 45 days: downloading hashed consumer identifiers from the platform, matching them against the broker’s records, and reporting status — record deleted, record opted out of sale, record exempt, or record not found — through DROP within 45 days of retrieval. Annual registration is required by January 31; failure to register accrues a $200-per-day penalty plus investigation costs, and the CPPA stood up a Data Broker Strike Force in late 2025 that has been actively enforcing the registration requirement.
The implication for buyers of external data: if your vendor is registered (or should be) as a data broker, they are operating on a 45-day deletion cadence whether your contract acknowledges it or not. Records you ingested in January may legitimately have to be removed in March because a downstream DROP signal reached your vendor. External data is no longer a static asset you license once. It is a continuous stream with deletion built in.
Enforcement reality
A look at what California has actually fined for tells you more than the statute does about where the regulator’s attention sits.
The 2025 CCPA penalty schedule sets civil penalties at $2,663 per unintentional violation and $7,988 per intentional violation or any violation involving a minor. Both figures are inflation-adjusted annually.
The settlement record, in size order, reads:
- Disney — $2.75 million (2025). The largest CCPA settlement to date.
- Tractor Supply Company — $1.35 million (2025).
- Sephora — $1.2 million (2022). Notable for two reasons: failure to honor Global Privacy Control signals, and the action that effectively ended the assumption that a 30-day cure period would precede every enforcement.
- Honda — $632 thousand.
- DoorDash — $375 thousand (2024).
Across these actions, three patterns repeat: failure to honor opt-out signals (especially GPC), data disclosures characterized as sales without proper disclosure, and — increasingly in 2025 — handling of B2B contact data, minors’ data, and ADMT-adjacent processing without adequate controls. The cure period that softened early enforcement is gone; CPRA sunsetted it. Each violation stands on its own facts.
The CPPA Data Broker Strike Force, stood up in late 2025, has been enforcing data-broker registration aggressively into 2026. The $200-per-day non-registration penalty compounds quickly, and the Strike Force has shown a willingness to pursue both the broker and businesses transacting with unregistered brokers.
The procurement conversation — turning CCPA into a vendor question
The most useful move a data leader can make is to lift CCPA out of the legal-question category and into the procurement-question category. Compliance treated as a vendor-evaluation lens is faster, more concrete, and more defensible than compliance treated as a legal review every time a contract crosses the desk.
The ten questions a compliance-aware procurement gate should ask of any external-data vendor:
- Are you contracting as a service provider, contractor, or third party?
- Show me your CCPA Service Provider Addendum or equivalent §7051 contract language.
- How do you handle a downstream deletion request — can you propagate it to me within 30 days, and how do you confirm completion?
- What sensitive personal information might end up in our extraction, and how do we mark, segregate, or exclude it?
- What is your audit trail at the record level: source, timestamp, transformation history?
- Have you completed a privacy risk assessment for the processing you do on our behalf?
- Are you a registered California data broker? If yes, what is your DROP processing cadence, and how does it interact with our records?
- What is your data-minimization posture — what do you deliberately not extract that you technically could?
- Where is the data processed and stored? Is on-premise or VPC-isolated deployment available?
- Has any third-party large language model seen our data in transit or at rest? Can it?
Some of these questions are diagnostic in themselves. A vendor that answers question 1 with “it depends” should produce the contract before any further conversation. A vendor that cannot answer question 5 in technical detail is not equipped for an enterprise compliance gate. A vendor that hesitates on question 10 will not survive a Sovereign-leaning procurement.
For the broader vendor evaluation matrix, beyond CCPA, see the enterprise vendor evaluation checklist.
The enterprises that win the compliance conversation tend to do one of two things. They build the four operational primitives internally and absorb the legal-engineering coordination cost themselves. Or they outsource the compliance load to a managed external-data partner whose lawyers have already mapped the statute, whose pipelines already produce the audit artifacts, and whose deployment options include the on-premise and no-third-party-LLM postures that compliance review tends to insist on. Forage AI is built around the Sovereign-first design that compliance review checks for: data minimization by default, on-premise availability, audit trail on every record, no third-party LLM exposure. Getting that posture from the partner — rather than rebuilding it — shifts the conversation from “can we” to “show me.”
Quick summary
CCPA, as amended by CPRA and as it operates in 2026, gives California residents five enforceable rights over their personal information regardless of source. Most external-data transfers between legal entities count as either a sale or a service-provider relationship, and the difference is decided by your written contract, not by your business model. Four operational primitives — minimization at extraction, consumer-rights response, record-level audit trail, downstream-flow control — carry most of the operational load. 2026 layers in ADMT rules, privacy risk assessments, cybersecurity audits, and the DROP universal-deletion platform. Enforcement is up and the cure period is gone. Turn CCPA into a procurement question with the ten-question gate above, and most of the legal-engineering coordination cost moves from a recurring drag into a one-time decision.
Frequently asked questions
Who does CCPA apply to?
Any for-profit business that does business in California and meets one of three thresholds: gross annual revenue over $25 million, annually buys/sells/shares the personal information of 100,000 or more California consumers or households, or derives 50% or more of annual revenue from selling or sharing personal information.
Does CCPA apply to companies outside California?
Yes. The geographic test is “does business in California” plus the size thresholds. A company headquartered in New York that sells to California consumers, or processes the personal information of California residents at scale, falls under CCPA.
Who is a third party under CCPA?
Anyone receiving personal information from a business who is not a properly-contracted service provider or contractor under § 7051. Third parties trigger sale or sharing disclosure obligations on the source business and inherit the consumer’s right to opt-out.
What are the penalties for violating CCPA?
$2,663 per unintentional violation and $7,988 per intentional violation or any violation involving a minor (CPPA 2025 schedule, inflation-adjusted). Settlements in recent years have ranged from low six figures to $2.75 million.
What is the difference between CCPA and CPRA?
CCPA is the original 2018 statute. CPRA (Proposition 24, 2020) amended it — adding sensitive personal information as a category, expanding consumer rights to include correction and the right to limit use of sensitive PI, sunsetting the cure period, and creating the California Privacy Protection Agency as the dedicated regulator. In modern usage “CCPA” usually means CCPA-as-amended-by-CPRA, which is how this guide uses it. For the broader compliance framework across jurisdictions, see Forage AI’s legal and ethical web scraping framework.
How do CCPA and the California Delete Act relate?
The Delete Act (SB 362, 2023) layers on top of CCPA. It applies specifically to data brokers — businesses that knowingly collect and sell personal information about consumers with whom they do not have a direct relationship. The Act created DROP, a state-hosted universal-deletion platform live since January 1, 2026, which processes consumer deletion requests against every registered data broker on a 45-day cadence starting August 1, 2026.
Does CCPA cover B2B contact data?
Yes, fully — since January 1, 2023, when the B2B partial exemption sunsetted. A California-based VP of Data’s work email is personal information under CCPA.
What is a “CCPA request”?
A consumer’s exercise of one of the enumerated rights: a request to know what personal information you have on them, a request to delete it, a request to correct it, a request to opt-out of sale or sharing, or a request to limit use of sensitive personal information.
