Accounts and access: the hosting checklist when someone leaves your company
The access checklist to run the day a colleague, freelancer or agency stops working with you, from domains to the services behind the site.
The short answer
Anyone who worked on your website, an employee, a freelancer, an agency, may still hold access to the domain registrar, the hosting platform, the code repository, DNS, the email sending service, analytics, the payment provider, the automation platform and whatever else the site touches. The day they stop working with you, that access is removed through a checklist, not left to goodwill. Each system is checked, the person is removed, anything they shared is rotated, and ownership is confirmed to be with the business. The list of systems should exist already from the day they were onboarded; if it does not, it is built now from invoices, DNS records and the member pages of each platform. Shared logins make clean offboarding impossible, because removing one person means changing a password everyone uses, which is the strongest argument for per-person access through organisation accounts.
The checklist
| System | Action | Confirm |
|---|---|---|
| Domain registrar | Remove the person; confirm the account and domains are in the business’s name; two-factor on | Ownership in your name; registrar lock on |
| DNS provider | Remove access; review records for anything pointing at their infrastructure | No unexplained records |
| Hosting platform | Remove from the organisation; check the project is owned by the organisation, not their personal account | Project transfers complete |
| Code repository | Remove from the organisation; revoke their personal access tokens and deploy keys | Repository owned by the organisation |
| Secrets and environment variables | Rotate any secret they could have seen: API keys, tokens, database credentials | New values deployed; old revoked at each provider |
| Email sending service | Remove; rotate API keys; confirm the sending domain is verified in your account | Account in your name |
| Analytics and search console | Remove; confirm an owner in the business remains | At least two business owners |
| Payment provider | Remove; check no payouts route to them; rotate keys | Payout account is the business’s |
| Automation platform | Remove; check connected accounts and credentials they authorised | Connections re-authorised by the business |
| Content system | Remove; reassign their content ownership | No orphaned drafts |
| Monitoring and status | Remove; update alert recipients | Alerts reach someone |
| Shared logins, if any | Change the password; then eliminate the shared login | Per-person access instead |
| Devices and local copies | Ask for and confirm deletion of local repositories and credentials | Written confirmation |
| Documentation | Update the access register with the date and what was done | Register current |
Doing it on the day
- Run the register: remove the person from every system listed.
- Rotate shared secrets: anything not tied to their personal account that they could have seen.
- Check ownership: for each platform, confirm the organisation or the business account, not a personal account, owns the asset.
- Search for the unknown: invoices, DNS records, platform member pages, site integrations.
- Confirm remaining owners: at least two people in the business with owner-level access to each critical system.
- Record what was done, when, by whom.
The prevention
Per-person access through organisation accounts on every platform, ownership in the business’s name from the first day, secrets in platform storage rather than shared documents, and an access register maintained from onboarding onward. With that in place, offboarding is removing a name from a few member lists and rotating a few keys, and takes an hour.
What this means for you
When anyone stops working on your website, run the access checklist the same day: remove them from every system, rotate what they could have seen, confirm ownership stays with the business, search for anything not on the list and record what was done. Set up per-person access and an access register so the next departure is an hour’s work rather than a discovery months later.
Frequently asked questions
The developer left on good terms. Do we really need to do all this?
Yes, and it is not about trust. Their account can be compromised later, their laptop can be stolen, their password manager can be breached, and an old access they forgot about becomes your problem. Clean offboarding protects them as much as you. Good terms make it easy to do properly; they do not make it unnecessary.
What if the account was in their name, not ours?
Then the priority is transfer before removal: the domain into a registrar account in your name, the hosting project into your organisation, the repository into your organisation, the email service into your account. Ask while the relationship is still cooperative. Once transferred, their access is removed like anyone else's. This is the situation that ownership in your name from the start prevents.
How do we know we found everything?
Cross-check three sources: the list of systems from onboarding, the invoices and subscriptions the business pays, and the member lists on each platform's organisation page. Then look at DNS records for services you did not know about, and at the site's integrations. Anything found in one source but not the list is added and offboarded.