Free checklist · Onboarding

IT Onboarding Checklist

An IT onboarding checklist defines how an employer provisions a new hire's identity, device, access and licences before the start date. It works from a role based access template rather than ad hoc requests, records every asset and account issued, and builds the removal path at the same time so the eventual offboarding is a reversal rather than an investigation.

IT onboarding fails in two directions and both are expensive. Provision too little and the new hire spends their first days raising tickets instead of working. Provision by copying another employee's permissions and you grant access nobody has reviewed, to systems the person will never use, which then persists for years. This checklist is written for IT, security and people teams working together, and it treats provisioning as a repeatable role based process with an audit trail rather than a series of individual favours.

Trigger provisioning from a single source, ahead of the start date

IT should not learn about a new hire from an email the week before. Provisioning needs a defined trigger, normally the accepted offer status in the applicant tracking system or the creation of the record in the HR system, and enough lead time to order hardware and complete the build.

The trigger should carry everything IT needs in one payload: legal name, preferred name, start date, job title, department, manager and location. Chasing those details individually is where most of the delay comes from.

  • Define the exact system event that triggers IT provisioning
  • Require the full data set at trigger time rather than collecting it piecemeal
  • Set a provisioning deadline that lands before the start date
  • Confirm the location, since it determines hardware, licensing and regional settings
  • Flag any start date change to IT automatically
  • Track provisioning as a ticket with an owner and a due date

Create the identity once and connect everything to it

The account is the foundation of everything that follows, so create it in the identity provider and let downstream systems inherit from it. Systems provisioned outside single sign on become the accounts nobody remembers to remove.

Set up authentication properly at creation rather than leaving it to the new hire. Multi factor enrolment, recovery methods and group membership all belong in the build, not in a request the person makes on day one from an account they cannot yet access.

  • Create the account in the identity provider as the single source of truth
  • Apply the naming convention consistently, including for duplicate names
  • Enrol multi factor authentication and confirm a recovery method
  • Assign group memberships based on role rather than individually
  • Connect every possible system through single sign on
  • Record any system that cannot use single sign on for manual review

Build the device before it reaches the new hire

A device handed over unconfigured turns the first day into a setup session. Enrol it in your management platform, apply the baseline configuration, install the standard software set and encrypt the disk before it leaves IT.

Record the asset at the same time. Serial number, model, assigned user and issue date take a minute to capture during the build and are very difficult to reconstruct two years later when the person leaves.

  • Enrol the device in the endpoint management platform before handover
  • Apply the security baseline including disk encryption and screen lock
  • Install the standard software set for the role in advance
  • Confirm updates are applied and the device is compliant
  • Record serial number, model, assigned user and issue date in the asset register
  • Prepare any peripherals, adapters and accessories as part of the same build

Run this checklist inside your hiring pipeline

Free 1-user plan · No credit card

Grant access from a role template, not by copying a colleague

Cloning an existing employee's permissions is fast and is the main reason organisations accumulate access nobody can justify. It copies whatever that person collected over years, including the temporary grant from an incident three roles ago.

Maintain an access matrix per job family instead: the systems every holder of that role needs, at what permission level, and which additions require named approval. Anything outside the template becomes an explicit request with a reason attached.

  • Maintain a documented access matrix per job family
  • Provision from the template rather than by copying an existing user
  • Require a named approver and a reason for anything outside the template
  • Grant the lowest permission level that allows the work
  • Set expiry dates on any temporary or elevated access at the point of granting
  • Keep production, financial and customer data access as separate explicit approvals
  • Log what was granted, by whom and on what basis

Assign licences deliberately and track the cost

Software licences are assigned during onboarding and almost never reviewed afterwards, which is how organisations end up paying for seats belonging to people who left. Assign only what the role actually needs and record the assignment against the person.

Where a tool has both a full and a limited licence tier, default to the lower one. Upgrading later takes minutes; identifying over licensed users retrospectively takes an audit.

  • Assign licences from the role template rather than on request
  • Default to the lowest licence tier that supports the work
  • Record every licence assignment against the individual
  • Note the renewal or true up date for each tool
  • Review licence assignments when the role or team changes
  • Confirm no licence is issued to a shared or generic account

Deliver security training and set the expectations early

The first weeks are when a new hire is most vulnerable to impersonation attacks, because they do not yet know who is supposed to be asking them for things. Cover that directly rather than relying on a generic annual module scheduled months away.

