After the n-th time a data leader has pinged us about the same Slack from legal (“we need to talk about CCPA before we sign this vendor”), we figured it was worth writing the framework down. The lawyer on the thread already knows the statute. The data leader does not, and is about to have to, defend an external data program in front of a procurement gate that they did not design.
This is not the article about whether scraping is legal. That conversation lives one level up in the broader legal landscape of web data acquisition. This is the narrower question, the one that arrives in week three of the procurement cycle. What does the California Consumer Privacy Act (CCPA) actually require when the personal information arrives from outside your perimeter, and how do you translate the law into vendor questions, contract clauses, and pipeline controls?
Scope, in one line: CCPA, as amended by CPRA (California Privacy Rights Act, Prop 24), as of 2026. Four operational primitives in §5, ten procurement questions in §8. That is what you leave the article holding.
Quick Digest
- §1 sets the trigger: CCPA regulates the handling of California residents’ personal information, regardless of where it came from. The thresholds and carve-outs (publicly available, sector-preemption) are narrower than most teams assume.
- §2 maps the five consumer rights to the four pipeline obligations they create.
- §3 covers sale vs sharing — the classification that turns an ordinary data transfer into a regulated event.
- §4 covers the three vendor classifications (service provider, contractor, third party). The contract is the classification.
- §5 gives you four operational primitives: data minimization, rights response, audit trail, downstream control.
- §6 covers what changes in 2026: ADMT rules, cybersecurity audit requirements, DROP obligations for data brokers.
- §7 covers enforcement reality — what California has actually fined for, and what the pattern says about risk.
- §8 is the procurement conversation: ten questions to take into a vendor meeting.
§1. What does the CCPA actually regulate when the data is external
CCPA regulates the handling of personal information about California residents, not the collection method. That is the point most external-data programs miss. It does not matter that the data arrived from a vendor, a data broker, a public registry, or a web extraction pipeline. If the record contains personal information about a California resident and your business meets the thresholds, CCPA applies to what you do with it from the moment it lands in your environment.
The thresholds (as of 2026): annual gross revenues over $25 million; or buy, sell, receive, or share the personal information of 100,000 or more consumers or households; or derive 50% or more of annual revenues from selling or sharing personal information. Any one threshold triggers the full statute. Mid-market SaaS companies building on third-party data frequently cross the 100,000-record threshold without realizing it.
Two carve-out teams over-rely on. Publicly available information: CCPA excludes “personal information that is lawfully made available from federal, state, or local government records.” This is narrower than it sounds. Information that appeared in a public registry at some point is not automatically outside CCPA if you have combined it with other data, used it for a purpose inconsistent with the public context in which it was disclosed, or re-identified it. The carve-out is for the government record itself, not for downstream aggregation. B2B data: There is a limited B2B exemption for personal information reflecting a person’s role as a business employee, contractor, or officer. It is partial, and California has signaled it does not extend to professional contact data sold commercially.
The baseline test for any external-data program: does this dataset contain fields that could identify a natural person who is or may be a California resident? If yes, CCPA governance applies. Provider directories, professional contact databases, and healthcare affiliation data all pass this test.
§2. The five consumer rights, translated into pipeline obligations
CCPA gives California residents five rights. Each one creates a specific operational obligation for any business that holds their personal information, including businesses that received that information from a third-party vendor.
Right to know. A consumer can request disclosure of what personal information you hold about them, the categories and specific pieces, the sources you collected it from, and the business purposes for which you used or disclosed it. Pipeline obligation: you need a record of where each PI field came from, which means your ingestion layer needs source provenance per record, not per dataset.
Right to delete. A consumer can request deletion of their personal information. You must delete it from your own systems and instruct your service providers and contractors to delete it from theirs. Pipeline obligation: deletion has to propagate downstream. If you have loaded PI into a warehouse, a feature store, or a third-party analytics tool, deletion is not a one-table operation.
Right to correct. Added by CPRA. A consumer can request correction of inaccurate personal information. Pipeline obligation: your data model has to allow in-place correction without breaking downstream joins. Immutable tables with no correction pathway fail this requirement operationally, even if they are not technically non-compliant.
Right to opt out of sale or sharing. A consumer can direct you to stop selling or sharing their personal information. Pipeline obligation: you need a flag per record, and that flag has to propagate to any downstream system that receives the data. This is the obligation that most frequently catches external-data programs off guard, because the “sale or sharing” definition is broader than most teams assume (covered in §3).
Right to limit use of sensitive personal information. Added by CPRA. Consumers can direct businesses to limit the use of sensitive PI (precise geolocation, race, ethnicity, religion, health data, biometrics, sexual orientation, and a few others) to what is necessary for the service. Pipeline obligation: sensitive fields need to be tagged at ingestion so you can enforce limits without manual auditing.
The operational translation of all five rights has the same shape: per-record source provenance + stable identifiers + deletion/correction propagation + opt-out flag propagation. Those four things are covered in §5 as the four operational primitives.
§3. Sale vs sharing, and why external data extraction often counts
This is the section most external-data teams need to read twice.
“Sale” under CCPA does not mean a cash transaction for data. It means any disclosure of personal information for valuable consideration. If you give a vendor access to your data in exchange for a service (even a non-monetary service), California may treat that as a sale. CPRA added “sharing” as a separate regulated act, defined as disclosing PI to a third party for cross-context behavioral advertising, with or without monetary exchange.
For external-data programs, the classification that matters most is whether your data vendor is treating the transfer to you as a sale or a sharing. If they are, you may inherit opt-out obligations for every record they transferred. If the vendor has a compliant service-provider contract (§4), the transfer is not a sale. If the vendor does not have that contract, or if the contract is defective, you may be holding data that was transferred in violation of consumer opt-outs.
The external data extraction case: web extraction of public data is generally not a “sale” by the extractor because the extractor is not disclosing someone else’s PI — they are collecting it. But if the extractor then licenses that data to you for valuable consideration, the transaction between the extractor and your business may qualify as a sale depending on the contract structure and the data involved. This is why the service-provider classification (§4) matters.
§4. Service provider vs contractor vs third party, the contract IS the classification
CCPA creates three vendor classifications. The classification determines whether a data transfer is a regulated event (a “sale”) and what contractual obligations apply. The classification is not determined by what a vendor calls themselves. It is determined by the contract.
Service provider. A business that receives PI from a business pursuant to a written contract, for a business purpose, and is prohibited by the contract from selling or sharing the PI, retaining it for its own commercial purposes, or using it outside the scope of the contract. A compliant § 7051 contract is what makes a vendor a service provider. Without it, the default classification is third party.
Contractor. Added by CPRA. Similar to a service provider, but applies to a business that collects PI directly from consumers on behalf of another business. The contract requirements are comparable to service-provider contracts. For external-data programs, this classification applies less frequently than service providers.
Third party. Any entity that is not a service provider or contractor. A disclosure to a third party is presumptively a “sale or sharing” under CCPA. The consumer opt-out right applies. There is no audit right by statute. Sub-processor flow-down is not regulated. Third-party status is the default if the contract does not specify any other classification.
The procurement implication: every external data vendor you work with is either a service provider under a § 7051-compliant contract or a third party by default. There is no middle ground. If your vendor contract does not contain the statutory prohibitions (no selling, no retaining for commercial purposes, no using outside the specified purpose), your vendor is a third party, and every transfer from them to you may be a sale that the consumer had the right to opt out of.
§5. Four operational primitives for a CCPA-aware external-data program
Every CCPA obligation for an external-data program reduces to four operational primitives. These are not legal conclusions — they are the engineering and data-architecture decisions that make it possible to fulfill the obligations without manual intervention at scale.
1. Data minimization. Extract what the purpose requires. Leave the rest. Pseudonymize at ingestion, where the downstream use does not require the raw PI. The reason this is the first primitive is that every piece of PI you do not hold is a piece of PI you do not have to govern. Minimization also makes privacy risk assessments (required under ADMT rules in 2026) easier to defend.
2. Rights response. For any individual in your dataset, you need to be able to answer four questions on demand: do we have their data, where did it come from, what have we done with it, and can we act on a deletion or correction request in hours. This requires stable identifiers per record (so you can find the record when it arrives under a slightly different name), source provenance per field (so you can answer where it came from), and a deletion/correction pathway that does not require manual intervention in the data warehouse.
3. Audit trail. Every record should carry: source URL or API endpoint, ingestion timestamp, extraction job ID, transformation history, and consent signal (if applicable). This is the artifact the regulator requests in an enforcement investigation and the procurement gate requests in a vendor audit. Building it at ingestion is cheap. Retrofitting it onto two years of data warehouse history is not.
4. Downstream control. You know who you have transferred PI to. Deletions propagate to every downstream system within the required timeframe. Opt-out signals propagate in the same way. This requires either a data catalog with lineage tracking or a service mesh that intercepts PI in transit and enforces signals before they reach downstream consumers. Bidirectional flow: data in, signals back.
§6. What changes in 2026: ADMT, audits, DROP
Three CPRA regulatory packages landed or began enforcement in 2026. Each has direct implications for external data programs.
ADMT rules (effective January 1, 2026). Automated decision-making technology rules require businesses to give consumers the right to opt out of, and in some cases the right to access and correct the logic behind, automated decisions made about them. If your external-data pipeline feeds a scoring, ranking, or segmentation model that produces decisions with significant effects on consumers, the ADMT rules apply. The rules also require privacy risk assessments for high-risk processing activities, which the CPRA broadly defines as processing sensitive PI, processing large volumes of PI, and processing PI of minors.
Data broker DROP obligations (effective August 1, 2026). California’s Delete Request and Opt-Out Platform (DROP) requires registered data brokers to process consumer deletion and opt-out requests submitted through the state’s centralized platform, on a 45-day cadence. If your external-data vendor is a registered California data broker — and most large commercial data providers are — they are now required to process consumer opt-outs from the state platform, which means the data they sold to you before August 2026 may contain records the consumer has since opted out of. Your service-provider contract needs language that addresses how your vendor handles DROP deletions of records they have already transferred to you.
Cybersecurity audit requirements (phasing in 2028–2030). CPRA requires the CPPA to issue cybersecurity audit regulations for businesses that process PI and pose a significant risk. The audit requirements are expected to phase in starting in 2028, with scaling based on revenue and data volume tiers. External data programs that process large volumes of PI will likely fall into scope. The operational implication for 2026: if you are not already maintaining audit-trail infrastructure (primitive 3 above), the window to build it before the audit requirement lands is now.
§7. Enforcement reality: what California has fined for
The California Privacy Protection Agency (CPPA) and the California Attorney General have been enforcing CCPA since 2020. The enforcement pattern through 2026 has a consistent shape: notice-and-cure failures, opt-out mechanism defects, and privacy notice gaps dominate the docket. Fines have ranged from $1.2 million (Sephora, 2022, for sale-without-notice violations) to $8.5 million (DoorDash, 2024, for data-sharing violations with a marketing co-op). The CPPA has expanded its enforcement staff and signaled that 2026 priorities include data broker compliance and automated decision-making.
What the pattern says for external-data programs: the highest-risk exposure is holding data received from a vendor who did not have a compliant service-provider contract, combined with no opt-out mechanism for consumer requests. These are not exotic violations. They are the default state of a data program that was not built with CCPA governance in mind.
The CPPA’s enforcement posture on data brokers has sharpened since DROP went live. Brokers who fail to process platform deletions are the stated priority for 2026. The downstream implication: if you received data from a broker that failed DROP compliance, you may be holding records that should already have been deleted from your environment, even if you did not receive the deletion request directly.
§8. The procurement conversation, turning CCPA into a vendor question
Ten questions to take into the vendor meeting. Each one maps to an operational requirement or a contractual obligation. A vendor who cannot answer them is a vendor who will create compliance exposure.
- Is your contract a § 7051-compliant service-provider agreement? Ask for the specific prohibitions. The answer “yes, we have a DPA” is not the same as “yes, we have a DPA”.
- Are you a registered California data broker? If yes, are you DROP-compliant as of August 1, 2026? How do you handle DROP requests for records that have already been transferred to customers?
- What is the source provenance of each record? Source URL or API endpoint, collection timestamp, and method per record — not per dataset.
- What is your deletion/correction process? If a consumer submits a request that applies to a record in data you transferred to us, how and when do you notify us?
- Do you tag sensitive personal information at the field level? Precise geolocation, health data, and other CPRA-defined sensitive categories must be identifiable in the delivered dataset.
- What sub-processors do you use? The service-provider obligations flow down to sub-processors. If your vendor uses a sub-processor for enrichment, normalization, or storage, that sub-processor must be subject to equivalent contractual restrictions.
- What deployment options do you offer? Sovereign/on-premises deployment avoids the third-party data-handling footprint introduced by cloud-only vendors. Relevant for HIPAA-adjacent data and for programs that cannot pass compliance review with commercial LLM APIs in the extraction path.
- What audit rights does the contract give us? Service-provider contracts require audit rights by statute. If the contract does not include them, the classification is wrong.
- How do you handle consumer opt-out signals received after data transfer? DROP and direct opt-outs both create downstream obligations. The vendor’s answer tells you whether deletion propagation is real or aspirational.
- Have you had a CPPA enforcement action or inquiry? California requires disclosure of material legal proceedings in some contexts. The question raises a risk that a due diligence review might miss.
Quick Summary
Q: Does CCPA apply to data we bought from a third-party vendor?
A: Yes, if the data contains personal information about California residents and your business meets any of the three thresholds. CCPA regulates how you handle the data, not how it was originally collected.
Q: What makes a data vendor a “service provider” under CCPA?
A: A written contract with the specific prohibitions required by § 7051: no selling, no retaining for commercial purposes, no using outside the specified purpose. Without the contract, the default classification is third party.
Q: What are the four operational primitives for CCPA compliance?
A: Data minimization, rights response (per-record provenance + stable identifiers + deletion/correction pathway), audit trail (source + timestamp + job ID per record), and downstream control (deletion and opt-out signal propagation).
Q: What changed in 2026?
A: Three things: ADMT rules (automated decision-making opt-out + privacy risk assessments, effective January 1), DROP obligations for registered data brokers (45-day deletion processing via state platform, effective August 1), and the start of the rulemaking window for cybersecurity audit requirements phasing in 2028–2030.
§9. FAQ
Does CCPA apply to business-to-business data?
There is a limited B2B exemption for personal information reflecting a person’s role as an employee, officer, or director of a business. It is partial. It does not extend to commercial contact databases or professional data sold as a product. If your external-data program processes professional directories, provider data, or commercial contact lists, the B2B exemption is narrower than your legal team may have assumed.
What is the publicly available information carve-out?
CCPA excludes personal information lawfully made available from federal, state, or local government records. The carve-out is narrow. It applies to the government record itself, not to aggregated downstream datasets. If you have combined government-record data with other sources, used it in a context inconsistent with how it was publicly disclosed, or re-identified it, the carve-out likely does not apply.
What is the DROP platform and does it affect my data vendor?
DROP (Delete Request and Opt-Out Platform) is California’s centralized consumer request platform for registered data brokers. Effective August 1, 2026, registered brokers must process deletion and opt-out requests submitted through the state platform on a 45-day cadence. If your external-data vendor is a registered California data broker — most large commercial data providers are — they are required to process DROP requests, including for records they have already transferred to customers. Your service-provider contract should address how they handle this.
What are ADMT rules and do they apply to my data program?
ADMT (Automated Decision-Making Technology) rules, effective January 1, 2026, give consumers the right to opt out of automated decisions that produce significant effects on them. If your external data pipeline feeds a scoring, segmentation, or ranking model that makes decisions about consumers, ADMT likely applies. The rules also require privacy risk assessments for high-risk processing, which includes large-scale PI processing and processing of sensitive PI.
Related Articles
- Web Scraping Legal Compliance: What Data Teams Need to Know
- Healthcare Data Extraction: How Health Data Teams Automate Provider, Claims, and Clinical Data
- Healthcare Data Analytics: How Health Organizations Extract and Analyze External Data
- Real Estate Data API: What to Expect and How to Evaluate Providers
Written by Sai Subramaniam, Forage AI.
