IT Onboarding Checklist for New Employees

Q: What should an IT onboarding checklist include?

Accounts, role based access, a prepared and enrolled device, an asset record, MFA enrolment, a first day sign in walkthrough, security basics, and a first week check in for missing access.

An IT onboarding checklist for new employees covers three windows: before day one (create accounts, prepare the device, grant role-based access, register them in your asset list), day one (hand over, sign in, enrol multi-factor authentication, confirm everything works) and the first week (security basics, follow-up access, a check-in). The most reliable way to run it is as a single onboarding request with a checklist, triggered by HR as soon as the hire is confirmed, so nothing depends on anyone remembering.

Why IT onboarding goes wrong

The classic failure: a new starter arrives, their laptop isn't ready, their account doesn't exist, and they spend day one watching someone else's screen. Causes are always the same:

IT hears about the hire late, or not at all.
Access is requested piecemeal by the manager over the first week.
Steps live in one person's head.

Every one of these is fixed by structure: an early trigger, a role-based template and a checklist on a tracked request.

The trigger: HR files it, early

The checklist starts when HR confirms a hire — ideally at least five business days before the start date, more if hardware must be ordered. HR (or the hiring manager) files one onboarding request with:

Name, role, team, manager, start date, location (office or remote).
Device needs (standard laptop or a specific configuration).
Which role template applies.

The start date sets the deadline. Because the request lives in the desk's queue sorted by deadline, it surfaces automatically as the start date nears. If requests currently arrive by email, see what is an internal request desk.

Before day one

Identity account created (email, single sign-on) with the correct name and team.
Role-based access granted from the template — the groups and apps everyone in that role gets. Nothing more.
Device ordered, received, enrolled in device management, encrypted, updated, and named per convention.
Asset record created: device serial, model, assigned person, date. The CIS Critical Security Controls start with exactly this — an inventory of enterprise assets — because you can't secure what you don't know you have.
Shipping or desk arranged for remote or office starters.
Temporary credentials prepared for first sign-in, delivered securely and forced to change at first use.
Their manager told what's ready and what to expect on day one.

Access from templates, not memory

Build a template per role: the groups, shared drives and SaaS apps that role needs. "Engineer" gets the code host, the cloud console (read-only at first) and the team's chat channels; "Finance" gets the accounting system and the finance drive. Templates enforce least privilege — access limited to what the role requires — and make offboarding easier, because you know exactly what to remove. The role model behind this is described in role-based access for internal tools.

Anything beyond the template is a separate access request with an approval, not an onboarding shortcut.

Day one

Hand over the device (or confirm delivery) and walk through first sign-in.
Change the temporary password and set up a password manager if you use one.
Enrol multi-factor authentication. CISA describes MFA as one of the most effective ways to protect accounts; do it before the new starter has built habits without it.
Confirm access works: email, chat, the main apps for their role, printing if relevant.
Show them how to get help: the request desk link, and file their first request with them so they see how status works. See onboarding a team to a new help desk tool.
Security essentials in ten minutes: how phishing looks at your company, how to report it, why the help desk will never ask for their password.

First week

Follow-up access: collect requests for anything the template missed — each as its own request with approval.
Short security training, if you run one.
Check-in on day three to five: "Is anything not working?" Small problems are cheap to fix early.
Update the template if the same extra access was needed — the next hire in that role shouldn't need to ask.

Remote starters

Remote onboarding adds logistics:

Ship the device early enough for delays and customs; track the shipment on the request.
Pre-enroll the device so it configures itself on first boot where your device management supports it.
Schedule a video call for first sign-in; don't rely on written instructions for MFA enrolment.
Confirm the home network can reach what they need (VPN, if used).

A role template, written down

A template is just a short list, kept somewhere editable. An example for a support-team hire:

Item	Access level	Approver
Email, calendar, chat	Standard	— (everyone)
Request desk	Agent, Support team	Team lead
Customer database	Read + update tickets	Team lead
Knowledge base editor	Write	Team lead
Finance systems	None	—
Admin consoles	None	—

