California DROP Starts August 1 with Ongoing Deletion Duties
Kaamel Lab 
Since January 2026, California residents have been able to use the Delete Request and Opt-out Platform (DROP) to submit a single deletion request to all active data brokers. Starting August 1, data brokers subject to the Delete Act and its implementing regulations must begin processing those requests.
Consumers need to submit the request only once and do not have to renew it periodically. A data broker’s responsibilities continue after the initial processing: current records must be deleted, service providers and contractors must receive processing instructions, and personal information obtained later must continue to be screened.
1. Businesses That Meet the Data Broker Definition Must Begin Processing on August 1
August 1 marks the start of the request-processing obligation. Before then, a business must determine whether it is a data broker under the Delete Act and arrange for DROP to operate alongside its existing CCPA deletion channels. Account creation, registration and fee payment, and request processing are subject to separate timing requirements.
(1) DROP Applies Only to Data Brokers Defined by the Delete Act
California law defines a data broker as a business that knowingly collects and sells to third parties the personal information of consumers with whom the business does not have a direct relationship. The DROP processing obligation applies on the basis of this definition. A business does not become subject to DROP solely because it is otherwise covered by the CCPA.
(2) DROP and the CCPA Right to Delete Apply in Parallel
Section 1798.105(a) of the CCPA allows a consumer to request that a business delete personal information the business collected from that consumer. After receiving a verifiable request, the business must delete the relevant information from its own records and direct its service providers and contractors to delete it. The business must also notify third parties to which it sold or shared the information. This third-party notice is excused where it is impossible or would involve disproportionate effort.
DROP preserves the channel through which consumers submit requests directly to businesses and adds a central channel operated by CalPrivacy. A consumer can use DROP to send one request to every data broker the consumer has not excluded. The Delete Act expressly preserves the application of the CCPA and uses relevant CCPA definitions and deletion exceptions. The grounds for retaining information may therefore include completing a transaction, security, debugging, legal obligations, and exemptions under Sections 1798.145 and 1798.146.
The Delete Act adds ongoing processing requirements for data brokers. After the initial deletion, a data broker must delete personal information subsequently obtained about the consumer at least once every 45 days and stop selling or sharing that information. The outcome may change if the consumer changes the request or a statutory exception applies. If a data broker denies deletion because a request cannot be verified, it must still process the request as an opt-out of sale or sharing.
(3) Account Preparation and Request Processing Begin in Stages
Businesses that operated as data brokers in 2025, and those that began brokering California residents’ data between January 1 and August 1, 2026, must create a DROP account and complete the applicable registration or fee payment. A business planning to start data brokering after August 1 must also create an account.
The request-processing obligation begins on August 1. From that date, a data broker must access DROP at least once every 45 calendar days and complete processing and status reporting within 45 days after downloading a list. It must also download the next list within 45 days of the previous download. Because download and processing periods may run consecutively, a status may take around 90 days to appear to a consumer. The legal deadlines continue to apply at the respective 45-day points.
A data broker that fails to register may face a fine of $200 for each day of noncompliance. Failure to delete information as required by the Delete Act may result in a fine of $200 per deletion request for each day of delay, together with the regulator’s investigation and administrative costs.
2. DROP Uses a 45-Day Statutory Processing Cycle
After preparing its account, a data broker must download request lists, match internal records, take the required action and report status during each 45-day cycle. Processing begins with selecting the request lists that correspond to the data the broker holds.
(1) Select Request Lists Based on the Identifiers Held
DROP produces six types of deletion lists based on identifiers supplied by consumers: a combination of name, date of birth and ZIP code; email address; telephone number; mobile advertising identifier; a combination of name and vehicle identification number; and connected TV identifier. A data broker must compare these categories with its own data and select all lists capable of matching personal information in its records.
The identifiers in the lists have already been hashed. Before comparison, a data broker must follow the technical specifications to convert case, remove special characters, standardise date, telephone number and ZIP code formats, and concatenate multiple identifiers as required. Internal records can be matched against DROP lists only after undergoing the same standardisation and hashing. Lists may be downloaded through an API or a DROP account. If an automated connection fails, the broker must provide written notice to CalPrivacy through its DROP account within the required period.
(2) Take the Required Action for Each Match Result
The result of the match determines the next action. Where a record matches one consumer, the data broker must delete all non-exempt personal information related to that consumer, including inferences derived from it, and direct service providers and contractors to delete corresponding records. Where one identifier is associated with multiple consumers, the broker must opt all associated consumers out of sale and sharing and send corresponding instructions to service providers and contractors.
If the current matching process finds no record, the broker must still retain the identifiers necessary for future screening. Those identifiers may be used only to comply with DROP, and the retained data must be limited in accordance with data minimisation requirements.
These steps must be completed within 45 days after the list is downloaded. The broker then reports a status such as deleted, opted out of sale or sharing, exempted, or not found. If information acquired later creates a new match, the broker must delete the non-exempt information and update the earlier status within 45 days after detecting the change.
3. Ongoing Deletion Must Be Integrated into Existing Data Processes
After one processing cycle ends, the original request continues to govern personal information obtained later. A business must connect the request record with the location of internal data, routine data ingestion, and the processing workflows of service providers and contractors.
(1) Matching Coverage Depends on Where Identifiers Are Stored
Identifiers for the same consumer may be distributed across customer databases, historical accounts, product back ends and vendor environments. Alias email addresses, changed telephone numbers, merged accounts and shared identifiers can also cause related information to appear as different records. A business should therefore identify where each type of identifier is held and which databases and products each matching run covers.
The DROP Sandbox can verify whether standardisation and hashing comply with the technical specifications. The distribution of internal data must be confirmed through the business’s own data inventories and system records. A “not found” status reflects only that no record was identified in the current matching run; its evidential scope depends on the systems and identifiers actually included.
(2) Ongoing Screening Must Be Part of Routine Data Ingestion
When a data broker purchases, collects or combines new data, it must compare the relevant records with the DROP requests it continues to maintain. Screening should occur before newly obtained personal information enters a sale or sharing process.
Ongoing screening requires the broker to retain a limited set of consumer identifiers. After deleting other non-exempt personal information, the business may retain only what is necessary to support matching, and only for DROP compliance. The fields, access permissions and retention arrangements for suppression records should be consistent with that purpose and should prevent their use in other business processing.
Data purchases, API imports and database merges may follow different ingestion paths. The business should determine where screening occurs in each path and prevent unscreened data from bypassing suppression records and entering downstream processing.
(3) External Processing Requires Records of Instructions and Outcomes
A business should identify which service providers and contractors hold relevant personal information and determine whether its contracts, interfaces and operational procedures support record location, instruction delivery and confirmation of results. The treatment of historical backups or multi-tier service provider arrangements requires a case-specific assessment based on applicable law, contractual arrangements and system capabilities.
When reporting a status to DROP, the data broker needs to be able to explain whether external processing has been completed. It may record the list download time, matching method, deletion scope, basis for an exemption, external instructions, execution feedback and status-upload time. These records remain subject to data minimisation and purpose limitation.
DROP requests must run through data procurement, data ingestion, vendor management and status reporting. A data broker should use consistent identifiers and processing statuses across these functions and complete screening before later data enters sale or sharing.
