New dataset retention obligation briefing agent
Problem
When a new system holds personal data, someone has to decide how long to keep it, and today that means one person in IT or data protection working from memory, a folder of old policy PDFs on the intranet, and whatever the previous data manager wrote in an email that is still in their sent folder. Special category data such as medical screening records gets treated the same way as a season ticket list because nobody wrote down why the previous determination was made. The retention register ends up populated with a date somebody guessed under time pressure, and the reasoning behind it is not written anywhere a colleague could find in twelve months.
Product idea
A research agent for the moment a new dataset or system is proposed. The data manager describes what is being collected, for whom, and why, for example medical screening records for an academy or ticket purchase records that include payment data. The agent searches the organisation's own policy documents and a maintained list of relevant regimes, such as UK GDPR and the Data Protection Act 2018, safeguarding standards, and records retention and audit trail requirements, and returns a briefing: which regime applies, what category the data falls into, what similar determinations exist in the organisation's own history, and the questions still open for the data protection officer to close. It does not set a retention date or write to the retention register itself.
Who it is for
Data managers and information security officers preparing a retention decision for a new system, and the Head of IT who sponsors the tool as part of keeping the retention register defensible.
Possible first version
A single form where the operator describes the dataset, its subjects and its sensitivity, against a curated set of internal policy documents uploaded once at setup. The agent returns a written briefing with citations to both internal precedent and the applicable regime, exportable as a document for the data protection officer to review. Out of scope for version one: any live connection to the document management system, automatic population of the retention register, and any output that states a compliance determination rather than a briefing for a human to act on.
- Build classification
- Workflow application
- Rough effort
- 4-6 week first release
- Roles involved
- Data manager, Information security officer, Head of IT
- Relevant to
- Professional club, Federation / governing body, League office
- Systems in play
- Document management and intranets, Spreadsheets, Messaging apps
- Product framing
- Research
Questions we get asked
What do we need to have ready before this is any use to us?
Your own policy documents, wherever they currently live in the document management system or the intranet, uploaded once at setup, plus a list of which regimes actually apply to your organisation. Without that corpus behind it the agent can only point at regime names in general terms, which is not much better than a web search. Most of the setup effort is gathering what your organisation already has, not building anything new.
Does this replace going to our data protection officer or legal team for a decision?
No. It produces a briefing with citations to the relevant regime and to how the organisation has decided similar cases before, which shortens the research the data protection officer or legal function would otherwise do from scratch. The retention decision and the sign off stay with them. Treat the output as an organised starting point for that conversation, not the answer to it.
Our data manager already emails the data protection officer and gets an answer eventually. Why build this?
That process works until the person who remembers the last three answers leaves, or until the same question comes up for a different system two years later and nobody can find the original email. This exists to make the reasoning searchable and consistent across the organisation rather than to replace the conversation with the data protection officer. If one person genuinely holds all of it in their head and that is not a risk you worry about, the case for building this is weak.
What does it deliberately not do?
It does not set a retention date, write to a retention register, or state that a dataset is compliant with anything. It produces a cited briefing that a named person uses to make that decision. Any output that reads as an automatic answer to how long something should be kept sits outside what this is built to do, because that determination carries legal weight this tool cannot carry.
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
- Access review attestation trackerReplaces the emailed access-review spreadsheet with a per-user confirm-or-revoke task for each system owner, producing a timestamped attestation record for audit.
- 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.
- Data retention and deletion obligation registerA register that tracks retention deadlines for datasets holding personal data across the technology estate and escalates to a named owner before deletion or review falls overdue.