California's DROP deletion platform for data brokers

What's DROP?

DROP stands for the Delete Request and Opt-out Platform, the California Privacy Protection Agency's deletion system. A consumer files one deletion request that every registered data broker must then process. It's designed to give consumers more control over their data.

Data brokers have a recurring duty to process deletion requests every 45 days. To take part, a broker registers with DROP, pays an access fee, and integrates its systems with the platform. The penalty for missing a request is $200 per request, per day.

Deletion request

A download from DROP is a compressed file of consumer deletion lists, one CSV per list type selected by the broker. A list type is a set of one or more consumer identifiers, such as an email address, or a name with date of birth and zip code. Each row holds a work item ID and a hashed identifier. The raw identifier is not shared with brokers; the file contains only its hash. Brokers follow the same hashing algorithm to check for a match. There are six list types.

List Type	Description
Email	email address
Phone	phone number
MAID	mobile advertising ID
CTVID	connected TV ID
NDZ	first name, last name, date of birth, zip code
NameVIN	first name, last name, VIN

Matching

To find who is on the list, a broker hashes its own records the same way and compares the results. A matching hash identifies the consumer for deletion.

Reporting

A broker is required to direct its service providers and contractors to carry out the same deletions and opt outs. It then reports an outcome for every deletion request by work item ID. There are four status codes.

Code	Status
2	Exempted. A match was found, but all the matched consumer's data is exempt from deletion.
3	Deleted. A match was found, and the data was deleted.
4	Opted out. Multiple consumers share the identifier, so all were opted out of sale or sharing.
5	Not found. No match was found in the broker's records.

Deletion workflow

Processing a deletion request is a standing duty. The diagram below traces one 45 day cycle, from the download to the status report.

The diagram is the simple view. A broker rarely keeps consumer data in one place. Brokers include people search and advertising audiences, credit and risk, location, and health data. Each spreads a person's record across many systems. A deletion has to reach all of them:

• Primary records. Operational databases and their replicas.
• Full copies. Data warehouses, lakes, the CDP, DMP, or CRM profile, backups, and archives.
• Fast lookups and streams. Caches, search indexes, event streams, and queues.
• Trails. Logs and audit records that captured the data in passing.
• Ad hoc exports. Spreadsheets, third party processors, and SaaS tools.
• AI and analytics. Analytics extracts, inferred data, model training sets, and feature stores.

Some of the hardest parts of the cycle do not appear in the diagram:

• Shared identifiers. A single identifier can belong to more than one consumer. When it does, the broker cannot tell which one the request is for, so it should opt every matched consumer out of sale and sharing rather than delete.
• Exemptions. Some matched data may be kept: data collected from the consumer as a first party, and data under laws like FCRA, GLBA, and HIPAA, or held for legal claims, security, and fraud prevention. Each case is decided on its own facts. Review at least a sample before reporting a record as exempt.
• Guardrails against deleting the wrong data. Matching is exact and deletion can be permanent across backups. One mapping or standardization slip can erase data the broker is entitled or required to keep. A safe pipeline previews how many records a run would touch, holds large runs for a person to confirm, samples the matches, and logs every deletion.
• Ongoing obligations. Beyond a single cycle, the broker keeps each request on file and screens newly collected data against it so the consumer is not sold again, publishes its request metrics each year, and from 2028 undergoes an independent audit every three years.

Open source hash functions

Ozvel publishes open source DROP hashing functions in Python, JavaScript, Java, Go, PHP, and C#. A sample test file is provided for brokers to test their system. Find it at Ozvel/california-drop on GitHub.

Potential sources of error

Standardization

Before hashing, DROP requires each value to be standardized. The rules are exact, and a small difference produces a different hash. Here are some examples.

• Case. Every identifier is lowercased first.
• Names and scripts. Accents fold to plain letters, so José becomes jose, but Chinese, Japanese, Korean, Arabic, and Hebrew characters are left as written. A name stored in one form, such as a romanized spelling, but submitted to DROP in its original script, will not match.
• ZIP leading zeros. The rule removes leading zeros, then takes the first five characters, so 07090 becomes 7090 and 00501 becomes 501.

Specification errors

We reviewed CalPrivacy's published examples on June 1, 2026 (docs version 1.0.0). For the CTVID list type, the hash printed in the docs did not match the hash we computed from the docs' own standardized value. Brokers should test their system thoroughly.

Composite order

NDZ hashes each field, concatenates the Base64 digests in a fixed order, then hashes the result. A wrong order produces no matches.