Data Deletion
A campaign framework for removing an individual's personal data from the commercial data-harvesting ecosystem — breach-search engines, OSINT lookup tools, people-search sites, B2B contact databases, email-verification services, ad-tech audience brokers and threat-intelligence platforms.
Built from a real fifteen-week campaign against 329 organisations. Everything in
references/ is field-tested: the contact addresses are the ones that did not bounce,
the templates are the ones that produced deletions, and the failure modes documented in
references/troubleshooting.md are the ones that actually happened.
What this skill is not
It is not legal advice, and you are not the user's lawyer. It drafts requests that cite statute, and it can tell the user which regulator has jurisdiction, but every judgement call about escalating to a regulator or a court is the user's to make. Say so once, early, and then get on with being useful.
Step 1 — Build the subject profile
Erasure requests fail when they are vague. Before drafting anything, collect the profile.
Use AskUserQuestion where the interface supports it; otherwise ask in plain text. Never
guess these values and never carry them over from another user.
Required
- Full name, exactly as they want it to appear on forms. Ask specifically about
diacritics — many US-hosted forms mangle
í,ó,ü, and a request that arrives with a corrupted name is a request that fails to match a record. - Email addresses to erase. Most people have more than one, and the forgotten decade-old address is usually the one sitting in the breach corpora.
- Country of residence. This alone determines which law applies and therefore which template to use. Do not infer it from a domain or a language.
Ask for, but proceed without
- Usernames / handles. Several breach-search engines (Snusbase, DeHashed, Leak-Lookup) index by username, so a handle is a distinct search selector and needs its own request.
- Phone numbers, and current plus previous postal addresses — required by most US people-search opt-outs, irrelevant to most EU requests.
- Date of birth. Some US brokers demand it to disambiguate records. Warn the user before they hand it over: they are giving a data broker a new field it may not have had.
Never
Never ask for, transcribe, or place in a request: government ID numbers, passport or driver's licence numbers, payment-card or bank details, or a photograph of an identity document. Some brokers demand ID to "verify" a deletion request. Under GDPR Art. 12(6) a controller may only request identification that is proportionate, and a redacted document is normally sufficient. Tell the user to redact everything except name and photo, and to upload it themselves through the controller's own portal — you do not handle their identity documents.
Store the completed profile as profile.yml (see profile.example.yml), and keep it out
of any repository or shared location.
Step 2 — Choose the legal basis
Read references/privacy-laws.md. It covers thirteen regimes — GDPR, UK GDPR, Swiss
FADP, CCPA/CPRA and the other US state laws, PIPEDA and Québec Law 25, LGPD, POPIA,
Australia's Privacy Act, APPI, PIPA, DPDP and New Zealand's Privacy Act — with, for each,
the operative article, the statutory deadline, whether erasure is a real right or only a
deletion-on-request, and the regulator to complain to.
Three rules decide the framing:
- The subject's residence sets the floor, not the controller's address. GDPR Art. 3(2) reaches any controller offering goods or services to people in the EU or monitoring their behaviour. A US breach-search engine indexing an Irish resident's address is inside the GDPR's scope. Say so in the request.
- Cite every regime that plausibly applies, in one request. A controller with users in California and Brazil and the EU has no incentive to work out which law binds it if you name all three. This costs one extra sentence and materially raises the reply rate.
- Where the subject's own law is weak, borrow the controller's. A subject in a country with no erasure right can still invoke the controller's California or EU obligations where the controller's own privacy policy extends those rights to everyone — most do, because operating two pipelines is more expensive than operating one.
Step 3 — Select targets
references/site-registry.md (and the CSV beside it) lists 329 organisations across nine
categories with verified privacy contacts. Do not send all 329. Select by what the subject
is actually exposed to:
| If the subject… | Prioritise |
|---|---|
| appears in breach corpora / HIBP | Breach & leak search, Threat intelligence |
| is findable by email in OSINT tools | OSINT / email intelligence |
| has a public professional profile | B2B contact data & lead-gen |
| is a US resident or ex-resident | People search, Major data broker |
| wants ad-profiling reduced | Ad-tech & audience data |
| lives in the UK/DE/AT/BE/FR | Regional directory |
Start with the categories that publish data to the open web — breach search, OSINT, people search. Those produce visible results fastest and are the ones that hurt. Ad-tech is the largest category and the least visible; leave it for a later wave.
Before each wave, verify the contact address is still live. Companies get acquired,
privacy pages move, and privacy@ addresses are deprecated without notice. Check the
current privacy policy or /.well-known/security.txt. The registry's Notes column
records which addresses had already gone stale once.
Finding the sites a registry misses
A registry is a snapshot. This category churns faster than almost any other: new credential-search services launch monthly, old ones get hijacked or go dark, and the loudest names are not the ones holding the most data. Assume the list is incomplete and run these four sweeps at the start of every campaign.
1. Mine the aggregators for their upstream providers. The single highest-yield move. Services that resell breach data through one API publish the list of sources they query — it is a selling point. One such page named fifteen upstream providers, five of which appeared in no "best breach search" article anywhere. Those pages are a free target list written by the industry itself. Send the aggregator an Article 19 request naming its providers back to it, and ask which ones it forwarded the erasure to.
2. Search for the data type, not the site type. "Breach search engine" surfaces the
same eight famous names every time. The services that expose the most search on the
contents: stealer logs, combolist, ULP, infostealer lookup, plaintext passwords, session cookies, hardware ID. A site that returns a password next to the
URL it belongs to describes itself in those words, not as a "breach checker".
3. Read the alternatives-to pages, past page one. Comparison and alternative-listing sites rank the well-known services first and bury the small operators on pages two and three. The buried ones are usually the ones with no privacy page, no DPO and the least scruples — exactly the ones worth contacting.
4. Re-check a site that "has no email". A bounced support@ or a legal@ that
auto-redirects to a web form is not a de