The Universal Deletion Cycle: Processing DROP Requests Without Repopulation

This guide is the processing-day runbook for the recurring cycle that pulls a batch of universal deletion requests from California's DROP, applies them across every sourced-contact dataset and downstream vendor, and keeps those people from reappearing. It is written for the sourcing-ops, revenue-ops, or privacy-ops owner who is answerable for how contact data was gathered and who has to run this loop every 45 days. Other guides cover basis-expiry purges and one-off deletion requests; this one covers the standing batch cycle, the cascade to service providers, and the suppression screen that stops upstream enrichment from repopulating what you just deleted.

The Delete Act, SB 362, was signed October 10, 2023 and amended by SB 361 in October 2025. DROP, the Delete Request and Opt-Out Platform, launched January 1, 2026, and the processing obligation begins August 1, 2026. From that date, a registered data broker must access DROP at least once every 45 days and process every request it retrieves. This is not a project with an end. The duty attaches to re-acquisition, so the moment you delete someone and later buy them back from a data vendor, the obligation fires again.

Am I a data broker if I source contacts?

You are a data broker if you knowingly collect and sell to third parties the personal information of a consumer with whom you have no direct relationship. The operative test is the source of the data, not whether you have any customer relationship at all. A business is still a data broker if it has direct relationships with some consumers but also sells personal information it collected outside a first-party interaction. The final rulemaking removed the earlier three-year lookback on "direct relationship," so you cannot lean on stale customer contact to argue your way out.

This is where sourcing operations get caught. If you assemble contact records from public LinkedIn, the public GitHub graph, and enrichment attributes derived from non-customer information, and you sell or share those records, the source-of-data test likely pulls you in. The same logic reaches retailers running retail media networks, SaaS providers offering audiences built from third-party data, and enrichment sellers. Exemptions apply for data covered by FCRA, GLBA, and the Insurance Information and Privacy Protection Act. Everything else you sell that you did not collect first-party is in scope.

Scope is a legal and privacy determination, run once and revisited each year. On or before January 31 following each year in which you meet the definition, you must register with the CPPA. The registration fee is $400. Getting this wrong is expensive in a specific way: the penalty for failure to delete is per person, per day, so the risk scales with how many of the queued requests you happen to hold.

Why the penalty structure makes scale the real risk

The penalty is per deletion request, per day, which means your exposure grows with the size of your dataset, not with a single act of non-compliance. Failure to delete carries a $200 fine for each deletion request for each day you fail to delete the information. SB 361 doubled that daily fine from $100 to $200 and created a Data Broker Enforcement Strike Force in November 2025. This is not theoretical enforcement.

Do the arithmetic on your own footprint. If you hold contact records for even a sliver of the requesters, every unprocessed row runs at $200 a day until you delete it. Named settlements already show the shape of enforcement: Background Alert agreed to cease operations through 2028, ROR Partners paid $56,600, Accurate Append paid $55,400, and Growbots and UpLead paid roughly $35,000 each. The constants that govern the cycle are worth pinning to the wall.

There is one open point worth flagging so you do not get caught by it: sources disagree on the completion clock. Most read the statute as "process within 45 days of receipt," while one law firm frames it as "complete determinations within 90 days of retrieval." Treat 45 days as your working deadline and confirm the current reading with your own counsel before you rely on the longer window.

The staffing gap this cycle has to survive

The people who generate sourced-contact data vastly outnumber the people who would own its deletion. In Refolk's index of professional profiles, roughly 4,212 US professionals hold sourcing titles such as Sourcing Specialist or Talent Sourcer, against roughly 370 who hold privacy-operations titles like Privacy Analyst, Data Privacy Manager, or Privacy Operations. That is about 11 sourcers for every privacy-ops professional who would run this loop.

The reason this matters operationally: a mismatch this wide predicts execution risk. Data enters your systems from many hands and leaves through very few. The cycle has to be built as a machine that runs on cadence with minimal human intervention, because you do not have a privacy team large enough to run it by hand every 45 days. That is why suppression on ingestion, covered below, does most of the load-bearing work.

The market is not only in the US. The same sourcing titles show up elsewhere, and the ratio between markets is a useful sanity check on where your data-generating headcount sits.

Data enters your systems from many hands and leaves through very few, so the cycle has to run itself.

Running the cycle: the 45-day procedure

The cycle has eight stages, from confirming you are in scope through re-screening on the next loop. Steps one and two are stand-up work you do once; steps three through eight repeat every 45 days. Assign an owner to each stage before your first cycle, because the report gate in step seven can freeze the whole pipeline if it slips.

The matching detail that most teams get wrong

Matching is the step where loose engineering quietly creates violations. The regulations require you to standardize your internal records - lowercase all fields, strip extraneous characters, convert dates to YYYYMMDD format, normalize phone numbers - then hash your data using the same SHA-256 method CalPrivacy specifies and compare the result against the downloaded consumer list. Where a request carries multiple identifiers, you concatenate the separate values and match the concatenated value.

