Leaver access deprovisioning tracker
Problem
Human Resources (HR) notifies the IT team that someone has left through an email or a line in a leavers spreadsheet, and a service desk ticket gets raised to disable the identity provider account. That ticket closes the moment the single sign-on login stops working, but access to the CRM (the system holding customer and fan records), the finance system, a handful of shared drives and the odd tool a manager set up directly with a vendor was never on that ticket. Nobody holds a single view of what a given leaver could still open, so the gap only surfaces when an access review ahead of an audit turns up a former employee whose email account is dead but who could still log into the document management system three months after their last day.
Product idea
A live board that lists every leaver against every system in scope: the identity provider, the CRM, the finance system, the shared drives, the lot. Each system carries a status of revoked, pending or overdue, and a countdown set by the access policy, for example a fixed number of working days after the last day of employment. Once a leaver crosses that threshold on any system, the board escalates to the named owner of that system rather than to IT in general, and keeps escalating until someone marks it done with their name and a timestamp. It produces an audit trail of who was told and when. It does not revoke access itself; confirming an account is disabled stays a person's job. The tool makes sure that job cannot quietly go undone.
Who it is for
Service desk staff who process leaver tickets, the Information security officer who has to answer for gaps at audit, and the Head of IT who sponsors it because the current process only proves what has been remembered, not what has been done.
Possible first version
Version one runs on a manually uploaded leaver list from HR and a fixed, one-off list of in-scope systems with a named owner and a policy deadline for each. Status per system is set by a person ticking a box with their name attached, not by checking any system automatically. The board shows red, amber and green per leaver and system, and sends an escalation email when a deadline is crossed. Out of scope for version one: any live connection to the identity provider or other systems, and any automated revocation.
- Build classification
- Workflow application
- Rough effort
- 4-6 week first release
- Roles involved
- Head of IT, Information security officer, Service desk lead
- Relevant to
- Professional club, League office, Federation / governing body, Venue & stadium operator
- Systems in play
- Identity and access management, Service desk and ticketing tools, Document management and intranets
- Product framing
- Monitor
Questions we get asked
What do you need from us on day one?
A leaver list from HR in whatever form you already produce it, even a spreadsheet, and a short one-off exercise to agree which systems are in scope, who owns each one, and how many days your policy allows before access must be gone. No connection to your identity provider is needed to start. Version one runs on that manual list and gets more useful once a few real leavers have moved through it.
We already close a ticket in the service desk tool when someone leaves. Isn't that the same thing?
Not quite. That ticket usually closes the moment the identity provider account is disabled, which is one system among several. It says nothing about the CRM, the finance system or a shared drive a manager set up without telling anyone. This board stays open across every system in scope until each one is confirmed, and it escalates on its own if a deadline passes, rather than waiting for someone to reopen the original ticket.
Does it actually revoke the access, or just tell us it is still there?
Just the second, deliberately. Version one records status and escalates; it does not log into anything or disable an account on its own. Handing an unattended tool the ability to cut someone's access carries its own risk, particularly if a leaver date turns out to be wrong. Automated revocation is a reasonable next step once the tracking has proven itself, not a starting assumption.
Who has to keep this updated once it exists?
Usually whoever already processes leaver tickets on the service desk, ticking off each system as they confirm it, and the Information security officer who owns the escalation when a deadline is missed. That is a real, ongoing task, not a one-off setup. If nobody is willing to close out the flagged systems, the board will just become an accurate record of access that was never actually removed.
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.
- 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.
- 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.