IT Onboarding and Offboarding Checklist for New Starters and Leavers

In short: onboarding and offboarding are the two most repeatable pieces of work an SME's IT function does, and the two where a missed step costs the most. Onboarding failures are embarrassing, a new starter sitting without a laptop on day one. Offboarding failures are a security problem, an ex-employee whose accounts still work. The fix isn't a bigger tool, it's a written checklist with one owner per step and a defined handoff between HR and IT.

Most small companies handle starters and leavers from memory. Someone mentions in passing that a new person joins Monday, IT scrambles, and it mostly works out. Then someone leaves, everyone is busy, and six weeks later you discover their email account is still active and still receiving customer enquiries.

Starter and leaver work is unusual because it is entirely predictable. You know the steps in advance, you know they will happen again, and you know roughly when. That makes it the highest-return process to write down, which is why it earns its own category in a well-configured internal IT help desk.

First, decide who owns what

The single most common cause of a missed step isn't forgetfulness, it's ambiguity. HR assumes IT is creating the accounts. IT assumes HR will tell them the start date. Nobody owns the gap.

Before writing any checklist, agree three things:

• Who triggers the process. Usually HR, at the point an offer is accepted or a resignation is received. This is the single most important handoff, because everything downstream depends on it starting.
• Who owns each step. Every line on the checklist gets exactly one name, not a department. "IT" is not an owner, a person is.
• What the deadline is. Onboarding steps hang off the start date. Offboarding steps hang off the last working day, and some of them must happen on that day, not "soon after."

This is the practical reason running IT and HR in one system tends to be simpler for an SME than splitting them: the handoff is the fragile part, and it stops being fragile when both sides can see the same checklist.

The new starter checklist

Split it by timing rather than by system. What matters is what must be true by when.

Before day one

• Confirm the start date, role, and manager in writing, ideally the trigger that opens the ticket
• Order or prepare hardware, laptop, monitor, dock, phone if relevant, allowing for delivery time
• Create the core account, usually the email and identity account everything else hangs off
• Assign licences for the applications the role actually needs
• Add to the right groups, distribution lists, shared drives, and team channels, based on role rather than copied wholesale from an existing employee
• Prepare access to role-specific systems, the finance tool, the CRM, the code repository
• Set up the desk or delivery, physical space in an office, or courier details for a remote starter
• Write down the first-day credentials handover, how they will receive their initial password securely

Day one

• Hand over hardware and confirm sign-in works, including a password change on first login
• Enrol in multi-factor authentication, this is the step most often deferred and least often revisited
• Confirm access to email, calendar, and the main tools the person needs in week one
• Explain how to get IT help, name the channel explicitly and repeat it, because a new starter who can't find the help desk will simply ask the nearest person forever
• Point them to the knowledge base, the wifi details, VPN setup, and printer instructions they will otherwise ask about within days

First week

• Grant secondary access as it becomes clear what the role actually touches
• Check in once, deliberately, a short "is anything not working?" message catches problems people won't raise on their own
• Update the asset record, which device went to which person, with serial number

That last one looks like busywork on day one and saves you significant time at offboarding, when the question becomes "which laptop are we asking for back?"

The leaver checklist

Offboarding is where informal processes fail hardest, because the deadline is real and the consequences are security consequences rather than inconvenience.

Before the last day

• Confirm the exact last working day and time, since access removal is timed against it
• Agree what happens to their email, forwarded to a colleague, converted to a shared mailbox, or set to auto-reply with a redirect. Decide before, not after
• Identify data only they hold, files on the local machine, documents in personal drive space, anything not in shared storage
• Identify systems only they can access, the vendor portal, the domain registrar, the payment provider. This is the step that quietly bites hardest
• Plan handover of in-progress work, including open tickets assigned to them
• Arrange hardware return, especially for remote staff, where a courier needs booking

On the last day

• Disable the core account at the agreed time rather than deleting it, which preserves data and is reversible if something was missed
• Revoke multi-factor devices and active sessions, since disabling an account does not always terminate a signed-in session immediately
• Remove from groups and distribution lists, so internal mail stops reaching them
• Revoke access to third-party systems, working from a list rather than memory
• Change shared credentials they knew, any password not tied to an individual account
• Collect hardware, and record that you did

Within a week after

• Reassign or archive their data according to what you agreed beforehand
• Reclaim licences, which is the step that quietly saves money and is almost always forgotten
• Wipe and reissue the device, updating the asset record
• Delete or fully archive the account once you're confident nothing is still needed

The offboarding problem nobody plans for

The dangerous accounts are rarely the obvious ones. Email and the main identity provider get handled, because they're visible. What gets missed are the accounts created outside any central process: a SaaS trial someone signed up for with a company card, a vendor portal login, a social media account, an analytics tool, a shared password stored in a browser.

These are exactly the accounts that don't disappear when the main account is disabled, because they were never connected to it.

The practical defence is boring and effective: keep a running list of every system in use and who has access, and update it when access is granted rather than trying to reconstruct it at offboarding. It's much easier to add a line when you create an account than to remember it existed nine months later.

If you do nothing else from this article, do this one.

Making the checklist actually run

A checklist in a document has a predictable failure mode: it gets copied into a message, half completed, and nobody can tell which half.

Three things make it hold up:

One ticket per starter or leaver, with the checklist inside it. Not one ticket per task. The whole process is one unit of work with one owner accountable for completion, even where individual steps are done by different people.

A saved template, so the checklist appears already written rather than being retyped from memory each time. Retyping is where steps quietly disappear.

A deadline the system tracks, not one that lives in someone's head. Offboarding in particular has a hard date, and the whole point is that it doesn't depend on somebody remembering on the day.

This is ordinary ticketing rather than anything exotic. A starter or leaver request is a service request rather than an incident, a planned, repeatable piece of work, which is the distinction worth borrowing from ITIL and covered in help desk vs service desk. PileDesk handles this with a saved reply for the checklist, a category for starter and leaver work, and a due date on the ticket, and because pricing is flat per workspace you can run the HR side of onboarding alongside it without paying twice.

Common failure modes

Copying an existing employee's permissions. It's fast and it silently grants access nobody intended, which then propagates to the next person copied from them.

Treating the last day as a soft deadline. It isn't. Access removal timed to "sometime that week" is the same as no process.

Deleting accounts immediately. Disabling is reversible and preserves data. Deleting on day one creates a different emergency when you discover something was only in their mailbox.

No named owner. If the checklist says "IT" rather than a person, expect gaps at exactly the moments when everyone is busy.

Never reviewing the list. The set of systems you use changes constantly. A checklist written eighteen months ago is missing whatever you adopted since.

Start smaller than you think

You don't need a perfect process. Write down the last starter and the last leaver you handled, as they actually happened, including the bits that went wrong. That is your first draft, and it will be more accurate than anything designed in the abstract.

Then run it once, note what was missing, and fix it. Two or three cycles gets you something genuinely reliable, which is considerably better than a comprehensive process nobody follows.

If starter and leaver requests currently arrive as messages that live in one person's memory, the signs you've outgrown a shared inbox apply here with sharper consequences than usual, because this is the process where forgetting is a security incident rather than an inconvenience.