DROP Compliance for Small Data Brokers: The Operating Guide

Then it starts again. The state's download arrives as one CSV per subscribed list; the status upload carries a matching record ID. The discipline that keeps cycles from tangling into each other is report, then pull: close out the status file for the cycle in hand before pulling the next download.

Why does cycle 2 break what cycle 1 got away with?

Cycle 1 downloads a full list. Every cycle after that, the download turns incremental: new identifiers only, plus a separate file for consumers who canceled their own request. A cycle 1 process built to reload three fresh CSVs from a folder breaks the first time it meets an incremental file that has to be merged with everything already on file, rather than simply replacing it.

Suppression starts to bite at the same moment. Every person deleted in cycle 1 has to be checked again in cycle 2 and every cycle after, forever, even though that person no longer appears on the fresh download. Cycle 1 for most registered brokers landed around August 1, 2026; cycle 2 lands roughly six and a half weeks later, in mid-September. That's the point where an improvised, one-off process meets a workload it was never built to repeat.

Why can't NDZ matching catch every record, even done perfectly?

NDZ, the name-plus-date-of-birth-plus-ZIP composite, only produces a match when all four underlying fields (first name, last name, date of birth, ZIP) standardize and hash identically. Lead-gen and list-broker data commonly has no real date of birth on file. A record with a blank DOB field can't be checked against NDZ at all, no matter how well the rest of the pipeline runs. That's not a bug to fix. It's a structural limit in the underlying data, and it belongs in a broker's own documentation as a known gap, not absorbed silently into a routine "not found."

The opposite failure runs the other way: placeholder dates of birth. An older CRM or list-import process that doesn't have a real DOB will sometimes fill the field with a sentinel value, something like 01/01/1900, rather than leaving it blank. If that placeholder isn't screened out before matching, every record sharing it becomes a spurious match candidate on that one shared field. Missing DOB produces false negatives; a shared placeholder DOB can produce the opposite problem. Both need a check before they reach a live match run, not after.

How long do cycle records need to survive?

Six years. That's the retention window the Delete Act's audit provisions expect a broker's cycle records to reach back across, and records can be requested for production within five business days once that duty attaches. A defensible per-cycle record holds: the download timestamp and the files pulled and uploaded, match counts, the disposition assigned to each matched record, the vendor directives sent with proof they went out, and upload receipts confirming the status file was received. None of that can be reconstructed after the fact from memory or an old email thread; it has to be captured the cycle it happens. (For the fuller treatment of what an eventual audit will actually check, see the 2028 data-broker audit guide.)

What are the failure modes that quietly break a cycle?

• Partial hashing. A broker holding the same identifier, most often email, in several systems but only wiring the hash pipeline to one of them gets a clean match on the table it checked and a silent miss on every table it didn't. The output looks identical to a genuinely clean cycle.
• Standardization drift. A ZIP+4 left un-stripped, a phone number with a country code still attached, a name that wasn't lowercased: any of these turns a real match into a "not found," because matching is exact-hash, not fuzzy. There is no partial credit for a formatting error.
• Silent false negatives. Nothing in a cycle's output distinguishes a genuinely clean run from a broken pipeline quietly reporting "no matches" for the wrong reason. A cycle that suddenly returns zero matches after months of steady matching is a signal to check the pipeline, not a reason to relax.
• Multi-consumer collisions coded wrong. When one hash resolves to more than one person and can't be narrowed to a single consumer, the correct status is 4, opted out, for all of them, not a guess at deletion and not a pass as "not found."

Why doesn't the generic DROP advice fit a 3-to-40-person shop?

Most of what's published about DROP compliance is written for a firm with a privacy engineering team, an automated pipeline that runs itself, and in-house counsel a few desks away. A 3-to-40-person data broker usually has none of that. There's an owner or an operations lead wearing the compliance hat alongside three other jobs, outside counsel billing $400 or more an hour for advice rather than execution, customer data spread across a CRM, a warehouse export, an email service provider, and a handful of legacy tables nobody's fully mapped, and no automated pipeline unless someone deliberately builds or buys one.

That gap changes what "compliant" has to look like in practice. It's not about doing less of the work; every step above still applies in full. It's about the work needing to run without an engineering team behind it: identifier variants get inventoried by hand across every system a person can name, not discovered automatically; the hashing step has to be checked against the state's published worked examples rather than assumed correct because the code compiled; and the record of each cycle has to live somewhere a non-technical reviewer, an auditor, or a future buyer's due-diligence team can actually read it. The mechanics don't change with company size. What changes is who's available to run them, and how much of the process has to survive without a dedicated owner watching it full time.

What does this look like for a team without engineers?

Nothing above requires custom software to run honestly. A working version for a 3-to-40-person operation usually holds five things: a maintained inventory listing every system that holds a name, email, phone number, date of birth, or ZIP; one tracking sheet recording the cycle date, match count, and disposition per record ID; a dated folder per cycle holding the files pulled, the files uploaded, and the vendor directives sent; a recurring calendar reminder tied to the actual 45-day cadence rather than a rough "once a month"; and one named person who signs off that a given cycle actually ran.

That list is deliberately unglamorous. The gap most small brokers carry into their first audit isn't a missing capability. It's a missing habit, repeated eight times a year, starting from a cycle that already happened.