Before the person leaves, transfer every repository, server, key, shared environment and scheduled job they own to a named successor, then remove their access and record the change. The goal is that no system is left with an owner who is no longer reachable.
Why this is a vulnerability issue
Lab software is usually maintained by whoever wrote it. When that person leaves, patching stops. The system keeps running, the dependencies age, and advisories pile up with nobody reading them.
Offboarding is therefore the cheapest point at which to prevent a future finding.
The checklist
Code and repositories
- List repositories the person owns or administers.
- Transfer ownership to the lab or a named successor.
- Make sure a lock file and a short README on how to build exist.
- Add or update the security contact.
Servers and services 5. List virtual machines, web services, databases and domains the person set up. 6. Assign each an owner, or schedule it for shutdown. 7. Check scheduled jobs and cron entries that run under their account.
Shared software 8. Find shared builds, modules and containers the person installed. 9. Record versions and rebuild or retire what nobody will maintain. 10. Check that no shared tool depends on a personal directory.
Credentials 11. Rotate keys, tokens and service passwords the person knew. 12. Check where those credentials are used, including notebooks and config files. 13. Remove the person from groups, mailing lists and shared accounts.
Knowledge 14. Ask what is fragile, what is old and what they would worry about. 15. Write the answers in a hand over note.
Make the successor real
Assign each item to a person with a name, not to the lab in general. If nobody can take a system, that is a decision to retire it, not a reason to leave it running.
What to leave in the record
For each transferred item keep: what it is, who owns it now, the date of transfer and the next review date. This is the same table you would use in an inventory, so offboarding and inventory feed each other.
A common failure
The person leaves on a Friday and the account is disabled on Monday. Jobs that ran under that account then fail silently, or a service that used their personal token stops working. Check dependencies on the account before disabling it, and disable access in steps: reassign, then restrict, then remove.
Who runs this
Give the checklist an owner: the lab manager, a senior student or the PI. Put the departure date on the calendar when it is known and set a reminder for the hand over meeting.
Keep the completed checklist. When the next person asks who set up a server, the answer is in the record.
For short term visitors and rotation students, use a shorter version: repositories, shared environments, keys and accounts. The same principle applies, since a few weeks of work can leave a service behind.
Where Safeguard fits
Safeguard can list dependencies and known vulnerabilities across repositories, which gives the successor a starting inventory for software they inherit. A free scan on a repository being handed over takes minutes.
Quick check
When should we start offboarding?
As soon as the departure date is known. Do the hand over at least two weeks before the last day if you can.
What about collaborators outside the institution?
Review their access to repositories and shared systems on the same schedule, and remove what is no longer needed.
Last reviewed: 19 October 2026.
