Hire to exit, in three parts
Read it all here, free. The fill-in forms and the device log come by email if you want them.
Most small firms do joining reasonably well, because somebody is waiting to start work. Standing access drifts, because nobody is waiting. And leaving gets done from memory, usually by whoever is least busy that week. The gaps are predictable, which is the good news: a predictable gap can be closed with a list.
- Decide the role first, then the access. Write the role down, even if the role is 'the second person here'.
- Create the account on your business platform, not a personal one. Free personal accounts cannot be recovered, audited, or offboarded.
- Turn on multi-factor authentication at creation, not later. Later never arrives on its own.
- Give the least access that lets them do the job on day one. Adding access is a two-minute conversation; removing it is an argument.
- Order the device and enroll it in management before it ships to them.
- Week one: walk them through the password manager, and make it the only place work credentials live.
- Week one: tell them where to report something suspicious, and who to ask when they are not sure. Name a person, not a mailbox.
- Week one: write down what they were given. This list is what you will use the day they leave, and it is much easier to write now.
This is the part that causes internal arguments, and the arguments are usually about history rather than risk. The person who set up the system is not automatically the right person to hold its keys. Four questions settle it:
- Who is accountable if this system's data leaks? Not who set it up. Not who pays for it. Who answers for the data in it.
- What does admin actually let them do that they need? Admin is a job with tasks, not a status. If the honest answer is that they just like having it, that is your finding.
- Who is the backup if that person is unreachable? One admin is a single point of failure. Two is a working minimum. Everyone is not a plan.
- Do they work in that account all day? An admin account that is also a daily-use account means every phishing click runs with full power.
- Nobody does daily work in an admin account. Separate accounts for separate powers.
- A break-glass admin account exists, its credentials are sealed somewhere only an owner can reach, and somebody has tested that it works this year.
- Disable the account. Do not delete it yet; you may need the mailbox and the files.
- Revoke active sessions and tokens, not just the password. Changing a password does not sign anyone out.
- Reset multi-factor enrollment so their phone stops being a key.
- Forward or delegate the mailbox to the right person, and set the out-of-office.
- Transfer ownership of their files and anything shared from their account, before the account is closed.
- Rotate every shared credential they knew. This is the step most often skipped, and the only one an attacker cares about.
This is where small-firm offboarding actually fails. Anything the person signed up for directly, or that predates your current setup, will not switch off when the main account does.
- Social accounts, ad accounts, and analytics.
- The shipping, banking, or supplier portals someone registered once.
- Design, scheduling, e-signature, and survey tools bought on a card.
- Anything their personal phone is still signed into.
Your week-one list from Part 1 is the answer to this. If you do not have one, build it from the last twelve months of card statements; it is tedious once and easy forever after.
- Name one owner of device recovery before you need one. It is a job, not a group instinct.
- For remote staff: send a prepaid shipping label and a box, with a return-by date, on the last day. Friction is why laptops do not come back.
- Confirm what your handbook or offer letter says about equipment return before the conversation, not during it.
- Wipe or re-enroll the device when it arrives, before it goes to the next person.
- Log it, so the next one is not run from memory either.
Pick the last person who left. Answer these out loud.
- Can you name every system they had access to?
- Is their account disabled, and were its sessions revoked?
- Were the shared passwords they knew changed?
- Where is their laptop right now, and has it been wiped?
- Who did all of that, and where is it written down?
Five yeses and you are in better shape than most firms your size. Any no is not a failing; it is just the next thing on the list.
- Fill-in joiner and leaver forms, one page each
- The admin-rights map as a fillable table: who should hold it, who actually does
- A device return log built for remote and multi-location staff
- The sixty-second test as a printable card