California Delete Act (SB 362) Compliance Guide: Data Broker Impact 2026

The Delete Act targets the $303 billion data broker industry. If you buy, sell, license, append, or resell third‑party lead data, SB 362 changes your downstream supply chain – not just your privacy policy.

(Disclaimer: This is general information, not legal advice. If your revenue depends on third‑party personal data, talk to privacy counsel about your specific data flows and contracts.)

---

The Structural Shift in Data Monetization

For years, third‑party data markets operated on accumulation: collect, aggregate, enrich, resell. California privacy laws introduced opt‑out and deletion rights, but consumers still had to act company by company – a logistical impossibility when dozens of intermediaries hold their data.

The Delete Act changes the distribution model. It centralizes the deletion request mechanism through DROP, so a consumer can submit one request that reaches all 545 registered data brokers simultaneously. California’s 40 million residents represent one-eighth of the U.S. population, meaning the industry’s largest consumer dataset faces systematic erosion.

For lead sellers and enrichment vendors, this is not a compliance checkbox. It’s a supply chain constraint that makes parts of third‑party data less renewable over time.

What SB 362 Actually Does

California privacy law (CCPA/CPRA) already gave consumers deletion and opt-out rights. In practice, those rights were fragmented: you had to find the companies holding your data and submit requests one by one.

The Delete Act (SB 362) changes the distribution model. It requires the California Privacy Protection Agency (CPPA) to build a single “accessible deletion mechanism” that lets a consumer submit one verifiable request that is transmitted to registered data brokers.

This is not a retroactive clawback of every copy of data in the world. It is a state-run request rail that creates standardized deletion and suppression obligations for the broker layer.

What DROP Is (and What It Isn’t)

DROP (Delete Request and Opt-Out Platform) is California’s centralized deletion mechanism for data brokers – a single portal where consumers submit one verifiable request that is transmitted to all registered data brokers simultaneously (Cal. Civ. Code § 1798.99.86). Unlike previous company-by-company deletion rights, DROP creates a standardized channel that imposes 45-day retrieval and 45-day processing obligations on the broker layer.

What DROP does:

• Lets consumers submit one verifiable request that reaches all registered data brokers
• Provides a standard channel for brokers to retrieve requests and report status
• Creates ongoing obligations designed to stop continued resale and re-introduction of deleted consumers into broker products
• Functions as both deletion request AND opt-out request – if deletion can’t be verified, the broker must still stop selling

What DROP does not do:

• It does not automatically purge a record from every downstream buyer system
• It does not reverse historical deliveries that already occurred

If you’re a lead seller, that “doesn’t reverse the past” nuance matters. The immediate effect is not “all your inventory disappears.” The effect is that broker-sourced records become harder to refresh, append, and resell over time as more consumers use DROP.

The Timeline That Matters (2026–2028)

The backlog risk window

Between January and August 2026, consumer requests can accumulate even though brokers aren’t yet required to operationally process them. This is why August 2026 is a backlog risk window, not just a calendar date.

What August 1, 2026 requires

Beginning August 1, 2026, registered data brokers must (Cal. Civ. Code § 1798.99.86(c)):

• Access DROP at least once every 45 days
• Process and delete within 45 days after receiving a request
• If a deletion request cannot be verified, process it as an opt-out of sale/sharing
• Direct associated service providers and contractors to delete the consumer’s personal information
• Report request status back through the mechanism

SB 362 also adds ongoing obligations after deletion, including continuing deletion on a repeating cadence and prohibiting sale/sharing of new personal information of the consumer, subject to narrow statutory exceptions.

Audit requirements (2028+)

Beginning January 1, 2028, data brokers must undergo an independent third-party audit every three years. The statute sets explicit evidence mechanics: brokers must provide audit reports to the CPPA within five business days of a written request, and retain materials for at least six years (Cal. Civ. Code § 1798.99.86(e)(2)–(3)).

Registration, Liability, and Why Lead Gen Keeps Misclassifying Itself

In plain language, a data broker is a business that sells personal information about consumers with whom it has no direct relationship. In lead gen, the word “broker” rarely appears in brand positioning, but the behavior shows up everywhere: aggregators, appends, enrichment APIs, list sellers, resellers, and identity products built on third-party feeds.

Some entities and activities can be exempt depending on the regulatory regime (for example, certain FCRA, GLBA, or HIPAA-regulated contexts). The practical point for operators is that “we have a compliance program” is not the same thing as “we’re not a broker.” You need to classify your actual product and data flows.

Under the statute, if you meet the definition of a data broker, registration is due on or before January 31 following each year in which you meet that definition. CPPA also publishes operational guidance about how brokers will register for 2026, including using DROP as part of the registration process.

Penalties: Why the Math Gets Ugly Fast

