Contractor Access That Outlives the Project: A Cleanup Plan

Access is granted in a hurry on day one and by many hands. The engineer adds a GitHub invite, the project manager shares a staging password and the client sends a VPN profile, and nobody writes any of it down. A contractor on a three month engagement can collect fifteen separate credentials without a single approval ticket.

At handover, the attention is on the demo and the final invoice, so removing a contractor feels like an afterthought that waits for a ticket that never gets raised. Meanwhile the contractor moves to the next client, and the laptop that holds the saved credentials goes with them.

Months later, a former contractor still holds a token that reads production data. Nobody meant for that to happen. Auditors flag exactly this.

Start from the contractor’s identity and list every system. Check the identity provider first, then work outwards. Single sign-on removes many accounts at once. Local accounts, personal access tokens and deploy keys sit outside it, and those are the ones that get missed.

Ask the contractor for their own list as well. They will remember the Slack workspace and the Figma file that your records miss. Compare both lists and resolve every difference. Any system on their list and not on yours is an access path you did not know existed, so log it as a finding.

Do the same on the client side. Your firm may hold accounts in a client portal or ticketing tool that the client should be told to close.

Sequence is the whole point here. A contractor who is removed from the repo but not the VPN can still reach internal tools, so cut the network first, then identity, applications and data stores.

Rotate every shared secret afterwards. A database password, an API key or a signing certificate the contractor ever saw should be replaced, even if you believe the copy was deleted.

Take care with accounts that own things. A cloud user who created the staging environment may own resources that stop working when the user is deleted, so reassign ownership first. Check Terraform state and CI pipelines too, because a deploy that runs under the contractor’s service account will fail on the next release and surprise the whole team.

Do not trust the admin screen alone. Look at the sign-in logs for the contractor’s accounts over the following thirty days and confirm there are no successful logins. A failed attempt tells you the account is still known somewhere.

Search the repositories for commits made after the end date, and review pull requests still open under their name. Check scheduled jobs and webhooks they created. Those keep running without a login. A cron job on a staging server or a webhook that posts build logs to a personal Slack channel can leak data for months after the person is gone.

Ask the client for a written confirmation that their side is closed.

Record, for each contractor, the end date, the systems checked, who removed access, the date and a screenshot or log reference. Store it with the project file so an auditor finds it in minutes. Auditors working to ISO 27001 or SOC 2 will ask for exactly this evidence, and a tidy register turns a long conversation into a short one.

Attach the offboarding list to the project closure checklist so the project cannot be marked complete without it. Set an expiry date on contractor accounts when you create them, so access ends unless someone renews it.

Pick the last contractor who left and run this plan on them today.