Data retention and deletion obligation register
Problem
The records retention schedule lives as a policy document in the document management system, several pages of categories and periods that nobody checks against what is actually held. Old player registration forms sit in a shared drive years after the retention period lapsed. A CRM export from a discontinued campaign, a scouting notes spreadsheet, a batch of consent forms from a youth programme that closed two seasons ago: none of it has an owner who knows it exists, let alone a date it should have been deleted. The data manager sends a reminder email once a year asking departments to check their own holdings, which catches whatever someone happens to remember and misses everything else. When a data subject access or erasure request arrives, nobody can say with confidence what is still held or how old it is.
Product idea
An obligation register listing every dataset that holds personal or sensitive data: the category from the retention schedule, the trigger date (registration date, contract end, programme closure), the calculated deadline and a named owner. Each entry sits in a status of upcoming, due or overdue. As a deadline nears, the owner gets a reminder; if it passes unconfirmed, the escalation moves to the information security officer. Confirming an entry requires the owner to state what happened: deleted, anonymised, or retained with a written justification and a new review date. Every confirmation is timestamped and kept as evidence. The register does not query source systems and does not delete anything itself; someone with access to the actual system still has to act, and this makes sure they are asked in time and that the answer is on record.
Who it is for
Data managers who own the retention schedule, information security officers who need audit evidence, and the department leads and service desk staff who hold the access needed to action a deletion.
Possible first version
A spreadsheet or CSV import of the retention schedule and the dataset inventory, with trigger date, calculated deadline and named owner per entry. A dashboard grouped by owner showing upcoming, due and overdue items, automated email reminders ahead of each deadline, and a confirmation form capturing action taken, by whom and when, as the audit record. Version one has no connection to the systems that actually hold the data: no automated discovery, no scanning of file shares or databases, and no deletion capability. Populating and updating the inventory is a manual step.
- Build classification
- Workflow application
- Rough effort
- 4-6 week first release
- Roles involved
- Data manager, Information security officer, Head of IT, Service desk lead
- Relevant to
- Professional club, League office, Federation / governing body, Collegiate athletics
- Systems in play
- Spreadsheets, Document management and intranets, Service desk and ticketing tools
- Product framing
- Manage compliance
Questions we get asked
What do we need to have ready before this is any use?
The retention schedule itself, with an actual period per category rather than general policy language, and an inventory of where data really lives: which datasets, which systems, which file shares, and a trigger date for each. If the schedule has never been broken down into periods, or nobody has ever mapped out where personal data sits, there is nothing for the register to track until that groundwork is done.
Does this replace our records retention schedule document?
No. The schedule stays the policy reference: which period applies to which category of data. This tool operationalises it by attaching a real deadline to a real dataset and firing a reminder before that deadline passes. Keep the document as the source of truth for the rule; this becomes the thing that tells you when the rule applies to something you actually hold.
We already have the data manager chasing this by email once a year. Why does that not work?
An annual chase catches whatever is on someone's mind the day it is sent, not the day a deadline actually falls. A dataset created in March might not get reviewed until the following January, ten months after it should have been actioned. The register raises the escalation against the real expiry date for each entry, rather than relying on a calendar reminder one person set for themselves.
Does it delete the data automatically once the deadline passes?
No, deliberately. Deletion has to happen inside the system that holds the data, by someone with rights to that system, in a way that can be checked afterwards. The register raises the obligation, escalates it if ignored, and records what the owner says they did and when. Automating the deletion itself would need write access into every system in the estate, and getting that wrong is a worse failure than a missed reminder.
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 IT, data, compliance & knowledge
- Certificate and domain renewal obligation registerA register of every TLS certificate and domain name renewal date across the technology estate, with a named owner and escalation before one lapses and takes a service down.
- Integration heartbeat monitor and owner escalation boardA live board of every integration's last successful run that escalates to a named owner before a missed sync turns into a bad report or an angry ticket.
- Internal policy and IT process chat assistantA chat assistant that answers routine IT and policy questions from existing documents and routes what it cannot answer to the service desk, instead of staff guessing or re-asking.