Checklist: removing vendor and freelancer access when a project ends

Direct answer

Start by writing an inventory of everything the vendor could reach, then remove access in a deliberate order and confirm each removal. The usual mistake is to remove the person from the code host and stop there, while their access to the CRM, the automation tool, the domain, the email sender and shared logins stays in place. Removing access reduces exposure; it is not a security guarantee, a compliance step or legal advice. Where contracts or data protection obligations apply, ask a qualified adviser.

Build an access inventory first

You cannot remove what you have not listed. Ask the vendor for the accounts, invitations, keys and shared logins they know about, and compare it with your own view: check the user lists of each system for their names and addresses. For each item record the system, the type of access, who granted it and its current status. Items the vendor did not mention are the reason to check your side too.

Order of removal

A sensible order is to remove the most powerful and the most reachable access first, while you still know what depends on it:

• Administrator and owner-level access to the systems that hold customer data or money
• Access to hosting, the domain and the code repository, per the [GitHub and Vercel ownership](/github-and-vercel-account-ownership-setup/) setup
• Access to business tools: CRM, automation platform, analytics, email sender and payments
• Lower-level accounts and invitations that are still pending

Sessions and tokens versus accounts

Removing an account does not always end what it created. A person may hold sessions that remain open, tokens they generated, or connections that were authorised under their own login. Check for and revoke tokens and connections separately, and look at what depended on the account before it is removed so that nothing stops unexpectedly. See API credentials and service account setup.

Rotate keys and secrets the vendor saw

Any key, password or secret the vendor could see should be treated as known to them, whatever their intentions. Replace them with new ones, update the systems that use them, and confirm those systems still work. Do this after you have a working replacement plan, not before, so you do not break a live service without meaning to.

Third-party tools

Work through each tool the project touched: CRM, automation platform, analytics, the email sender, the domain registrar and DNS, payment systems and any cloud accounts. For each, check the user list, connections, API keys, webhooks and any integrations that were set up under the vendor's name.

Forwarding rules and delegated access

Check the places access hides: email forwarding rules, shared mailboxes, calendar or file sharing granted to the vendor, and delegated permissions. These are easy to forget because they are not in any list of users.

Replace shared logins with named accounts

If the vendor worked through a shared login, change its password and move the work to named accounts owned by the business. Shared logins make it impossible to tell who did what and make removal a guessing game.

Written confirmation and a final check

Ask the vendor to confirm in writing what they had access to and that they no longer use it, and to say whether they kept copies of any data. Then do your own final check across the same inventory: each item marked removed, rotated or kept, with a date and a name. Keep the inventory; it is the record.

Keep a documented handback path

Removing access is easier when you have what you need to run without them. Before cutting off, check the handover: credentials you own, documentation, and a way to reach the vendor for questions if agreed. The software handover checklist covers this, and CRM handover when a salesperson leaves covers the internal version of the same problem.