The 45-day DROP cycle, operationally
DROP (the Delete Request and Opt-out Platform) is the state’s matching system for California’s Delete Act. It has been live for registered data brokers since August 1, 2026. Under Civil Code §1798.99.86(c), a registered broker must access DROP and delete every matching consumer’s data at least every 45 days. That’s not a one-time project; it’s a recurring operational cycle for as long as the broker holds the kind of data DROP covers.
The loop
Each cycle runs through the same seven steps, in the same order:
- Pull. Download the current deletion/opt-out lists (through the manual portal at databroker.drop.privacy.ca.gov or through the API; sandbox live since April 2026 at api.drop.privacy.ca.gov/sandbox, per the DROP Technical & API Reference v1.1.0) at least every 45 days.
- Standardize. Format the broker’s own identifiers to match the state’s rules for whichever of the six lists apply (see the six DROP hash lists, explained).
- Hash. Run the standardized values through SHA-256.
- Compare. Match the broker’s hashes against the state’s list for exact equality: no fuzzy or partial matching (11 CCR §7613).
- Act. Delete the records that match. Where a written, counsel-approved exemption policy applies (grounds drawn from CCPA §1798.105(d) and §§1798.145-.146, such as security, fraud prevention, legal compliance, or federal-law conformity), apply it and report accordingly. Where a single identifier corresponds to more than one person and the match can’t be resolved to one consumer, that record gets treated as opted out rather than deleted outright.
- Direct downstream. Send the required deletion directive to downstream vendors, on the broker’s own letterhead, and archive proof that it went out. The evidence a broker needs is the sent directive itself. The scope stops there; it doesn’t extend to policing what each vendor’s own systems do next.
- Report. Upload File 2 with a status code for every record the cycle touched: 2 for exempted, 3 for deleted, 4 for opted out, 5 for not found.
Then it starts again. The state’s download (File 1) arrives as one CSV per subscribed list, header Id,Hash; the status upload (File 2) carries header Id,Status. The shared Id field is what keeps a cycle’s download and its status upload paired to each other rather than drifting apart. After a broker’s first complete pull-and-report cycle, later downloads turn incremental (new identifiers only), plus a separate Removed file (Id,Hash,ListType) whenever a consumer cancels their own request.
Operationally, the sequence that keeps cycles from tangling is report, then pull: close out File 2 for the cycle in hand before pulling the next download. It’s a small discipline, and it’s the one that keeps a broker from matching this cycle’s pull against last cycle’s unfinished status file.
Book a 20-minute call if it’s not clear yet how much of this a given system already covers.
Suppression doesn’t end
Under §1798.99.86(d), suppression is perpetual. Once a consumer’s data has been deleted, the broker has to keep deleting any newly acquired data on that same consumer at least every 45 days, indefinitely, and can never sell or share new data about them again. The deletion list only grows from here: every cycle adds names, and none of them come back off.
What’s worth keeping
The 2028 audits (§1798.99.86(e); see the 2028 Delete Act audit guide) read whatever records exist by then, not records assembled afterward. Worth keeping from every cycle: the download timestamp, the files pulled and uploaded, match and record counts, the status assigned to each record, and upload receipts. Six years is the retention window the audits will expect records to reach back across. None of that can be reconstructed after the fact. A cycle run without a record of it is a cycle that, for evidence purposes, didn’t happen.
Common questions
How often does DROP actually need to run?
At least every 45 days. Civil Code §1798.99.86(c) sets the access-and-delete cadence at 45 days; there's no compliant version of the cycle that runs less often. Running it more often is allowed. It just doesn't buy any relief from the 45-day floor.
What if a broker doesn't hold any of the six listed data types?
A broker still has to pick at least one list and report. The documented path for a broker holding none of the listed data is to select at least one list anyway and return status 5 (not found) across the records reported. Silence isn't a reporting option.
What happens if the API is down during a cycle?
The manual portal at databroker.drop.privacy.ca.gov is the required fallback when API automation fails. Under §7612(b), that fallback comes with a written-notice requirement: notice to CalPrivacy through the DROP account, within 45 days. A 45-day deadline doesn't move because a script did.