The New Employee Onboarding Checklist for HR and IT

Open the onboarding checklist your HR team uses and read it top to bottom. It probably covers the offer letter, tax forms, the welcome note, the buddy, the laptop, and orientation in careful detail. Somewhere in the middle, one line says "IT: set up accounts," and it gets a check mark the moment someone closes a ticket.

That line decides whether a new hire can work on day one, and whether anyone can show months later that their access waited for the training it depended on. A closed ticket can't tell you either.

An onboarding process checklist is a step-by-step list that guides a new hire from accepting their offer to becoming fully productive. Each step should have a person responsible, a deadline, and a clear way to confirm it’s completed. An effective checklist combines account access steps with HR steps, ensures access is only granted after necessary HR steps are finished, assigns someone's name to every step, and makes sure access can be removed later during offboarding. In this article, you’ll find a complete checklist covering everything from the signed offer to the first 90 days, with an owner and a completion check for each step. You’ll also get two quick checks you can use this week with your most recent hires.

Combine your HR and IT onboarding checklist into one timeline

Put the access steps on the same page as the HR steps, one row per milestone, with an owner and a "done when" line that says what finished looks like. Kept together, the two halves of onboarding run on the same calendar.

When access lives on a separate list, the HR checklist finishes on schedule while the access steps run late, and nobody sees the gap until the new hire does. Often those steps sit in a ticket queue, a spreadsheet, or one admin's memory. The welcome, paperwork, and training belong to your employee onboarding program, and the checklist below adds the access half alongside it.

Write each "done when" line as something the new hire can now do, such as "has signed in to every day-one app," and keep IT's activity, such as "accounts requested," out of that column. An outcome either happened or it didn't, and it leaves a record you can point to later. Any step on your current list whose "done when" is a closed ticket is the first one to rewrite.

The HR record decides what every later row can do, which is why automating HR onboarding and offboarding starts with the fields access depends on. Here's the full checklist, from signed offer to day 90.

‍

Once the HRIS start date drives provisioning, the two-weeks-out row runs without a ticket. Lumos Lifecycle Management grants the accounts and entitlements a role requires before the new hire logs in for the first time, so IT's part of that row shrinks to the apps that still need a person.

Contractors, interns, and rehires follow the same rows, with a sponsor standing in for the HR record and an end date set when their access is created. Their edge cases, such as a rescinded offer or a contractor who converts to an employee, are where employee onboarding software earns its place. AI tools need more than a row too, because a new engineer's coding agent runs on whatever the checklist just granted, and employee onboarding best practices handle them role by role.

The row before the first sign-in is the only one where both columns stop and wait for each other. It holds the HR prerequisites and the live identity check that online employee onboarding puts ahead of any working account, and every later row inherits whatever it lets through. It's also the row most checklists don't have.

Hold new hire logins until screening, agreements, and training clear

Screening, signed agreements, any training your policy puts first, and a live identity check all have to clear before a new hire's first sign-in works. Each one decides whether the company should trust the account at all, and a sign-in that works before they clear has skipped that decision. Where your policy requires screening or training before access, the checklist should enforce the order.

NIST's control catalog for federal agencies, SP 800-53, puts the first two of those ahead of access. Organizations screen people before authorizing their access (PS-3), and people sign access agreements before they're granted access (PS-6). The catalog is written for federal agencies, and it's still the clearest statement a private company can borrow.

When auditors working for the Education Department's inspector general tested how the department onboarded new users from January through July 2025, access came first at least once, and the records often couldn't show the order. In a report dated September 30, 2026, they found that on the platform that handles federal student aid, one of nine sampled users got access before finishing assigned cybersecurity training, and four of the nine had no record of the provisioning steps performed. On a platform holding federal tax information, the records didn't show that all three sampled new users had finished training before their access was granted.

The auditors called it "inconsistent adherence to onboarding requirements" and listed it for awareness, with no recommendations issued. The department had the requirement, and its process still let access go first and often left no record of the steps. A prerequisite that lives only in a policy document is a reminder, and a checklist that records check marks can't show whether anyone honored it. Whoever samples your new hires next will ask whether training came first, and a check mark won't answer.

