California's Delete Act Is Now an Engineering Problem
By Jim McGowen
Since August 1, every registered California data broker has been on a clock. The Delete Request and Opt-out Platform, DROP, requires every broker on the state's registry, more than 660 of them, to pull the consumer deletion lists at least once every 45 days, act on them, and report back. More than 560,000 Californians have signed up as of mid-October 2026.
Here's what you need to know to run a cycle, as the regulation and the state's technical specification define it.
What is a cycle?
A cycle starts when you download. You pull a ZIP with one CSV per list you have selected (email, phone, mobile ad ID, connected TV ID, and two composites: name plus date of birth plus ZIP, and name plus VIN). After your first pull, each download contains only requests received since your last one.
The lists contain hashes, not values. There is no option to download a consumer's actual email address. To match, you standardize each of your own records exactly the way the state does, hash it with SHA-256, Base64-encode the digest, and compare strings. On a match you delete the record, or opt it out of sale where the statute allows that instead, and direct your service providers and contractors to do the same.
Then you report. You upload a status for every request from the previous download: deleted, opted out, exempted, or not found. The upload is not complete until every record has a status. Statuses for the previous list are due before you download the next one, and that download starts the next 45 days.
The gotchas
The state publishes its standardization rules with worked examples, and the examples are worth running before your first real match. Each of the following produces a hash that will never match, which means a "not found" on a consumer you are in fact holding.
Email. The rule is lowercase and strip whitespace, nothing else. Engineers who have built identity systems reflexively apply Gmail-style normalization, dropping dots or a "+tag". The spec says not to, and the resulting hash is different.
Phone. Strip non-digits and keep the last ten. Keeping the country code, as most CRM exports do, breaks the match for every number.
Advertising IDs. Mobile ad IDs are hashed with the hyphens removed and in lowercase. Hash the UUID form your SDK gives you and you match nothing.
VINs. Conventionally written in capitals. The spec wants lowercase. This is the step most often skipped because it looks wrong.
ZIP codes. Drop the +4, drop leading zeros, take five characters. The spec's own example turns 00300 into 300. Most address tables store the zeros.
Names. Lowercase, then remove hyphens, apostrophes, spaces and punctuation, and flatten accents to plain ASCII: O'Brien is obrien, Juan Pablo is juanpablo, ß becomes ss. Greek and Cyrillic are transliterated by the spec's own mapping; Chinese, Japanese, Korean, Arabic and Hebrew are left as they are. First and last name are hashed as separate fields.
Dates of birth. YYYYMMDD, four-digit year, nothing else. July 4, 1985 is 19850704.
Composites. For name-plus-DOB-plus-ZIP, each field is hashed separately, the four Base64 strings are concatenated in a fixed order with their "=" padding, and that string is hashed again. Concatenate the raw values instead, or strip the padding, and the final hash is wrong.
Padding on the state's side. The spec's own CSV examples show the same hash once with its trailing "=" and once without. Compare with padding normalized or a real match can fail on a single character.
It's important to test your solution against the state's examples with every cycle. The specification carries a version number, 1.2.0 as of July 2026, and the rules can change with it.
Keep a record
The regulation lets you ask the state for a complete re-download when you need one for reconciliation or audit, and independent audits of the process begin in 2028. The practical minimum to keep from each cycle: the date and time of each download, which lists you selected, the specification version you hashed against and the version of your own hashing code, the match counts, and a copy of the status file you uploaded and the state's Upload Processed notice for it. That is enough to show what you did and to reproduce it later.
You set the clock
Nothing in the regulation gives a state-wide calendar beyond the August 1 start. Your deadline is 45 calendar days from your own last download, so two brokers that started a week apart are on different schedules. You keep that schedule yourself.
Jim McGowen, founder of DropClerk