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

*You can run one full DROP cycle end to end - pull the batch, match, purge or opt out, suppress re-entry, and report a determination for every request inside the mandated windows.*

- Canonical URL: https://www.refolk.ai/guides/drop-deletion-cycle-runbook
- Pillar: Process, data, and compliance
- Format: Playbook
- Published: 2026-10-12
- Last reviewed: 2026-10-12
- Reading time: 16 min
- Keywords: how to process DROP deletion requests, delete act 45 day deletion cycle, match consumer deletion request to records, suppress deleted records from reappearing, data broker deletion workflow, report deletion determination DROP

## Key takeaways

- Beginning August 1, 2026 a registered data broker must access DROP at least once every 45 days, match, act, and report; AB 883 cuts that window to 30 days effective January 1, 2027.
- The final rules require a 100% consumer identifier match for deletion to be required; the original 50% threshold was removed precisely because hashed matching cannot tell namesakes apart.
- The penalty is $200 per deletion request per day, and it compounds per request, so a delayed email list of roughly 300,000 items becomes financially severe within days.
- When a single hashed identifier maps to multiple consumers, the rule is opt all of them out of sale or sharing, not delete wholesale.
- Suppression, not deletion, is the recurring cost: brokers must block repopulation and re-delete newly acquired data every cycle against live ingestion pipelines.
- In Refolk's index there are only 260 US privacy-manager-level and 238 senior privacy professionals, a thin bench to staff recurring cycles across 495-plus registered brokers.

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.

**$200 - Fine per deletion request, per day of non-compliance**

SB 361 doubled it from $100 and extended it to cover failures to process requests, not just failure to register.

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.

| Window | Current (from Aug 1, 2026) | AB 883 (from Jan 1, 2027) |
|---|---|---|
| DROP access interval | 45 days | 30 days |
| Process verified deletion | 45 days | 30 days |
| Recurring re-deletion | 45 days | 30 days |

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.

> **Watch out:** Do not run to the 90-day number
>
> Some summaries cite a 90-day determination deadline that conflicts with the 45-day statutory processing window. Process within 45 days. Treat 90 days as unverified until you confirm it against the regulation text yourself.

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.

#### Classifying one deletion-list record

1. **Full identifier match** - One consumer matches on 100% of identifiers, route to delete
2. **Shared-identifier match** - One identifier maps to multiple consumers, route to opt-out for all
3. **No match** - Keep the record, retain the list, re-check before any future sale or share
4. **Unverifiable request** - Cannot verify identity, process as opt-out of sale or sharing

*Every hashed record resolves to one of four routes before you act on it.*

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.

> **Rule:** The threshold is 100%, with no exceptions
>
> Delete only on a full consumer identifier match. Anything below 100% routes to retain-and-recheck, and any identifier shared across consumers routes to opt-out. Treating a partial match as a hit deletes the wrong person.

## 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.

| Determination | When it applies | Status code to report |
|---|---|---|
| Deleted | 100% identifier match, no exemption | deleted |
| Opted out | Shared identifier, or unverifiable request | opted out |
| Exempt | Retention necessary under 1798.105(d), 145, 146, or first-party data | exempt |
| Not found | No identifier match | not found |

