When someone leaves your firm, the work of ending their employment usually gets handled well. Final paycheck, equipment return, exit interview. HR has a process. The separation is documented.
The work of ending their access is a different story.
For most firms, access revocation is not a defined process. It is a task that gets added to someone’s mental list, handled partially, and assumed to be complete. That assumption is where alot of quiet exposure lives.
Why This Happens
Offboarding in most professional services firms is treated as an HR event. The focus is on the human side of the separation, which makes sense. However, the security side of the separation rarely gets the same structure.
IT might disable a primary login. Someone might collect a laptop. The accounts everyone thinks about get touched.
The ones no one thought to map in the first place stay open.
That is the core issue. Access at most firms is not contained to a single system. A paralegal, associate, or contractor who was onboarded properly likely touched Microsoft 365, a case management platform, a billing system, a client portal, shared drives, and possibly a handful of third-party tools depending on the practice area. If no one documented all of that access at the start, there is no reliable way to close all of it at the end.
What This Actually Looks Like
Here is a scenario I have walked through with firms more than once.
A paralegal joins the firm. During her first week, she is given access to the client portal, the case management system, shared drives, and the billing platform. She is set up in Microsoft 365 and everything seems covered.
Eight months later, she resigns. HR processes the separation. IT disables her primary login. The laptop comes back.
Three weeks after her last day, someone notices she can still access the billing platform. It turns out that platform used a separate credential that was created during onboarding and was never connected to the main account. No data was taken. No harm was done. However, the access had been sitting open without anyone knowing.
That is not a story about a bad actor. It is a story about a process gap.
The Part That Surprises Most Firms
Disabling an account in Active Directory or Entra ID does not automatically close access everywhere. That surprises people, but it is a common misconception.
Delegated permissions, shared mailbox access, app-specific logins, and third-party integrations can all persist after a primary account is disabled. If someone was added directly to a vendor platform under their personal email, that access lives entirely outside your main identity system. Disabling their Microsoft 365 account does nothing to touch it.
Shared credentials are another layer. If a team was using a shared login for a specific tool and that password was never rotated after the person left, access is still open to anyone who remembers it.
The risk here is not malicious intent. A former employee who can still reset their own password or receive forwarded emails from a shared inbox is a liability even if they have no intention of doing anything with it. Exposure does not require bad actors to be a problem.
What Good Looks Like
A reliable offboarding process for access revocation is not complicated, but it does require intention. Here is what it needs to include.
- A full access map built during onboarding
You cannot revoke what you did not document. When someone is onboarded, every system they are given access to should be recorded. That list becomes the starting point for offboarding.
- A defined process owner
Offboarding access revocation needs to belong to someone. Not to whoever is available that week. A named role, whether that is your IT administrator, office manager, or external IT provider, should be responsible for running through the checklist every time someone leaves.
- A checklist that covers every system, not just the obvious ones
The checklist should include Microsoft 365, case management software, billing platforms, client portals, cloud storage, shared inboxes, third-party tools, and any vendor platforms the person was added to directly. It should also include shared credentials that need to be rotated.
- A review of delegated and shared access
Beyond individual accounts, someone should check for delegated mailbox access, calendar sharing, and any permissions tied to the departing person’s account that might affect others’ workflows after they leave.
- A completion sign-off
The process is not done when someone thinks it is done. It is done when a checklist is completed and signed off by the process owner. That creates accountability and a record.
A Simple Self-Check
Before moving on, it is worth asking a few honest questions about where your firm stands.
– If someone left your firm today, do you know every system their access would need to be removed from?
– Do you have a documented list of all the platforms and tools your team uses that require individual logins?
– Is there a named person whose job it is to manage access revocation when someone leaves?
– Have you ever rotated a shared credential after a team member departed?
– When was the last time you confirmed that a former employee’s access was fully closed across every system?
If any of those questions gave you pause, that is useful information. It does not mean you are in trouble. It means you have a starting point.
Closing the Gap
The firms that are protected from this kind of exposure are not necessarily doing anything complicated. They have a process, a process owner, and a checklist that covers every system. That is what separates a firm that is actually protected from one that is assuming it is.
If you want to think through whether your current offboarding process actually closes access across every system, or just the ones someone thought to check, that is a conversation worth having. You can book a time at https://diasystems.net/schedule-now/.
For now, I will leave you with this: when was the last time someone left your firm, and do you know with certainty that their access is fully closed?