DROP Suppression and Ongoing Request Handling
Processing a request once is not the end state. Records acquired later that match a prior request generally require continued handling.
The recurring-collection problem
A consumer whose request you processed correctly can reappear through your next data acquisition. Without persistent suppression state, the record re-enters your sellable inventory and the outcome of the original request is effectively undone.
Design questions to answer
- Where does suppression state live, and who owns that store?
- Which pipelines — ingestion, enrichment, sale, sharing, export — consult it, and at what point?
- How is suppression represented for identifiers you only hold as hashes?
- What happens when a record matches partially rather than exactly?
- How are opt-out outcomes handled differently from deletion outcomes?
Put the suppression check as close to the point of release as possible. A check that only runs at ingestion misses records that change state after they are loaded.
How long suppression state must persist, and what may be retained for that purpose, are questions to confirm with 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.