Inside the build: how Ethyca Engineered Compliance for California's DROP
California's Delete Act created a new kind of deadline: not a report due once a year, but a live feed of deletion requests that never stops. Here's how we built the infrastructure to keep up with it, and what we learned along the way.
What's the DROP Act?
In 2026, the California Privacy Protection Agency (CPPA) turned on the Delete Request and Opt-out Platform, DROP Act, as required under the state's Delete Act. For the first time, California citizens can submit a single request and have it apply to every registered data broker in the state at once. California is serious about enforcing this requirement. They have already fined 2 data brokers who failed to register as required with the state and thus missed the consumer opt-out requests. For data brokers, the convenience of a centralized registry comes with a hard mandate: retrieve the latest deletion list from DROP at least every 45 days, and honor it permanently.
We built the infrastructure to make that possible, using Astralis, our data governance platform. Here's what that build actually looked like.
The problem wasn't the warehouse
The instinct with a mandate like this is to treat it as a database problem: find the records, delete the records, done. Early into these implementations, a pattern kept showing up that made it clear the real work is somewhere else.
The "data broker" classification rarely maps onto a clean, standalone system. More often it lands on a business line that sells or licenses data collected elsewhere in the company, which means the same PI a business needs to keep for its own operations has usually already flowed downstream into whatever system earned it the data-broker label in the first place. Erasing it from the primary warehouse doesn't help once it's living somewhere else too.
Compliance had to reach every place the data actually ended up, not just the warehouse, without touching the operational data the rest of the business still depends on.
A suppression layer, not a delete button
That constraint shaped the architecture: enforce suppression at query time, so flagged records disappear from the results that need them gone, without ever touching the source data.
The system we built does four things, continuously:
- Pulls the list. Astralis authenticates directly to the DROP platform and retrieves the latest hashed consumer identifiers daily (well ahead of the 45-day cycle the state requires) so nothing sits waiting for a deadline.
- Hashes to spec. Astralis traverses a customer's data stores, identifies the relevant PI (email, phone, name, address, and more), and produces cryptographic hashes that match DROP's format exactly. No plaintext PI ever leaves the system.
- Matches and maintains a ledger. Incoming DROP identifiers are matched against the customer's own hashed records, and every match is written to a suppression ledger: an auditable, timestamped record of what's been suppressed, when, and why.
- Writes it into the warehouse. Astralis pushes the matched, hashed records directly into a dedicated table inside the customer's own environment. From there, the customer's row-access policies do the enforcement: bound to the secure views the data-broker side of the business queries, so suppressed records simply never appear in the result set.
The effect: one team owns the compliance logic, and it enforces itself at query time, everywhere the data lives, without a human re-checking each release.
What it looked like in production
The first real test was a backlog: over 400,000 standing deletion requests that had to be cleared before ongoing 45-day cycles could even start. We matched well over 200,000 of those identities against records that actually existed in this customer's warehouse and suppressed them, without a single failed record.
After that infrastructure takes over. A recent daily cycle processed several thousand records and minted the corresponding deletion requests in Astralis in well under an hour, fully automated, with zero errors. That's the real measure of success for something like this: not a launch announcement, but a Tuesday that nobody has to think about.
Future-proofing deletion
DROP is the first mandatory, centralized deletion clearinghouse of its kind in the U.S., but the shape of the problem is one other states are already watching closely. We built the suppression ledger once, inside Astralis, specifically so it wouldn't need to be built again. For customers who'd rather own the sync themselves, that same ledger is also available as a simple, read-only API to pull from directly. Either way, any customer with a data-broker classification can wire it into their existing warehouse.
