CalPrivacy Answers Brokers’ Biggest Questions Ahead of the Delete Act’s Next Compliance Deadline
Fifty million dollars. That’s how much money is potentially on the line on September 15, 2026. Over 250,000 California residents submitted requests to the California Delete Request and Opt-Out Platform (DROP) as of March 2026. With fines of $200 per request per day for noncompliance, the potential Delete Act fines will only continue to climb from here.
Data brokers just got their first look at DROP this month. With pressure mounting, privacy teams naturally have many questions about their upcoming workflow in DROP. DataGrail hosted Liz Allen (Attorney, California Privacy Protection Agency)* to walk through what DROP looks like in practice during this month’s community Privacy Huddle.
Liz answered questions live clarifying the request processing window, what to expect from the API, and specifically what data needs to be deleted. Read on for all of the event’s biggest takeaways.
#1: DROP requests are not the same as CCPA data subject requests.
It’s tempting to think of DROP requests as exactly the same as a deletion request under the California Consumer Protection Act (CCPA). But there are important differences: consumer requests submitted via DROP are subject to their own timelines and compliance requirements.
For instance, if a data broker receives a DROP request they can’t match with a consumer in their database, they are meant to process that request as an opt out of any future selling or sharing of that consumer’s data. That is not the same obligation as under the CCPA.
The requests do have one thing in common. Liz reminded attendees that “California consumers” are anyone taxed by the state of California. A consumer keeping a mailing address or using an IP address outside of California is not grounds to deny their request.
#2: Your team may need to align behind a single log-in.
This is a practical operational point that caught several attendees off guard. DROP currently supports a single login per registered data broker. That means your compliance team, engineering team, and anyone else involved in processing requests all need to share a single account. Your account will be used for manually processing and reporting on requests, as well as for configuring the API connection if you choose to process requests via that route.
Liz recommended setting up a shared mailbox (like [email protected]) as the primary account email rather than using an individual’s work address. That shared mailbox also matters because it’s where you’ll receive API error notifications and any system downtime alerts from the agency. Two email contacts, a primary and a secondary, can be designated within the account. These are not surfaced publicly on the registry but are used for agency communication with data brokers.
Just make sure the emails you use are actively monitored. API errors won’t be an excuse for non-compliance as the Agency offers a manual process and requires data brokers to use it if they cannot download requests in a timely fashion with the API (see Section 7612). Handle them swiftly to avoid fines.
If you need to update your account’s login email before August 1st, the team at Cal Privacy can help. Reach them at [email protected].
#3: Expect a large backlog on August 1.
March’s DROP request count came in before CalPrivacy started any paid ad campaigns. The number will only grow ahead of DROP’s enforcement deadline. Expect to process over 275,000 requests in your first 45 days of processing.
While API request processing is generally faster, you should plan extra time for your first day of real request handling, even if you have already tested and confirmed your API configuration in the sandbox. When you begin processing live requests, be prepared for rate-limiting and throttling on your request volume.
#4: Deletion requirements are more nuanced than you may think.
It wasn’t that long ago that privacy teams were still figuring out whether or not the Delete Act applied to them at all. California’s broad definitions of selling and sharing data, including that a monetary exchange is not required to constitute a “sale,” left plenty of room for debate.
As it turns out, even with over 550 data brokers registered today, privacy teams still have questions on exactly what data needs to be deleted in a DROP request.
In many cases, data deletion is nuclear. The broker uses a matched identifier to locate the consumer in their records, and then deletes all non-exempt personal information, including inferred personal information, leaving only a hashed suppression identifier behind.
There are two exceptions to this rule:
- If there is a separate legal basis for retaining the data, such as a litigation hold, it does not need to be deleted.
- If the broker has a combination of first and third party data, only third party data and inferences made using third party data need to be deleted.
This is an extremely relevant point for businesses at the fringe of the Delete Act’s data broker definition who may have genuine direct business relationships with consumers. The more complicated your data subject relationships are, the more complicated your DROP compliance may become.
Deletions and opt outs can also be complicated for reasons that have nothing to do with the data broker’s business practice. For example, if a consumer submits a DROP request using an email address associated with and accessed by seven different family members, it won’t result in a clean 1-to-1 match. That doesn’t mean the request is ignored, it means that all seven family members are processed as an opt out of selling or sharing their data, rather than a deletion of data.
#5: The clock starts when you pick up the request.
This item came as a relief to many attendees. Brokers who pull requests daily (whether manually or via API) will have a rolling 45-day window to process and report completion of each batch.
But brokers also have the option to pull DROP requests once every 45 days (or at any other more frequent cadence), at which point they can take up to 45 days from the date of the export to process the batch. Data is batched daily by the Agency, so pulling information more frequently than once a day is unnecessary.
Either approach is technically compliant. What is not compliant is failing to report status back within 45 days of retrieval. The report must include a request status for every request. Request status can be deleted, exempt, not found, or opted out. Once you report the request status, DROP handles transparency with the requester, you don’t need to close the loop separately.
#6: DROP requests can be cancelled.
If a consumer submits a DROP request but later changes their mind, they will need to submit a cancellation before you can begin processing their data again. These updates, like other request amendments, will be included in DROP.
That may mean brokers need to update their consumer education materials to include relevant instructions. Don’t let confusion test your compliance posture.
#7: Your responsibility to the request doesn’t end with your DROP status update.
You’ll need to confirm that requests were processed in DROP on a regular basis, but that doesn’t mark the end of the request lifecycle.
After deletion, brokers are expected to retain a suppression identifier (such as a hashed ID or Ramp ID) to make sure that consumer doesn’t re-enter the system through a future data purchase or append. Deleting the profile without maintaining that suppression record creates a compliance gap that will catch up with you.
Your practical next steps
Don’t wait until August to get a handle on your plan for DROP. For teams not sure where to start, consider these tips from Liz:
- Map the compliance requirements from the regulations and API documentation against your actual internal systems and workflows.
- Run a full end-to-end test in the sandbox, from retrieval through matching to status reporting
- Check your infrastructure for logging, retry handling, and alerts.
- Set expectations across privacy, compliance, and engineering before the deadline, not after.
- More resources will become available for DROP as we get closer to August 1. Stay connected with CalPrivacy as API documentation and other supports are continuously updated.
If you’re a DataGrail customer preparing for DROP, discuss with your account manager. DataGrail will support customers in maintaining compliance with manual and API request handling, whichever your organization prefers. You can help influence our roadmap.
Even if you’re not a DataGrail customer yet, you can still take meaningful steps towards DROP compliance by auditing your data map. DataGrail Live Data Map provides continuous insight into your data ecosystem with AI-powered, real-time data mapping.
And whether you’re taking steps towards the August 1 deadline or just following along with Delete Act news to keep an eye on privacy regulation trends as a whole, join Privacy Roundtable and become part of the conversation. You’ll see daily privacy news updates, break down difficult legal jargon with 2,000+ peers in privacy, and be the first to know about our next exclusive Privacy Huddle event.
—
*Liz Allen’s comments during the huddle and as recapped here were made in her individual capacity, not from an official agency position. Always refer to CalPrivacy directly for the latest news on DROP and the Delete Act.