SB 362 sets penalties that punish delay (Cal. Civ. Code § 1798.99.82):

• Failure to register: up to $200 per day until registration occurs (§ 1798.99.82(c))
• Failure to delete on time: up to $200 per deletion request per day for each day the broker fails to delete as required (§ 1798.99.82(d))

Enforcement is already happening

The CPPA launched a Data Broker Enforcement Strike Force in late 2025 and has announced hundreds of open investigations. Early enforcement actions demonstrate the penalty structure in practice:

The penalty math scales fast

Consider the deletion penalty structure: $200 per request, per day. If 10,000 California consumers submit DROP requests and a broker misses the processing deadline by 10 days:

10,000 requests × $200 × 10 days = $2,000,000 in potential exposure

This structure is designed to make operational drift expensive. Missing retrieval cadence, building deletion backlogs, and “we’ll get to it later” workflows don’t just create theoretical risk. They create compounding exposure that accumulates daily.

The Supply Chain Shock: Patchy Data

The most immediate impact of DROP won’t be a fine landing in your inbox. It will be product degradation across the enrichment layer: identity graphs lose matchable nodes, append vendors return fewer attributes, and two “similar” leads can look very different solely because one consumer used DROP.

Think of it as a Swiss‑cheese effect in third‑party datasets. The holes won’t be evenly distributed, and they’ll show up as missingness in fields your scoring and routing logic currently assumes are reliable.

The “death of refresh”

Historically, third‑party records could be deleted and then reacquired from another feed. SB 362 is designed to prevent “delete today, re‑collect tomorrow” at the broker layer by imposing ongoing obligations after deletion. In practical terms: once a consumer is in scope, you should expect that consumer to become harder to enrich and harder to monetize through broker channels going forward.

What Lead Sellers Will Notice First

Most lead operators won’t feel DROP as a wave of direct consumer requests. They’ll feel it through vendor behavior and field availability in third-party supply chains.

Enrichment gets patchier

If your product depends on broker-sourced appends (phone, address, demographics, household links), you should expect coverage to degrade for opted-out consumers. The result shows up as inconsistent outputs:

• Vendor A returns a phone number; Vendor B returns nothing for the same lead
• The same vendor returns fewer attributes over time for the same segment

This breaks scoring models and routing logic that assume certain enrichment fields will always be present.

Inventory becomes harder to refresh and resell

Many lead businesses monetize the same person more than once: refresh the record, append new attributes, resell again, or redistribute through multiple buyers. DROP is designed to restrict that “refresh forever” loop at the broker layer.

Suppression becomes a product feature

When obligations run on a repeating cadence, the real operational question becomes: can your outbound delivery pipeline stop shipping a consumer’s record once suppression applies? Deleting rows in a database isn’t enough if exports, appends, and resale products can rebuild and ship the same person later.

Practical steps to take now

• Map field provenance: Document which fields come from which vendors and what “layer” those vendors operate in. The distinction between first-party and third-party lead data becomes operationally critical under DROP.
• Separate first-party from appended data: In your schema and delivery contracts, clearly distinguish first-party captured fields from appended third-party attributes.
• Add suppression controls at export: Build suppression checks at the point of export and resale, not only as periodic cleanup jobs.
• Update vendor contracts: Push deletion and suppression obligations into vendor terms, including timelines and evidence requirements.
• Strengthen consent documentation: If your model depends on consent as an asset, tighten consent capture using documented consent patterns (TrustedForm, Jornaya) so you can distinguish first-party relationship data from appended broker fields.

---

Frequently Asked Questions

What happens to data that’s already been delivered?

The Delete Act and DROP do not retroactively claw back data already delivered to buyers, partners, or internal systems before a deletion request is processed. The law is designed to stop continued circulation at the broker layer, not automatically purge every downstream copy. Practically, historical deliveries remain, but future resale, sharing, and enrichment through broker channels is supposed to stop once the request is processed. Over time, this “freezes” opted-out records: they become non-refreshable inventory rather than assets that can be repeatedly appended and resold.

When do brokers have to start processing DROP requests?

Consumers can submit DROP requests starting January 1, 2026, but brokers are required to begin retrieving and processing requests starting August 1, 2026. Beginning then, brokers must access DROP at least once every 45 days and must process and delete within 45 days after receiving a request. If you depend on third-party enrichment, assume the biggest operational disruption begins in the second half of 2026 as the cadence becomes enforceable.

How often must brokers check DROP?

At minimum, once every 45 days beginning August 1, 2026. Brokers can retrieve more frequently, and many will automate retrieval to reduce backlog. The operational risk of checking infrequently is spikes: the longer the gap, the larger the batch of requests that hits your deletion workflow at once, and the easier it becomes to miss the 45-day processing window.

What happens if a broker cannot verify a deletion request?

