DROP isn't a compliance deadline. It's an infrastructure test.

On August 1, California's Delete Request and Opt-Out Platform (DROP) went into force. The first 45-day cycle is already running.

Every registered data broker in the state - 566 and counting - must check DROP every 45 days, either through the state's portal or API, download new consumer deletion requests, delete that consumer's data across every system where it exists, and report back to the state once the work is complete.

Miss it, and the fine is $200 per request, per day, with no cure period. Since DROP opened for consumer submissions, more than 300,000 people have already filed a request, and the volume is accelerating past what the state itself projected.

It sounds like a legal problem: a deadline, a fine, a form. And that's exactly how most organizations are staffing it, as a project that lives on the privacy or legal team's calendar. That's the wrong org chart.

DROP is a data infrastructure problem disguised as a compliance deadline. The team that should own it isn't just legal or privacy, it's the team responsible for your data infrastructure.

See how it's actually being solved. Join a live conversation with ZoomInfo and Upwork on August 25.

Register for the webinar

DROP is two problems in one

Here's what the regulatory summaries leave out. DROP hands you deletion requests as hashed identifiers, split across six list types: email, phone, mobile advertising ID, name plus date of birth plus ZIP, name plus VIN, and connected TV ID. There's no shared ID connecting any of them. The same consumer can show up as three or four completely unrelated rows, with different hashes, with nothing in the file telling you they're the same person.

So before you delete anything, you have to solve two distinct problems.

• The first is matching i.e. normalizing and hashing your own records the same way DROP does, and checking for hits.
• The second is assembling: taking every hit that belongs to the same person, across all six list types, and resolving them into a single identity before you touch anything.

Skip that second step and you're not wrong, you're just inefficient, running four disconnected erasures for one person instead of one clean deletion.

That's identity resolution, and it's the same category of problem your team is already solving for personalization, AI training data, and first-party audience activation. DROP just adds a regulator checking your homework every 45 days instead of a product metric checking it continuously.

This isn't a new problem for Transcend. DSR Automation already resolves each request to a core identifier, the same key we use to unify identity across a customer’s entire stack for privacy operations or AI-driven personalization.

When a DROP match includes a resolved person key or core ID from the data broker, that value becomes the request’s core identifier, so later cycles can land on the same person instead of treating every 45-day list as a blank slate. Transcend isn't re-deriving who's who every cycle. It's remembering.

The identity resolution problem behind DROP shows up everywhere customer data lives.

Read the guide

If your systems get identity resolution wrong, then the compliance part is wrong too. You can't accurately report deletion status back to the state if you never correctly figured out who was actually deleted.

Semi-automated is not automated

The instinct is to bolt on a workflow for the problem: open a ticket per request, assign an owner, track a deadline, send reminders. Someone still has to log into every downstream system, find the record, confirm the deletion, and manually build a report-back file from whatever's left in the spreadsheet.

At 300,000+ requests and climbing, on a fixed 45-day cadence, forever, that model doesn't scale. It’s a to-do list with a regulatory timer, and it will break.

A sustainable operating model runs the policy requirement as code. For example: a matched request becomes a person-scoped deletion job automatically. That job executes against every system where the person's data actually lives.

The audit trail is a byproduct of execution, not something a human assembles afterward from memory and CSVs. That's infrastructure. And infrastructure is an engineering deliverable, not a legal one.

Policy Engine makes the same case at the platform level: writing the policy was never the hard part, but applying it at scale is. Enforcing rules everywhere data flows, at the speed the business actually moves, is the infrastructure problem, and it belongs with the CIOs and VPs of engineering leading that work, not buried in a compliance queue.

Already in production

Transcend's DSR Automation resolves one identifier into every identifier a downstream system needs: user ID, account number, advertising ID, whatever that system requires, so no system gets skipped just because the incoming request doesn't speak its language.

That's the same "one identifier in, every identifier out" model DROP requires at the list-type level, now applied across a broker's entire integration surface.

Transcend already operates infrastructure at this scale. We've automated DSRs across 1,000+ connected data systems and managed more than 4 billion consent decisions, all through our zero-trust architecture (Sombra) that encrypts your data before anything is sent to Transcend, so no raw data ever reaches Transcend's systems. In 2025 alone, Transcend customers fulfilled over 2.1 million requests, reclaimed more than 14 million hours, and saved over $960 million in manual compliance costs, by letting the infrastructure run instead of a team.

For DROP specifically, that means brokers can upload their matched DROP files today, group matches into person-scoped deletion requests, execute erasure across every configured system, and generate a report-back file formatted to CPPA’s current DROP specification automatically. That's live today.

The direction is full end-to-end automation: Transcend retrieves the list, resolves identity, executes, and reports back, with a human only in the loop where you choose. For existing Transcend customers, there's nothing new to configure: point DROP at whichever CCPA erasure workflow you're already running, and your infrastructure handles the rest, because it already understands your data and your rules.

Put DROP on the right roadmap

If DROP is sitting on your compliance team's project list right now, it will probably get handled the way compliance teams handle things: carefully, manually, and just in time. That might get you through the first 45-day cycle.

It won't get you through the tenth one, and it definitely won't get you through the next state that passes DROP legislation. Connecticut already has, and additional states are moving in the same direction.

The organizations staying on top of DROP legislation are treating it as what it actually is: an identity resolution and enforcement problem that belongs on the engineering roadmap, built once, so it runs itself.

We're hosting a live roundtable on August 25 with practitioners from our customers, ZoomInfo and Upwork, who've been building exactly this. Not a legal briefing, but a conversation about what it actually took to turn DROP from a manual scramble into infrastructure that runs on its own. Register here.