DROP Privacy runs the same idempotent, checkpointed sequence from a background worker each cycle. Here's exactly what happens — and where your data does and doesn't go.
Nothing about the cycle requires a human watching a screen. It's started by a worker or cron, survives a crash, and can be safely re-run.
Your consumer identifiers (name, email, phone, date of birth, VIN, and more) are normalized and transliterated to a canonical form, then hashed. The result is a reverse hash index: one row per identifier hash pointing back to the source record. It's built incrementally using a high-water mark, so new leads are folded in without re-scanning everything, and stale entries are purged on a schedule.
The cycle pulls the outstanding request file from California's DROP platform and matches each consumer's hashes against your index. Because both sides are hashed and normalized identically, matches are exact and reproducible — and the comparison happens without either party exchanging raw personal information.
Each record gets a status: deleted, exempt (a lawful basis to retain), opted-out, or not found. The decision rules are configurable per tenant, so a broker's specific exemptions and identifier weighting are honored without changing the engine.
DROP Privacy answers through the DROP API (new responses and corrections each go through their correct endpoint), redacts or suppresses matched leads, and adds each consumer to a forward-suppression list so their future imports are rejected automatically. Every action is sealed into a hash-chained audit log that produces a proof-of-deletion lookup and a printable attestation.
We'll walk you through indexing, matching, deciding, responding, and the attestation it produces — on sample data, in one short session.