IT Onboarding Checklist for New Employees

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.

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.

Sources

• CIS Critical Security Controls v8
• CIS — Inventory and control of enterprise assets
• CISA — Require multifactor authentication
• NIST — Least privilege (glossary)
• NCSC — Device security guidance