Two rules keep templates healthy. First, a named owner per template — usually the team lead — who reviews it every quarter. Second, every exception granted to a new starter is a signal: if three hires in a row needed the same extra access, it belongs in the template; if one did, it stays an exception with its own approval.

An IT onboarding checklist template for Excel, Word or PDF

The same list as one table. Paste it into Excel or Google Sheets (one sheet per new starter), or into Word and export to PDF if you want a printable copy for the manager.

Task	Owner	When
File the onboarding request: name, role, team, manager, start date, location, device needs	HR or manager	At least 5 business days before
Create the identity account and apply the role template	IT	Before day one
Order, receive, enrol, encrypt and update the device	IT	Before day one
Create the asset record (serial, model, assignee, date)	IT	Before day one
Prepare temporary credentials, forced to change at first use	IT	Before day one
Tell the manager what is ready for day one	IT	The day before
Hand over the device; walk through first sign-in; change the temporary password	IT	Day one
Enrol multi-factor authentication	IT and new starter	Day one
Confirm email, chat, role apps and printing all work	IT	Day one
Show how to get help; file their first request together	IT	Day one
Security essentials: what phishing looks like and how to report it	IT or security	Day one
Collect follow-up access requests, each with its own approval	Manager	First week
Short security training, if you run one	Security	First week
Check-in: is anything not working?	IT	Day three to five
Update the role template if the same extra access was needed again	Template owner	End of week one

Add a "Remote?" column if you onboard both ways, and a separate sheet for contractors with an end date on every account. Whatever the format, the checklist only works if one person owns it and the start date drives the deadlines.

Contractors and temporary staff

Contractors need a variant of the checklist:

An end date on every account, set at creation, so access expires even if nobody remembers to offboard.
A narrower template — the project's systems only.
Their own devices? Decide in advance whether they may use personal devices and what that requires (device management enrolment, a browser-only workspace, or a company laptop).
A named sponsor inside the company who approves extensions.

Run it as one request with a checklist

A single onboarding request with a checklist beats a dozen separate tickets:

One place to see status: HR, the manager and IT all look at the same request.
Checklist items tick off as work happens; the request resolves when all are done.
A deadline from the start date, visible in the queue.
History for audits: who granted what, when.

In LetRelay, tasks support checklists that can be added when the task is created and edited inline, so an onboarding template can be a task with a pre-filled checklist linked to the request.

Measure it

Two numbers tell you whether onboarding works:

Ready on day one — the share of new starters with device, account and core access working at 9 am on their first day.
Access requests in week one — if every new starter files five extra access requests, the templates are incomplete.

The same metrics discipline is described in help desk metrics that matter.

Don't forget the other end

Every access granted at onboarding must be removed at offboarding. Keeping the asset list and role templates accurate now is what makes offboarding a checklist instead of a hunt.

FAQ

What should an IT onboarding checklist include?

Accounts, role-based access, a prepared and enrolled device, an asset record, MFA enrolment, a first-day sign-in walkthrough, security basics, and a first-week check-in for missing access.

How far in advance should IT onboarding start?

At least five business days before the start date, longer if hardware must be ordered or shipped.

Who should trigger IT onboarding?

HR or the hiring manager, by filing one onboarding request as soon as the hire is confirmed, with role and start date.

How do you manage access for new employees securely?

Grant access from role templates that follow least privilege, require approval for anything extra, enrol MFA on day one, and record everything so it can be removed at offboarding.

Is there an IT onboarding checklist template I can use in Excel, Word or PDF?

Yes: the table above lists fifteen tasks with an owner, a timing and a done-on column. Paste it into Excel or Google Sheets, or into Word and export a PDF to print. Keep one copy per new starter and file the finished one with the hire's record; adjust the rows for your tools and for remote or contract staff.

What is the difference between IT onboarding and general employee onboarding?

General onboarding is HR's: contracts, payroll, policies and introductions. IT onboarding is the technical part inside it: accounts, devices, access, MFA and security basics. They share a trigger (HR confirms the hire) and a deadline (the start date), so file them as linked requests, not separate processes that each wait for the other.