When an Employee Leaves, When Does Their Access End?

Ask a leader when a departing employee's access ends and you will usually hear a confident answer: on their last day. Ask for the evidence and the confidence fades. Payroll stops on schedule because payroll has a process, an owner, and a deadline. System access often ends whenever someone gets to it, if they get to it at all. That gap between the personnel event and the access event is one of the most common and most preventable weaknesses I see in governance reviews, and it persists because offboarding is treated as an administrative errand instead of what it really is: an access control.

Treat offboarding as a control, not a task

A control has an owner, a trigger, a standard, and evidence. Offboarding should have all four. The trigger is a defined HR event: resignation, termination, contract end, or a change of role that removes the need for certain access. The standard is a stated deadline, for example that access ends on the final working day, and sooner where the departure is involuntary. The evidence is a record that someone can later inspect: which accounts were disabled, by whom, and when. When any of those four elements is missing, the organization is relying on memory and goodwill, and memory is not a control.

One named owner for the whole chain

Departures cross departmental lines. HR knows the person is leaving, the manager knows the work, and IT knows the systems, and each tends to assume another party is driving. The fix is a single named owner for the offboarding chain, accountable for confirming that every step completed, not merely that a ticket was opened. That owner works from a checklist tied to the individual: network and email accounts, business applications, remote access, shared and administrative accounts, physical access, and company data held on personal devices. The checklist matters because the accounts most likely to be forgotten are the ones that were never in the standard set: the vendor portal, the reporting tool, the shared mailbox, the local administrator account created for one project and never revisited.

Make the end date provable

There is a difference between access that ended and access that can be shown to have ended. Periodically, and always after sensitive departures, someone independent of the person who did the work should sample leavers and confirm their accounts are actually disabled across systems. This does not require special tooling. It requires a list of leavers, a list of accounts, and the discipline to compare them and record the result. Managers should also certify, at sensible intervals, that everyone with access to their systems still works there and still needs it. Access reviews feel bureaucratic until the first time they catch a live account belonging to someone who left months earlier, and then they feel essential.

Do not forget role changes and contractors

Full departures get the attention, but access also accumulates quietly when people change roles inside the organization, keeping old permissions while gaining new ones. Contractors and temporary staff are the other blind spot: their engagements end on a date known to a contract file, yet their accounts often have no end date at all. Build the expiry into the account at creation, and let the review process catch whatever slips through.

The takeaway

When someone leaves, their access should end on a date you can name, through a process you can describe, with evidence you can produce. Set the standard, name the owner, and check the result. It is one of the simplest governance controls to run well, and one of the most embarrassing to explain when it has not been.