Why offboarding a contractor is harder than it looks

When a freelance designer wraps a project, or a contract developer finishes a build, the natural instinct is to send the final invoice and move on. That instinct is wrong. The work is not really done until the access that enabled the work has been closed, rotated and verified.

Most founders learn this the hard way. A contractor leaves on a Friday, the founder changes a few passwords on Monday, and three months later discovers that an old API key still pulls customer data, a Notion workspace is still editable, or a paid seat on a design tool has been quietly renewing for a contractor who left in spring. The risk is rarely dramatic in the moment — it is the slow leak of standing access that nobody tracks end to end.

This guide is a working checklist for solo founders and small teams. It is opinionated about order, conservative about claims, and built around the question a founder actually asks: what could still be reachable tomorrow that I forgot about today?

The goal is not a 200-item IT checklist. The goal is a routine you can run in an afternoon, repeated whenever a contractor’s work ends, that produces a clear answer to one question: is anything of mine still in their hands?

What “clean offboarding” actually means

A clean contractor offboarding has four outcomes. If you can answer yes to all four, you are done.

  1. The contractor cannot log in to anything you control.
  2. The contractor cannot use any shared credential, API key or token that still works.
  3. The contractor’s data — files, comments, draft work — is either retained by you or intentionally deleted, not orphaned.
  4. The seat, license or subscription tied to that person is recovered or reassigned, not silently billed.

Each of those outcomes maps to a different category of access. Skipping a category is how old access quietly returns.

A founder’s contractor offboarding checklist

Run the steps in order. Steps 1–4 are about discovery, steps 5–8 are about revocation, and steps 9–10 are about verification. Discovery is where most teams fail; verification is what catches what discovery missed.

1. Inventory every tool the contractor touched

Open a fresh doc and write down every SaaS tool the contractor logged into for your work. Pull this from real signal, not memory:

  • Email and chat history. Search their email address and handle in your shared inbox and chat tools. Every tool they were cc’d on is a candidate.
  • Past invoices and receipts. Anything you paid for on their behalf, or that touched their work, is a candidate.
  • Browser bookmarks and password manager entries, if you have access.
  • Calendar invites to recurring tools (design reviews, sprint demos, deploy approvals).
  • SSO and identity provider logs, if you use single sign-on — most modern identity tools will tell you exactly which apps a user has touched recently.

The list will be longer than you expect. That is the point. The longer the list, the less likely you are to miss the obscure tool that holds production access.

2. Classify what kind of access each tool had

Not all access is the same. For every tool on your inventory, note which of these categories applies:

  • Personal login — they had their own username and password, possibly with their personal email as the recovery address.
  • Shared login — they used a team email like team@yourdomain.com, or a generic login everyone shares. This is the riskiest category.
  • SSO-based login — they authenticated through Google Workspace, Microsoft 365 or an identity provider, and access is controlled centrally.
  • API key, token or service account — they generated or used a credential that calls into your systems programmatically (CI/CD, hosting, analytics, payment, AI tools).
  • OAuth grant — they connected a third-party app (an AI assistant, a reporting tool, a scheduler) to a core system like your CRM or cloud account.
  • File or document share — they had access to specific folders, files, docs, boards or repos, rather than a whole account.

This classification matters because each category is revoked differently. A personal login needs deletion. A shared login needs rotation. An API key needs regeneration. An OAuth grant needs revocation. A file share needs permission removal.

3. Capture anything you want to keep before you revoke

Revoking access sometimes deletes the data behind it. Before you start pulling credentials, decide what you want to keep:

  • Design files, repos, branches, dashboards, documents.
  • Drafts, comments and conversations in shared workspaces.
  • Recordings of calls or demos they were part of.
  • Any client deliverables that only exist inside their account.

Transfer ownership of repos, move files to a folder you own, export what you need. Do this before step 5, not after.

4. Decide who owns the revocation

Even on a one-person team, name the function that owns this work, even if it is you. The reason is not bureaucracy; it is that offboarding fails when nobody is accountable for the full lifecycle. The function that granted access should be the one that confirms it is gone. If a contractor was set up by an agency or a partner, write down who at that partner was the technical contact — you will need them.

5. Revoke personal logins first

For each tool where the contractor had their own login:

  • Disable or delete the user account in the tool’s admin console.
  • If the tool supports it, transfer their work to a named owner before deletion.
  • Remove the tool from their SSO profile if they had one.
  • Change any recovery email or phone tied to their account so they cannot trigger a password reset.

Most SaaS apps let you do this from a settings or members panel. For tools you do not actively administer, contact support and ask for a written confirmation that the account is disabled.

6. Rotate every shared credential

This is the step founders most often skip, and it is the one with the longest blast radius. Shared credentials include:

  • Shared email or social accounts (team@, social@, generic logins).
  • Shared passwords in your password manager.
  • API keys, service account keys and webhook secrets stored anywhere.
  • SSH keys authorized on your servers or repos.
  • Tokens issued to integrations and automation tools.
  • Recovery codes for any 2FA that was set up under a shared identity.

