Home › How it works
How we do it

One repeatable cycle, every 45 days

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.

Plain English: a hash is a one-way fingerprint of an identifier — we can compare fingerprints without sharing the original name or email. A reverse index lets us look up "does this deletion request match anyone in our database?" in seconds. Forward suppression means once someone is deleted, their future leads are blocked automatically. Attestation is the printable proof you keep for auditors.

The pipeline at a glance

Index → Match → Decide → Respond

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.

  • Background-only. Heavy work runs from a CLI worker or cron, never an HTTP request that can time out.
  • Resumable. Each stage checkpoints to the database, so a failure resumes where it left off.
  • Idempotent. Re-running a cycle never double-deletes or double-responds; corrections go through a dedicated amend path.
The Drop Privacy pipeline: lead data to hash index, matched against the state batch, decided, responded, and audited.
Step by step

What each stage does

1

Index — build a privacy-preserving map

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.

2

Match — against the state deletion batch

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.

3

Decide — classify every record

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.

4

Respond & prove — and suppress forward

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.

Three ways to onboard

Pick the path that fits your data — as simple as 1 · 2 · 3

However your leads live today — in database tables, in massive CSV exports, or behind a wall where nothing is allowed to leave — Drop Privacy meets them there. Every path ends the same way: matched against the state batch, deleted, and provably attested.

Step 1: your source tables of consumer identifiers. Step 2: we normalize and hash them into a privacy index. Step 3: the DROP cycle matches, deletes, and produces proof.
Use case 1 · Connect your tables

You have source tables of leads

Point us at the tables where your consumers live — first name, last name, date of birth, ZIP, phone, email, VIN, MAID, CTV ID. We handle the rest.

  1. Map your columns — a one-time mapping tells us which column is which identifier.
  2. We index — every identifier is normalized and hashed into a privacy-preserving index. Nothing is stored as readable PII.
  3. We cycle — each 45-day batch is matched, decided, answered to the DROP API, and sealed with a proof-of-deletion attestation.
Step 1: upload a CSV of raw leads or pre-hashed records. Step 2: it is streamed into the hash index at any scale. Step 3: the DROP cycle matches, deletes, and produces proof.
Use case 2 · Upload a file

You have a big CSV export

No database connection needed. Upload a delimited file of leads — or, if your team already hashes to the DROP spec, upload the pre-hashed records and skip sharing raw PII entirely.

  1. Upload — drop a CSV of raw identifiers, or a pre-hashed file in DROP's format.
  2. We import — the file is streamed straight into the hash index, scaling to billions of rows without loading it all into memory.
  3. We cycle — the imported index is matched against the state batch, decided, answered, and attested.
Step 1: an on-prem agent indexes and cycles inside your network so PII never leaves. Step 2: only hashes and reports reach the Drop Privacy dashboard. Step 3: the dashboard submits to DROP with proof.
Use case 3 · On-prem agent

Your data never leaves your network

For brokers who can't share PII or hashes off-site — or whose database is simply too large to move — deploy the Drop Privacy agent inside your own perimeter. It does the heavy lifting locally; the dashboard stays in control.

  1. Deploy the agent — a headless service runs on your Windows or Linux server, reading your source database in place. PII never crosses the boundary.
  2. It indexes & cycles locally — hashing, matching and (optionally) deletion happen inside your network; only hashes, progress and reports flow to the dashboard.
  3. The dashboard submits to DROP — orchestration, approvals, reporting, audit and the proof-of-deletion attestation all live in the dashboard, exactly as the other paths.

Available now. Download signed Windows or Linux installers from your dashboard after onboarding. The agent indexes and cycles inside your network; only hashes, progress, and reports reach the coordination plane. See the security model or request a demo to walk through deployment.

Want to watch a cycle run end-to-end?

We'll walk you through indexing, matching, deciding, responding, and the attestation it produces — on sample data, in one short session.