Your people-data vendor has a compliance calendar. Ask to see it.

On 1 August 2026, five days from now, a scheduling clause in California law starts doing real work. The California Privacy Protection Agency's data broker registry page says the Delete Request and Opt-out Platform, DROP, became operational on 1 January 2026, and that California residents have been able to submit one request to all active data brokers since that date. The same page says data brokers "are required to begin processing these requests on August 1, 2026."

The statute behind it is Civil Code section 1798.99.86, added by the Delete Act. The text on the California Legislative Information site reads that beginning 1 August 2026, a data broker shall access the accessible deletion mechanism at least once every 45 days and process all deletion requests it finds there. Deletion runs on a clock after that: every 45 days, indefinitely, against a queue the broker does not control.

Almost everything written about this is aimed at brokers or at consumers. Very little of it is aimed at the engineering and data teams who buy person-level records and feed them into something. If you license B2B contact or company records and a supplier of yours is a registered California data broker, that supplier now has an operational cadence with dates attached, and some of it lands on you.

This is not legal advice. It is a supplier-reliability argument. Take the legal question to a lawyer and the procurement question to the checklist below.

What the statute actually says

Four mechanics matter for a buyer, all from the section text as published on leginfo.legislature.ca.gov:

A registered broker must access DROP at least once every 45 days and delete all personal information related to the consumers making verifiable requests, within 45 days.

It must direct all service providers or contractors associated with it to delete the same information in their possession.

Where a request cannot be verified, the broker must process it as an opt-out of sale or sharing rather than a deletion.

There are carve-outs. Deletion is not required where retention is reasonably necessary for a purpose listed in section 1798.105, or where deletion is prohibited under sections 1798.145 or 1798.146. Retained records may only be used for those purposes.

The definition matters as much as the obligation. Section 1798.99.80 defines a data broker as a business that knowingly collects and sells to third parties the personal information of a consumer with whom the business does not have a direct relationship, and it excludes entities covered by the Fair Credit Reporting Act, Gramm-Leach-Bliley, the California Insurance Information and Privacy Protection Act, and entities exempt under section 1798.146. Registration itself is annual, on or before 31 January following each year the business meets the definition, with a $200-per-day administrative fine for failing to register. Beginning 1 January 2029 the registration form also asks whether the broker has undergone an audit.

I have not checked the registry entry for any specific vendor, and neither should you take a vendor's word for it. The registry is public and searchable at the CPPA. Look up the legal entity name, not the brand.

Why a buyer should care about somebody else's cadence

Buying records instead of collecting them yourself is usually framed as the low-risk path, and across most of the risk surface it is. You skip the anti-bot arms race and the parsing maintenance, and you never have to answer for who sourced your exit nodes. Our guide to evaluating web data providers treats it that way, and the data providers category on this site exists because for a lot of teams it is the correct call.

Deletion is the exception, and it has a specific shape. It is the one part of the arrangement where the vendor's inventory can shrink on a schedule set by people who are neither you nor the vendor.

Person-level suppliers sit at different points on this. People Data Labs and Coresignal sell person and company records at volume, resolved into profiles. Scrapin returns structured professional details per lookup rather than as a bulk file. Bright Data Datasets packages pre-built and custom datasets scraped from public sites. Datarade is a marketplace: it introduces you to a supplier rather than being the supplier, which means the compliance question passes through it to whoever is actually on the other end of the contract. Outscraper is closer to the scraping API end, selling collection rather than a standing inventory of people. Where a given vendor sits on that spread changes what a deletion obligation does to your data, and none of it can be read off a marketing page.

The four questions

Is the entity a registered California data broker, and under what legal name? Not "are you compliant," which every vendor answers yes to. Registration is a row in a public table with a legal name and a filing date on it. A vendor that is not registered is telling you something too, and the interesting follow-up is which exclusion it believes applies.

How are upstream deletions propagated to customers? This is where you find out whether the compliance badge has any plumbing behind it. There are only a few real answers: a delta or suppression file on a schedule, a per-record status endpoint you can poll, a flag on the next full refresh, or nothing. "Nothing" is a live answer and it is more common than the category likes to admit. If the answer is a full refresh, the deletion latency you inherit is your refresh interval, not the vendor's 45 days.

What does the contract oblige you to do once a record is deleted upstream? The statute reaches service providers and contractors of the broker. Whether your company is one of those, or an independent recipient with its own obligations, is a contract-and-counsel question I am not going to answer for you. But the data services agreement almost certainly already says something about it, and most buyers have not read that clause since signing. Read it before August, not after.

What does attrition look like in a refresh? Ask for the historical numbers: records removed per refresh cycle, as a percentage, over the last four cycles. A vendor that measures this can tell you. A vendor that cannot is telling you it does not track its own churn, which is a separate problem.

How this shows up in a pipeline

By the time coverage attrition reaches you it has stopped being a legal event and turned into a data-quality one, and it arrives looking like something else.

A join that matched 94% last quarter matches 91% this quarter. A downstream table keeps rows whose upstream source no longer exists, and nobody notices because nothing errors. If you have ever debugged silent coverage loss in a crawl, the failure mode is familiar from large-scale crawl architecture: the pipeline runs green while the population underneath it changes.

The defense is the same as it is for any dependency you cannot control. Measure the input, not just the output. Keep a per-refresh record count and match rate as a monitored metric with an alert on it, the way you would monitor a proxy pool's success rate. Keep provenance on every person-level row: which supplier, which refresh, which date. Without that, a deletion propagated to you is unactionable, because you cannot find the row.

And consider whether a single supplier is the right shape at all. The argument for second-sourcing across proxy vendors is about outage risk. Here it is about correlated attrition: two suppliers drawing from overlapping upstream sources will lose overlapping records, so a second contract buys less resilience than the invoice suggests.

What this means for a team collecting web data

The sourcing question has moved. For years the uncomfortable question in this market was about collection: where the records came from, and whether the IP sourcing behind them would survive scrutiny, a theme that has been running through the proxy market for a while now. Deletion runs the other direction. It governs what leaves, on a schedule, whether or not you notice.

So treat a person-level supplier as infrastructure with an SLA rather than as a file you bought. The registry check, the propagation mechanism, the contract clause and the attrition numbers go into the vendor review alongside price and coverage. The same discipline the market learned about proxy vendors after their ownership changed applies here.

And if you are choosing between buying person-level records and collecting public data yourself, deletion obligations are now a real input to that decision rather than a footnote. They do not settle it. Collection has its own costs, well covered in choosing web scraping tools, and buying still removes more risk than it adds for most teams. But the comparison is no longer static on one side, and a build-versus-buy model that treats purchased coverage as a fixed asset is modelling something that stops being fixed on 1 August 2026.

Ask for the calendar. If the vendor does not have one, that is the finding.