This free IT onboarding checklist is the run IT repeats for every new hire, from the moment HR confirms the hire to a 30-day check that removes the access nobody uses. It has three owners. HR confirms the details and files the signed policies, the hiring manager requests and approves access by role, and IT builds the account, the device and the MFA. Every due date counts from the start date, a remote starter gets shipping tasks, and a role with admin rights gets a separate approval. For engineering hires, add the Developer Onboarding Checklist for the code host and dev environment. HR’s side of the hire is in the Preboarding Checklist and the Employee Onboarding Checklist, and contractors have their own Contractor Onboarding Checklist.
Identity teams describe an account’s life in three events. A joiner gets access, a mover changes role and should lose what the old job needed, and a leaver has everything switched off. The mover and leaver steps have their own templates: the Internal Transfer Checklist and the IT Offboarding Checklist. This page is the joiner step, and it sets the pattern for the other two. Whatever is granted on the way in without a record has to be found by hand on the way out. If you are an MSP taking on a new client rather than a new person, the Co-Managed IT Onboarding Checklist is the one you need.
The IT onboarding process usually fails at the handoffs, not inside IT. HR tells IT late, or with a job title that matches no access profile. The manager asks for “the same as Sam”, which hands the new person everything Sam collected over five years. IT then grants it, because nobody told them otherwise. So each step here belongs to the person who actually knows the answer, and IT grants nothing until the manager’s request is approved.
Seven phases and 36 tasks, dated from the start date. Shipping tasks appear for remote and hybrid starters, and the admin phase only when the role needs it.
HR opens the checklist when the hire is confirmed. The start date and work location entered here drive the rest.
The approval halts the checklist, so IT grants nothing until the request is signed off.
The build itself is defined in the Laptop Provisioning Checklist and enrolment in the MDM Enrollment Checklist. This phase only issues and records a device that already meets them.
Standard access comes first. Admin rights follow once the security lead approves, and the approval halts the checklist until then.
A month in, compare what the starter has with what was approved and what they actually use.
If you are certified to ISO/IEC 27001, audited for SOC 2 or applying for Cyber Essentials, the assessor will ask how a new account is approved, how the first credential reaches the person and when access is checked again. The table maps each part of the checklist to the controls that ask for it. Control references were checked in October 2026. It is a process guide, not legal or audit advice; your own scope and auditor decide what counts as evidence.
| Checklist step | What the control expects | Where it comes from |
|---|---|---|
| Approved request before access (Phase 2) | A documented process for granting access when someone is hired, and new users registered and authorised before credentials are issued | CIS Controls v8.1 Safeguard 6.1; SOC 2 criterion CC6.2; ISO/IEC 27001:2022 Annex A 5.18 Access rights; Cyber Essentials: a process to create and approve user accounts |
| Access by role (Phases 2 and 3) | Rules for access based on business need, and the access each role needs written down | ISO/IEC 27001 Annex A 5.15 Access control; CIS Safeguard 6.8; Cyber Essentials: access only to what the role needs |
| Identity and account inventory (Phase 3) | The identity lifecycle managed, and an inventory of every account with its owner and start date | ISO/IEC 27001 Annex A 5.16 Identity management; CIS Safeguard 5.1 |
| First credential and MFA (Phases 3 and 5) | Authentication information issued and handled securely; MFA on cloud and externally exposed services | ISO/IEC 27001 Annex A 5.17 and 8.5; CIS Safeguard 6.3; Cyber Essentials v3.3: cloud services must always use MFA |
| Device and asset register (Phase 4) | An inventory of assets with owners, and rules for user endpoint devices | ISO/IEC 27001 Annex A 5.9 and 8.1 |
| Policies and training (Phases 1 and 5) | Acceptable use rules communicated and agreed; security awareness training for staff | ISO/IEC 27001 Annex A 5.10, 6.2 and 6.3 |
| Admin access (Phase 6) | Privileged rights restricted and managed; a dedicated admin account with MFA | ISO/IEC 27001 Annex A 8.2 and 8.15 Logging; CIS Safeguards 5.4 and 6.5; Cyber Essentials: separate accounts for admin activities |
On MFA, two sources set the bar. NIST’s SP 800-63B-4, final since July 2025, says verifiers at AAL2 must offer at least one phishing-resistant option, and that one-time codes and out-of-band methods such as text messages are not phishing-resistant. CISA’s fact sheet on phishing-resistant MFA names FIDO/WebAuthn and PKI as the phishing-resistant forms and treats SMS or voice codes as a last resort. In the UK, the NCSC’s Cyber Essentials requirements v3.3 took effect in April 2026 with the Danzell question set. According to IASME, not using MFA on a cloud service that offers it now fails the assessment outright. If you are rolling MFA out across the whole company rather than one hire at a time, use the MFA Rollout Checklist.
HR picks the hiring manager, IT owner and security lead in the first task, and each task is assigned from those pickers. Due dates count from the start date: the access request twelve days out, the device seven, the review thirty days in. Move the start date once and every deadline moves with it.
The manager’s request is an approval task, and the checklist halts there until it is approved. The access table records each system, level, approver and grant date, and the 30-day review compares against that table, with names and timestamps in the audit trail.
Two dropdown answers shape the run. A remote or hybrid starter gets the shipping and home-working tasks. A role that needs admin rights gets the whole admin phase, with its own approval by the security lead and a check at 30 days that the rights are still used.
CheckFlow’s IT onboarding software shows every new hire in progress, which tasks are overdue and who owns them, so HR and managers stop asking IT for updates.
For the reasoning behind each step, the new hire IT setup guide walks through pre-start provisioning, day one, the first week and the 30-day review.
The hire details from HR, an access request by role that the manager approves before anything is granted, the identity, mailbox and SSO, a device built and enrolled before it is issued, software and licences, signed acceptable use and security policies, MFA enrolled at first sign-in, security awareness training, first-week checks, and a review around day 30 that removes what is not needed. Each step should have a named owner and a due date counted from the start date.
HR onboarding covers the contract, payroll, right to work, introductions and the probation review. New hire IT setup covers what the person can sign in to and the device they use. The two meet at three points: HR supplies the details IT builds the account from, HR files the signed policies, and the manager approves the access. Run them as separate checklists with the same start date, so each team owns its own record.
Ideally they never receive a reusable one. Issue a single-use code or short-lived link that lets them set up their own password or passkey and enrol MFA, and send it through a personal contact route HR already holds, separately from the username. Avoid shared default passwords and avoid emailing credentials to the work mailbox they cannot yet open. Record the method and expiry in the checklist, never the secret itself.
A phishing-resistant method where your systems support one: a passkey, a FIDO2 security key or a platform authenticator built into the laptop. Where they do not, CISA puts an authenticator app with number matching next, and text-message or voice codes last. NIST also recommends that people keep at least two ways to authenticate, so enrol a second method for recovery on day one rather than after the first lost phone.
Because the first month is when access drifts. Temporary grants made to get someone working are forgotten, licences are assigned and never opened, and requests made over chat skip the approval. A check at 30 days catches these while the manager still remembers why each one was given. After that the account joins your regular user access review, and admin accounts join the privileged access review.
No. They start from different triggers, involve different people and are often months or years apart. Keep them as two templates that share the same access table structure, so the leaver run can work from what the joiner run recorded. For the leaver side, use the IT Offboarding Checklist, with the SaaS Offboarding Checklist for application access and the Employee Offboarding Checklist for the wider exit.
14-day free trial, no card required. The Business plan is $10 per user per month after the trial. Full details at checkflow.io/pricing.