The threshold matters. The regulations removed the earlier 50% threshold, which leaves a 100% consumer identifier match requirement for deletion to be required. Fuzzy or partial matching is a trap in both directions: it can delete the wrong person or miss the right one. Reproduce CalPrivacy's standardization exactly, because a hash that diverges by one normalization rule will not match a hash that should.

Handling unverifiable requests

You may only deny a request for one reason: the requestor's identity cannot be verified. Even then, a denied request must be processed as if the individual opted out of the sale and sharing of their personal information, inside the same 45-day window, with the opt-out cascaded to your service providers and contractors. Treating an unverifiable request as a plain "no" is a violation. Build your pipeline so that "cannot verify" routes to opt-out automatically, not to a dead end.

Proving records do not repopulate

Suppression, not deletion, is the control that keeps this working. Once a request is processed, its hashed identifiers go on a permanent suppression list, and every 45 days you screen newly collected data against that list. If you have re-acquired the person, you delete them again. This is the mechanism that stops an enrichment buy from silently undoing a completed cycle.

The obligation is explicit and continuing. A broker that re-acquires information after deleting it must delete it again on the following cycle, and within 45 days of detecting the change must report the DELETED status to DROP. Proposed amendments would go further: they would define "suppression list," specify what you may retain, and require screening incoming data against consumers who previously submitted DROP requests even where no match was initially made. In practice that means the screen belongs at the point of ingestion, ahead of any sale or share, not as a periodic cleanup job.

This is the practical difference between a one-time purge and a durable cycle. A purge empties the tank; the suppression screen closes the valve so it does not refill. If you run outbound sourcing on top of continuous enrichment, the screen has to sit above the enrichment, because that is the upstream source most likely to repopulate a deleted person.

Finding the person who has done this before is faster than teaching it. When the constraint is people rather than process, Refolk lets you describe the exact profile - a privacy-ops manager who has run a CCPA deletion workflow, or a compliance lead at a California-registered broker responsible for DROP processing - and get named candidates back across LinkedIn, GitHub, and the open web.

How this cycle goes wrong

Most failures are quiet: the dashboard shows green while a rule is being broken somewhere the dashboard does not look. These are the failure modes that recur, what the false positive looks like, and how to check for it.

• Assuming a vendor can pull DROP for you. The false positive is "our privacy platform handles DROP." It cannot. Vendors are not permitted to access DROP directly on your behalf. Check that the DROP login uses your own broker credentials.
• Treating "not a broker" as settled because you have customers. The false positive is "we have a direct relationship, so we're exempt." You are still a broker if you also sell personal information you did not collect directly from the consumer. Check by auditing each sold field for its collection source.
• Deleting internally but not cascading. The match is erased in your database and the dashboard goes green, but service providers still hold the record. Check that each service provider and contractor received the delete or opt-out direction and confirmed the action.
• No suppression screen on ingestion. Records repopulate from the next enrichment buy. Check that new acquisitions run against the suppression list before any sale or share, and that re-acquired matches auto-delete.
• Loose matching. Fuzzy or partial matches delete the wrong person or miss the right one. The standard is a 100% concatenated-hash match. Check that you reproduce CalPrivacy's SHA-256 standardization exactly.
• Missing the report window. A broker that misses its reporting window loses access to the next batch and accrues penalties on every unprocessed request in the interim. Check that every retrieved row has a status within 45 days.
• Ignoring unverifiable requests. Denying without opting out is a violation. Check that denied requests become sale and share opt-outs and cascade downstream.

The two-variable judgement that decides how much of this you automate is match confidence against acquisition volume. Where you buy little and match cleanly, a light manual process survives; where you ingest constantly and match at scale, the suppression screen has to be automatic or you will miss re-acquisitions.

Before you call the cycle done

Run this check at the end of every 45-day loop, not just the first one. The obligation is recurring, and the most common way teams fall out of compliance is doing this correctly once and then letting the screen drift.

Keeping the cycle current

The rules around this are still moving, so build in a re-check rather than a fixed reading. Independent third-party compliance audits begin January 1, 2028, on a three-year cadence, with audit records retained at least six years and submitted to CalPrivacy on request. That means the evidence trail you keep now - which rows you deleted, when, and how you matched them - is the record an auditor will eventually ask for. Log it from the first cycle.

Three things to watch and re-verify each period. First, the completion clock: confirm whether your counsel reads it as 45 days from receipt or 90 days from retrieval, and default to the shorter until told otherwise. Second, the suppression-list amendments: the proposed rules on screening previously non-matching consumers would widen what your ingestion screen must cover. Third, automation failures: if your automated download fails and it is not user error, you must notify CalPrivacy within 45 days and download the list manually in the meantime. Wire that alert into whoever owns step three, because retrieval is the one step you can never delegate to a vendor.

The work does not end because the duty attaches to re-acquisition, not to a single deletion. Run the loop, keep the screen at ingestion, report every row on time, and keep the evidence. That is the whole job, repeated every 45 days.