Operations

IT onboarding checklist: the steps that get skipped and what they cost

Most IT onboarding checklists are a list of accounts to create, and creating accounts is the easy half. The expensive half is everything the list quietly assumes: who starts it, how soon, what the new starter should be able to reach unaided, and what happens to the access nobody wrote down. Below is an IT onboarding checklist with the reasoning attached, written for whoever is responsible for the estate, whether that is an in-house team of two, a one person IT department, or an MSP standing up a starter inside a client tenant.

Before day one: the week that decides the rest

Roughly a fifth of staff turnover happens in the first month and a half, and a first day spent watching someone else install software is a poor opening impression. Everything in this section should be done before the new starter walks in, which means the clock starts at contract signature, not when someone remembers.

1. Trigger the process from the signed contract, not an email

The trigger matters more than the tasks. If onboarding starts with an informal message to whoever is nearest, it starts whenever that person happens to send it, which is usually the Friday before. Hardware has lead times and a device build cannot be compressed to nothing. Without a defined trigger you are not running a process, you are running a favour, and the failure mode is a laptop ordered on the morning someone starts.

2. Build the account from a role template, never by copying a colleague

Copying an existing user is the most common shortcut in IT onboarding, and the one that compounds. The colleague being copied carries permissions from three old projects, a temporary elevation nobody removed, and a group whose purpose is long forgotten. Copy them and the new starter inherits all of it on day one. Do that for two years and nobody can explain why anyone has the access they have, which turns every future access review into guesswork.

3. Assign licences deliberately and record the decision

Licences get handed out by pattern matching: this person looks a bit like that person, so give them the same. It is how a warehouse supervisor ends up on a premium suite, and how a subscription bill drifts upwards every quarter with no single decision to point at. Record who approved which tier and why, because the reclaim conversation a year later is impossible without it.

4. Enrol, encrypt and patch the device before it leaves your hands

A device handed over first and enrolled later is often never enrolled at all. Get it into management, confirm disk encryption is on and the recovery key is escrowed somewhere you can actually reach, check the antivirus is reporting rather than merely installed, and bring it to a current patch level before it ships. Skip this and the newest machine in the estate is the least protected one, invisible to every report you rely on.

Day one: the first hour is the whole impression

If the preparation went well, day one is not a build but a verification. Budget half an hour with the person and use it to prove things work rather than to discover they do not.

5. Hand over credentials through a channel that cannot be forwarded

A temporary password sent to a personal address, or printed in the welcome pack, lives there permanently and passes through systems you do not control. Use a channel that expires, force a change at first sign-in, and never let the first credential and the second factor travel together. Skipped, this becomes the weakest link in an otherwise well run estate.

6. Watch them enrol multi-factor authentication, do not simply require it

The gap between an account going live and its second factor being registered is a real attack window, because whoever enrols first owns the factor. Registering it together, on the spot, closes that window to minutes. Leave it to a prompt the user can defer and a new account with a guessable name sits unprotected for a fortnight. Our Microsoft 365 security checklist covers the tenant settings that make this enforceable rather than optional.

7. Prove the access instead of assuming it

Walk through it with them: open every application, send a message, join a video call, open the shared folder, reach the line-of-business system. It takes a quarter of an hour. Without it the failures surface one at a time over the next fortnight, each arriving as a ticket that reads like user error and each costing the new starter half a morning.

8. Tell them how to reach support and what you will never ask for

New joiners are targeted deliberately: they are eager, they do not yet know who is who, and their arrival is often announced publicly. Give them the real support channel and tell them plainly what IT will never do, which is ask for a password or a code, or message them urgently from an unknown number claiming to be a director. Skip it and their first security decision is made with no information at all.

The first fortnight: what the checklist usually forgets

These are the items that get dropped when things are busy, precisely because nothing visibly breaks when they are. The cost lands months later, usually on someone else's desk.

9. Record the asset against the person on the day you hand it over

An asset register written from memory at the end of the quarter is fiction. Capture the serial, model, purchase date and holder at the moment of handover, when the information is free. Skip it and you cannot say who has what, kit leaves the building unnoticed for a year, and any hardware refresh cycle you plan is built on guesses.

10. Capture the access that lives outside single sign-on

Directory access you can query later. The rest you cannot: the supplier portal with a shared login, the VPN profile, the shared mailbox, the finance system that has never heard of your identity provider. Write these down as you grant them, because this is the exact list that survives a departure and turns a leaver into a live credential. It is why offboarding fails far more often than onboarding does.

11. Settle the local administrator question in writing

Someone will need to install something in week one, and the fastest answer is to grant local admin and move on. Elevation granted informally is permanent elevation, because there is no record of it and therefore no trigger to remove it. Decide the rule, apply it consistently, and if you must elevate someone, put an end date on it in a system that will chase you.

12. Book a thirty day review before you close the ticket

Thirty days in, the new starter knows what they still cannot do and which tools they have never opened. That is the one moment when right-sizing access is easy and uncontroversial. Without it, over-provisioning is never corrected and the gaps get worked around with personal accounts, which is how shadow IT actually starts.

What makes an IT onboarding checklist survive contact with reality

Almost every organisation has a checklist. Far fewer have one that is followed under pressure, and the difference comes down to four things.

It lives where the work happens. A checklist in a document is read once and remembered badly thereafter. It needs to arrive as work, in the same queue as everything else you are accountable for, or it loses every time it competes with an outage.

Every item has an owner and a date relative to the start date. Not "before they start" but "five working days before". Shared responsibility means nobody is ever late, because nobody was specifically on the hook.

It produces a record automatically. The question an auditor, an insurer or an incoming client asks is not whether you have a process. It is "show me the last five people you onboarded and what each was given." If answering means reconstructing history from mailbox archives, the process exists on paper only.

It mirrors your offboarding list. Anything granted at onboarding and not written down cannot be revoked at offboarding. Building the two as a matched pair, same items in the same order, is the cheapest control available to a small team.

Where this fits with Helios

The practical difficulty with all of the above is that it spans systems: identity in Microsoft 365, the device and its protection state, the asset record, and the ticket tying them together. Helios keeps those in one place, so a starter's device, its patch and antivirus posture, its owner and the onboarding ticket are one object rather than four systems to reconcile, and the protection gaps onboarding tends to create get flagged rather than waited for. None of that removes the discipline above. It means the record writes itself.