California DROP lets an eligible resident send one deletion and sale opt-out request to more than 600 data brokers. That is a major reduction in manual work. It is not proof that 600 databases have already erased every record. A reliable privacy workflow distinguishes request submission, broker matching, reported status, legal exemptions, recurring deletion, and independent verification.
What changed on August 1, 2026
California launched the Delete Request and Opt-out Platform, or DROP, for consumer requests on January 1, 2026. Data brokers' processing duty began on August 1.
According to CalPrivacy's consumer explanation, one request is sent to over 600 active data brokers. The public 2026 California Data Broker Registry CSV contained 603 registration records in its July 29 snapshot. That is a dated count, not a permanent ceiling. Registrations and active-broker coverage can change.
August 1 was the start of processing obligations, not a universal deletion date. Brokers must access DROP at least once every 45 calendar days. After downloading requests, they have another 45 days to process them and report status. CalPrivacy warns consumers that status updates can take up to 90 days.
For a request already waiting on August 1, the slow edge of those two windows reaches roughly October 30. As of August 4, only four days of the first processing period had elapsed. Aggregate deletion effectiveness, matching accuracy, exemption rates, and long-term recollection outcomes remained unverified.
A DROP request creates a state machine
The useful way to understand DROP is as a workflow with distinct evidence states.
eligible resident
-> request submitted
-> hashed identifiers available to brokers
-> broker downloads request
-> broker matches or fails to match
-> broker processes deletion, exemption, or opt-out
-> status returned to DROP
-> consumer reviews and updates identifiers
-> future broker data is checked again
Each arrow matters. A receipt proves submission. It does not prove a broker found a matching record. A match proves linkage to identifiers. It does not prove all data was legally deletable. A broker-reported Deleted status is stronger than a submission receipt, but it remains a status report rather than a cryptographic proof of deletion.
How matching works without distributing raw identifiers
DROP separates residency verification from broker record matching. Eligible California residents verify through the California Identity Gateway, with Login.gov available as one path. They can provide identifiers such as names and former names, date of birth, ZIP code, email addresses, phone numbers, mobile advertising IDs, connected-TV IDs, and vehicle identification numbers.
More identifiers can improve matching. They also increase the amount of information supplied to the workflow. Use the smallest set that supports the intended result, then add missing historical identifiers when status patterns show likely matching gaps.
CalPrivacy's broker technical specification defines normalization and hashing rules, including SHA-256, UTF-8 input, and Base64 output. Brokers standardize and hash their own records under the same rules, then compare them with DROP lists. The lists cover identifier combinations such as name with date of birth and ZIP, email, phone, mobile advertising ID, name with VIN, and connected-TV ID.
CalPrivacy's consumer page calls hashing a form of encryption. Technically, SHA-256 is a one-way hash rather than reversible encryption. The practical point is that raw identifiers are not distributed to brokers through the matching lists. Hashing also does not make the system anonymous by itself. Common identifiers have limited input spaces, and the system's purpose is to find linkable matches.
Read the five statuses as evidence, not labels
Consumers can use an eight-digit DROP ID to check results. The official status explanation defines five outcomes.
| Status | What it means | What to do next |
|---|---|---|
| Deleted | the broker reports a match and deletion of non-exempt personal information | retain the dated result and review again after later cycles |
| Exempted | the broker reports a match but a legal basis to retain information | identify the exemption category before assuming failure |
| Opted-out | an identifier maps to multiple consumers, so sale or sharing stops while data may remain | add more precise identifiers when appropriate |
| Record not found | the broker reports no match | distinguish no data from insufficient identifiers |
| Pending | the broker has not completed processing | wait through the published window, then escalate persistent cases |
Record not found is the easiest status to misread. It can mean the broker has no information about the resident. It can also mean the submitted email, phone, name, ZIP, or device identifiers did not match the broker's normalized records. It is not a deletion receipt.
Opted-out also matters. When the same identifier could represent several people, deleting one person's data without a reliable match could harm another. The system therefore allows sale and sharing to stop while data remains. This is a safety tradeoff, not equivalent to deletion.
What DROP can delete, and what can remain
A matching broker must delete non-exempt personal information associated with the identifiers, including inferred information, and direct relevant service providers and contractors to process the request. The duty is persistent: if the broker later collects matching information again, it must continue honoring the original request before selling or sharing that data.
The right has boundaries. DROP targets registered data brokers, defined around businesses collecting and selling personal information without a direct consumer relationship. It does not cover every business that holds data, every search result, or every public record.
Information may remain when a legal exemption applies. Examples include certain public records, first-party data collected through a direct relationship, information required for security, debugging, transactions, or legal obligations, and categories governed by other statutory exemptions. Backup or archived data can follow delayed treatment until restoration or renewed commercial use. Brokers may also retain the minimum identifiers needed to keep enforcing the deletion request.
The California Delete Act and implementing rules provide the authoritative boundaries. A consumer-facing status compresses those legal and operational details, so high-impact cases may require reading the stated exemption rather than treating every non-deletion as noncompliance.
Build a personal deletion evidence ledger
DROP reduces the number of portals a resident must manage. A small evidence ledger turns that convenience into an accountable workflow.
Record:
- submission date and the securely stored DROP ID;
- identifiers included, with sensitive values masked in your own notes;
- the registry snapshot or coverage date;
- expected first review and 90-day review dates;
- counts by status, not screenshots of a single total;
- persistent
Pending, unexpectedExempted, and ambiguousRecord not foundcases; - profile updates and the next review cycle;
- a separate check for high-risk people-search or fraud-exposure sites.
Do not publish the DROP ID or raw identifiers. Preserve enough metadata to understand why a match may have succeeded or failed.
A practical cadence is:
- Submit with current core identifiers.
- Save the DROP ID and a masked inventory of supplied fields.
- Review status after the first 45-day window without declaring failure early.
- Review again by the 90-day outer window.
- Add relevant former emails, phone numbers, names, addresses, or device identifiers when repeated
Record not foundresults suggest a match gap. - Track exceptions and persistent pending cases for complaint or legal follow-up.
- Recheck periodically because brokers and personal identifiers change.
Verifiable does not mean independently proven
DROP materially improves observability. Consumers receive a stable request ID and broker-level status instead of sending hundreds of unrelated forms. Brokers must report transaction identifiers and response codes. Noncompliance can bring administrative penalties of $200 per day per deletion request, plus investigation and enforcement costs.
The evidence still has limits. A Deleted result is reported by the broker. DROP does not give consumers a database snapshot, a signed deletion log, a proof about every backup, or independent verification of each record. Independent compliance audits begin in 2028 and then recur every three years; they are a system-level control, not a real-time proof attached to each request.
The correct claim in August 2026 is therefore precise: DROP has made data-broker deletion requests centralized, persistent, and status-trackable. It has not yet produced enough elapsed time or independent evidence to measure complete real-world deletion effectiveness.
That evidence discipline is similar to connected medical-data trust boundaries. Storage, access, derived use, disconnection, and deletion are separate states. One control cannot stand in for the whole lifecycle.
FAQ
Who can use California DROP?
California residents who complete the platform's eligibility verification can submit requests. Official help materials also describe limited cases for authorized representatives or requests on behalf of another resident.
Does one request reach every data broker?
It applies to active brokers registered in California, subject to the user's exclusions and the current registry. It does not cover unregistered actors, every U.S. broker, or ordinary businesses with direct customer relationships.
Why can results take 90 days if brokers process every 45 days?
Brokers can wait up to 45 days to download requests, then have up to 45 more days to process and report them. Those two windows create the consumer-facing outer timeline.
Does Record not found mean the broker never had my data?
No. It may mean no record exists, or that the provided identifiers did not match the broker's standardized data.
Does Deleted prove every copy is gone?
It means the broker reports deleting matched, non-exempt personal information. It is not independent proof about every exempt record, archive, backup, contractor, or downstream copy.