The Delete Act suppression mandate: why a deletion is permanent
· 7 min read · Drop Privacy
Is a Delete Act deletion a one-time event?
No. Under the California Delete Act (SB 362), a consumer's deletion request through the DROP platform is a perpetual opt-out, not a one-time chore. Once you match and delete a consumer, you are legally required to keep them deleted — which means adding their identifier to a permanent suppression list and screening every future batch of data you acquire against it. A deletion you performed in March is not "done"; it is a standing instruction you must keep honoring cycle after cycle.
This is the single most misunderstood part of the law, and it is where a "we ran the deletion once" process quietly falls out of compliance.
The suppression list mandate
When you match a DROP identifier and delete the consumer's file, the CPPA rules require you to add that identifier to a permanent suppression list. From then on, every time you pull a fresh batch of records or scrape new information — which many brokers do daily or weekly — you must immediately check it against that suppression list.
If you accidentally re-acquire that same consumer's data from a third-party source, you cannot sell it or rebuild a profile from it. It must be automatically filtered out and deleted again. The suppression list is what turns a single deletion into an ongoing obligation, and it is why the identifier — a one-way SHA-256 hash, not the raw PII — has to be retained indefinitely even after the underlying record is gone.
The obligation is not "delete this record." It is "ensure this consumer never reappears in your saleable data." Those are very different engineering problems, and only the second one is compliant.
What happens when a consumer appears in two batches?
Because DROP processes requests in recurring cycles (you must access the DROP platform and process deletion requests at least once every 45 days), the same consumer can — and often will — appear in more than one batch. A match in the current batch that you already handled in a previous one is not an error and it is not something to skip. It is a validation check, and it still requires a response.
There are two scenarios, and both resolve to the same reporting action:
- Record already deleted and suppressed — the consumer's data was removed in a prior batch and is currently blocked from re-ingestion. You confirm it remains deleted and report the record as fulfilled / success.
- Record was reintroduced — the data was deleted last cycle but accidentally re-acquired or re-enriched through a third-party stream in the interim. You re-run the deletion across your entire database, update your suppression list, and again report fulfilled.
The key rule: never treat a duplicate match from a previous batch as noise. DROP has no "pending" or "already handled" status — if a hashed identifier appears in your current download, it must receive a corresponding status token reported back to the platform. The CPPA requires an affirmative signal for every record present in the current active batch before you can close out the cycle and access subsequent files.
Cumulative versus incremental — plan for cumulative
Do not assume each batch only contains brand-new requests. A consumer's request can remain active in the state's master ledger and be re-issued, so your process has to be idempotent: re-running a deletion for someone you already handled must never break, double-count, or stall the cycle. This is exactly why matching against your full request history — not just today's new identifiers — matters on every cycle. Drop Privacy does this with a cumulative request registry and a forward-suppression pass that screens newly-acquired leads against every identifier ever requested, so a consumer from an earlier batch stays suppressed on data you buy tomorrow.
Why "mostly deleted" compounds into real exposure
The penalties make the cost of a leaky suppression process concrete. Failing to register carries a statutory $200 per day penalty, but the far bigger risk is on the processing side: regulators can levy administrative fines of $200 per consumer, per day for failing to process deletion requests correctly and on time, on top of existing CCPA enforcement. That "per consumer" is the dangerous part — the meter runs separately for every unhandled request, every day it stays unhandled. A batch of just 10,000 requests left un-actioned past the processing window is $2,000,000 in exposure per day. And because the duty repeats every 45 days, a suppression process that lets deleted consumers quietly leak back in doesn't fail once — it re-accrues that liability cycle after cycle. We break the numbers down in California Delete Act penalties, and the CPPA is already issuing fines.
What a compliant suppression process actually requires
To honor the mandate reliably, every cycle you need to:
- Match the current DROP batch against your data, without moving consumer PII around — hash matching keeps identifiers one-way.
- Delete and suppress each match, adding its hashed identifier to a permanent list you keep forever.
- Screen every new acquisition against that list — on import, not just at cycle time — so re-acquired consumers never re-enter your saleable data.
- Answer every current-batch record with a status token, including repeat matches from prior cycles.
- Keep tamper-evident proof of every deletion and suppression, so you can show an auditor the loop actually ran.
How Drop Privacy handles the suppression mandate for you
The suppression mandate is where hand-rolled processes quietly break: a spreadsheet of "deleted" records doesn't screen tomorrow's data purchase, and a per-batch script has no memory of prior cycles. Drop Privacy is built around the fact that a deletion is permanent — it maps directly onto each of the five requirements above:
- A permanent, cumulative suppression list you never have to maintain. Every identifier ever requested through DROP is kept once in a deduped cumulative request registry. Because the entries are one-way SHA-256 hashes (non-PII, not the raw record), they can be retained indefinitely — which is exactly what a perpetual opt-out requires. You get the "keep them forever" list without hoarding any consumer personal information.
- Every new acquisition is screened automatically — on import, not just at cycle time. When you import or acquire new leads, Drop Privacy screens them against the entire request history, so a consumer deleted in an earlier batch is filtered out of data you buy tomorrow before it can ever be sold or re-profiled. A forward-suppression pass also runs on every cycle, and it is incremental (it only scans what's new since the last run), so it stays cheap even at hundreds of millions of records.
- Repeat matches are handled, never skipped. Drop Privacy answers every record present in the current batch with a status token through the DROP API — including a consumer who already appeared in a prior cycle — and if a suppressed consumer was accidentally re-acquired, it re-runs the deletion across your data and re-reports it. Cycles are idempotent and resumable, so re-processing someone you already handled never double-acts, breaks, or stalls the run.
- Matching happens without moving PII. It matches the DROP batch against a privacy-preserving hash index, so consumer PII never leaves your systems — and with the on-prem agent, only hashes, statuses, and audit metadata cross your boundary.
- You can prove the loop actually ran. Every deletion and suppression is recorded in a hash-chained, tamper-evident audit log, producing a printable proof-of-deletion attestation — the evidence an auditor will ask for once the 2028 audits begin.
In short: you delete a consumer once, and Drop Privacy makes sure they stay deleted — across every future batch and every new data source — without you having to remember, and without exposing PII to do it.
Sources
- California Delete Act (SB 362) — full statutory text, including the deletion, suppression, and penalty provisions (Civil Code §§ 1798.99.80–1798.99.89).
- California Privacy Protection Agency — Information for Data Brokers: registration, the DROP deletion mechanism, the 45-day processing cycle, and the third-party audit requirement that begins January 1, 2028.
Request a demo to see a repeat match handled end to end, from re-acquisition to automatic re-suppression.
See Drop Privacy run a full Delete Act cycle on sample data. Request a demo →