Honoring deletion requests without exposing PII: the hash-matching approach
· 2 min read · DROP Privacy
The privacy paradox of a deletion law
The California Delete Act exists to reduce the amount of personal data circulating about consumers. So there is a real irony in the obvious way to comply: take the state's list of consumers, take your own consumer database, and compare them — which usually means copying sensitive lists of names, emails, and phone numbers between systems. A tool that answers a privacy law by spreading personal data around defeats the purpose.
There is a better way, and it hinges on never comparing raw personal information at all.
What is privacy-preserving hash matching?
Instead of comparing raw identifiers, both sides compare hashes — fixed-length fingerprints derived from an identifier. A hash is one-way: you can produce it from an email address, but you cannot reverse it back into the email. If your records and the DROP batch are hashed the same way, two hashes match if and only if the underlying identifiers match — without either side ever handling the other's raw data.
Why doesn't a hash leak the original value?
A cryptographic hash is deterministic and irreversible: the same input always produces the same output, but the output reveals nothing usable about the input. When the hashing is also salted and normalized consistently, matching stays exact and reproducible while the raw name, email, phone, or VIN never leaves your systems.
Normalization is what makes matching reliable
Two systems will only produce the same hash if they first reduce an identifier to the same canonical form. Jose, josé, and JOSE should all match; (415) 555-0100 and 4155550100 should too. That requires careful, identical normalization and transliteration on both sides before hashing. Get it right and matches are byte-exact; get it wrong and your match rate silently collapses — which is why this logic has to be verified against the platform's answer key, not just assumed.
What actually crosses the boundary
With this approach, the only things that ever leave your perimeter are:
- Hashes — not the identifiers behind them.
- Statuses — deleted, exempt, opted-out, not found.
- Audit metadata — enough to prove the action, not the person.
Raw consumer PII stays inside your database. With an on-premise option, even the hashing happens on your own infrastructure, so nothing identifiable moves at all.
The goal: complying with the deletion law should reduce your data-exposure risk, not create a new copy of every consumer list to leak.
Compliance that doesn't create new risk
This is the core of how DROP Privacy is built — it indexes your data into a privacy-preserving hash index, matches the DROP batch each cycle, and produces a tamper-evident proof of deletion, all without taking custody of consumer PII. Read more on the security model, or request a demo to see exactly what does and doesn't cross the boundary.
See DROP Privacy run a full Delete Act cycle on sample data. Request a demo →