Your customer data never touches our servers.

This isn't a policy promise — it's the architecture. California's DROP platform transmits only one-way SHA-256 hashes, never raw identifiers. PrivacyClock works the same way end to end.

How matching actually happens

1. The state sends hashes. Your DROP download is a list of SHA-256 hashes of the consumers who requested deletion — no names, no emails.
2. You hash your own records locally. When you upload your customer file, it's normalized and hashed inside your browser using a Web Worker. The raw file is read into memory and discarded; it is never transmitted.
3. We compare hash to hash. Matching is a set intersection of two hash lists. A match means "this consumer is in your database" without either side ever seeing the other's plaintext.
4. You act and report. You delete the matched records in your own systems and file a status code back to the state. We store the work-item IDs, statuses, and timestamps — the evidence — not the underlying people.

Validated against the official specification

A hashing bug would silently cause missed deletions and compliance failures. Our matching engine is golden-tested against all 14 test vectors the CPPA publishes — email, phone, DOB, ZIP, names (including accented and non-Latin scripts), MAID, VIN, CTV ID, and the NDZ and NameVIN composites — plus the sandbox standardization tool.

What we do store