DROP Suppression Lists: What Data Brokers Must Keep
A DROP deletion request doesn't end when you report a status. California data brokers are also expected to keep a standing record of who has asked to be deleted — a suppression list — and check new records against it going forward. Here's what actually has to be on it, what doesn't, and how to build one without turning it into its own privacy liability.
The duty hiding inside one checklist item
If you've read our DROP overview, you've seen the 45-day cycle: download, standardize, match, report a status. The last item on that checklist — "add every requesting consumer to your ongoing suppression list" — looks like housekeeping. It isn't. CalPrivacy's own guidance on processing DROP requests says brokers must maintain identifiers from deletion requests and compare them "against any newly collected records before new personal information is sold or shared" (privacy.ca.gov/drop-for-data-brokers/process-drop-requests/). The data broker rules add detail on broker-specific obligations (Cal. Code Regs., tit. 11 § 7616).
In other words: a DROP deletion request is not a one-time cleanup job. It's a standing instruction that has to survive every future data acquisition you make — a new list purchase, a new lead source, a re-scrape of a public record — for as long as you operate as a data broker.
It's not just your "not found" pile
The instinct is to treat the suppression list as a home for the records DROP couldn't match — the ones marked "not found," where you don't have enough confidence to say you've already handled them. That's half right, but too narrow. A consumer whose record you did match and delete, opted out, or logged as exempt still needs to be on the list, for a simple reason: today's deletion doesn't stop tomorrow's data source from handing you the same person again under a different record. If they're not in your suppression set, you'll onboard them as if they never asked to be removed at all.
So the practical rule is: every identifier that came through a DROP list you downloaded — matched or not, deleted, opted out, exempted, or not found — goes into the suppression set. What differs is what you're allowed to do with a re-match later (an exempted match may still be usable for the reason it was exempt; a deleted or opted-out match generally shouldn't resurface at all).
The status codes, by number
If you're building or reviewing an upload file yourself rather than relying on a vendor, it helps to know DROP's response file uses numeric status codes, not just the plain-English labels most guides quote:
| Code | Status | Meaning |
|---|---|---|
| 2 | Exempted | Match found; the personal information is exempt from deletion. |
| 3 | Deleted | Match found; non-exempt personal information was deleted. |
| 4 | Opted out | Multiple consumers shared the identifier; all were opted out of sale and sharing. |
| 5 | Not found | No match after completing the matching process. |
Codes 0 and 1 aren't used. All four outcomes are suppression-list candidates — the code just tells you (and, if you're ever audited, CalPrivacy) which handling rule applied to that identifier.
What to actually store — and what not to
You don't need to keep DROP's own hashed identifiers verbatim, and you shouldn't keep more than you need. CalPrivacy's guidance is explicit that brokers can use their own internal identifiers and formats for the suppression list, provided the record still lets you recognize a match later, and that brokers should "retain only the minimum data necessary to maintain your compliance obligations" — data that "may not be used for any other purpose."
In practice that means:
- Keep: the hashed or standardized identifier(s) that matched (email, phone, or the NDZ/name-VIN composite you matched on), the DROP list ID, the status code, and the date you reported it.
- Don't keep: the consumer's full unhashed profile, unrelated fields from your original record (purchase history, address, device data) or anything beyond what you need to recognize the same person if they show up again.
- Don't repurpose it: a suppression list exists to block re-collection, not to build a marketing exclusion list, a fraud model, or anything else. Using it for a second purpose undercuts the "minimum necessary" basis for holding it at all.
When to actually run the screen
The 45-day DROP cycle governs when you pull new deletion requests, not when you're allowed to check the suppression list. The screening obligation is tied to your own data flow: any time you're about to sell or share newly collected personal information, that batch needs to pass through the suppression check first. For most brokers that means folding the comparison into whatever pipeline already standardizes and dedupes incoming records, rather than running it as a separate manual step once a month and a half.
A minimal way to build one
You don't need an enterprise data-governance platform for this. A workable version is a single table or CSV with four columns — hashed identifier, list type, status code, date — appended to every time you finish a DROP cycle, plus a lookup step (exact match on the hash, no fuzzy logic needed since you're comparing like-for-like standardized values) that runs before any new record is sold or shared. Keep a short log of when you ran the screen and how many records it touched; that log is your evidence trail if CalPrivacy ever asks how the ongoing duty is being met.
Drop45 Pro exports a ready-to-store suppression list alongside your Id,Status response file every time you run a match, so you're not building the bookkeeping layer by hand. The matching itself stays free — SHA-256 hashing runs in your browser, so consumer data never leaves your machine.
Mistakes worth avoiding
- Treating each cycle as disconnected from the last. The suppression list is cumulative across every DROP cycle you've ever run, not a per-cycle scratch file you discard.
- Only logging "not found." As above — deleted, opted-out and exempted matches belong on the list too.
- Over-collecting "just in case." Storing full consumer profiles in the name of compliance is itself a data-minimization problem.
- Skipping the screen between cycles. Waiting until the next 45-day download to re-check new records means you can resell a deleted consumer's data for weeks before you'd catch it.