Deleted or exempted: the broker decides

When you close a DROP cycle you upload a file with two columns: Id and Status. The Id is the work item ID the platform gave you. The Status is a single digit, and there are four of them.

Most rows are 5. Of the rows that actually match your data, almost all will be 3. The interesting one, and the one this page is about, is 2.

What an exemption is

The Delete Act, SB 362, sits on top of the CCPA rather than replacing it. The obligation it creates is to act on a consumer's deletion request, and the CCPA's existing framework is what decides whether a particular record has to be deleted at all. Where another obligation requires you to keep a record, the deletion obligation gives way. That is an exemption.

The common shapes are familiar to anyone who has handled a deletion request before: a record held under a litigation hold, a record another statute requires you to retain for a stated period, or data that falls outside the scope of the request in the first place. What matters here is not the list of shapes, it is who decides which shape a given row is.

This page describes how the two status codes work. It is not legal advice, and no software product can tell you whether an exemption applies to a particular record of yours. That answer depends on facts only you and your counsel have.

The determination is yours, always

A status code is an assertion made by the data broker of record to a state agency. Code 3 asserts that you deleted something. Code 2 asserts that you did not, and that you had grounds. Both are statements about your own conduct and your own legal position, and a vendor is in no position to make either of them for you.

That is why DropDue does what it does and stops. The software standardizes, hashes, matches, and hands you a worklist with counts. Every row arrives with no status code set. There is no default, no suggested value, and no heuristic that guesses 3 because 3 is usually right. A person picks the status, a person confirms the counted set, and the confirmation is written to the audit log with a name and a timestamp before anything is built or uploaded.

The word for that is a confirm gate, and it is deliberate friction. The button carries the number, so it says how many determinations you are about to confirm rather than an abstract "confirm". You are the one clicking, and the record says so.

The determination disclaimer, verbatim from the product: you pick the status for every match. We file exactly what you pick and log who picked it. We never choose for you.

Why no default is ever applied

A default would be convenient. It would also be the single most dangerous feature the product could ship, for three reasons.

• A default is an assertion nobody made. If a row goes out as 3 because it was pre-selected, then the statement "we deleted this" was authored by a settings screen. If it turns out the record was not deleted, there is no person behind the claim.
• A default erodes review. People confirm what is already filled in. The value of the confirm gate is that it forces the determination to be looked at once, and pre-filling it removes exactly that.
• A default makes the vendor the decision-maker. The moment software chooses between 2 and 3 it is exercising judgment about your legal position. That reclassifies the relationship, and it is the wrong shape for both parties.

So status_code starts as null in the data model, and submitting a null is treated as an error rather than quietly resolved. That is not a UI preference, it is a rule the code enforces.

Exemptions carry a reason. It stays with you.

There is a useful asymmetry between the two codes. Marking a row 3 needs no explanation, because the row itself is the whole story: you deleted it. Marking a row 2 says you kept data a consumer asked you to delete, and that is the row somebody will one day ask about.

So an exempted row requires a reason to be entered before it can be confirmed. The reason is short, free text, written by the person making the determination, and stored against the row in the audit log alongside who wrote it and when.

Here is the part worth being precise about: that reason is never sent to the state. The status file DROP accepts has exactly two columns, Id and Status. There is no field for a reason, so there is nowhere for it to go even if you wanted it to. In DropDue the exclusion is enforced by an explicit column allowlist in the file builder, with a test asserting the CSV header is exactly Id,Status. The builder reads two named properties off a decision row and writes those, so the rest of the record cannot reach the bytes by accident.

The reason exists for you, and for whoever reviews your record later. Six months after a cycle closes, "exempted" on its own tells you nothing. "Retained under a litigation hold opened 12 March, per counsel" tells you everything. That is the difference between having an audit trail and having a row of digits.

Practical guidance for running the worklist

• Decide your exemption categories before the cycle opens, with counsel, and write them down. Deciding row by row under time pressure on day 43 is how inconsistent determinations happen.
• Batch by category rather than by row where the facts genuinely are identical, but make the batch an explicit choice, and record the same reason against every row in it.
• Keep the reason specific enough to be re-read. Name the hold, the statute, or the retention schedule. "Legal" is not a reason.
• Treat an unusually high exempted count as a prompt to check your own logic, not as a result. A large jump between cycles usually means a category was applied too broadly.
• Re-check standing exemptions each cycle. A litigation hold that closed does not stop applying itself.

None of this is complicated. It is just work that has to be owned by a person who can answer for it. Software can make that work fast, keep it consistent, and record it honestly, and stop there. Where the codes sit inside the wider sequence is covered in the 45-day cycle.