Keys after an employee leaves: the password changed, the cloud stayed open

A departure in a small company looks like this: the pass was collected, the mail password was changed, good luck was wished. A month later the map or cloud bill looks odd, the site has a quiet new user, the ads have a stranger's access. The person does not have to be a villain. It is enough that the key stayed in a program on their computer, and nobody ended the session.

A list that is shorter than it looks

• Mail, and all sessions, not only the password. Reissue the second factor if the device stayed with the person.
• Hosting, the CMS, the domain registrar, ads, maps and payment providers.
• Shared sheets and chats where leads landed. Removing someone from the group does not erase what they downloaded, but it stops the new.
• Keys built into the site. They are changed on the server, not only in the thread.

Doing this on the day they leave is easier than restoring a month later. If the person left in a quarrel or could see orders, it is worth looking at the logs: did anyone sign in at night, did new accounts appear. That is closer to incident response than to an HR checklist.

Lexora builds this list in an access audit. The basic site audit is free for new clients, and former contractors show up in it no less often than staff. If a key was already used after the departure, we do not stop at a password change: we look at what was exported and end the sessions. Site maintenance after that keeps accounts by role, so the next departure does not start with archaeology.