Security Basics: Revoking Access Across Your Tools When Someone Leaves a Team
Most small teams can tell you who has a login to their main systems. Far fewer can tell you who still has access to the project management board, the shared design folder, the analytics dashboard, the domain registrar, and the three AI writing tools a former contractor once signed up for. This article takes a different angle from general account hygiene: it focuses on the moment a person's access should end, and on the method for making sure it actually does. The goal is not to recommend any particular product. It is to give you a repeatable process you can run with whatever tools you already use, and a set of questions to ask vendors before you depend on them.
Start With an Inventory of Where People Can Actually Get In
Before you can revoke anything, you need a list of the places where access exists. Begin by writing down every tool that holds company data, customer information, source code, financial records, or credentials. Include the boring ones: the email domain console, the file storage space, the shared password manager, the team chat workspace, and any billing portal where someone can change payment details.
For each tool, record three things: who the administrators are, who the ordinary users are, and whether any accounts are shared. Shared logins are the most common blind spot. A single login used by a marketing group or a support desk does not show up in a user list as a person, so when someone leaves, nobody thinks to change the password. Note these separately and flag them for rotation.
Finally, record recovery paths. Many systems let an account be reset through a personal email address, a phone number, or a backup code stored on someone's laptop. If the person who leaves controls the recovery method for an account the team still needs, access has not really ended. Treat recovery control as part of the access map, not an afterthought.
Build an Offboarding Checklist Before You Need It
An offboarding checklist works best when it is written before the first departure, while nobody is emotional or rushed. A workable version lists each system from your inventory, the action required, the person responsible for it, and a place to confirm completion. Keep it short enough that someone can finish it in one sitting.
A practical checklist for a departing employee or contractor might include: remove the person from the team workspace and any channels they own; transfer ownership of shared documents, calendars, and project boards to a current employee; remove them from the email group and shared inboxes; revoke their access to the code repository and any deployment tools; rotate any shared credentials they knew; remove them from the password manager and confirm the vault key is not held solely by them; check billing and subscription admin roles; and review any API tokens or personal access tokens they created.
Assign a single owner to the checklist. Shared responsibility sounds fair but tends to produce gaps, because each person assumes another person has handled a particular tool. The owner does not have to perform every step personally, but they should confirm that each line item is closed and record the date.
Revoke Carefully and Verify Each Step
Removing a user from a list is not the same as ending their access. Some tools keep active sessions alive until they expire. Others keep API keys, OAuth grants, or connected third-party apps working even after the user is deleted. When you revoke, look for the difference between disabling an account and deleting it, and between ending a session and invalidating a token.
Verification is what separates a checklist from a guess. After each revocation, try to confirm the change from the outside. If you can, sign in with a test account that has the same role and confirm the old credentials fail. Check whether the former person's name still appears as an owner of any integration, webhook, or scheduled job. A scheduled export that runs under a departed employee's account can keep pulling data long after anyone remembers it exists.
Be cautious about deleting content as part of offboarding. Transfer ownership first. Deleting a shared document or a project space can destroy work the team still needs, and restoring it may not be possible in every tool. Your checklist should say what gets moved, to whom, and when.
Ask Vendors the Questions Before You Sign
Offboarding is much easier when the tools you choose make it visible. Before adopting a new tool, ask the vendor or read their documentation for the answers to a few specific questions. Can administrators see a complete list of users, including inactive ones and external guests? Can they see which third-party apps are connected to each account? Is there a way to transfer ownership of content without the departing user's involvement? How are active sessions ended, and do the changes take effect immediately or after a delay?
Also ask about recovery. Who can reset a user's password or enroll a new authentication method? Is there a way for an administrator to regain access if the only admin has left? Does the tool support more than one administrator so a single departure does not lock the team out? If the answers are vague, treat that as information about the operational cost of the tool, not just a support question.
Finally, look at how the tool records account changes. A simple log of who was added, removed, or granted a new role makes audits possible. If a tool offers no visible history of access changes, you will have to rely on your own records, so write them down yourself from the start.
A Short Verification Routine for Each Quarter
Offboarding handles the departures you know about. A quarterly review catches the ones you do not. Set aside an hour each quarter to walk through your inventory from the first step. Compare the current user lists against your staff roster and your contractor agreements. Look for accounts that belong to no one, shared logins that have not been rotated, and integrations whose owners no longer work with you.
Keep the review simple. Export or screenshot the user lists where possible, mark any account you cannot match to a current person or service, and resolve those before the review closes. Record the date and the name of the person who ran it. Over time, this record becomes evidence that your access controls are maintained, which is far more useful than a general belief that they are.
Access problems rarely come from a single dramatic failure. They accumulate through small omissions: a forgotten admin role, a recovery email that points to an old inbox, a token nobody remembers creating. A written inventory, a shared checklist, and a regular review will not eliminate every risk, but they turn invisible access into something your team can see, question, and close.