The whole job is four things: know which rules apply to you, process every DROP cycle correctly, keep deleted consumers deleted, and be able to prove all of it two years later. This is how each of those works in the app, followed by the questions people actually ask.
Roughly twenty minutes, once. Everything afterwards is built from what you enter here.
Answer the questions about where you handle data about people and what you do with it. The answer sets which of the eleven jurisdictions apply, and everything downstream — obligations, deadlines, registration packets — is filtered by it.
Being registered in California does not automatically mean Texas or Vermont apply, and the erasure regimes (GDPR, LGPD, PIPEDA, Quebec Law 25) attach to processing personal data whether or not you consider yourself a broker.
Legal name, addresses, the contact who owns privacy, and the disclosure details. Every registration packet and every consumer-facing disclosure is assembled from these fields, so the dashboard blocks registration until the required ones are filled.
The same screen asks ten CCPA threshold questions, including three about your own opt-out form — whether it asks for a Social Security number, an ID document, or account creation. Those three exist because CalPrivacy fined LocateSmarter $116,490 in August 2026 for exactly that, and any one of them on its own is enough to raise a critical finding.
Shows which of your jurisdictions run a broker registry, what each one needs, and what is still missing. Not every regime has one — the erasure regimes impose duties without a register.
Worth doing first. Registration failures are the easiest thing for a regulator to find, because the register is public. Every CalPrivacy fine before August 2026 was for failing to register, not for mishandling a request.
California requires every registered broker to access DROP at least once every 45 days, match the deletion requests against its own records, act on each one, and report an outcome. This is the part that repeats, and the part that accrues $200 per request per day when it goes wrong.
Stamps the access date and starts the 45-day clock. The Compliance Clock and the dashboard both count from this, and the audit simulation flags the gap if the next cycle is late.
DROP publishes deletion requests as SHA-256 hashes across six separate lists. Each is its own download and its own matching pass — a request that arrives on the Name + DOB + ZIP list will not appear on the email list.
| List | What it matches on |
|---|---|
| Email address | |
| PHONE | Phone number |
| MAID | Mobile advertising ID |
| CTVID | Connected-TV identifier |
| NDZ | First name + last name + date of birth + ZIP |
| NAMEVIN | First name + last name + vehicle identification number |
The last two are composite: each field is hashed separately and the digests are then hashed together. Getting that order wrong produces perfectly well-formed hashes that match nothing — it is the single most common way a DROP integration fails silently.
The DROP list, and a CSV export of your own records. Any export works — the app reads your headers and guesses the column mapping, and you correct anything it got wrong before running. Then tell it which of the six lists you are matching.
Neither file is uploaded anywhere. Both are read into the browser tab and matched on your machine. The page cannot open a network connection, so there is nowhere for them to go.
Matching sorts every row into four buckets, and each maps to what you owe:
| Bucket | What it means | Report |
|---|---|---|
| In your data | A real match. You must act on this consumer. | 3 deleted |
| No match | Not in the records you supplied. | 5 not found |
| Ambiguous | Enough signal to be a person you hold, not enough to delete confidently. | 4 opted out |
| Missing fields | Your rows lacked the fields this list matches on. Not a result — a gap in the export. | — |
The fourth bucket is the one to watch. A large "missing fields" count usually means the CSV you exported does not contain the identifier this list uses, so the pass proved nothing. Re-export with those columns rather than reporting not-found.
Delete or opt out each matched consumer wherever you actually hold them, and pass the instruction to any service provider you have sold or shared that data with. Record an exemption only where you have a statutory basis, and write the basis down — an unexplained exemption is the first thing an audit asks about.
Writes the final entry in the cycle's hash chain. From that point the record is tamper-evident: changing any earlier entry breaks the chain, and Verify integrity will say which entry changed.
Deletion is a state, not an event. A consumer you deleted in July who reappears in a list you buy in September has to be blocked — and re-acquisition is invisible, because the cycle was processed correctly and the outcome was reported correctly. Nothing errors.
Upload the acquired list. It is checked against everyone you have already deleted or opted out, and the blocked rows are separated out. Download them as CSV if you need to show a supplier what you removed and why.
Do this before the data reaches your systems. Screening afterwards means the obligation has already restarted.
Runs the 2028 independent audit against your current record and prices the gap: cadence breaches, exemptions with no recorded basis, records never searched, registrations not filed. Anything it cannot determine is left unpriced rather than billed, so the number you see is a floor, not a scare.
A self-describing record of every cycle, every request and every outcome, carrying its own hash chain. Your auditor recomputes the chain with any SHA-256 tool and gets VERIFIED or the identity of the altered entry. They never need our software, and they never need to trust us.
The same screen generates the privacy-policy disclosure text your jurisdictions require.
Exports the entire record as one file, and restores it on any machine. Because nothing is on our servers, this is your only copy. Back up after every closed cycle.
Restore is atomic. A backup file is validated in full before anything is written, so a corrupt or truncated file fails cleanly and leaves your existing record intact. It will never half-import.
No, and you do not have to take our word for it. The site sends a Content-Security-Policy
containing connect-src 'none'. That instructs the browser to block every outbound
connection the page could make — fetch, XHR, WebSocket, beacon. It is enforced by the browser,
not promised by us.
Your security reviewer can confirm it in about ten seconds:
curl -sI https://mcstanding.millennialscreatives.com | grep -i content-security
In your browser's local storage, on the device you are using. There is no server holding it, because there is no server. That is why Backup and restore matters more here than in a cloud product — the export file is your copy of record.
The record goes with it, exactly as a spreadsheet on that laptop would. Export a backup after every closed cycle and keep it wherever you keep your other compliance records. This is the honest cost of the architecture: in exchange for your consumer data never leaving the device, you own the durability.
Not at the same time. Sharing means exporting a backup on one machine and importing it on the other. If you need several people operating cycles concurrently, tell us — that is a genuine limitation of local-first, not something we are pretending away.
No. You download the DROP lists and submit outcomes through the DROP platform yourself. The app does the matching, the record-keeping and the evidence — the error-prone parts, and the parts an audit examines. A tool that could submit on your behalf would need network access, which would end the guarantee above.
Yes, and this is the point of the format. The evidence file states its own hash chain. An auditor recomputes it with any SHA-256 implementation. If an entry was altered after the fact, the chain breaks and the file identifies which one. They do not install anything, and they do not contact us.
You keep them. The record is in your browser and in your exported backups, and evidence files stay readable and verifiable with no software from us at all. Nothing is held hostage, because nothing is held.
Yes. Download the single-file build — the entire
application in one HTML file. Open it from disk with the network off and it works. One caveat:
browsers do not expose WebCrypto to pages opened from file://, so a licence cannot be
checked there; serving the same file over http://localhost resolves it.
Ten, as separate profiles rather than one blended checklist: California, Texas, Oregon, Vermont, Connecticut and New Jersey (registries), plus EU GDPR, UK GDPR, Brazil's LGPD, Canada's PIPEDA and Quebec Law 25 (erasure duties). Connecticut's law takes effect 1 October 2026, with registration from 1 January 2027.
Two things most tools do not do. Suppression screening, so a consumer you deleted cannot be silently re-acquired in your next data purchase. And evidence a third party can verify without you — most platforms produce a report that asserts compliance rather than a record that demonstrates it.
It is tested against CalPrivacy's published conformance vectors, not against our reading of
the spec. That distinction caught two real bugs during development, both of which produced
well-formed hashes that matched nothing. Run npm test on the source — the suite runs
CalPrivacy's published vectors, and both of those bugs fail loudly if anyone reintroduces them.
No. It is software that runs a process and keeps a record. Where a question turns on your specific facts — whether an exemption applies, whether you are a broker at all — the app tells you to get advice rather than guessing on your behalf.
Something here unclear or out of date? The guide should match the app exactly — if it does not, that is a bug in one of them.