An Employee Leaves Tomorrow: Who Still Has Access to Your Data?

Nobody leaves intending to do harm, and that is not what this is about. The real risk is elsewhere: an access that stays active is an access nobody is watching. It appears on no dashboard, triggers no alert, and if that credential is one day compromised somewhere else, it becomes a way into your systems under the name of a person you can no longer reach.

Disabling an account is not enough, because an account is not the only entry point. What often stays active: sessions already open on a personal phone or browser, membership of shared mailboxes and chat groups, the external sharing links that person created on documents, and the third-party applications they had connected to their work account. Every one of those survives the disabling.

There are two, and the order matters little as long as both are done. The first is to block sign-in for the account. The second, the one almost always forgotten, is to revoke all active sessions. Without that second action, a session already open on a personal device can keep working for a while, because the device does not need to sign in again to carry on reading mail. Microsoft in fact documents both operations as the very first step when an employee leaves, before anything else.

This is the part that gets expensive when handled too late. Before releasing the licence, you need to decide what happens to the mailbox and the work files: hand them to a manager, convert the mailbox to a shared one, or archive them. Once the account is deleted a countdown starts, and at the end of it the content is no longer recoverable. The order to remember is therefore simple: cut access first, recover data second, release the licence last.

Good practice is not to memorise everything but to write the list down once, with the name of the person responsible for each line and the expected timeframe. That list fits on one page. It should be triggered by HR, not by IT, because HR know the leaving date first. That trigger, more than the list itself, is what separates a written procedure from an applied one.