If a broker denies deletion because a request cannot be verified, SB 362 still requires the broker to process the request as an opt-out of the sale or sharing of the consumer’s personal information. In other words, “we can’t verify you” is not permission to keep selling. At minimum, circulation must stop.

Can consumers exclude specific data brokers from a request or change a prior request?

Yes. The statute requires DROP to let consumers selectively exclude specific brokers from a request. It also requires the platform to allow consumers to alter a previous request after at least 45 days have passed since their last request. Operationally, that means suppression status can change over time and your controls need to handle changes without creating gaps.

Does this apply to companies outside California?

Often, yes. If California residents are in your dataset and you operate in a broker-like model (selling personal information without a direct relationship), the Delete Act can still matter even if you’re not headquartered in California. If you’re unsure, treat it as a classification question and talk to counsel rather than relying on “we’re not based there.”

What happens if I don’t register at all?

The statute’s registration penalty is designed to make ignoring the registry expensive over time: $200 per day, plus fees and enforcement costs. If you’re operating in a broker‑like role and you stay unregistered, you’re not “flying under the radar.” You’re accumulating daily exposure while remaining unprepared for the August 2026 operational requirements.

Can a broker charge consumers a fee to process these requests?

DROP is intended to be a free consumer-facing mechanism. CPPA can charge access fees to data brokers for accessing the mechanism, but the consumer shouldn’t be paying a broker to honor a statutory deletion request. If your workflow assumes “pay us to delete,” treat that as a red flag and get counsel before you ship it.

What if the data is “publicly available”?

California privacy law has specific definitions for publicly available information, and the Delete Act also incorporates deletion exceptions from the broader CCPA/CPRA framework. The safe operational assumption is: don’t treat “we found it on the internet” as a blanket exemption. If you’re building profiles that combine sources (and especially if you’re adding contactability like email/phone or behavioral attributes), expect deletion and suppression obligations to apply unless counsel confirms a specific exception.

Can a broker keep data for legal defense or compliance holds?

In many regulatory frameworks, limited retention for legal compliance or defense is allowed. The key operational requirement is separation: retained data for legal hold purposes should be quarantined so it cannot be used for marketing, enrichment, or resale. If you’re audited, you need to be able to show that separation in practice, not just in policy language.

Is DROP basically a “Do Not Call” list?

The analogy is useful but incomplete. DNC restricts outbound contact. DROP targets the broker resale layer by creating deletion and suppression obligations, changing whether a consumer’s data can continue circulating through resale and enrichment markets. For lead businesses, the practical similarity is the control pattern: you need a reliable suppression check baked into your ingestion and delivery pipelines.

Key Takeaways

• DROP creates a compliance cliff with a backlog window. Consumer requests can accumulate starting January 1, 2026, but processing requirements don’t become enforceable until August 1, 2026 – meaning brokers who wait until summer face a seven-month backlog hitting their workflows at once.

• The penalty math scales to existential exposure. At $200 per request per day, even modest consumer adoption creates compound risk. 10,000 requests × 10 days late = $2 million in potential penalties. This structure is designed to make “we’ll get to it later” an expensive posture.

• Verification failure is not a loophole. If a broker can’t verify a deletion request, SB 362 still requires processing the request as an opt-out of sale/sharing. “We can’t verify you” does not mean “we keep selling.”

• The first visible impact is patchy data, not direct enforcement. Lead sellers will feel DROP through vendor behavior: weaker appends, lower match rates, inconsistent enrichment across providers. Third-party datasets develop holes that break scoring and routing logic.

• Suppression becomes a systems problem, not a compliance task. Deleting rows in a database doesn’t prevent re-introduction through exports, appends, and resale products. Suppression controls belong at the point of outbound delivery, not in periodic cleanup jobs.

• First-party data separation is now operationally critical. Contracts and schemas need to distinguish first-party captured fields from appended third-party attributes – because deletion obligations apply differently, and proof of that distinction matters in audits.

---

The Bottom Line

The Delete Act doesn’t ban third-party data or immediately erase existing records. What it does is change the economics of broker-sourced data by making deletion and suppression enforceable at scale. For lead sellers, the question isn’t whether DROP will affect your business – it’s whether you’ll see the impact as gradual quality degradation in your enrichment layer or as a sudden compliance scramble when penalties compound.

The operators who treat 2026 as a systems problem rather than a policy update will be the ones still operating profitably in 2028.

Sources

• California SB 362 bill text: https://leginfo.legislature.ca.gov/faces/billTextClient.xhtml?bill_id=202320240SB362
• CPPA data brokers guidance: https://cppa.ca.gov/data_brokers/
• CPPA data broker registry: https://cppa.ca.gov/data_broker_registry/
• CalPrivacy DROP overview: https://privacy.ca.gov/drop/