Offboarding Software Access: A Leaver Checklist for UK Small Businesses
Most small businesses think carefully about who gets access to their software when someone joins. Far fewer think with the same rigour about access when someone leaves. Yet a departing employee, contractor, or agency partner often retains a surprising amount of reach: a personal login to the accounts system, a shared password in a team chat, an admin seat on a marketing tool nobody remembers buying, or a forwarding rule on a mailbox that quietly copies customer enquiries somewhere else. Leaver access is one of the most common gaps in small-team operations, and it rarely fails loudly. It fails in the quiet months afterwards. This article sets out a practical method for offboarding software access in a UK SMB, with a checklist you can adapt, and the questions to ask your software vendors before you need them.
Start with a list of places people can sign in
The starting point is an inventory of where your business accounts live. You cannot revoke what you have not listed. For most UK small teams this includes email and calendar, the file storage and document system, the accounting or finance platform, customer relationship or sales tools, project management boards, communication channels, code repositories if you build software, domain and DNS registrars, and any admin consoles for hosting or cloud services. Add the tools that were set up informally, such as a design subscription paid on a founder's card or a survey tool a previous marketing hire signed up for.
For each entry, record four things: who the account owner is, whether it is a personal login or a shared one, what level of permission it holds, and where the credentials are recovered if the owner is unavailable. The last point matters more than most teams expect. If the only person who can reset the admin password is the person who has just left, the business has a continuity problem disguised as an access problem. A spreadsheet is enough for this, provided it is reviewed on a schedule rather than created once and forgotten.
Separate the three kinds of access a leaver holds
Leaver access tends to fall into three categories, and each needs a different response. The first is direct, named accounts: the person's own email, their login to the accounting tool, their seat in the project board. These are the easiest to deal with, because the platform knows who they belong to and most administrators can disable them directly. The second is shared credentials: a team password for a supplier portal, a single login used by a rota of people, or an API key sitting in a configuration file. These are harder because revoking them affects everyone who depends on them, so the replacement must be ready before the old secret is removed. The third is delegated or derived access: the leaver as the approver in a workflow, the owner of a shared calendar, the recipient of a copied mailbox, or the person whose name is on an automated integration. These are the ones teams most often miss, because nothing about them looks like an account at all.
When you run an offboarding, walk through all three categories explicitly. Ask for each one: what would stop working if this person's access disappeared tomorrow, and what would keep working that should not? The answers will tell you what to reassign, what to rotate, and what to delete.
Sequence the revocation without breaking operations
The order in which you remove access matters. A common mistake is to disable the leaver's main login first, only to discover that an automated report, a supplier integration, or a scheduled export was running under their credentials and has now failed silently. A safer sequence is to first identify dependencies by reviewing recent activity logs where your platforms provide them, then reassign ownership of shared resources to an accountable person, then rotate any shared secrets the leaver knew, and finally disable or remove their individual accounts. Keep a short written record of each step with the date, so that if something breaks later you can trace what changed.
Be careful with data the leaver created. Deleting an account can delete the documents, mailboxes, or project history attached to it on some platforms, and not on others. Before removing anything, check what each vendor does with a departed user's content, whether it is retained, transferred, or deleted, and how long a recovery window lasts. Some tools hold content for a period; others do not. Do not assume. Confirm from the vendor's own documentation or support channel, and note the answer against the relevant entry in your inventory.
Ask vendors the questions before you need the answer
Offboarding is much easier when the questions have been answered in advance, ideally at the point of purchase. When evaluating or renewing an SMB software tool, ask how user accounts are removed, whether a departing user's content can be transferred to another user, what happens to data attached to a deleted seat, whether there is an audit log of permission changes and how far back it goes, and whether shared logins are supported or discouraged. Ask whether single sign-on or centralised identity management is available on your plan and at what tier, because the cost of offboarding through a single identity provider is far lower than doing it account by account.
Do not infer answers from a marketing page. Pricing tiers and feature availability change, and what a sales conversation implies may differ from what the plan you buy actually includes. Put the questions in writing and keep the replies with your contract records. This is also the moment to check whether your contract auto-renews and whether unused seats are billed, because a leaver's seat often continues to be paid for long after they have gone.
A practical leaver checklist and a quarterly verification
Use the following checklist for each departure. Confirm the leaver's last working day and the time access should end. Review your inventory and list every account, shared login, and delegated role associated with them. Reassign ownership of any shared resources, workflows, calendars, and integrations to a named accountable person. Rotate any shared credentials they knew, and update the stored copy in your password manager or secrets store. Remove their individual accounts and any admin roles, and release their paid seats where the vendor allows. Check their devices for saved sessions, authenticator apps, and browser-stored passwords, and recover company hardware. Record the date each step was completed and by whom.
Offboarding is only half the discipline. The other half is verification. Once a quarter, compare your inventory against the active user lists in your main platforms. Look for accounts that no longer match a current team member, seats that were never assigned, and shared logins that have grown in use. A short review of this kind, perhaps thirty minutes for a small team, will catch most of the drift that accumulates between departures. It is far cheaper than discovering a stale administrator account during an incident or a renewal audit, and it turns offboarding from an occasional scramble into a routine that your business can rely on.