Quick answer: CCPA DROP compliance is the recurring obligation for California-registered data brokers to retrieve consumer deletion requests from the state's Delete Request and Opt-out Platform (DROP), delete all matching non-exempt personal information, report the outcome, and keep that data deleted going forward. Processing became mandatory on August 1, 2026, and the Delete Act attaches a fine of $200 per deletion request, per day, to each day a broker fails to act. Because a single requester's personal information can sit in databases, object storage, SaaS apps, logs, backups, and copied datasets under several different identifiers, manual search-and-ticket workflows cannot reliably close a request or prove it stayed closed. Automating discovery, deletion verification, and ongoing monitoring is what makes the 45-day DROP cycle operationally survivable.
As of August 1, 2026, California data brokers must process deletion requests submitted through the state's Delete Request and Opt-out Platform. Created under the California Delete Act (SB 362) and built on CCPA definitions and privacy rights, DROP lets a California resident send one verified request to every registered data broker instead of contacting hundreds of companies individually.
The scale is not theoretical. According to the California Privacy Protection Agency (CalPrivacy), more than 600 registered data brokers are in scope, and hundreds of thousands of consumer requests were queued in DROP before the processing deadline arrived.
What DROP requires data brokers to do every 45 days
The Delete Request and Opt-out Platform (DROP) is a state-operated deletion mechanism that routes a single verified consumer request to every data broker registered with CalPrivacy. Unlike a standard CCPA deletion request, which a consumer sends to one business, a DROP request is a standing, government-administered obligation that persists after the first deletion.
Per CalPrivacy's DROP processing requirements, the cycle has four steps and repeats at least once every 45 calendar days:
- Download consumer deletion lists. Brokers pull hashed identifiers from up to six lists: name + date of birth + ZIP code; email address; phone number; mobile advertising ID; name + VIN; and connected TV identifier. Every list that could match records the broker holds must be selected.
- Standardize and hash internal records. Text is lowercased, special characters removed, and dates, phone numbers, and ZIP codes normalized before comparison.
- Match and process. On a match, the broker deletes all non-exempt personal information including inferences and directs service providers and contractors to do the same. Where one identifier maps to multiple consumers, all associated consumers are opted out of sale and sharing instead. Where there is no match, the identifier still goes on a suppression list.
- Report status. Each request must be reported back within 45 days of download as Deleted, Opted out, Exempted, or Not found.
Two ongoing obligations sit underneath that cycle. Consumers never have to resubmit, so brokers must screen newly collected records against retained identifiers before that data is sold or shared, retaining only the minimum data necessary and using it for no other purpose. And if a request's status changes later, such as a "Not found" identifier that matches after a subsequent data acquisition, the broker must delete the newly matched information and update the status in DROP within 45 days of detecting the change.
Status reporting also gates the next batch: a broker that falls behind stops pulling new requests while its backlog, and its exposure, keeps growing.
Why manual DROP workflows do not scale
Manual privacy operations were expensive before DROP existed. Gartner's Market Guide for Subject Rights Request Automation estimates that a single access or deletion request costs roughly $1,524 to complete manually, a figure that is almost entirely labor: searching systems, verifying identities, compiling results, and documenting the process. DataGrail's 2026 Privacy & AI Trends Report found deletion requests have risen 567% since 2021, and that manual data subject request management now costs a mid-sized organization upwards of $1.5 million annually.
DROP changes the shape of that cost in three ways.
Volume arrives in batches, not a trickle. A single 45-day download can deliver more matched identifiers than a privacy team previously handled in a year, and every one needs an auditable outcome.
The penalty meter runs per request, per day. As Fenwick's Delete Act guidance notes, a broker that fails to process deletion requests through DROP faces a fine of $200 per deletion request for each day it fails to delete personal information as required, and those fines apply regardless of intent. The arithmetic compounds fast: 5,000 unresolved requests carried for a full 45-day cycle is $45 million in theoretical exposure. CalPrivacy's Data Broker Enforcement Strike Force has already shown it will pursue these penalties, settling with Nevada-based marketing firm ROR Partners for $56,600 over a registration failure in December 2025.
Personal data does not sit where the data map says it does. The same person can appear under different identifiers across production databases, cloud object storage, SaaS applications, legacy platforms, logs, exports, documents, and duplicated analytics datasets. IBM's 2026 Cost of a Data Breach Report found most breaches involved data distributed across multiple environments, and that those incidents cost more and took longer to resolve than single-environment breaches. The same fragmentation that inflates breach cost is what causes deletion requests to be closed while records survive off the map.
Tickets, spreadsheets, and system-owner confirmations produce a record that a task was closed. They do not produce evidence that the data is gone.
How DROP requests differ from standard CCPA deletion requests
Standard CCPA deletion request | DROP request under the Delete Act | |
|---|---|---|
Where it arrives | Directly from the consumer to one business | Downloaded from a state platform as hashed identifiers |
Who it reaches | That business only | Every registered data broker at once |
Identity verification | Performed by the business | Performed by CalPrivacy before the request enters DROP |
Duration | Point-in-time obligation | Standing obligation; screening of newly collected data continues |
Downstream parties | Varies | Broker must direct service providers and contractors to act |
Proof | Internal records | Status reported into DROP on a 45-day cycle, subject to audit |
The practical difference: a CCPA deletion request ends when the data is deleted. A DROP request ends when the broker stops collecting that person's data, which for most brokers is never.
How Sentra supports DROP compliance
Sentra is a data security posture management (DSPM) platform built for continuous classification and identity-aware data governance at enterprise scale. It continuously discovers and classifies sensitive data across cloud, SaaS, on-premises, structured, and unstructured environments using in-place scanning, so sensitive data never leaves the customer environment during classification, a meaningful property when the workflow in question is a privacy obligation.
Sentra does not replace DROP integration, identity matching, or deletion execution. It addresses the part of the cycle that manual workflows handle worst: knowing where a requester's data actually exists, confirming it was removed, and catching it when it comes back.
How do you find every record tied to a DROP requester?
After a DROP request has been matched according to the platform's hashing and standardization requirements, Sentra can search relevant environments for personal information associated with the requester's known identifiers.
Sentra's data map and classification capabilities locate related records across different systems and data types, including unstructured stores where copies tend to accumulate. Privacy teams get a consolidated view of what was found and where, which reduces manual effort and the risk of overlooking a dataset nobody remembered to inventory. Sentra's API can fold these searches into a broader automated DROP workflow so discovery runs on the same 45-day clock as the rest of the cycle.
For context on scale: Sentra has scanned 9 petabytes in under 72 hours, with classification accuracy independently validated above 98% in a third-party audit conducted by a Fortune 500 consumer technology company.
How do you prove a deletion actually happened?
Completing a deletion task does not prove that every relevant record was removed.
After deletion or anonymization actions are performed, Sentra can search again for the requester's information. This follow-up check surfaces records that were missed, duplicated, restored from backup, or retained in unexpected locations. These are the failure modes that turn a "Deleted" status report into a misstatement.
The results become evidence supporting internal review, DROP status reporting, and future audits. That matters beyond August 2026: the Delete Act introduces independent third-party compliance audits for data brokers beginning January 1, 2028, with audit records retained for at least six years. Compliance teams building an evidence trail now are building the one they will be asked to produce later.
How do you detect requester data that reappears after deletion?
DROP requests remain in force after the first deletion. If a broker collects matching personal information later, it must identify and process that data before it is sold or shared, then update the request status within 45 days of detecting the change.
Sentra's continuous data discovery and classification helps detect when requester data appears in a new dataset, is copied into another environment, or returns following a migration, restoration, or third-party data acquisition. The broker can then trigger the required action, verify the result, and update the request's status in DROP, closing the loop that suppression lists alone leave open.
A scalable DROP workflow, end to end
Sentra serves as the discovery and verification layer inside a broader DROP process:
Step | Owner | Sentra's role |
|---|---|---|
1. Retrieve requests from DROP | Privacy engineering / API | Not applicable |
2. Standardize and hash identifiers | Privacy engineering | Not applicable |
3. Locate associated personal information | Data security | Automated discovery and classification |
4. Review exemptions, determine action | Privacy / legal | Context on data type and location |
5. Trigger deletion or anonymization | System owners | Not applicable |
6. Direct service providers and contractors | Vendor management | Visibility into shared and copied datasets |
7. Verify deletion was completed | Data security | Re-scan and evidence generation |
8. Report status in DROP | Privacy operations | Evidence supporting the reported status |
9. Monitor for reappearing data | Data security | Continuous discovery and alerting |
Operationalize DROP with continuous data intelligence
DROP converts deletion from a one-time task into an ongoing data management responsibility with a per-day penalty attached. Data brokers need an efficient, repeatable way to identify personal information across complex environments, validate that deletion happened, and continuously monitor for its return.
To see how Sentra discovers, classifies, and verifies deletion of sensitive data across your cloud, SaaS, and on-premises environments, request a demo.
This post is intended as operational guidance, not legal advice. Data brokers should confirm scope and obligations under the Delete Act with counsel.
A DROP request ends when the broker stops collecting that person's data, which for most brokers is never.
