Most onboarding problems are scheduling problems. The request arrives on the morning somebody starts, and everything after that is recovery.
The usual diagnosis of bad IT onboarding is that IT is slow. Occasionally true. Far more often, the request reached IT at 8.40am on the day the person started, with a job title and no other information, and everything that followed was triage.
So the first item on any useful onboarding checklist is not technical.
Five working days
The request has to arrive five working days before the start date, and it has to contain the role, the start date, the manager and the location. That is the whole requirement, and enforcing it fixes more onboarding problems than any amount of automation.
Making it happen is a process problem rather than an IT one. The two things that work: put the IT request inside the offer-acceptance workflow, so it is triggered by HR rather than remembered by a manager, and publish what happens when the lead time is missed. Not as a punishment, but so that a manager who raises it the day before knows the new person will not have a laptop, and can decide whether that is acceptable.
Role templates, not copied colleagues
The most common access-control failure in any organisation starts with a reasonable instruction: "give them the same access as Sarah."
Sarah has been here six years. She covered for finance during a maternity leave in 2023, she was on a project team that needed access to a system she no longer uses, and she has administrative rights to something because of an incident two years ago. Copying Sarah copies all of it, and it compounds: the next person is copied from the new starter, and so on.
Define a template per role instead. Groups, licence, applications, and the systems that role needs. Ten to twenty templates covers most organisations. They need reviewing annually and they take an afternoon to build, and they turn provisioning into a decision somebody made once rather than a judgement made under time pressure.
Who owns what
The item that matters most and is almost always absent is the last one in the first group: the manager confirming, in writing, during week one, that the access is correct.
Without it, over-provisioning is invisible. The new person has access to three things they do not need, nobody notices because nothing breaks, and those permissions follow them for the rest of their time at the organisation. A one-line confirmation closes the loop and costs the manager thirty seconds.
The three things never to do
Never email credentials. Even temporary ones, even with a forced change at first sign-in. Set the password with the person present, or use a self-service process with identity verification. A password in an inbox is a password in a backup, an archive, and possibly a forwarded thread.
Never register MFA for somebody else. If IT enrols the authenticator, IT can authenticate as that person, and the audit trail is meaningless. The enrolment happens with the person holding their own device.
Never grant local administrator by default. If a specific role needs it, that is a documented exception on the role template with a reason. Default-on local admin is the single largest multiplier of impact when something does go wrong on an endpoint.
The first-day experience
Worth caring about beyond politeness: the first day sets expectations about whether the organisation is competent, and people talk about it.
What good looks like is unremarkable. The laptop is on the desk, it starts, the person signs in with their own credentials, everything they need is already installed, and a human spends twenty minutes with them covering how to get help, how to report something suspicious, and where files belong.
That last twenty minutes is the highest-value security training the organisation will ever deliver, because it is the only time the person is fully attentive and has no habits yet.
Automate the boring half
Once role templates exist, most of the provisioning sequence can run without human involvement: account creation from the HR system, group membership from the template, licence assignment from the group, device configuration and application delivery from enrolment.
What should stay manual is anything requiring judgement, meaning exceptions to the template and any elevated access. The goal is not to remove people from the process; it is to remove them from the parts where they add only the possibility of error.
And the other end
Offboarding is the same checklist in reverse and it is reliably worse, because nobody is waiting for it to be finished. Nothing visibly breaks when a leaver's account stays active, which is precisely the problem.
Two things make it work: the trigger comes from HR rather than from a manager remembering, and somebody reviews what was actually disabled a week later. A quarterly reconciliation of active accounts against the current staff list catches whatever both of those missed, and it should be a short list. If it is a long one, that is this quarter's finding.
