California’s DROP: 7 Brutal Reasons Most Dev Teams Will Fail It

TL;DR California switched on DROP, the Delete Request and Opt-out Platform, and since August 1, 2026 every registered data broker has to check it at least once every 45 calendar days, match hashed identifiers against its own records, delete what matches, and report back. Miss it and the fine is $200 per day, per request. Most engineering teams will fail this, and not because the rules are unclear. They will fail because DROP is a recurring data-engineering job wearing a legal costume, and nobody staffed it.

This sits inside our checklist for staying on the right side of privacy rules, which covers the wider compliance program this one obligation plugs into.

What is DROP, and who does it actually bind?

DROP is a state-run platform where a Californian files one deletion request and every registered data broker has to honor it. One form, 600-plus companies, no haggling. It was created by the Delete Act (SB 362, Chapter 709, Statutes of 2023), amended by SB 361 in 2025, and the implementing regulations took effect January 1, 2026.

The binding question is not whether you call yourself a data broker. California defines one in Civ. Code § 1798.99.80(c) as a business that knowingly collects and sells to third parties the personal information of consumers it has no direct relationship with. Read that twice. Plenty of AdTech vendors, lead-gen platforms, identity resolution shops, enrichment APIs and “audience” businesses land inside that sentence while their marketing site says “we’re a SaaS company.”

If you fit, you register with CalPrivacy every January 31, pay the $6,000 annual fee, and from August 1, 2026 you work the DROP cycle. CalPrivacy publishes the full obligation list, and it is short enough that nobody can claim surprise.

The 45-day clock most teams misread

Here is the part that trips people. The 45 days is not a grace period. It is a loop.

You download your consumer deletion lists from DROP. That download starts the clock. Within 45 calendar days you must standardize and hash your own records, match them, act on every match, report each request’s status back into DROP, and download the next list. CalPrivacy’s own worked example ends with “Day 45: Restart the cycle.” There is no idle state. The processing workflow is documented step by step, including what to do when the automated connection fails: you still have to retrieve your lists manually through your DROP account, and a written notice to CalPrivacy is filed in addition to that, only where the outage was not of your making.

So the real requirement is a scheduled job with a hard SLA, an audit trail, and a failure path that generates legal correspondence. Which is not what most teams hear when someone forwards them a privacy memo.

7 brutal reasons engineering teams fail DROP

1. They treat DROP as a project instead of a pipeline

A project ends. DROP does not. Eight cycles a year, forever, with a regulator watching. Teams that ship a one-time script and move on discover the gap at cycle three, when nobody owns the cron job and the person who wrote it has changed teams.

2. They underestimate the hashing spec

DROP never hands you raw identifiers. You get SHA-256 hashes, UTF-8 input, Base64 output, across six list types: a composite of first name, last name, date of birth and ZIP; a composite of first name, last name and VIN; plus standalone Email, Phone, MAID and CTVID. The technical specification prescribes normalization before you hash: names lowercased with accents folded to ASCII, Greek and Cyrillic transliterated using CalPrivacy’s own mapping, CJK and Arabic left alone, hyphens and apostrophes stripped, ZIP codes cut to five characters with leading zeros removed, phone numbers reduced to the last ten digits, MAIDs normalized to 32 lowercase hex characters.

Get one normalization rule wrong and every hash misses. Silently. Your pipeline reports “Not found” with total confidence while the regulator’s clock keeps running at $200 a day.

3. They cannot actually find the data they hold

Matching assumes you know where every copy of a consumer record lives. Production database, warehouse, three BI extracts, a vendor’s S3 bucket, the CSV someone emailed to a partner in 2023. DROP does not care that your lineage documentation is aspirational. The obligation extends to directing service providers and contractors to delete their matching copies too.

4. They miss the multi-consumer trap

If a single matched identifier is linked to several consumers in your records, you do not delete. You opt all of them out of sale and sharing, and push that instruction downstream. That is a different code path, a different status code, and a different downstream contract. Teams that built one branch now have a correctness bug with a statutory price tag.

5. They forget that “Not found” creates a permanent obligation

No match today does not mean you are finished. You must keep a suppression list and screen newly collected records against it before they are sold or shared. If a match appears later, you delete and report within 45 days of noticing. This is the single most expensive line in the regulation for anyone running continuous ingestion, and the one teams read past fastest.

6. They build it without an audit trail

From January 1, 2028 brokers face independent third-party audits every three years, retain the reports for six years, and must produce them within five business days of a written request. A pipeline that deletes correctly but cannot prove it did is, for audit purposes, a pipeline that did nothing.

7. They assume legal will handle it

