Deletion verification log for athlete and fan data requests
Problem
When an athlete or fan asks for their data to be deleted, the data protection lead emails the CRM manager, the ticketing lead and the wearables vendor and asks them to confirm it is done. The replies land in the same messaging app thread as everything else: a thumbs up, a 'done', sometimes a screenshot of a deleted row. Nobody re-opens the warehouse table or the vendor portal to check the record is actually gone, because the confirmation message is treated as the proof. If a regulator or the athlete later asks for evidence, the file that exists is a chat message from someone who has since left, not a record of what any system actually contained on the day.
Product idea
A verification checklist tied to one specific deletion or consent request, not a general audit tool. Every system known to hold that person's data is listed as a line item: CRM, warehouse, registration database, wearables portal, ticketing platform. Whoever checks a system logs into it directly, attaches a screenshot or export line showing the record is gone, timestamps the check and signs their name to it. A request cannot be marked closed until every line has evidence attached. It does not perform the deletion itself and does not connect live to any vendor system: it is the record that someone looked, not the mechanism that does the looking for them. The output is one exportable file per request.
Who it is for
Data protection staff and data engineers who need evidence rather than a confirmation email, and the Head of data who would sponsor it as the accountable owner of the audit trail.
Possible first version
A single-request checklist: manually enter the systems that hold a person's data, attach a screenshot or text evidence file against each one, mark it checked with name and timestamp, and export a signed PDF once every line is complete. Requests are entered by hand rather than pulled from a consent tracker or a CRM record. There is no live connection to any vendor system in version one: someone still has to open the system and look. That is the point of the tool, not a gap to close later.
- Build classification
- Micro-tool
- Rough effort
- 10 day prototype
- Roles involved
- Head of data, Data engineer, Head of IT
- Relevant to
- Professional club, League office, Federation / governing body, Collegiate athletics
- Systems in play
- CRM, Data warehouse, Registration and membership database, Messaging apps
- Product framing
- Verify or inspect
Questions we get asked
What do we need before we can start using this?
A list of every system that might hold athlete or fan personal data, and who has access to check each one. That list is worth building even without this tool, because most organisations discover during a real deletion request that nobody has it written down. Version one takes that list as manual entry, so there is no prerequisite integration, only the harder organisational work of knowing where personal data actually lives.
We already have a spreadsheet that tracks deletion requests. Does this replace it?
No. A tracker that assigns and chases deletion tasks across systems is a different job, and if you have one, keep it. This tool only handles the step that spreadsheet cannot do: recording that someone actually opened each system and saw the record gone, with evidence attached. The two would sit side by side, with this one producing the file you hand over when someone asks for proof rather than a task list.
Our process already asks each system owner to confirm deletion by email. Isn't that enough?
It works until someone asks to see the evidence rather than the confirmation, at which point an email saying 'done' is not something a regulator or an athlete's lawyer treats as proof. The gap is not trust in your staff, it is that nobody re-opens the system to check. This tool asks for the same effort your process already spends and turns it into a screenshot and a timestamp instead of a sentence in an inbox.
Does it delete the data itself or check the systems automatically?
No, on both counts, and that is deliberate. It does not touch any vendor system and does not run automated queries against a warehouse or CRM. A person still has to log in, look, and capture what they saw. Automating that check is a reasonable next step once the manual version proves the evidence is actually being requested and used, but building the connections first, before anyone has asked to see the output, risks integration work nobody needed.
Is this your workflow?
Tell us one sports workflow that still runs on paper, spreadsheets, WhatsApp or an outdated system. We will map it and show you what a simpler product looks like.
Tell us about itMore in Data platform & engineering
- Access permission drift monitor for warehouse and reporting toolsA monitor that compares entity access rules across the identity provider, warehouse and reporting tool, and alerts a named owner when they drift out of sync.
- Attendance reconciliation report across ticketing and till systemsA reconciliation report that turns a ticketing export and a till export for the same fixtures into one defensible attendance and spend figure, with the variance between them shown and explained.
- Chat intake assistant that triages ad hoc data requestsA chat assistant that answers a data request instantly when the metric already exists, and turns anything new into a structured, tracked ticket instead of a message lost in a chat thread.