A runbook for offboarding a contractor from your systems

Bringing a contractor in is a project: a kickoff, an account, a few approvals. Letting them go is often an afterthought. The contract ends, the invoice is paid, and somewhere in a spreadsheet nobody revisits there is a login that still works.

This is not carelessness so much as arithmetic. Joining happens once with someone pushing for it. Leaving happens quietly, and nobody owns the list of everything the person could reach. A runbook fixes that by turning leaving into a short, boring routine.

Before they start: make leaving easy

Most of the work of a clean exit happens on day one. If a contractor needs one application, give them that one application, through their own named identity. Not a shared account, not a VPN that puts them on the whole network, not a copy of someone else's password.

• Give them their own account, in the role with the least they need.
• Write down the end date when you create the access, and put a reminder on it.
• Name an owner on your side who is responsible for the exit.
• Avoid anything shared: shared logins, shared links, shared mailboxes.

On the day: cut access in one place

The principle is simple: there should be one place where you can end someone's access, and it should take effect immediately. If you have to visit five systems, you will miss one. If the access ends only when a token expires some hours later, you have left a window open on purpose.

So remove the person where access is managed, and check that it worked. Look for any live sessions, confirm they cannot sign back in, and revoke any links you issued. If you set an expiry on a share link at the start, it will have closed itself already. That is the benefit of writing the end date down.

Afterwards: look back

Cutting access is half the job. The other half is asking what the person did while they had it, while it is fresh and before the details blur.

• If you keep an audit log, review the person's last weeks for anything unusual: bulk exports, access to records outside their scope, odd hours.
• If you record sessions for the sensitive applications, spot-check the final sessions.
• Rotate anything the person knew, such as a shared credential or an API key. The need to do this is the cost of having shared them.
• Close the loop: record that the exit was done, by whom and when.

The failure modes

Three things turn a routine exit into a problem. The first is the shared login, because you cannot revoke one person's access without changing it for everyone, so it never happens. The second is access that rides on the network: once someone is inside the VPN, you cannot say what they could reach. The third is open-ended links that never expire.

All three have the same cure, which is to make access narrow, named and time-bound from the start, so that the exit is a single, boring action.

If you do one thing after reading this, pick your three most recent contractors and ask what each can still open today. The answer will tell you how much of this you need.