Legal can read the statute. Legal cannot write a resilient job that handles a ZIP of CSVs, enforces six normalization schemes, performs double-hash concatenation for composite keys, posts status codes through POST /data/-upload, amends them through POST /data/-amend, and raises an alert when the download endpoint returns nothing on day 44. That is engineering work, and it was almost certainly not in anyone’s quarterly plan.

Which industries should be sweating

Adtech and identity resolution. MAID and CTVID appear in the DROP list types for a reason. If your business joins device graphs to households, you are squarely in scope and your matching logic is the product.

Lead generation and B2C marketing data. The classic pattern: collect from one source, sell to many buyers who have no relationship with the consumer. That is the statutory definition almost word for word.

People search, background and skip tracing. Already the enforcement priority. CalPrivacy’s strike force started here.

Automotive and insurance data. NameVIN exists as a list type specifically because vehicle identification numbers tie to individuals.

Financial and credit-adjacent services. Exemptions exist but are narrower than most compliance decks assume, and claiming one still requires reporting status code 2 inside DROP.

Health-adjacent audience sellers. See the enforcement section. This is where the fines got personal.

What DROP costs when you get it wrong

CalPrivacy has not been subtle. The penalty for failing to register is $200 per day plus the agency’s investigation costs. The penalty for failing to delete is $200 per day per deletion request, plus costs. Multiply that second figure by a list of a few thousand matched consumers and the arithmetic stops being theoretical.

The enforcement record so far, from the agency’s own announcements:

COMPANY	PENALTY	WHAT HAPPENED
LocateSmarter LLC	$116,490	Late registration, and demanded partial Social Security numbers before honoring an opt-out
S&P Global, Inc.	$62,600	Failed to register. The agency called it an administrative error. The fine landed anyway
Rickenbacher Data LLC	$45,000	Unregistered, and sold lists keyed to health conditions, age, race and political views
ROR Partners LLC	$56,600	Failed to register as a data broker

Three of those four were punished for paperwork, before anyone even looked at whether their deletion pipeline works. Sources: CalPrivacy on LocateSmarter and the January 2026 enforcement round.

Why DROP is a software problem wearing a legal costume

Strip the statute away and look at the spec. A scheduled retrieval against an authenticated API. Deterministic normalization across six identifier families. Cryptographic hashing with a composite double-hash for two of them. A join against every system that holds consumer records. A branching write path with four status codes. An idempotent reporting step with a hard deadline. A permanent suppression set that filters all future ingestion. An immutable log that survives six years.

That is not a policy document. That is a backlog. And it has the uncomfortable property that correctness is invisible until a regulator asks, at which point the cost of being wrong is already counted in days.

Teams that already own their identifier layer have a head start here, because DROP matching is only as good as your ability to resolve a person across systems. If that layer is held together by vendor pixels and goodwill, start with the data set you collect and control yourself. And if you are building anything new in this space, designing for consent before the first sprint costs a fraction of retrofitting it under a 45-day clock.

Sanddev’s response: a DROP connector on a production suppression platform

We started building this because we kept meeting the same conversation: a competent engineering team, a real deadline, and a six-week detour nobody had budgeted.

The foundation is not new. We already run a suppression platform in production. It maintains permanent suppression lists, screens newly collected records against them on every ingestion, runs cleanse jobs across lists, raises compliance alerts when a downstream party falls behind its suppression obligations, and keeps a full event history of what was removed and when. That is the unglamorous half of DROP, and it has been carrying real traffic rather than sitting in a slide deck.

On top of it we are completing a DROP connector: authenticated retrieval of your selected lists on schedule, CalPrivacy’s normalization rules applied to your own records, SHA-256 hashing with Base64 output, including the composite double-hash for the name-plus-date-of-birth-plus-ZIP and name-plus-VIN list types, matching across the sources you connect, separate paths for single-consumer and multi-consumer matches, status codes posted back through the API, countdown alerting well before day 45, and an append-only log built for the 2028 audit cycle rather than for a dashboard screenshot. It is in final build, ahead of the cycles that will actually be audited.

Because it runs as a scheduled service, a broken connection surfaces early rather than on day 44. That matters more than it sounds: when the automated interface is down, the obligation does not pause. You are still expected to retrieve your lists manually through your DROP account, and the written notice to CalPrivacy comes on top of that, only when the failure was outside your control.

If you want to see where it stands against your own stack, we will walk you through it. How we build and run compliance infrastructure is on our services page.

FAQ

Where this leaves you

DROP is the first regulation that hands engineering teams a machine-readable contract and a stopwatch. There is no interpretive wiggle room in a SHA-256 hash and no sympathy in a 45-day window. The companies that handle this well will be the ones that stopped treating deletion as a ticket and started treating it as a service with uptime.

The rest will find out at the end of a cycle, which is the most expensive place to learn.