Make each prerequisite a dependency in the workflow, so the account can exist while sign-in stays off until it clears. Record the date and source of each one, such as the training completion or the signed agreement. For an urgent start, write a dated exception with an end date and never skip the step quietly, because an employee onboarding checklist that can't show these dates will fail the same kind of sample. Keep Form I-9 out of this gate, since its timing rules belong to HR and counsel.

For your last ten hires, compare when each first account worked with when each prerequisite cleared. Count the hires whose access came first.

Give every onboarding task one owner across HR, IT, and managers

Every step on an onboarding checklist needs a person's name beside it. A step owned by a team waits until someone on the team happens to notice.

HR operations owns the record, and the hiring manager owns week-one requests and the day-30 call on elevated access. Each app's owner owns the roles inside that app, IT owns the automation and anything nobody else owns, and security owns the prerequisites and the day-90 review. The table names roles, and your copy should name people, because an owner is a person, never a team.

Requests outside the defaults are where a missing owner shows up first. Before Lumos, Roku's approvals sometimes ran through "email chains that accidentally routed approvals to the CEO," and people worked around the process with Slack DMs to IT. With Lumos, anything outside department defaults follows a set chain, the manager first and then the app's owner, which cut down those backdoor messages. A request with no named owner travels up until it finds the most senior person who'll answer it, so send it straight to the app's owner from the start.

The list of what a role gets on day one needs an owner as well, since it decides most of the access steps in the table. When IT owns it, it drifts, because the people who know what a sales rep or an analyst uses all day sit outside IT. Give it to the team lead or the app owner closest to the work.

The hard part of owning that list is knowing which grants anyone uses. Lumos lets each access policy (the rules that decide what a role gets on day one) name an owner, a person or a group who can edit it while admins keep control of publishing, and it logs every ownership change. Every app and permission in the policy carries a plain-language insight, such as Essential, Widely Used, or Rarely Used, with the usage numbers behind it, refreshed at least weekly. A team lead who owns the sales role's list could see that most new reps never open a tool everyone gets, and cut it before the next hire starts.

Once every step has a name, a slipping start date has someone to call. The day-one list gets better with each hire, because someone is watching it.

Grant new hire access through workflows that can also remove it

The access offboarding misses are usually access that onboarding granted by hand. Every step on a new hire checklist is a future removal on someone's offboarding list, whether or not anyone wrote it down.

An admin adds a role directly inside an app. A seat gets created in an app that no connector reaches, a connector being the integration that lets an access platform create and remove accounts in that app. An elevated role goes out with no end date, or someone shares a login to get a new hire started. Each of those day-one exceptions can outlive the person who received it.

The leftovers pile up where nothing reads the app's own accounts. Offboarding that reads each connected app's live accounts will find the admin role added in week one. Offboarding that works from old tickets, or reaches an app with no connector, can only remove what someone wrote down, so that role stays put until an access review or an incident turns it up.

The removal for a day-one grant should exist the day the grant is made. With Lumos, each app's grant and removal workflows are defined once, or once per permission, and run wherever access changes, from onboarding and self-service requests to moves between teams, offboarding, and access reviews. Every app starts with working defaults for both.

For anything that still happens by hand, log the grant when it's made, with the app, the role, and who granted it, in the same place as the automated grants. Give every elevated grant an end date the moment it's granted, and retire shared logins. An employee offboarding checklist can only remove what the joiner's list recorded.

That log can stay short. Tekion runs more than 1,500 access requests a month across 200+ SaaS integrations for more than 3,000 employees, with 95% resolved without manual intervention. We'd expect any team working at that rate to have a hand-made list short enough to check line by line.

List every grant your past quarter's hires received by hand. Then check whether your offboarding checklist would find each one.

Make every onboarding step provable on day one and at audit

The line that said "IT: set up accounts" was carrying the whole access half of onboarding. Give it the access and done-when columns, the row before the first sign-in, and a name on every step, and the checklist can answer for the new hire on day one and for the auditor months later. None of it needs more than the checklist you already keep.

From there, hold sign-in until the prerequisites clear, log every hand-made grant when it's made, and close each hire's onboarding with a day-90 access review. A ticked box proves someone ticked it, and a finished checklist proves what happened.

The next offer letter your team sends starts a new checklist. Book a demo to see Lumos Lifecycle Management build that hire's accounts and day-one access from the start date, give each role's day-one list a named owner with usage evidence, and run each app's grants and removals from workflows defined once.

‍

‍