California DROP FAQ
How many consumers have signed up for DROP?
Currently, there are over 350,000 California consumers who have signed up for DROP. That being said, many consumers have submitted multiple emails so if you maintain email in your systems, you will need to process more than 350,000 requests to delete email addresses. On the other hand, CalPrivacy has reported that only about 10% of registered consumers have input a MAID or CTVID.
Is the DROP Sandbox live?
Yes, you should be able to log into your account now and access the DROP API as well as download a synthetic dataset and example DROP requests from individuals. We recommend you login and play around in the sandbox ASAP because you want all the processes in place before the August 1, 2026 start date. If you choose to access DROP via API, in your account you will create a unique key for accessing the sandbox API. You will need to create a Production API key for accessing the real data when the DROP goes live.
Can I access real requests now?
Our understanding is that you should only have access to the sandbox right now. It's possible that data brokers are able to process real requests from consumers a few days before August 1, but data brokers will not be able to access real consumer requests much in advance of August 1, so be prepared to process the 350,000+ requests in August.
When uploading how we processed requests, what does “Record Exempted,” “Record Deleted,” “Record Opted Out,” and “Record Not Found” mean? When do we state these responses?
“Record exempted” means that a match was found, but the data is exempt under Civil Code §1798.99.86(c)(2). There are a few potential exemptions at play here, for example, the information is public record, it needs to be kept for security purposes, or it needs to be kept to comply with legal obligations (e.g., you're required to retain that information under law or its subject to an ongoing/potential litigation).
"Record deleted” means a single match was found and non-exempt personal information was deleted.
"Record opted out” means multiple consumers in the data broker’s systems were matched to the DROP request and the data broker opted all matches out of sale or sharing. To be clear, the obligation is to delete records, but if you can't delete a record for some reason (like because of the above exemptions or because the individual matches multiple individuals in the data broker’s systems) then you need to apply an opt out for that record so that even though you maintain that record, that record won't be sold or shared. Essentially, you need to maintain a suppression list. That being said, the suppression list should be made up of all requests received (requests to delete and requests to opt out), so that individual's data is never sold/shared again.
"Record not found” means there were no matches found. This applies if there is no match (as opposed to the above, where there are multiple matches).
But what happens if a match is found subsequently? Should we send "Record deleted" or "Record Opted-out"? If you report a particular record with a status like "not found" but then later find the record (meaning you may have made a mistake somewhere in the processing of the consumer deletion list or didn't suppress successfully, or data was added to the record later that then matched on the latest deletion sweep) then you use the POST /data/amend API call to update the recorded status code for that particular list ID to deleted. The suppression list should enable you to catch matching records up front and prevent their data from being sold/shared when you run new data against the suppression list.
We aggregate data from vendors who themselves are supposed to be complying with DROP. Do we still have to access DROP? And if our data providers are fully compliant, we should really have no matches because we are downstream from them, right?
Ideally, yes, if you are just aggregating the data from registered data brokers, but, as a registered data broker yourselves, you still have to access DROP. Data may slip through the cracks and in fact, many entities that should be registered as data brokers are not, so you may still see data coming in that should be deleted. Also, the law doesn't have any carve outs for companies that aggregate data from registered data brokers, meaning that even if all your data providers stop sending DROP data, you still have an obligation to access DROP every 45 days (and remember, noncompliance faces steep, bankrupting fines).
The DROP sandbox only has synthetic data available. Will I be able to access the 350,000 requests before August 1?
It sounds like data brokers will only be able to access synthetic data until August 1. That means that data brokers will not be able to get a head start on requests. However, this is yet to be confirmed by CalPrivacy.
How do data brokers comply with the suppression list?
The Delete Act requires data brokers to maintain a suppression list of consumers who have exercised their rights via DROP. Recently, CalPrivacy clarified that the suppression list can be maintained in the data broker’s format and identifiers. In other words, the suppression list doesn’t have to be in DROP format or hash. This will make it simpler for the data broker to regularly review their databases against suppressed consumers.
Moreover, DROP requires data brokers to forward any requests data brokers have processed via DROP to any downstream service providers or contractors with which the data broker has disclosed that consumer’s personal information. This forwarding requirement is in the 45 day timeframe of DROP.
Can authorized agents use DROP on behalf of consumers?
Yes, authorized agents can upload requests on behalf of consumers. However, currently DROP has no mechanism for authorized agents to bulk upload requests (no API or anything). Not to mention, authorized agents may be technically challenged to validate email addresses and phone numbers submitted to a consumer record.
What is the risk of noncompliance? What are the potential fines?
There are a couple of ways to not comply with the Delete Act and DROP.
The first is to not register with DROP. That fine is $200 per day plus the registration fee of $6,000. Even if a company has not yet registered with the state as a data broker, if the company is operating as a data broker, there is still the obligation to register for DROP and begin processing requests in August.
The second way to not comply is to not access DROP and process your ‘consumer deletion list(s)’ at least every 45 days. The fine for this is $200 per day per request. This means that if a data broker doesn’t comply for even just 1 day, the data broker could be fined up to $70,000,000 ($200 x 1 day of noncompliance x potentially 350,000 matching requests). These are bankrupting fines, which is why we encourage you to play in the DROP sandbox now and make sure that the process is familiar to you so when August 1 rolls around, you’ll be prepared.
What file formats and data fields does DROP accept for matching? And what counts as a “match”?
Based on the data DROP collects from consumers, there are six defined ‘consumer deletion lists’:
Each list is provided as a two-column csv text file, where the first column has a unique, sequential ID number for each record, and the second column has the single hashed value of the consumer’s data (whether it’s from a single value or concatenation) to be used for matching purposes. The ID numbers are sequentially unique per list but not across lists.
DROP requires a data broker to normalize data associated with the data used to make the lists following specific rules, and then to hash the data using a UTF-8 based SHA256, Base64 methodology. In the case of a single field list, like email address, a match occurs when the properly hashed version of an email held by a data broker is identical to the hashed email record provided by DROP. In the case of a composite hash, the data broker hashes each field individually first, and then concatenates all the hashes in order, and hashes that value again. In other words, for say NDZ, the final hash a data broker would compare to DROP could be represented as “HASH [ Hash(FirstName) + Hash(LastName) + Hash(DOB) + Hash(ZIP) ].” If that multi-hashed composite equals the hashed value provided by DROP there is a Match.
What issues might prevent my data from matching with the DROP ‘consumer deletion list’ data?
If your dataset does not include the exact same information as the DROP list is based on, you will not be able to make a match. For example, if the hashed emails you hold have been encrypted and you do not have the decryption key or the original clear-text emails, you will not be able to make a match. Likewise, if you hold birth month and year, but not birth day, then your hash of DOB will not match the data from DROP rendering your NDZ composite hash not to match any DROP hashes either. Another issue could be that the DROP hashes are based on consumers’ legal first names, such as Daniel and Lawrence, but your dataset has preferred first names such as Dan and Larry. This will also prevent a match because data brokers are not obligated to theorize all the possible versions of a name to hunt for matches.
Vendor obligations/what exactly must be forwarded?
If a data broker has a match to delete, the data broker must forward that deletion request downstream to all service providers and vendors with which the data broker disclosed the consumer’s personal information. This can be in any format; it doesn’t have to be in the format of the DROP consumer deletion lists.
If a data broker has multiple matches under DROP, the data broker must opt all of the matched records out. This opt out must be forwarded to all downstream to service providers and vendors with which the data broker disclosed the consumers’ personal information. Like with the forwarded deletes, this can be in any format; it doesn’t have to be in the format of the DROP consumer deletion lists.
If I operate in an environment where I receive and sell/share data in real time (like RTB) how does DROP apply to me?
When a match occurs, DROP requires that the personal information of all registered consumers is both deleted AND suppressed from future sale/share. Therefore, data brokers operating in real-time environments must very quickly hash relevant incoming data according to the DROP specifications and compare the result to the most up-to-date version of your suppression list. Since this may be a technical or latency burden for some data brokers, we encourage a company’s engineering staff to be engaged as soon as possible to investigate solutions.
This FAQ was originally published at https://lucidprivacy.io/drop-faq.
