DROP status codes explained: 2, 3, 4, 5
Every line in the response file you upload to DROP gets exactly one status code — 2, 3, 4 or 5. This is a working reference for the people who actually build that file: what each code means, a worked example for each one, how the Id,Status CSV and file name need to be shaped, and how to correct a code after you've already submitted it.
The four status codes, exactly as DROP defines them
CalPrivacy's technical reference ties each response line to one of four numeric codes. There is no 0 or 1 — the list starts at 2, which trips up anyone who assumes the file is zero-indexed:
| Code | Label | Official meaning |
|---|---|---|
2 | Exempted | Match found and personal information is exempt. |
3 | Deleted | Match found and non-exempt personal information was deleted. |
4 | Opted out | Multiple consumers are linked to the same identifier and all were opted out of sale or sharing. |
5 | Not found | No match found after completing the matching process. |
Source: privacy.ca.gov's DROP technical reference. If you need the broader context for how these fit into the 45-day cycle, see California DROP program requirements; this page stays narrowly on the codes themselves.
Picking the right code for a real match
The four codes aren't a menu you choose from freely — each one maps to a specific outcome of the matching step, and getting it wrong misreports what actually happened to that consumer's data.
Code 3 — Deleted
The default outcome for a clean match. You standardized and hashed your own record, it matched an identifier on the list, nothing about that record is legally exempt, and you deleted it. This is the code you'll use most often on a healthy list.
Code 2 — Exempted
You found the same match, but some or all of that record falls under a CCPA exemption (for example, information you're required to retain for a legal obligation). Code 2 still requires a match — if there was no match at all, that's code 5, not 2. Keep a note of which exemption applied; that's the first thing an auditor asks about.
Code 4 — Opted out
This is the code for shared identifiers, not a general-purpose "partial match" bucket. If a phone number, address, or other identifier resolves to more than one consumer in your records — a shared household line is the common case — you can't selectively delete one person's share of it without touching the others. Instead you opt everyone tied to that identifier out of sale and sharing, and report code 4 for the request.
Code 5 — Not found
You ran the full standardize-hash-match process against every list you pulled and nothing matched. Report 5 rather than skipping the line — every Id in the list needs a status, including the ones you don't have data for.
Building the response file
The response file is a two-column CSV, Id,Status, mirroring the request list you downloaded but with a status code added to every row. File names follow a fixed pattern:
| Part | Example |
|---|---|
<YYYYMMDD> | 20260901 — the date you're submitting |
<DataBrokerId> | your registered broker ID |
<DataType> | the list type you're responding to, e.g. NDZ, MAID, VIN |
[_<OptionalSuffix>] | used for amendments — see below |
Full pattern: <YYYYMMDD>_<DataBrokerId>_<DataType>[_<OptionalSuffix>].csv. Composite list types — NDZ (name + date of birth + ZIP) and NameVIN (name + VIN) — use a composite hash: each field is hashed individually first, the hashes are concatenated, then that concatenation is hashed again. Matching against a composite list means reproducing that exact two-step hash, not just hashing the combined fields once.
New upload vs. amend — correcting a code after the fact
DROP's API exposes two separate upload operations: a new-upload endpoint for your first response to a given list, and a separate amend-upload endpoint for correcting rows you already submitted. If you catch a misreported code — say you sent 5 for a row that should have been 3 — don't just re-upload the same file name; use the amend path and the optional suffix in the file name so CalPrivacy's system can tell it's a correction to an existing submission, not a duplicate.
A status code doesn't close the file
Reporting a code is not the end of your obligation to that identifier. The Delete Act requires you to keep every DROP identifier you've ever processed on a permanent suppression list and screen new data you acquire against it going forward — so if you re-acquire a match for someone you already reported deleted, you delete it again rather than waiting for the identifier to reappear on a future DROP list. Treat every code you report as the start of a standing instruction, not a closed ticket.
Drop45 assigns the status code for you. Upload a DROP list and your own records; matching runs in your browser and Pro exports a ready-to-upload Id,Status file with 2/3/4 assigned and 5 auto-filled for every unmatched row.
Frequently asked questions
Can I report code 2 without a match?
No. Code 2 (Exempted) requires that a match was found — it's an exemption from deleting matched data, not a substitute for "not found." A row with no match is always code 5.
What if only part of a matched record is exempt?
Report code 2 for that row and delete whatever portion isn't covered by the exemption. The code describes the outcome for that identifier, not a claim that every field was untouched.
Does a shared identifier ever get deleted instead of opted out?
If an identifier is genuinely tied to only one consumer, delete it and report code 3. Code 4 is specifically for identifiers your matching process shows are linked to more than one person.
Where's the authoritative source for these codes?
CalPrivacy's own technical specification: privacy.ca.gov/drop-for-data-brokers/technical-specifications. This page summarizes it for the response-file step specifically; the spec is the source of truth if the two ever diverge.