The rule is simple: if more than one human ever knew it, rotate it now. Rotating means generating a new secret, updating every system that consumes it, and invalidating the old one. For API keys, treat the old key as compromised the moment the relationship ends.

7. Recover or reassign license seats

Every paid SaaS seat a contractor occupied is a line on your next invoice. Recover them in the same pass:

  • Reassign the seat to a current user if you need it.
  • Downgrade your plan to a smaller tier if the seat was the only one above the new threshold.
  • For annual contracts, check whether unused seats can be credited or rolled over — terms vary by platform, so confirm in writing before assuming.
  • For tools billed per workspace or per project, archive the contractor’s workspace so it stops counting toward active usage.

This step saves real money. It also reduces the number of accounts that exist at all, which makes the next offboarding easier.

8. Revoke file shares, OAuth grants and third-party connections

A surprising amount of contractor access is granted through indirect paths:

  • Shared Google Drive, Dropbox, OneDrive or Box folders.
  • Shared Notion, Coda or Confluence workspaces.
  • GitHub or GitLab repository collaborators, deploy keys and personal access tokens.
  • Connected apps in your CRM, accounting tool, support inbox, calendar or AI workspace.
  • Browser extensions and bookmarks that hold session cookies.

For each, remove the contractor’s access directly from the host system. Do not rely on the contractor to disconnect — many SaaS OAuth flows do not notify the host when a third party is removed, and stale grants are a known source of silent access.

9. Verify, do not assume

Revocation that is not verified is a guess. Pick a verification method that matches the risk:

  • Try to log in to the most sensitive accounts using the old credentials, in an incognito window, with the contractor’s contact details still attached.
  • For API keys, call the key against a read-only endpoint and confirm it fails.
  • For shared logins, sign in with the new password from a different device to confirm the old one no longer works.
  • For OAuth grants, list connected apps in your core tools and confirm the contractor’s connection is gone.
  • For SSO, check the identity provider’s recent activity log for the contractor’s account — it should show no successful logins after the offboarding date.

Verification is cheap. It is also the difference between I think it is off and I know it is off.

10. Document and date-stamp the cleanup

Keep a short record of what was revoked, when, and by whom. This is useful for three reasons: it makes the next offboarding faster, it gives you an audit trail if something is questioned later, and it surfaces tools you forgot to inventory so you can add them to your next round. A simple spreadsheet is enough.

Where automation helps — and where it does not

Automated access revocation tools, identity governance platforms and SaaS management suites can attach revocation to a trigger event — a contract end date, a status change in HR, a manual flag. The benefit is consistency: revocation happens the moment the trigger fires, not when someone remembers to do it.

The trade-off for a small team is cost and complexity. Many governance platforms are priced and shaped for mid-sized organizations, and the time to configure them can rival the time saved. A leaner alternative is to attach the checklist above to a single trigger — usually the contract end date in your project or contract tool — and to assign it to a named owner with a due date. That is automation in spirit, if not in software.

For non-human identities — API keys, service accounts, automation tokens — the same lifecycle principle applies: credentials are assets with an owner, an expiry and a revocation step. Treating them like contractor logins, just programmatic ones, is a useful mental model.

Common blind spots founders hit

  • The contractor’s email is the recovery address on a shared inbox. Even after the password changes, they can reset it.
  • A personal GitHub account is a collaborator on a private repo. Removing them from the org is not the same as removing them from each repo.
  • A connected AI tool holds read access to your CRM or data warehouse. The tool’s own account remains live even after the contractor leaves.
  • An annual seat was paid up front and is still billing. Cancellation terms vary; assume nothing.
  • A shared 1Password, Bitwarden or LastPass vault holds production secrets. Sharing vault entries is convenient and dangerous in equal measure.
  • A deploy key on a server was set up once and never recorded. Search your known_hosts files and your hosting provider for SSH fingerprints.

How long this should take

For a single contractor on a typical SaaS stack, the first run takes two to four hours. With practice, and with a maintained inventory, it can be thirty to sixty minutes. The cost of skipping it is rarely visible the day it happens. It shows up as a billing anomaly six months later, a security incident that traces back to a stale key, or an audit question nobody can answer.

FAQ

Do I really need to rotate a shared password we only used internally? If more than one person ever knew it, yes. People leave, devices get reused, and former contractors sometimes forward credentials to a successor. Rotation is cheap insurance.

What about contractors who never logged in to anything sensitive? Do the inventory anyway. The cost is low and the upside is finding the one tool you forgot they touched — a CMS, a translation platform, an AI workspace — that holds more access than you remembered.

Should I just delete the contractor’s accounts and skip the rotation step? Deletion removes the account but not the secrets the contractor may have copied. Rotate shared credentials and API keys regardless of whether the account is still active.

How often should I review access for active contractors? A lightweight quarterly review catches drift. The offboarding checklist handles the endpoint. Together they cover both routine creep and clean exits.

Sources