How to Process DROP Deletion Requests
A single DROP processing cycle has a predictable shape. Getting it written down is what makes it repeatable across staff changes and 45-day cycles.
A single processing cycle
| Step | What happens | Common failure |
|---|---|---|
| 1. Access | Sign in to DROP within the required cadence and retrieve current deletion information. | No named owner, so the cycle slips. |
| 2. Select lists | Choose the deletion list types matching the identifiers you hold. | List selection does not reflect an actual identifier inventory. |
| 3. Standardize | Normalize your identifiers to the specified format before hashing. | Casing, whitespace, and formatting differences. |
| 4. Hash | Apply SHA-256 over UTF-8 input and represent output in Base64, including composite hashes where required. | Wrong field order or encoding in composite values. |
| 5. Match | Compare hashed values against the list and resolve related records. | Related records in other systems are missed. |
| 6. Act | Delete, suppress, or apply the applicable outcome, including exemptions. | Outcome applied in one system only. |
| 7. Report | Record and report processing status, and amend where needed. | Status not captured as evidence. |
| 8. Persist | Maintain suppression so later-collected matching records are handled. | Records reappear at the next ingestion. |
Operational recommendation
Write the cycle as a runbook with a named owner per step and the evidence each step produces. A cycle that only works because one engineer ran it is not an operational process.
Question to verify
How exemptions apply to your specific records, and what your retention obligations are for evidence of processing, are questions for counsel.
This page describes CA DROP Broker's operational reading of publicly available California materials. Verify current requirements against official CalPrivacy sources and with qualified counsel.