The DROP Deletion Cycle Runbook: Retrieve, Match, Purge, Report

This is the runbook for the recurring job that California's DROP now puts on every registered data broker: process the batch of consumer deletion requests sitting in the platform, on cadence, without letting purged people reappear in your active datasets. It is written for recruiting operations, revenue operations, data governance, and anyone answerable for how the data was gathered. Most published material explains whether you must register or how to answer one person's access request; this covers the batch cycle - the matching logic, exception handling, suppression, and per-request reporting you execute every 45 days.

By the end you can run one full cycle start to finish: pull the request batch, match it against every system using the required identifiers, purge or opt out each matched record, suppress re-entry, and report a determination for every request inside the mandated windows.

What the DROP cycle is and who runs it

The DROP cycle is a recurring batch job: a registered data broker accesses California's accessible deletion mechanism, downloads its selected hashed consumer deletion lists, matches them against its own records, acts on every match, and reports a status for each request. Beginning August 1, 2026, a broker must do this at least once every 45 days under the Delete Act (Cal. Civ. Code 1798.99.86(c)).

DROP stands for the Delete Request and Opt-out Platform, the single mechanism California built so a consumer can ask every registered data broker to delete their data with one request. The consumer-facing side went live January 1, 2026. The broker-facing processing obligation starts August 1, 2026.

The job spans three owners. Compliance or legal owns registration, exemption determinations, and reporting. Data engineering owns retrieval, standardization, hashing, and matching. Both own the purge, because deletion decisions are legal and the execution is technical. One person cannot run this cycle alone, and the handoffs between those owners are where cycles slip.

The penalty structure is what makes the cadence non-negotiable. The fine is $200 for each deletion request for each day you fail to delete the information. It compounds per request, so liability scales with batch size, not with a flat per-violation cap.

The statutory clock: 45 days now, 30 days soon

Two load-bearing windows govern the cycle: how often you must access DROP, and how fast you must process a verified deletion once retrieved. Both are 45 days today and both drop to 30 days on January 1, 2027 under AB 883.

Here is the clock as it stands and as it changes. Build your scheduler to the current column now and plan the migration before the new year it takes effect.

There is a conflict in the secondary guidance you should know about before it bites you. Some practitioner pages state that determinations must be completed within 90 days of retrieval. That figure conflicts with the 45-day statutory processing window, and I treat it as unverified. Process within 45 days of retrieval, and treat any 90-day guidance as something to confirm against the regulation text before you rely on it. Running to the shorter window is always safe; running to the longer one on bad authority accrues $200 per request per day if it is wrong.

The registration side has its own calendar. Register between January 1 and 31 each year and pay the fee, which rose from $400 in 2024 to $6,600 in 2025. Independent audits begin January 1, 2028 on a three-year cycle, so the logs you keep from the first cycle are the evidence an auditor reads later.

The matching procedure and the identifiers that drive it

DROP publishes consumer deletion lists as hashed identifiers. You standardize your own records to the same rules, hash them with the same algorithm, and compare. The algorithm is SHA-256 followed by base64, and DROP specifies which algorithm produced each list so there is no ambiguity.

Standardization is the step that silently decides your match rate. The rules address date of birth, zip code, phone numbers, email, names, and non-English characters, and they specify how to hash a record that carries multiple identifiers by concatenating them. A phone number is normalized to ten digits before hashing, so "(415) 555-1234" becomes "4155551234". Get the normalization wrong and you hash into a different space than DROP, producing false no-matches that leave live data accruing penalties.

The final rules require a 100% consumer identifier match for deletion to be required. The original 50% threshold was removed. This is a deliberate trade: regulators pulled the looser bar because hashed matching cannot distinguish namesakes, so a sub-100% match risks deleting someone who never asked. The stricter bar prevents collateral deletion at the cost of more no-match records you must retain and re-check.

Every record on the list resolves to exactly one of four routes.

The shared-identifier route is the one most teams get wrong. If a single hashed identifier matches multiple consumers, you opt each of them out of the sale or sharing of their personal information rather than deleting. Deleting wholesale would purge people who never requested it. The no-match route is not a dead end either: you must retain the consumer deletion list solely to compare against newly collected personal information before that information is sold or shared.

Exceptions and the determinations you must log

You are not always required to delete. A broker need not delete where retention is reasonably necessary under CCPA section 1798.105(d), or where deletion is not required under sections 1798.145 or 1798.146. First-party data - personal information you collected directly from the consumer - is exempt. But inferences you drew from exempt data remain deletable, and that distinction is where audits turn.

The discipline is documentation. For every request you deny or exempt, log the determination and the specific statutory basis you invoked. Maintain detailed logs of requests and outcomes, implement reasonable identity-matching procedures, and document the exemptions. An "exempt" code with no recorded basis is an audit finding waiting to happen.

One rule catches teams off guard: where you deny a deletion because you cannot verify the request, you must still process it as an opt-out of the sale or sharing of that individual's personal information. An unverifiable request is never simply dropped. It becomes an opt-out, and you report it as opted out.

Run the cycle: the eight-step procedure

Run the cycle in this order every time. The first cycle is an engineering spike because the historical pull is large; subsequent cycles are incremental and far smaller.

A few operational notes on execution. The API lives at a production endpoint and a parallel sandbox, both authenticated with an X-API-KEY header; your key is scoped to the lists you selected, so only those lists appear in your downloads. The sandbox has been live since April 2026, which means you can diff your hashes against DROP test vectors before you ever touch production data. Do that. It is the cheapest way to catch standardization drift.

The retrieval volume tells you how to staff. The first cycle front-loads compute and match work; the email list alone runs to roughly 300,000 items. Subsequent incremental cycles include only new requests since the last download, so the engineering bench you need at go-live is larger than the steady-state bench.

