For California data brokers · DROP
Did the DROP deletion actually happen?
ZeroKept is researching independent testing of DROP deletions, and the evidence brokers will need for their audits.
Research stage. Nothing is for sale yet. We're talking with brokers, privacy practitioners and auditors about how deletion works today.
DROP cycle check
IllustrativeCycle ZK-B-EXAMPLE, sampled checks
- Deletion list pulled from DROPVerified
- Sample of matches re-run1 exception
- Vendor confirmations1 missing
- Later lookup of test-panel membersAbsent in tested scope
- Backup restoreNot tested
2 findings openExceptions, gaps and limits are recorded, not hidden.
The problem we're investigating
Processing a deletion and showing it worked are different jobs
California's Delete Request and Opt-out Platform (DROP) lets residents ask every registered data broker to delete their data in one request. Brokers must act on that list on a fixed schedule and will face independent audits. Privacy tools carry out the deletions; what's less clear is how a broker shows, cycle by cycle, that they worked.
Every 30 days
From January 1, 2027, brokers must process the DROP deletion list every 30 days, down from 45 (AB 883).
$200 a day
The fine for each consumer request left unprocessed, for every day it stays that way.
From 2028
Independent audits every three years. Under draft rules (not final), first reports would be due November 1, 2028, covering activity since August 1, 2026.
625
Data brokers in California's 2026 registry (October 31, 2026 download).
"Not Found" that wasn't
A small formatting or hashing slip turns a real match into "Not Found," and the tool's own log can't show who it missed.
Copies held elsewhere
Vendors and buyers holding copies are notified, but confirming they acted is a separate step.
People who come back
A backup restore or a new data load can bring deleted people back after the cycle closes.
1 million+
Deletion requests California brokers denied or ignored over two years. Bloomberg Law, 2026
About 70%
Of brokers tested with made-up identities never reported what happened to the deletion request. UC Irvine study via Help Net Security
Estimate Delete Act penalty exposure
What unprocessed deletion requests can cost
Delete Act penalties add up per request, per day. Change the numbers to see a broker's potential exposure.
Potential exposure
$20,000
$2,000 for every extra day
Illustrative only: $200 per request per day under the Delete Act, before enforcement costs. Not legal advice.
Sources: Manatt, California's data deletion platform goes live; Hunton, California amends data broker law; Wilson Sonsini on the draft audit rules. Draft audit rules may change. Reviewed November 2, 2026. This is a summary, not legal advice.
Illustrative sample
What a cycle's evidence could look like
A made-up example of the kind of record we're exploring. It deliberately includes an exception, a missing item and an untested area, to show how findings would be reported alongside what checked out.
Sample evidence record
DROP cycle, March 2027
| Area | What was checked | Evidence source | Observed | Result |
|---|---|---|---|---|
| List selection | Full DROP list downloaded; file fingerprint matches an independent pull | DROP download record | Mar 1 | Verified |
| Matching | 100 sampled requests re-run independently: 99 agreed; 1 reported "Not Found" matched on rerun. Unresolved at cycle end | Broker matching output; independent rerun | Mar 2 | Exception identified |
| Deletion | 50 sampled matched records looked up again after deletion in the 3 tested systems | Broker deletion logs; sample lookups | Mar 4 | No records found within tested scope |
| Service providers | 4 of 5 vendor confirmations received; 1 still outstanding at cycle end | Vendor confirmations | Mar 30 | Evidence missing |
| Status reporting | Totals submitted to DROP match the broker's internal totals. This checks the counts only; it doesn't resolve the matching exception above, which remains open | DROP status submission | Mar 27 | Counts agree |
| Suppression | The Mar 15 data load checked for the 412 deleted identifiers | Suppression check | Mar 15 | No records found within tested scope |
| Outside lookup | 3 consenting test-panel members, each found by the same product search before their DROP request (Feb 20), searched again 7 days after deletion. A later lookup result, not a DROP status | Independent lookup, before and after | Feb 20; Mar 28 | No records found within tested scope |
| Backup restore | Outside this exercise | n/a | n/a | Not tested |
Limits: results cover only the systems, samples and dates listed. Sampling can miss problems, and checking selected sources can't establish that no copy exists anywhere else. Access was limited to what the broker provided.
Proposed approach
How the testing would work, and where it stops
A proposal we're testing in conversations, not a finished product: independently test parts of each DROP cycle and document what was found, including exceptions, missing evidence and what wasn't tested, in a form a broker's auditor can review. Some evidence would come from the broker's own systems; the independent part is re-running samples, comparing sources and looking from the outside.
Collect
Evidence from several places: the broker's own logs, its vendors' confirmations, and independent checks such as re-run samples and outside lookups.
Compare
Where sources disagree or evidence is missing, that's recorded as a finding, alongside what was and wasn't tested.
Record
Results are timestamped in a tamper-evident record so they can't be quietly backdated or edited. Who can see them is agreed with each customer.
What testing can't show
- That every copy of someone's data is gone everywhere. Results cover only what was tested.
- Anything in systems the broker doesn't give access to.
- Outside lookups work only where a broker's product can be searched.
- An audit opinion. That stays with the broker's independent auditor.
The areas a DROP test could cover
List selection and DROP access
Whether the right deletion list was downloaded in full, by authorized staff.
Standardization, hashing and matching
Whether records were formatted and hashed to DROP's specification, by re-running matching on a sample.
Deletion
Whether a sample of matched records is gone from the systems tested.
Service providers and status reporting
Whether vendors confirmed deletion, and whether the status sent to DROP matches internal records.
Suppression
Whether deleted people reappear after a new data load or restore, within the periods tested.
Outside lookups
Whether consenting test-panel members known to be in the data can still be found in the broker's product after deletion.
Record integrity
Whether results were kept in a record that can't be quietly edited afterward.
Areas 1 to 5 follow the areas listed in CalPrivacy's draft DROP audit rules, which may change.
What ZeroKept never does
- Buy, sell or reuse anyone's data.
- Act as your lawyer or auditor.
- Charge more or less depending on what a test finds.
Research conversations
Talk with us for 20 minutes
We'd like to hear from data broker privacy and data teams, privacy practitioners, and independent auditors.
- The conversation is about your existing process and what's hard about it.
- No purchase or partnership commitment.
- No consumer data or confidential records needed.
Registered broker? You can also ask about a free check of your registry filing.
Common questions
Can my company use ZeroKept today?
Not yet. ZeroKept is in the research stage and nothing is for sale. We're talking with data brokers, privacy practitioners and auditors about how DROP deletion works today and where evidence is hard to produce. If that research shows a real need, the next step would be a small number of narrowly scoped pilots.
What is DROP, and how often must brokers process it?
DROP, California's Delete Request and Opt-out Platform, lets California residents send one deletion request to every registered data broker at once. It is run by the California Privacy Protection Agency (CalPrivacy) under the Delete Act. Since August 1, 2026, brokers must process it at least every 45 days; under AB 883 that tightens to every 30 days from January 1, 2027. Each request left unprocessed can cost $200 per day.
Would ZeroKept replace a Delete Act audit?
No. The Delete Act requires brokers to undergo an independent audit every three years starting in 2028; under CalPrivacy's draft rules, which are not final, the first reports would be due November 1, 2028. ZeroKept is not an audit firm or a law firm. The idea is evidence a broker's auditor can review, not a replacement for the audit.
We already use a privacy tool such as DataGrail or OneTrust. How is this different?
Those tools run deletion, and some now help brokers test their own setup; DataGrail, for example, documents testing with CalPrivacy's synthetic sandbox data, matching validation and audit logs. Those tests are run by the broker on its own systems. ZeroKept is exploring checks an independent party could add, such as re-running a sample of matches and looking up consenting test-panel members in the broker's product after deletion. Whether that adds enough to be worth it is exactly what our research is testing.
What can independent testing not show?
Checking selected systems and samples cannot establish that every copy of someone's data has been deleted everywhere. Results only cover the systems, samples and time periods actually tested, and depend on the access a broker provides. Inconclusive results and missing evidence are recorded as findings rather than hidden.
Would ZeroKept see the data being deleted?
The design aim is to work from the minimum needed, such as counts, logs and one-way fingerprints of records, not full consumer profiles. Fingerprints that could be linked back to a person would still be treated as personal data. ZeroKept never buys, sells or reuses anyone's data.