When Someone Leaves, What Happens to Their Accounts and Work?
When a colleague leaves, someone needs to close their access and someone needs to take over their work. Agree who does each job, when it happens and how you will check that both are finished.
When someone leaves, agree who closes their access and who takes over their unfinished work. Each needs its own confirmation. Deleting an account tells you little about whether tomorrow's customer enquiries will reach the right person or whether a colleague can update the shared report.
Start with the work that must continue
Imagine a colleague who answers customer enquiries and prepares a weekly report. Before a planned departure, their manager identifies the open enquiries, the next report due and the person taking over. That successor needs the relevant work through their own authorized account.
The manager decides what work needs a new owner. People or HR confirms the authorized timing and any relevant constraints. The people responsible for each system determine the access changes and how necessary material can be retained or transferred. In a small company, one person may hold several roles. Keep the decisions explicit even then.
For an urgent security departure, follow your organization's authorized response. Do not delay containment to finish a tidy handover.
Closing access and keeping work are different actions
Blocking sign-in, deleting an account, preserving records and giving another person access have different effects. Choose them for the result you need, in the order appropriate to the service and circumstances.
Microsoft's former employee guidance, for example, treats preventing sign-in, preserving mailbox material, email continuity, successor access, licensing and deletion separately. Those are Microsoft 365 instructions. They illustrate why a single instruction to “delete the user” leaves important decisions unanswered.
Keeping a record does not automatically authorize another person to read it. Ask what business material the successor needs and who can approve the transfer or access. Personal material does not become available to everyone because its owner leaves.
For the hypothetical customer enquiries, agree which conversations the successor needs and how future enquiries will reach them. For the report, establish where it lives, who owns it and whether anything needed to update it still depends on the departing person's account. Avoid copying a whole mailbox by default. Where privacy, retention, investigation or employment obligations affect the decision, the responsible people should obtain advice for the actual circumstances.
Check the services behind the central login
A central login can help manage access, but ask what disabling it actually changes in each relevant service. Some applications may have separately managed accounts. Ask system owners about existing sessions, access tokens and automations where these are used. The right action depends on the service.
The NCSC's guidance on using SaaS securely covers the user lifecycle for internal and external users, managed identity sources and automation where possible. It also recognizes applications using direct authentication. Treat that as a reason to check the applications involved, rather than assuming one sign-in change settles everything.
“Access removed” and “work handed over” need separate confirmation. One can be finished while the other is still open.
Leave a short record someone can check
For each relevant service, record the responsible owner, the access action, the authorized destination for required work, the agreed time and the evidence of completion. Include unfinished decisions and who will resolve them. Keep passwords and other credentials out of this record.
GitLab's public offboarding handbook shows another organization separating People Operations coordination, manager handover discussions and system access responsibilities. Its completion records distinguish removed access from confirmation that someone never had access. Its tools and deadlines belong to GitLab; the useful point here is knowing who confirms each item.
Ask each system owner for administrative evidence of the agreed change. Then have the authorized successor perform the ordinary task: find the assigned enquiry or open and update the report through their own account. Never test by signing in as the departing person or sharing their password.
An HR update or a completed automation is useful information, but it does not by itself establish every application's state. Keep unresolved items visible until the responsible owner confirms them.
If an existing system makes ownership or access difficult to untangle, we can discuss that system and the work someone needs to take over. Our services include software, infrastructure and email, with the scope agreed for your situation.
Questions about accounts and handover
Is blocking sign-in the same as deleting the account?
No. Blocking sign-in, deletion, preservation and transfer have different effects. Ask the system owner which actions achieve the agreed access and handover decisions for that service.
How does the next person get the work without the old password?
Agree which business material they need and who authorizes access or transfer. The system owner arranges the appropriate change, and the successor checks the work through their own authorized account.
Does removing a central login close access to every application?
Do not assume so. Ask the responsible owners what the change does in each relevant service, including separately managed accounts, existing sessions, tokens and automations where applicable.
Who confirms the handover is finished?
Each system owner confirms the agreed access changes. The manager and authorized successor check that the necessary work can continue. Record any unfinished items and who is responsible for resolving them.