The last time I ran a contractor access audit for an organization I work with, I found three active accounts belonging to contractors who had wrapped their engagements more than six months earlier. One had read access to the shared support inbox. One was still in the Slack workspace with visibility into the IT channel. One had a live CRM login. Nobody had done anything wrong. Nobody had told IT the engagements were over.
That is the contractor offboarding gap. It is not a technology problem. It is a process gap that the technology quietly exploits while everyone assumes someone else handled it.
Why Contractor Offboarding Falls Through
Employee departures, however imperfect, have infrastructure behind them. HR initiates a process. Payroll gets notified. The manager is in the loop. IT eventually gets a ticket or an automated trigger from the HR system. The access gets deprovisioned. It is not always fast or clean, but there is a chain of custody.
Contractor engagements end differently. The project manager or department lead decides the work is done. They stop assigning tasks. The contractor stops showing up. If they were hired through an agency, the agency gets notified. HR may or may not be in the loop at all, depending on how the engagement was structured. IT is almost never notified directly unless someone thinks to do it, and in a busy organization, nobody thinks to do it.
The result is that the contractor's access just sits there. Not because of negligence, exactly. Because no process existed to close it.
This matters more than it might look. Contractors routinely have access to the same systems as full-time employees: the CRM, the support platform, the project management tool, cloud storage, internal communication channels. Some have admin access they needed for a specific project. Some used a personal email address to create their SaaS accounts, which means you cannot even see the account in your directory.
The Access Footprint a Contractor Actually Leaves
Before you can close the gap, it helps to understand how wide it usually is. A typical contractor who works with a team for three to six months may have been given access to some or all of the following:
- Individual SaaS accounts (CRM, helpdesk, project management, analytics)
- Shared accounts or credentials (social media manager, ad platform, generic support email)
- Cloud storage folders (Google Drive, SharePoint, Dropbox)
- Communication tools (Slack, Microsoft Teams, WhatsApp groups)
- Code repositories (GitHub, GitLab) if they touched the codebase
- Website or CMS admin access if they managed content
- Ad or marketing platform access (Meta Business Manager, Google Ads)
- VPN or remote desktop access if they needed it for systems work
That is a real footprint. And unlike an employee whose accounts are all tied to a company email address in Azure AD or Google Workspace, a contractor may have provisioned several of those tools using a personal email, which means they do not appear in any identity directory you manage. You have to find them the hard way: by pulling user lists from each tool and checking manually.
A Practical Offboarding Checklist
The fix is not complicated. It does require doing it deliberately rather than hoping the departure takes care of itself. Here is the process I use.
A few specifics on step two: start with any admin or elevated access, this is the highest-risk category. Then move to individual app accounts. When you get to shared credentials (a shared social media login, a generic inbox, an API key the contractor used), rotate or change the credential entirely. You cannot simply remove one person from a shared login. You have to change it so that anyone who previously knew it no longer has access.
Step three is the one that most automation cannot fully handle. When a contractor's Google Drive access is revoked, any documents they owned that nobody transferred ownership of will either become inaccessible or revert to the organization account in a way that is not always visible. Run this step with the department lead, not just IT, so someone with business context can confirm what matters and where it should live.
The Registry You Wish You Had Built Earlier
The cleanest version of this process starts before the engagement does. When a contractor is onboarded, create a simple record that captures what they were given access to. A spreadsheet is fine. The columns that matter:
- Contractor name and company (if agency)
- Engaging department and internal point of contact
- Start date and expected end date (update when extended)
- Tools provisioned and the email address used for each
- Any shared credentials rotated at the start of the engagement
- Offboarded date and who completed each revocation
The moment to build this is not when someone leaves. It is when someone joins. The offboarding takes maybe thirty minutes if the inventory exists. It takes two to three hours if you are reconstructing it from memory and Slack messages after the fact.
One practical note: build in a notification trigger. When the engagement is within two weeks of its expected end date, IT should get a heads up from whoever manages the contract. Do not rely on a human remembering to loop in IT at the moment the engagement closes. The busier the organization, the more reliably that step gets skipped.
When You Inherit the Mess
Sometimes you are not setting up a clean process from scratch. You are joining an organization that has been running contractors for years with no registry, and the audit task falls to you. This is the situation where you find the three active accounts from the people who left in April.
Start with the highest-risk tools, not the easiest ones. Pull the user list from your CRM, your cloud storage platform, and your support tool first. These are where a former contractor with active access can cause the most damage, either by accident or not. Work through each one against a current roster of employees and active contractors. Anything that does not match gets flagged for review before removal.
Expect to find accounts you cannot immediately identify. A generic email format, a name that does not ring a bell. Check with the department leads before you delete anything. Some of those accounts may belong to current contractors who were just never properly registered, or service accounts that look like a person but are not. Delete the wrong one and you could break a live integration.
After the initial cleanup, document what you found and what you changed. That record is not just for compliance. It is the evidence that motivates the department leads to start using the registry going forward. When you can show someone a list of the tools a contractor from two years ago still has access to, the conversation about process changes immediately.
The Quiet Risk Nobody Budgets For
Contractor access sprawl rarely appears on anyone's risk register. It does not generate tickets. There are no error messages. The accounts just sit there, and because nothing is visibly broken, nobody looks.
The cost when it does matter tends to be one of two things: a data breach investigation that reveals a former contractor's credentials were compromised, or an awkward audit finding during a security review that should have been routine. Either way, the underlying problem is the same. The process to close access was never owned, so nobody closed it.
The registry and the four-step checklist above are not complicated. The hard part is getting them treated as IT's responsibility to own, even when the engagement is managed entirely by a department lead who has never thought to notify IT. That is the conversation worth having before the next engagement starts, not after it ends.
If you are in the middle of a contractor access audit right now and want to compare notes, drop me a message. I have done this a few times across different tool stacks and can usually help you figure out where to start.
Comments