Privacy Safeguards Built Into California's DROP Platform

DROP platform privacy safeguards combine separate residency verification, consumer choice over optional identifiers, encrypted storage, hashed broker matching, restricted broker access, purpose limits, and security duties. They reduce unnecessary exposure across the request flow, but they do not eliminate privacy or security risk.

The naming matters. The DELETE Act is the law enacted through SB 362. DROP is the Data broker Requests and Opt-out Platform created to implement the law’s accessible deletion mechanism. The statute and the effective DROP regulations establish legal requirements; DROP is the system through which eligible requests and broker responses move. The California DELETE Act overview explains that relationship in more detail.

DROP privacy safeguards at a glance

No single control carries the entire privacy burden. The design separates eligibility, request creation, matching, broker access, and reporting, with a different safeguard at each point.

Separation between eligibility and the request profile

Residency verification occurs outside the matching flow

The Agency must verify California residency before a consumer may submit through DROP under section 7620 of the regulations. CalPrivacy says the California Identity Gateway performs that eligibility check without requiring a DROP user to create a Gateway account. It also says information entered for the check is not retained by DROP or shared with the DROP request profile. After eligibility is confirmed, the consumer enters the identifiers that brokers will use for matching through a separate interface.

This separation limits function creep between two tasks. Residency information is used to decide whether a person may use the California mechanism; request-profile information is used to locate records. It does not mean DROP collects nothing else. The platform’s notice at collection says the Agency collects information entered into the request, along with usage time, device ID, and IP address, for stated purposes that include providing the request, enhancing the product, answering questions, and ensuring safety. The live notice should therefore be read before submission.

Optional identifiers create a controlled tradeoff

CalPrivacy’s current consumer instructions identify name, date of birth, and ZIP code as the basic information needed to submit, while email addresses, phone numbers, mobile advertising identifiers, connected-TV identifiers, and vehicle identification numbers can be added to support matching. The consumer chooses whether to supply those additional fields.

That choice is a data-minimization control, not a promise that the smallest profile will work equally well for every broker. A company that holds only an email address may not match a request that omits it. Conversely, adding a device or vehicle identifier expands the information held in the request system. The cautious approach is to weigh the value of a likely match against the sensitivity and relevance of each optional identifier, rather than entering every available value automatically.

Encryption and hashing perform different jobs

CalPrivacy states that data is encrypted when collected and before it is stored. It separately explains that DROP uses hashing so brokers can compare request identifiers without receiving the original values in their consumer deletion lists. These are related but distinct controls: encryption protects readable data through controlled transformation and access, while hashing produces a comparison value used in matching. The Agency’s personal-information explanation supports both descriptions but does not call them interchangeable.

The matching rules are more specific on the broker side. Under section 7613, a broker standardizes comparable information in its own records, applies the same hashing method identified for the deletion list, and compares the resulting values. For a list that combines multiple identifiers, the regulation prescribes additional combination and hashing steps before comparison. Raw profile values therefore are not the ordinary matching payload downloaded in those lists.

DROP also divides requests into identifier-based consumer deletion lists. A broker must select the lists corresponding to identifier categories it can match in its records, subject to the duplicative-list rule in section 7610. This limits routine access to list types relevant to that broker’s matching process. It does not make the broker’s own source records anonymous, and it does not prove that a particular matching implementation is error-free.

Broker-facing safeguards are enforceable duties

The regulations place controls on the account used to reach DROP. A broker must establish secure credentials, keep them confidential, restrict them to authorized persons, restrict access to DROP-derived information, and notify the Agency immediately of unauthorized account use or a related security breach. The broker is responsible for actions taken through its account under section 7610.

Separate use restrictions apply after information is obtained. Section 7616 permits a broker to use consumer personal information supplied by the Agency only to comply with Civil Code section 1798.99.86, prohibits selling or sharing it, and requires reasonable security procedures and practices appropriate to the information. The same rule bars the broker from contacting a consumer to verify a DROP request. This prevents the centralized request from becoming a reason for a broker to solicit more identity material directly.

Ongoing compliance requires narrow retention rather than indiscriminate reuse. When a request matches, section 7613 allows the broker to maintain the minimum personal information necessary to keep complying, while barring another purpose unless a statutory exemption applies. When no record matches, the broker must maintain the deletion list for the sole purpose of comparing later-collected records before sale or sharing. Service providers and contractors receive only the minimum information necessary for the specified compliance function.

These duties apply to entities covered by the statutory definition, not every company that stores personal information. The current California Civil Code defines the regulated category and its exclusions. A plain-language explanation of what a data broker is is useful orientation, but the current legal text controls coverage.

Consumer controls after submission

The consumer receives a DROP ID for status access, and CalPrivacy advises keeping it private. Reported outcomes show whether a broker states that it deleted a matched record, applied an opt-out after an ambiguous match, found an exemption, found no record, or has not completed processing. The official status explanation makes clear that “record not found” can mean either that the broker has no information or that the submitted identifiers did not produce a match. It should not be treated as proof that no relevant data exists anywhere.

Consumers can also exclude selected active brokers from receiving a request and later update the selected list through the official interface, according to the same CalPrivacy workflow. That selection control is useful when a person wants a direct relationship or first-party record left outside the centralized request. It does not change whether a separate California privacy right may apply to information held directly by a business.

Practical privacy checklist

• Enter DROP only from the official privacy.ca.gov route and confirm that any handoff remains on a government service.
• Read the current notice at collection before providing profile, device, or vehicle identifiers; the notice may be revised after this article’s publication date.
• Separate information needed for residency verification from identifiers being considered for broker matching.
• Add an optional identifier only after deciding that its expected matching value justifies placing it in the request profile.
• Keep the DROP ID out of public posts, shared documents, and messages to brokers; CalPrivacy specifically advises consumers not to share it in its official instructions.
• Treat any broker message asking for identity verification of a DROP request cautiously, because section 7616 prohibits that contact.
• Interpret status labels as broker-reported matching and processing outcomes, not as security certifications or universal proof of deletion.

What the safeguards do not guarantee

The official descriptions support a careful conclusion: DROP reduces raw-data distribution, separates eligibility from matching, gives consumers some control over inputs and recipients, and imposes access, purpose, retention, and security duties on brokers. They do not support claims that the platform is risk-free, that hashing makes all reidentification impossible, or that every record will be matched and deleted. Statutory exemptions, first-party information, incomplete matching, and broker compliance can affect the result under the current law and regulations.

A DROP submission is one specialized consumer request. Direct access, correction, deletion, or opt-out rights under the broader California privacy framework may require a different channel, depending on the entity, data relationship, requested result, and applicable exceptions. This article provides general information, not legal advice.