I ran this search: `Privacy compliance managers in California who have built or run CCPA/Delete Act deletion workflows` - [see the full result list](https://www.refolk.ai/s/s5jqwr7tsx).

*Returns named practitioners who have run exactly this cycle, so you can staff the determination and documentation work rather than improvise it.*

## 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.

#### One full DROP cycle, start to finish

1. **Confirm account and select lists** - Register during Jan 1-31, pay the fee, create a DROP account, and select the deletion lists matching your identifiers. Update selections before your next access if collection practices expand.
2. **Retrieve the batch** - Pull the hashed lists via the DROP Data Broker API or manual download at least every 45 days. The first pull is the full historical set; later pulls are incremental.
3. **Standardize and hash your records** - Apply DROP standardization rules to DOB, zip, phone, email, names, and non-English characters, then hash with SHA-256 and base64. Concatenate multi-identifier records.
4. **Match** - Require a 100% identifier match for deletion. Route multi-consumer identifiers to opt-out, and route no-matches to retain-and-recheck.
5. **Purge or opt out** - Within 45 days of retrieval, delete all personal information per matched identifier including inferences, direct service providers and contractors to delete, and opt out shared-identifier consumers.
6. **Suppress re-entry** - Maintain suppression lists that gate ingestion so purged people do not repopulate, and keep deleting newly acquired data each cycle.
7. **Report determinations** - At the next access session, upload an Id,Status file using standardized codes for deleted, opted out, exempt, or not found.
8. **Document and retain** - Log each determination and the specific exemption invoked, audit-ready for the three-year audits beginning Jan 1, 2028.

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.

**1.3M - Work items in the first full historical download if all six lists are selected**

Roughly 60 to 70MB. Incremental cycles after the first are far smaller, so staffing peaks at go-live then falls.

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.

#### Where a false positive hides in your status report

Horizontal axis runs from Reports a wrong code to Reports a clean code. Vertical axis runs from Caught by the status file to Hidden behind a passing report.

| Quadrant | What it means |
| --- | --- |
| Visible mismatch | Fix the code mapping before upload |
| Silent repopulation | Gate ingestion with suppression, re-audit each cycle |
| Rejected status file | DROP flags it, correct and re-upload |
| Reversible exemption | Log the statutory basis so an audit cannot overturn it |

*The dangerous errors are the ones that report clean while the obligation is unmet.*

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.

| Broker | Fine | Days late / period |
|---|---|---|
| Background Alert | $50,000 | 250 days |
| KMA | $55,800 | Feb 1 - Nov 5, 2024 |
| Infillion (PayDae) | $54,200 | Feb 1 - Nov 4, 2024 |
| The Data Group | $46,600 | Feb 1 - Sep 20, 2024 |
| NPD (proposed) | $46,000 | 230 days |

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.

| Segment | Count | Note |
|---|---|---|
| US privacy managers | 260 | Top employers include Meta, Bank of America, PwC, IBM |
| UK privacy managers | 150 | US pool is 1.73x the UK's, despite a far larger regulated base |
| US senior privacy leaders (CPO/DPO/VP) | 238 | 0.92 senior per manager, led by Chief Privacy Officer titles |

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.

#### Before you report the cycle complete

- [ ] Every matched deletion cleared the 100% identifier threshold, confirmed by sample audit
- [ ] Every multi-consumer identifier resolved to opt-out, not delete
- [ ] Hashes were diffed against DROP sandbox test vectors this cycle, not just at go-live
- [ ] Service providers and contractors acknowledged their deletions in writing
- [ ] Suppression list gates ingestion, and no purged identifier re-entered storage
- [ ] Every exemption logs a specific statutory basis, and no inference from exempt data was left undeleted
- [ ] The status file reports a code for every request from the prior session and DROP accepted it
- [ ] All determinations are logged and audit-ready for the three-year cycle beginning Jan 1, 2028

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.

**Per-request determination record (one row per request)**

```
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
```

*Keep this as your internal log; map the status column directly to the DROP upload codes.*

## Frequently asked questions

### How often do I have to process DROP deletion requests?

Beginning August 1, 2026, a registered data broker must access DROP at least once every 45 days, download its selected deletion lists, match, act, and report status. AB 883, signed September 27, 2026, shortens that interval to 30 days effective January 1, 2027, and it shortens the processing and recurring re-deletion windows with it. Build your schedule to the 45-day clock now and plan the migration to 30 days before the start of 2027.

### What identifier match threshold triggers a deletion?

The final rules require a 100% consumer identifier match for deletion to be required; the original 50% threshold was removed. Regulators pulled the looser bar because hashed matching cannot distinguish namesakes, so a partial match risks deleting a non-requester. Anything below a full identifier match routes to retain-and-recheck, not deletion, which is why standardization accuracy matters so much.

### What do I do when one hashed identifier matches multiple consumers?

Opt all of those consumers out of the sale or sharing of their personal information rather than deleting wholesale. A shared email or phone tied to several people cannot be safely purged as one deletion, because you would delete people who never requested it. Route every multi-match identifier to opt-out logic and record each as opted out in your status file, not deleted.

### What is the penalty for missing a DROP cycle?

The fine is $200 per deletion request for each day the broker fails to delete the information. SB 361 doubled it from $100 and extended penalties beyond registration failures to cover failures to process requests. Because it compounds per request, a delayed large batch scales fast: a single broker, NPD, faced a proposed $46,000 fine for registering 230 days late, which is 230 times $200.

### How do I report a determination for each request?

At every subsequent access session, upload an Id,Status file that reports the outcome of each request received in the prior session using the standardized codes: deleted, opted out, exempt, or not found. Use the DROP Data Broker API or the manual upload option. A request you could not verify is processed as an opt-out of sale or sharing and reported as opted out, not denied silently.

### Why do deleted records keep reappearing in my active data?

Because a nightly vendor refresh or ingestion pipeline reintroduces a purged consumer unless a suppression list gates the intake. Deletion alone clears current storage; it does not stop repopulation. Brokers must maintain internal suppression so a honored deletion is not re-collected without a new lawful basis, and they must keep deleting newly acquired data on cycle. Put suppression at the ingestion boundary, not just in the database.

---

*From the Refolk guide library. I revise these guides rather than replacing them, so the current version is always at https://www.refolk.ai/guides/drop-deletion-cycle-runbook*