Pre-Arrival Setup: Where IT Onboarding Problems Begin
Most IT onboarding failures do not happen on day one. They happen in the days before the new starter arrives, when hardware requests are raised too late, accounts are not created, and licences go unassigned. The pre-arrival phase is the foundation of everything that follows, and skipping it creates a cascade of problems that IT teams spend the first week firefighting.
A realistic IT onboarding process treats the period before a new employee starts as the most critical phase. This means hardware procurement beginning the moment an offer is accepted, accounts provisioned before the start date, and every step documented with a named owner and a deadline. Without that discipline, day one becomes a recovery operation instead of a smooth handover.
Hardware Procurement Timelines
MacBooks, docking stations, monitors, and peripherals regularly have lead times of two weeks or more. If the new starter begins 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 rather than hoping logistics work out.
The pre-arrival checklist should cover 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 appropriate network segment or VLAN, provisioning accounts in the identity provider, assigning role-appropriate application licences, and pre-configuring VPN access for remote or hybrid workers.
The Three Core 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. 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.
Day-One Configuration and Handover
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 follow as the second step.
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 Follow-Through
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. When a device ships with everything pre-configured, the new starter can focus on their actual work rather than troubleshooting setup problems on day one. This requires applying a consistent device build standard before handover.
Operating System Setup Before Handover
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.
VPN Configuration for Remote Workers
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.
Without pre-tested VPN access, a remote new starter on day one is effectively blocked from accessing the systems they need. If VPN troubleshooting requires an in-person visit on day one, the remote onboarding process has already failed before it started. organisations with distributed teams often find that investing in solid remote onboarding documentation and testing procedures pays back in reduced support tickets throughout the year.
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.
Reducing Manual Overhead with Automation
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.
For smaller IT environments without full identity management infrastructure, a structured checklist still works. The key is having a documented sequence that covers every account type, in the correct order, with a check that each one was completed before the new starter starts.
Role-Based Access Control
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. When something goes wrong with an account that had excessive permissions, the investigation is more complicated and the potential damage is larger.
Managing Contractor and Agency Access
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.
The moment a contractor's engagement ends, their access should be revoked. Leaving credentials active after a contract ends is a common security oversight that creates unnecessary risk.
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. This should cover practical IT security awareness rather than abstract policy documents that nobody reads. For teams looking to build a stronger security culture from day one, formal IT security awareness training content can complement the initial briefing over the following weeks.
Communicating Password Standards
Communicate the password policy before the new starter sets their first password. Cover minimum length and complexity requirements, where to store passwords (an 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.
Explain that forcing frequent password changes is now considered counterproductive by many security frameworks. If passwords are strong and unique, changing them every ninety days without reason often leads to weaker passwords or simple variations that are easier to guess.
Phishing and Social Engineering Awareness
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. Unusual requests for money or access should be verified by phone using a known number, not one in the email. Running a simulated phishing exercise in the first month is one of the most effective ways to reinforce this training safely.
Data Handling Expectations
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.
Make these concrete for day-to-day work rather than simply referring to a policy document. Give examples of what is acceptable and what is not. New starters who understand the reasoning behind the rules are more likely to follow them consistently.
Common IT Onboarding Mistakes to Avoid
Most IT onboarding problems fall into a small number of recurring categories. Identifying them is the first step toward fixing them.
- Treating onboarding as an IT task rather than an organisational process: When IT is the only team responsible, 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.
- Assuming the new starter knows 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.
- 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.
- No documentation for common IT tasks: If the answer to how to connect to the VPN 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.
- 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.
Remote and Hybrid IT Onboarding
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
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.
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.
Remote Enrolment Tools
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.
Organisations building out their remote work infrastructure may find it useful to review how team IT security is structured more broadly, as remote onboarding is most effective when it sits within a coherent remote work IT setup strategy.
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
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 in the First Month
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
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.
Related practical reading
These related guides can help you connect this topic with the wider website, server, security, and support decisions around it.
- SSH Config Tips That Save Hours of Time - useful background for related technology decisions
- How to Build a PHP Webhook Receiver: Complete Implementation Guide - useful background for related technology decisions
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. Others 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. You can get in touch to discuss the specific gaps in your setup and what a practical improvement plan would look like.