Keep it practical. What a real internal request looks like, how to verify an unexpected instruction, where to report something suspicious and what the password and device rules actually are will serve better than an abstract policy overview.

  • Deliver security awareness training within the first week
  • Explain how to verify an unexpected request that appears to come from a colleague
  • Show exactly how and where to report a suspected security incident
  • Cover the password manager, device handling and public network rules
  • Explain the acceptable use policy and obtain acknowledgement
  • Cover any data handling rules specific to the role

Build the offboarding path while you are provisioning

Every account and asset issued during onboarding has to be recovered eventually, and the difference between a clean removal and a forensic exercise is whether anyone recorded what was granted at the time.

Maintain a per employee record of accounts, assets, licences and any non standard access. This is also the record that makes access reviews possible, which is otherwise a task nobody can complete accurately.

  • Maintain a per employee record of every account, asset and licence issued
  • Note every system outside single sign on, since those need manual removal
  • Record who approved any access granted outside the role template
  • Schedule a periodic access review rather than relying on departure to trigger one
  • Confirm the leaver trigger from HR reaches IT automatically
  • Test the removal process periodically rather than assuming it works

Get this checklist emailed to you

We'll send this checklist plus the rest of the onboarding pack — and the occasional hiring tip. No spam, unsubscribe anytime.

No spam — just the resource and the occasional hiring tip. Unsubscribe anytime.

FAQ

IT Onboarding Checklist — FAQs

When should IT provisioning start for a new hire? +
As soon as the offer is accepted and the start date is confirmed, because hardware lead times are the constraint rather than the configuration work. Waiting until the week before is the most common reason a new hire spends their first days without a working device or without access to the system they were hired to use.
What access should a new employee get on day one? +
Identity, email, calendar, chat and the primary system for their role, which is enough to participate and to start learning. Everything else can follow during the first week. Provisioning every system at once produces a wall of unfamiliar tools and grants access before anyone has confirmed it is needed.
Why is copying another employee's permissions a problem? +
Because it copies whatever that person has accumulated, including temporary grants that were never removed and access tied to responsibilities the new hire does not have. Permissions cloned this way compound across the organisation and become impossible to justify during an access review. A role based template gives a defensible starting point.
Who should own the IT onboarding checklist? +
IT owns the execution and the access matrix. HR or people ops owns the trigger and the accuracy of the joiner data. Security owns the standards the matrix must meet. The failure point is usually the handoff, so it helps to have one named person accountable for confirming provisioning is complete before the start date.
How do we track equipment issued to employees? +
Record it at build time, not at handover, capturing serial number, model, assigned user and issue date in a single register. Reconstructing this later is extremely difficult, particularly for remote employees, and an incomplete register is why organisations write off devices they cannot locate when someone leaves.
Should new hires complete security training in week one? +
Yes, because early tenure is when impersonation attempts are most likely to succeed. A new joiner does not yet know which internal requests are normal. Practical training on verifying unexpected requests and reporting suspicious activity is more useful in that first week than a policy module scheduled for the next annual cycle.
How does IT onboarding connect to offboarding? +
The record created during provisioning is what makes removal complete. Every account, asset and licence issued should be logged against the individual, with any system outside single sign on flagged, since those require manual action. Without that record, offboarding becomes guesswork and accounts survive long after the person has left.
Pitch N Hire ATS

Run this checklist inside your hiring pipeline

Pitch N Hire is an applicant tracking system. The steps on this page become stages in a pipeline, so nothing is skipped and everyone can see where each candidate stands.

  • Turn process steps into pipeline stages the team follows
  • See exactly where every candidate is, without status meetings
  • Keep notes, feedback, and documents on the candidate record

Free for 1 user · No credit card · Talk to a real hiring expert

Built for recruiters & hiring teams

Onboard new hires from the same system you hired them in

Pitch N Hire keeps the offer, the paperwork trail, and the candidate record in one place — so nothing is retyped between hiring and day one. Start free with the 1-user plan.

Prefer to talk? Book a demo · Talk to sales · View pricing

Free 1-user plan · No credit card · Talk to a real hiring expert

One Hiring Infrastructure.
Zero Tool Chaos.

Demos are consultative. We respect privacy and enterprise
governance. No lock-ins.

Start free Book demo