The Three Phases of IT Onboarding
IT onboarding is not a single event. It is a sequence that runs from before the new starter arrives to about one week after they begin. Each phase has a different owner, a different objective, and a different set of tasks. Skip any phase and the problems show up in the next one.
The three core phases are pre-arrival setup, day-one configuration and handover, and first-week follow-through. Every organisation's exact sequence varies based on size, industry, and role, but these phases are universal. The discipline is in executing each one consistently, not in finding clever shortcuts around them.
Pre-Arrival Phase
Pre-arrival is where most IT onboarding failures originate. Hardware requests raised too late, accounts created on the morning of day one, software licences that have not been assigned, VPN profiles that have not been tested. These are not IT team failures in the traditional sense. They are process failures: nobody made the pre-arrival tasks someone's explicit responsibility with a deadline.
Hardware procurement should begin the moment an offer is accepted. MacBooks, docking stations, monitors, and peripherals regularly have lead times of two weeks or more. If the new starter is starting on a Monday, the hardware request needs to be raised the previous Thursday at the latest. For specialist equipment or non-standard builds, add more lead time.
The pre-arrival checklist covers raising hardware requests with enough notice, registering the device in the asset management system, applying the correct operating system image or build, configuring the device to join the correct network segment or VLAN, provisioning accounts in Active Directory or the identity provider, assigning role-appropriate application licences, and pre-configuring VPN access for remote or hybrid workers. None of these tasks are optional. Each one has a specific owner and a specific deadline.
Day-One Phase
Day one begins with credential handover. This should never be a handwritten note or a plain-text email. A practical approach is a sealed letter with a temporary password, or a one-time link that the new starter uses to set their own password on first login. Either way, the new starter must be prompted to change the temporary password immediately, and MFA enrollment should be the second step after first login.
The first-day IT agenda should be structured. The new starter needs to sign off on the IT acceptable use policy, enroll MFA on all critical accounts, log into the device and verify full configuration, connect to required network drives or cloud storage, install and verify access to role-specific software, confirm VPN connectivity if applicable, and understand how to raise an IT support ticket. Assigning an IT buddy for the first morning prevents a flood of confused emails to the wider team and gives the new starter a direct line to help that does not involve waiting in a ticket queue.
First-Week Phase
The first week is where the onboarding is either confirmed as complete or found to have gaps. The new starter should be able to use their device, access the systems they need, and work without IT intervention for routine tasks. If the first week generates more than two or three IT tickets from the same new starter, something in the onboarding process failed to communicate or configure correctly.
First-week follow-through includes verifying that all accounts are active and accessible, confirming that shared drive and printer access works as expected, ensuring the new starter can log support tickets without assistance, and collecting feedback on anything that was confusing or missing from the IT setup. That feedback is the raw material for improving the next onboarding cycle.
Device Setup and Configuration Standards
A device should arrive in a state that requires no configuration from the new starter. OS setup before handover includes joining the device to the domain or appropriate management framework, applying group policy objects for security settings, enabling disk encryption on Windows or macOS, confirming antivirus or endpoint detection software is active and up to date, setting up automatic updates or a managed update schedule, and configuring screen lock timeout and sleep settings.
Drive mappings should be pre-configured where possible. If automation is not possible, document the mapping process clearly. Do not assume a new starter knows what a UNC path is or how to map a drive letter. Printing failures in the first week are one of the most common sources of early frustration and IT tickets. Printer access needs to be pre-configured or clearly documented, not left to the new starter to figure out.
For remote or hybrid workers, VPN setup and testing must happen before the first day ends. The VPN client needs to be installed and licensed, the correct profile applied for their role, split tunneling settings reviewed so that all traffic is not routed unnecessarily through the VPN, and the new starter walked through how to connect, disconnect, and what to do when it fails. If VPN troubleshooting requires an in-person visit on day one, the remote onboarding process has already failed.
Account Provisioning and Access Management
Accounts should exist before the new starter arrives. This means coordinating with HR or line management to get the new starter's details early enough to provision accounts before their start date. At minimum, these accounts need to be live before day one: Active Directory or identity provider account, email account, role-specific application accounts, appropriate group memberships based on job function, and VPN client pre-configured for remote workers.
Automated provisioning scripts or identity management tools significantly reduce manual overhead. A script that provisions a new account consistently will save more time over twelve months than it took to write. Without automation, account creation is error-prone and dependent on whoever is available on the day, which is how you end up with new starters who have email but no access to the project management system for their first three days.
Before access is granted, someone needs to decide what the new starter actually needs. Role-based access control is the right framework: map the role to the access required, not the individual to a long list of permissions. The default position is always least privilege. A new starter gets the minimum access required to do their immediate job. Additional access is granted upon request, after justification, and after approval. This is not distrust. It is good security practice that protects both the individual and the organisation.
Contractors and agency staff require additional consideration. Their access should be time-bound, tied to the contract end date, scoped to the specific project or environment they are working in, and reviewed at each contract renewal. Contractors should not have standing admin access to production systems under any circumstances.
IT Security Fundamentals for New Starters
Every new starter needs a security briefing before they touch anything sensitive. This briefing should happen on day one, not in week three. New starters who have not been told about the password policy, phishing, or data handling expectations are a security liability from the moment they log in. A structured approach to security awareness during onboarding sets the right tone from the beginning.
Password Standards
Communicate the password policy before the new starter sets their first password. Cover minimum length and complexity requirements, how often passwords must be changed and why forcing frequent changes is now considered counterproductive, where to store passwords (approved password manager, not browser autocomplete or a spreadsheet), and that passwords must never be shared, even with IT staff. Legitimate IT will never ask for a password.
Phishing and Social Engineering
Phishing is the most common attack vector for small and medium organisations. A new starter who has not been briefed on it is a liability on day one. The briefing should cover how to spot a suspicious email: unexpected urgency, mismatched sender addresses, unexpected attachments. What to do when they see something suspicious: do not click, report to IT. And that they should verify unusual requests for money or access by phone using a known number, not one in the email.
Running a simulated phishing exercise in the first month is one of the best investments an IT team can make. Catch the mistake safely, teach the lesson immediately. New starters who fall for a simulation on their first month learn more from that experience than from any policy document.
Data Handling
New starters need to understand what categories of data they will be handling. At minimum, they need to know what constitutes personal or customer data, that customer data must not be copied to personal cloud storage or sent via personal email, how to handle data securely when working remotely, and what to do in the event of a suspected data breach. The briefing should make these concrete for day-to-day work, not simply refer to a policy document that nobody reads.
Common IT Onboarding Mistakes
Mistake one is treating onboarding as an IT task rather than an organisational process. When IT is the only team responsible for onboarding, the HR and line management handoffs break down and hardware arrives after the start date. Treat it as a cross-functional process with named owners at each stage.
Mistake two is assuming the new starter knows how to use standard business software. If they have never used your chosen project management tool, ticketing system, or communication platform, five minutes of guided walkthrough on day one prevents a week of confused requests.
Mistake three is no security briefing in the first week. New starters who have not had a security briefing are more likely to click suspicious links, use weak passwords, and mishandle data. Schedule it as day-one work, not optional orientation content for week three.
Mistake four is no documentation for common IT tasks. If the answer to "how do I connect to the VPN" or "how do I set up my email on my phone" is "search the knowledge base", the knowledge base probably does not have the answer. When the answer is "email IT and wait", that is a process failure, not a training failure.
Mistake five is no review loop. Collect honest feedback after every new starter joins. What was confusing, what took too long, what was missing. Use that feedback to improve the next onboarding. A process that does not improve is a process that is falling behind.
IT Onboarding for Remote and Hybrid Teams
Remote onboarding introduces specific challenges that in-office onboarding does not face. Without the ability to walk a desk and troubleshoot in person, every step of the process needs to work remotely from the start.
Shipping pre-configured hardware to a remote worker's home address is the most reliable approach. The device arrives ready to use, with accounts pre-provisioned and VPN already configured. This requires coordinating delivery timing with the new starter's availability to sign for the package and has the added benefit of testing their home network setup in advance.
When pre-configuration is not feasible, remote enrolment tools can apply settings over the network once the device is powered on and connected. This requires MDM or mobile device management infrastructure, which many small businesses implement as part of their broader IT support setup. Without that infrastructure, remote onboarding becomes heavily dependent on video calls and step-by-step guidance, which works but takes more time from the IT team.
A video walkthrough on day one is a practical substitute for in-person setup. Walk the new starter through their device, show them where to find the software they need, and have them perform each critical task while you watch. This catches configuration problems early and builds the new starter's confidence faster than sending a list of instructions to follow alone.
For distributed teams spread across the UK, time zone coordination adds another layer. Schedule onboarding sessions during overlapping working hours and document the process in writing for reference outside those hours. Asynchronous documentation cannot replace synchronous walkthroughs entirely, but it reduces the number of real-time support calls needed in the first week.
Documentation and Knowledge Management
A realistic IT onboarding process depends on documentation that actually exists and is kept current. The most common failure is not missing documentation entirely but documentation that was accurate six months ago and has not been updated since.
Each step in the onboarding process should map to a document or knowledge base article. Hardware setup maps to a device build guide. Account provisioning maps to a checklist with the specific systems and the correct order of operations. VPN setup maps to a guide that covers installation, configuration, and common problems. If the answer to a common new starter question does not exist in the knowledge base, create it the first time the question is asked.
Review documentation quarterly or whenever a common ticket reveals a gap. Stale documentation is worse than no documentation because it creates false confidence. A new starter follows steps that no longer match the current software version and ends up more confused than if they had been told to ask IT directly.
Measuring Onboarding Effectiveness
Without measurement, there is no way to know whether the onboarding process is working or falling behind. The most useful metrics are straightforward to collect.
Time to first IT ticket measures how long the new starter goes before raising their first support request. A well-configured new starter should not need to raise an IT ticket for basic setup issues within the first three days. Frequent tickets in days one through three indicate configuration gaps that need fixing before the next onboarding.
Ticket volume per new starter in the first month gives a sense of how prepared they were. A few tickets are normal as they learn the environment. A high volume suggests the onboarding checklist is missing steps or that the documentation was insufficient.
New starter feedback collected at the end of the first week is qualitative but invaluable. Ask specifically what was confusing, what took longer than expected, and what they wish they had known on day one. This feedback directly improves the process for the next person who joins.
A Realistic IT Onboarding Process Starts with Discipline
The difference between a smooth IT onboarding and a chaotic one is not budget or headcount. It is discipline. Disciplined organisations treat IT onboarding as a defined process with owned steps, time-bound execution, and a feedback loop. Disorganised ones treat it as something that happens and hope for the best.
The investment is modest: a pre-arrival checklist, a first-day structure, a security briefing, and a knowledge base that actually has answers. That investment pays back immediately in reduced tickets, faster time-to-productivity, and a new starter who feels supported rather than abandoned.
If your current onboarding process has gaps, the practical next step is to document what you have, identify the missing steps, and build the checklist that brings consistency to every new hire. Start with the pre-arrival phase because that is where most problems originate. Get that right and day one becomes straightforward.
If you need help reviewing your current onboarding process or building a checklist from scratch, prepare a note covering your current setup steps, where new starters typically get stuck, and the systems you currently use for account management and device configuration. That gives a clear starting point for identifying what needs to change.