How this goes wrong: failure modes and false positives

The failure modes below are the most valuable part of this runbook, because each produces a status report that looks clean while the underlying obligation is unmet. A passing report is not a done job. Treat these as the checks your cycle must survive.

Over-deletion from partial matches

A sub-100% match treated as a hit deletes a non-requester. The false positive looks like a clean "deleted" status for the wrong person. Enforce the 100% identifier match and sample-audit matched records against source identifiers before you commit a purge.

Shared-identifier collision

One hashed email tied to multiple consumers gets deleted wholesale instead of opted out. The false positive is a "deleted" status where the rule required "opted out," and you have purged people who never requested it. Route every multi-match identifier to opt-out logic, and verify the counts: matches flagged as multi-consumer should never resolve to a delete code.

Standardization drift

Un-normalized phone, DOB, or non-English characters produce false no-matches, leaving data live and accruing $200 per request per day. The record silently fails to match because your hash lands in a different space than DROP's. Diff your hashes against DROP test vectors in the sandbox before every production cycle, not just at go-live.

Repopulation after purge

A nightly vendor refresh reintroduces a deleted consumer. The false positive is a passing report while the record quietly returns through ingestion. Suppression must gate ingestion, not just storage - if your suppression list only cleans the database and does not block intake, the next refresh undoes the cycle.

Vendor gap

You delete internally but never instruct contractors, so the record survives downstream. Under the Delete Act you must direct service providers and contractors to comply with the delete request. Confirm service-provider deletion acknowledgements every cycle and log them; an unacknowledged instruction is an open obligation.

First-party over-exemption

Mislabeling third-party data as first-party to dodge deletion. The false positive is an "exempt" code an audit reverses. Remember that inferences drawn from exempt data are still deletable, and log the specific statutory basis for every exemption so the determination is defensible.

Determination-window confusion

Treating 90 days as the deadline when the statutory processing window is 45 days. Process within 45 days and treat 90-day guidance as unverified until confirmed against regulation text.

The lesson across all seven is the same: the status file passing does not mean the cycle is correct. Over-deletion, shared-identifier collisions, and repopulation all report clean. Your controls have to catch them before the report, not after.

A passing status file is not a finished job; the dangerous errors are the ones that report clean.

Suppression: the recurring cost after the first purge

Suppression is the lasting burden, not deletion. After you honor a deletion, you must maintain internal suppression systems so the individual's information is not re-collected or repopulated without a new lawful basis, and you must keep deleting newly acquired data each cycle. Deletion is a one-time act per request; suppression runs forever.

The mechanism behind reappearing "deleted" records is almost always an ingestion pipeline that does not consult the suppression list. You clear the record, a vendor feed or scraper reintroduces it, and your next cycle either re-deletes it (wasted work) or misses it (a live record you reported deleted). Put the suppression check at the ingestion boundary so a purged identifier never enters storage in the first place.

This is also where the penalty math gets unforgiving. Because the fine is $200 per request per day, a broker that lets a large queue sit faces liability that scales with batch size. An email list of roughly 300,000 items makes even brief delay financially severe. Suppression failures do not announce themselves, so they are the cheapest place to accrue silent liability.

The early enforcement record shows how fast per-day penalties compound, even though these settlements were for failure to register rather than failure to process. The arithmetic is identical.

Five early settlements totaled $226,400, all for failure to register, all at $200 per day. SB 361 extended that same daily rate to failures to process consumer deletion requests. The settlements above are a preview of what a missed processing cycle looks like once enforcement turns to the batch job this runbook covers.

Staffing the cycle and keeping it current

The cycle is a recurring obligation, so the real constraint is a thin bench of people who can run it. In Refolk's index there are only 260 US privacy-manager-level professionals and 238 senior US privacy leaders at the CPO, DPO, and VP tier. That is a small pool to staff recurring 45-day cycles - soon 30-day - across 495-plus registered brokers.

The ratio is the signal: the US privacy-manager pool is only 1.73 times the UK's, even though the US regulated base is far larger and growing with each new state mandate. That thinness is why the first cycle is often where teams realize they are under-resourced. When you need to add a practitioner who has already built a CCPA or Delete Act deletion workflow, or a data engineer with identity-resolution and SHA-256 matching experience, naming the exact pool matters. Refolk turns that request into a named shortlist instead of a keyword search across job boards, which is the difference between staffing a cycle on time and missing a window.

Before you call any cycle done, run this check. It maps one-to-one to the failure modes above.

To keep this runbook current, re-check two things on a calendar. First, the AB 883 migration: the access, processing, and recurring windows all compress from 45 to 30 days on January 1, 2027, so your scheduler and your staffing must change before then. Second, the 90-day determination question: if the regulation text is amended to confirm or reject that window, update your processing deadline accordingly. Until it is confirmed, run to 45 days. The mechanism for staying current is the same discipline the cycle itself demands - verify against the source, log what you found, and do not rely on a number you cannot trace.

Here is a status-file template to standardize how your team records each determination before upload.

request_id, matched_identifier_count, determination, status_code, statutory_basis, vendor_instructed, suppression_added, cycle_date
R-00017, 1, full match deletion, deleted, n/a, yes, yes, 2026-08-15
R-00018, 3, shared identifier, opted out, n/a, yes, yes, 2026-08-15
R-00019, 0, no identifier match, not found, retain-and-recheck, n/a, n/a, 2026-08-15
R-00020, 1, retention necessary, exempt, CCPA 1798.105(d), n/a, n/a, 2026-08-15
R-00021, 1, could not verify, opted out, unverifiable request, yes, yes, 2026-08-15