Starting August 1, 2026, California residents can hit a single button and force data brokers to delete everything they've collected about them. No more "submit your request to each company individually." No more hiding behind vague privacy policies. One opt-out, legally binding, with a 45-day compliance window.
If you build software that collects, stores, shares, or sells personal data - and you have California users - this affects you directly. Not in a theoretical "you should care about privacy" way. In a "the California Privacy Protection Agency can fine you and drag you into an administrative proceeding" way.
Let's talk about what actually changed, who's on the hook, and what your backend needs to look like by now.
What the DELETE Act Actually Does
Senate Bill 362, signed by Governor Newsom in October 2023, created something the privacy world had been pushing for years: a centralized deletion mechanism. The California Privacy Protection Agency (CPPA) was tasked with building a platform - now called the Deletion Request and Opt-Out Platform, or DROP - where any California resident can submit a single request to delete their personal information from every registered data broker in the state.
Before this, exercising your deletion rights under the CCPA was exhausting. You'd have to find each company, figure out their process, submit a request, wait, follow up, argue. Most people gave up. The DELETE Act was designed to fix that by putting the burden on the brokers, not the consumers.
Here's the timeline that matters:
- October 2023: SB 362 signed into law
- January 1, 2024: Updated data broker registration requirements took effect
- January 1, 2026: CPPA was required to have the DROP system operational
- August 1, 2026: Data brokers must process and honor deletion requests received through DROP
That August 1 date isn't aspirational. It's the enforcement line. If the CPPA has routed a deletion request to your company, you have 45 days to comply.
Who's Actually a "Data Broker" (It's More People Than You Think)
The term "data broker" sounds like it only applies to Acxiom and those shadowy companies building profiles from public records. It doesn't. Under SB 362's definition, a data broker is any business that knowingly collects and sells personal information about consumers with whom it doesn't have a direct relationship.
That last part - "no direct relationship" - is the trap. If your app collects user data and shares it with ad networks, analytics providers, data enrichment services, or affiliate partners, you might qualify. If you operate a marketplace or platform where third parties can access user behavioral data, you might qualify. If you scrape public records and resell them, you definitely qualify.
Some common situations developers overlook:
- Your app sends behavioral data to a demand-side platform (DSP) for ad targeting. If that data is sold (not just used internally), you're brokering.
- You run a lead generation site. Users fill out a form thinking they're contacting one company, and you sell that lead data to five others. Classic brokerage.
- You aggregate data from multiple sources and provide it as a service. Even if it's "enrichment" or "verification," the data brokerage label might apply.
- You operate a people-search or background-check service. You're a broker under this law. No ambiguity.
The CPPA maintains a public registry of registered data brokers. If your company should be on that list and isn't, the penalties start at $200 per day for failure to register, plus potential administrative fines for non-compliance with deletion requests.
What "Honor a Deletion Request" Actually Means Technically
This is where most articles about privacy law lose developers. They say "comply with deletion requests" without explaining what that looks like in a production system. Let me fix that.
When the CPPA routes a deletion request to you through DROP, the system sends you identifying information about the consumer. You're expected to:
- Locate all records associated with that consumer across your systems - primary databases, replicas, backups, data warehouses, third-party integrations.
- Delete those records or, if you have a legal basis to retain some data (financial records, fraud prevention), delete what you can and document what you can't and why.
- Notify downstream recipients. If you sold that consumer's data to other parties, you need to tell those parties to delete it too. This is the part nobody wants to deal with.
- Confirm completion within 45 days of receiving the request.
That 45-day clock is firm. And "we're still working on it" isn't an excuse the CPPA has shown interest in accepting.
The Downstream Problem
Step 3 is where things get genuinely difficult. If your system sells or shares user data with 15 different partners through various APIs and batch file transfers, you need a way to track which data went where and trigger deletion cascades.
Most systems weren't built with this in mind. Data pipelines tend to be fire-and-forget. You export a CSV to a partner's S3 bucket every night and don't think about it again. Now you need to think about it again. You need to:
- Maintain a mapping of which consumer data was shared with which downstream partners
- Have a mechanism to notify those partners of deletion requests
- Track whether those partners actually deleted the data
- Keep a compliance log showing the full lifecycle of each request
If you can't do this today, you're behind.
Concrete Steps for Your Backend
Here's what engineering teams should have in place (or be actively building) right now:
1. Implement a Deletion Request API Endpoint
If you're registered with CPPA, you need to handle incoming deletion requests programmatically. The CPPA's DROP system communicates with registered brokers through defined interfaces. Set up a webhook or polling endpoint that:
- Accepts incoming deletion requests from the CPPA
- Validates the request format
- Queues the request for processing
- Returns an acknowledgment with a case ID
2. Build a Data Locating System
You can't delete data you can't find. If user data lives in 12 different services, a Postgres primary, a Snowflake warehouse, three S3 buckets, and a Redis cache, you need a way to find and delete it all.
Some teams build this as a "right-to-delete" service - a dedicated microservice that can query all data stores, find records matching a given identity, and issue deletion commands. Others use data catalogs like Apache Atlas or Amundsen to track where PII lives.
Whatever your approach, it needs to work across your entire data infrastructure, not just the main application database.
3. Add Deletion Propagation
For every downstream partner you share data with, you need a way to tell them "delete this person's data." That means:
- Maintaining a registry of data recipients and their contact/API details
- Building notification integrations for each partner
- Logging when notifications were sent and whether partners confirmed deletion
Some partners will have their own deletion APIs. Others will want email notifications. You'll need to handle both.
4. Audit Logging
The CPPA can ask you to prove you complied with a request. That means you need logs showing:
- When you received the request
- Which systems you searched
- What data you found and deleted
- Which downstream partners you notified
- Their confirmation of deletion
Don't store the consumer's personal data in your audit logs. That would be ironic. Store anonymized case IDs and action timestamps.
5. Retention Policy Documentation
Some data you genuinely can't delete. Financial transaction records, for example, often have legal retention requirements. When you can't fully honor a deletion request, you need to document exactly why - which law or regulation requires retention, which specific data elements are retained, and how you've minimized what you keep.
The CPPA allows partial compliance, but only with clear justification.
The Penalties Aren't Theoretical
Data brokers who fail to register face 200 per day. That's the baseline. For non-compliance with actual deletion requests, the CPPA can pursue administrative fines under the CCPA framework, which can reach 7,500 per intentional violation. For a company with millions of consumer records, that math gets ugly fast.
And there's the reputational hit. The CPPA publishes its enforcement actions. Nobody wants to be the company that made the news for ignoring deletion requests in 2026.
The Bigger Picture
California tends to set the pattern for US privacy regulation. The DELETE Act is the first law that creates a truly consumer-friendly deletion mechanism at scale. Other states are watching. If this works - and early indications suggest the CPPA is serious about enforcement - expect similar frameworks in Colorado, Connecticut, Texas, and the other states that have been building their own privacy laws.
From an engineering perspective, the companies that treated privacy infrastructure as a first-class concern are going to sail through this. They already have data maps, deletion pipelines, and audit systems. The teams that have been treating data deletion as "we'll figure it out when someone asks" are scrambling.
If you're in the second camp, stop reading articles about this and go build the endpoint. August 1 already passed.
