Employee IT OnboardingChecklist
A phase-by-phase IT onboarding checklist covering account creation, least-privilege access, device enrollment, training, and the evidence an assessor will ask to see. Built by Petronella Technology Group for defense contractors, medical practices, and regulated firms in Raleigh and nationwide.
What Is an IT Onboarding Checklist?
An IT onboarding checklist is a written, repeatable sequence of tasks that gives a new hire exactly the accounts, devices, applications, and training they need to do their job, and nothing beyond that. It covers identity creation, multi-factor authentication, endpoint enrollment, email and file access, line-of-business applications, security awareness training, and policy acknowledgments. It also records evidence that each step happened, who approved it, and when, so the organization can demonstrate the control later.
Most organizations treat onboarding as a productivity problem: get the person working by Monday. Petronella Technology Group treats it as a security and compliance event, because every permission granted on day one is a permission someone will later have to find, justify, and remove. Access that was never granted does not need to be revoked. That is why this page is the companion to our employee offboarding checklist: the quality of your onboarding decides how hard your offboarding will be.
Key Takeaways
- An employee IT onboarding checklist is the documented sequence that provisions identity, devices, applications, and training for a new hire, with a record of who approved each grant and why.
- Least privilege starts on day one. Role-based access templates, approved in writing by the hiring manager, prevent the permission sprawl that later shows up as findings in a user access review.
- Multi-factor authentication, endpoint enrollment, and security awareness training should be complete before the new hire touches regulated data such as controlled unclassified information or protected health information.
- Onboarding maps to named requirements in CMMC 2.0 and NIST SP 800-171, the HIPAA Security Rule, SOC 2, and PCI DSS. The artifact that proves it happened is what an assessor evaluates.
- Petronella Technology Group runs onboarding for clients as an evidenced process, with ComplianceArmor® tracking policy acknowledgments and training records, and the Managed XDR Suite enrolling every endpoint before it is handed over.
Not sure what your new hires actually receive on day one?
Petronella Technology Group can review your current onboarding workflow, compare it against your framework, and show you exactly where the access, enrollment, and evidence gaps are. Serving Raleigh, Durham, Cary, and the Triangle since 2002, plus clients nationwide.
Schedule a Free ConsultationThe Employee IT Onboarding Checklist
The checklist below is organized by phase. Each task names an owner and the evidence that proves it was completed, because those two columns are what separate a working process from a demonstrable control. Adapt the owners to your organization, but do not drop the evidence column.
Phase 1: Pre-Start Planning and Access Request
Everything in this phase happens before the start date, triggered by the signed offer letter rather than by first-day urgency.
| Task | Owner | Evidence |
|---|---|---|
| Open an onboarding ticket from the HR system event, with start date, role, department, manager, work location, and employment type (employee, contractor, temporary) | HR | Ticket with HR record reference and timestamp |
| Select the role-based access template that matches the position, or document why a custom set is required | Hiring manager | Named template or written justification attached to the ticket |
| Approve the access request in writing, including any elevated or privileged rights and any access to CUI, PHI, or cardholder data | Hiring manager and data owner | Approval record with approver name and date |
| Confirm background screening is complete where the role requires it, before any regulated data access is granted | HR | Screening completion recorded in the HR file |
| Reserve a device from the IT asset inventory, or order one, and assign it to the new hire's asset record | IT | Asset record updated with assignee and status |
| Confirm licence availability for email, the productivity suite, security tooling, and line-of-business applications | IT | Licence allocation noted on the ticket |
| Set an account expiration date for contractors and temporary staff at request time | IT | Expiration date visible on the ticket and in the directory |
Phase 2: Identity and Account Creation
The directory account is the foundation every other grant rests on. Create it from the approved template, not from a coworker's profile, and enforce multi-factor authentication before the first login rather than after.
| Task | Owner | Evidence |
|---|---|---|
| Create the primary directory account using the standard naming convention, tied to one real person and never shared | IT | Directory audit log entry |
| Apply group memberships from the approved role template only; do not clone an existing user | IT | Group list on the ticket matches the template |
| Issue a one-time initial password through a secure channel, with a forced change at first login | IT | Password policy enforcement confirmed in the directory |
| Register multi-factor authentication with an authenticator app or hardware key before the account is handed over; avoid SMS as the primary method | IT and new hire | MFA registration record with method and date |
| Create a separate privileged account for anyone who needs administrative rights, and never grant admin to the daily-use identity | IT | Privileged account approval and separate credential record |
| Assign single sign-on application access from the template; confirm no application still relies on a local password | IT | SSO assignment list |
Phase 3: Device Provisioning and Endpoint Enrollment
No device should reach a new hire until it is enrolled, encrypted, patched, and reporting to your monitoring platform. The order matters: enrollment first, then handover. For clients on the Managed XDR Suite, the endpoint is reporting to the 24/7 SOC before the box is sealed.
| Task | Owner | Evidence |
|---|---|---|
| Image or auto-enroll the device from the standard build, with local administrator rights removed from the end user | IT | Build version and enrollment timestamp |
| Enable full-disk encryption and escrow the recovery key before shipping | IT | Encryption status and key escrow confirmation |
| Install and verify the endpoint detection and response agent, and confirm the device appears in the console | IT or SOC | Agent check-in record in the Managed XDR console |
| Enroll the device in remote monitoring and management and apply the correct patch policy | IT | RMM enrollment and patch management compliance status |
| Apply the configuration baseline: screen lock, host firewall, USB and removable media policy, browser policy, and backup agent | IT | Baseline compliance report |
| Record the serial number, assignee, and handover date in IT asset management | IT | Asset record with signed receipt |
| For bring-your-own-device users, enroll the personal phone or laptop in mobile device management with a work profile, and confirm the user signed the BYOD agreement before company email is configured | IT and new hire | MDM enrollment record and signed BYOD agreement |
Phase 4: Email, Collaboration, and File Access
This is where most over-provisioning happens, because file shares and collaboration spaces tend to be granted by convenience. Tie every grant to the role template and to the owner of the data.
| Task | Owner | Evidence |
|---|---|---|
| Provision the mailbox with the correct licence, retention policy, and email security protections applied | IT | Mailbox creation record with policy assignment |
| Add the user to the distribution lists and shared mailboxes named in the role template, and nothing else | IT | Membership list reconciled to the template |
| Grant collaboration workspace and team membership per the template, with the workspace owner approving any additions | IT and workspace owner | Owner approval on the ticket |
| Grant file share and cloud drive permissions through role groups rather than direct user assignment | IT | Group-based permission record |
| Restrict access to folders containing CUI, PHI, or cardholder data to the users the data owner approved, following your data classification policy | Data owner | Data owner approval for each restricted location |
Phase 5: SaaS and Line-of-Business Applications
Application access should flow through single sign-on wherever the platform supports it. Where it does not, the local account becomes an item on the offboarding checklist, so record it now while it is fresh.
| Task | Owner | Evidence |
|---|---|---|
| Provision line-of-business applications (EHR, ERP, CRM, accounting, engineering tools) from the role template with the lowest role that supports the job | Application owner | Application role assignment record |
| Route every application through single sign-on where supported; document each exception with its local account name | IT | Application inventory entry per user |
| Confirm no administrator, billing, or owner role is granted unless the access request explicitly approved it | Application owner | Approval reference for any elevated role |
| Provision approved AI tools only, and have the user acknowledge the AI acceptable use policy before access is enabled | IT and user | Signed AI acceptable use acknowledgment |
| Grant code repository, CI/CD, and infrastructure console access only where the role requires it, with SSH keys and tokens recorded | Engineering lead | Repository role and key inventory entry |
| Add the user to the client or vendor portals the role requires, and note it in your IT documentation | Account manager | Portal access list updated |
Phase 6: Security Awareness Training and Policy Acknowledgments
Training and acknowledgments belong before regulated data access, not after. Frameworks phrase the requirement as "before authorizing access" for a reason: a signed acceptable use policy is what makes later enforcement possible.
| Task | Owner | Evidence |
|---|---|---|
| Deliver initial security awareness training covering phishing, password handling, data handling, and incident reporting, before regulated data access is enabled | HR and IT | Training completion record with date and score |
| Capture signed acknowledgment of the acceptable use policy, password policy, remote work policy, and data classification policy | HR | Signed acknowledgments stored with the onboarding record |
| Capture confidentiality and, where applicable, CUI-specific or HIPAA-specific handling acknowledgments | HR and compliance | Signed role-specific acknowledgments |
| Enroll the user in the ongoing simulated phishing program so their first campaign lands within the first month | IT | Phishing platform enrollment date |
| Store training and acknowledgment records where they can be retrieved by workforce member for an assessment | Compliance | Record filed in ComplianceArmor® or equivalent |
Phase 7: First-Week Verification and 30-Day Access Review
The first week confirms the person can work. The 30-day review confirms the organization granted only what was needed, and it is the step almost every internal checklist omits.
| Task | Owner | Evidence |
|---|---|---|
| Confirm first login, the MFA challenge, and the device compliance check all succeeded on day one | IT help desk | Sign-in log and compliance report |
| Walk through each application the role requires and confirm the user can reach it, logging any missing access as a new approved request rather than an ad hoc grant | Manager and help desk | Day-one verification checklist |
| Reconcile granted permissions against the approved template at day seven, and remove anything added outside the request | IT | Reconciliation note on the ticket |
| At day 30, have the manager attest that the user's access is still appropriate and that no further elevation is needed | Manager | Signed 30-day attestation |
| Confirm training, acknowledgments, and the first phishing simulation are complete | Compliance | Completion summary attached to the record |
| Add the user to the quarterly user access review population | Compliance | Access review roster updated |
Phase 8: Evidence and Compliance Record
Everything above produces artifacts. This phase assembles them into a single per-person record so that an assessor can pull one file and see the whole story.
| Task | Owner | Evidence |
|---|---|---|
| Compile the approved access request, template name, account creation log, MFA registration, and group memberships into the onboarding record | IT | Complete onboarding record |
| Attach device enrollment, encryption status, EDR check-in, and the asset handover receipt | IT | Device section of the record |
| Attach training completion and every signed policy acknowledgment | HR and compliance | Training and policy section of the record |
| Map the record to the specific controls in your framework (for example NIST SP 800-171 AC, IA, AT, and PS practices) | Compliance | Control mapping on the record |
| File the record in a system an assessor can query, not in a technician's ticket queue | Compliance | Record stored in ComplianceArmor® or equivalent |
| Review whether the onboarding exposed a template or process weakness and update the IT runbook accordingly | IT lead | Runbook change log entry |
Want this checklist adapted to your systems?
Petronella Technology Group writes the role templates, builds the evidence record, and runs the first onboardings with your team. Ask about managed IT services, or co-managed IT services if you already have internal staff.
Get a Free AssessmentHow Onboarding Maps to Compliance Frameworks
Onboarding is a named requirement in every framework our clients operate under, and the requirement is phrased in terms of authorization, training, and evidence rather than any particular tool.
| Framework | Requirement | What Assessors Look For |
|---|---|---|
| CMMC 2.0 and NIST SP 800-171: Access Control (AC) | Limit system access to authorized users and to the transactions and functions those users are permitted to execute; apply least privilege | Approved access requests tied to role templates, and evidence that granted permissions match the approval |
| NIST SP 800-171: Identification and Authentication (IA) | Identify users and authenticate them before allowing access, including multi-factor authentication for network and privileged access | Account creation records, MFA registration per user, separate privileged accounts |
| NIST SP 800-171: Awareness and Training (AT) | Make users aware of security risks and train them on their responsibilities before access and periodically afterward | Training completion records per workforce member with dates |
| NIST SP 800-171: Personnel Security (PS) | Screen individuals prior to authorizing access to systems containing CUI | Screening completion recorded before the access grant date |
| HIPAA Security Rule: Workforce Security and Information Access Management | Authorize and supervise workforce access to ePHI, and implement procedures for granting access | Written authorization procedures and per-person evidence. See HIPAA workforce security |
| HIPAA Security Rule: Security Awareness and Training | Implement a security awareness and training program for all workforce members | Training records and periodic reminders, including phishing awareness |
| SOC 2: CC6 Logical and Physical Access | Register and authorize new users, provision credentials, and restrict access based on role prior to granting access | Population testing: a sample of new hires checked for approval, provisioning date, and role alignment. See the SOC 2 compliance checklist |
| PCI DSS Requirements 7 and 8 | Restrict access to cardholder data by business need to know; assign a unique ID to every user and enforce MFA | Documented approval of access rights, unique accounts, MFA enrollment for the cardholder data environment |
The recurring theme is that the artifact is the deliverable. A team that provisions access correctly but records nothing receives the same finding as a team that never had a process. Craig Petronella, CMMC Registered Practitioner, NC Licensed Digital Forensics Examiner (License 604180-DFE), and author of the IT Buyers Guide and "How Hackers Can Crush Your Business", covers this distinction between a control that exists and a control that can be demonstrated across the 110 NIST SP 800-171 practices.
"We have been working with Craig and his team for more than 16 years for all of our company's computer, network and IT Support needs. Our confidence level has allowed us to recommend Petronella Technology Group to long time business partners."
Vanessa Jenkins, Construction CompanyPetronella Technology Group is rated 4.7 across 92 verified TrustIndex reviews and 5.0 across 15 Google reviews.
Common IT Onboarding Mistakes
These are drawn from what we find during access reviews at new client engagements, ordered roughly by how often they appear.
| Mistake | Why It Happens | What It Costs Later |
|---|---|---|
| Cloning an existing user's permissions | Fastest path when no role template exists | Inherited over-privilege that surfaces as access review findings and widens the blast radius of a compromised account |
| MFA registered "later" | Account is handed over before the person has a phone or token in hand | A window of password-only access, and an account that may never get MFA at all |
| Device shipped before enrollment | Remote hire, vendor drop-ship, time pressure | Unmanaged endpoint with company data and no EDR coverage |
| Personal phone reading company email without MDM | Mail profile set up by the user on day one | No way to selectively wipe at departure; data on a device you do not control |
| Admin rights on the daily-use account | Convenient for IT staff and power users | Every phishing click runs with administrative privilege |
| No 30-day review | Onboarding is considered finished at first login | Temporary access granted during the first week becomes permanent |
DIY Onboarding vs a Managed, Evidenced Process
The difference between the two columns is rarely technical skill. It is whether the sequence exists in writing, whether someone owns closeout, and whether evidence is produced as a by-product of the work rather than reconstructed before an audit.
| Dimension | DIY Onboarding | Managed, Evidenced Onboarding by Petronella Technology Group |
|---|---|---|
| Trigger | Manager emails IT the week before, or the morning of | HR system event opens a ticket with a defined start-date target |
| Access scope | Copied from a coworker | Role-based template approved by the hiring manager and data owner |
| Identity and MFA | Password emailed; MFA when the user gets to it | MFA registered before handover; separate privileged accounts |
| Devices | Shipped from the vendor, agent installed later | Enrolled in Managed XDR and RMM, encrypted, patched, and reporting to the 24/7 SOC before shipping |
| BYOD | User adds email on their phone | MDM work profile and signed BYOD agreement before mail is configured |
| Training and policies | Assigned in a learning platform, chased quarterly | Completed before regulated data access; acknowledgments tracked in ComplianceArmor® |
| Verification | Ends at first successful login | Day-seven reconciliation and 30-day manager attestation |
| Evidence | A ticket that says "new user setup" | Per-person record mapped to AC, IA, AT, PS, HIPAA, SOC 2 CC6, and PCI DSS controls |
| Assessment outcome | Finding, even if access was correct | Demonstrable control |
How Petronella Technology Group Runs Onboarding for Clients
For clients on our security-led managed IT services or co-managed IT services, onboarding is a standard workflow rather than a project. Here is how it runs.
Define role templates
We work with department heads to write the access template for each role, including which CUI, PHI, or cardholder data locations each role may reach. Templates live in your policies and procedures set.
Build the trigger
The HR event opens the ticket in our IT help desk, with manager approval captured before any account exists.
Provision identity and MFA
Accounts are created from the template, MFA is registered before handover, and privileged users receive a separate elevated identity.
Enroll every endpoint
Devices are enrolled in the Managed XDR Suite and remote monitoring before shipping, so the 24/7 SOC sees the endpoint from its first boot. BYOD devices get an MDM work profile and a signed agreement.
Train and acknowledge
Security awareness training with simulated phishing runs before regulated data access. Policy acknowledgments are captured and tracked in ComplianceArmor® against the relevant control.
Verify and file
Day-seven reconciliation and the 30-day attestation close the record, which is filed in ComplianceArmor® where an assessor can retrieve it. The user joins the quarterly access review population.
Onboarding sits alongside the other controls we manage: offboarding at the other end of the lifecycle, quarterly user access reviews in between, and ongoing security awareness training. To see how your workforce responds to a phishing message today, start with our free phishing security test. Petronella Technology Group serves Raleigh and the Triangle, including Durham and Cary, plus clients across North Carolina and nationwide.
Frequently Asked Questions
What should be on an IT onboarding checklist?
An approved access request tied to a role template, directory account creation with multi-factor authentication, a managed and encrypted device enrolled in endpoint detection, email and file access scoped to the role, application access, security awareness training, signed policy acknowledgments, a first-week verification, a 30-day access review, and one evidence record tying it together. The owner and evidence columns matter more than the task list itself.
When should a new hire's accounts be created?
Create accounts in the days before the start date, after the access request is approved and any required screening is complete, but do not hand over credentials until the first day. Register multi-factor authentication during the handover rather than as a follow-up task. An account created early with a known password is an open door; one created the morning of the start date invites mistakes under time pressure.
Should new employees get administrator rights on their computer?
No. The daily-use account should be a standard user on the device and in the directory. Anyone whose role needs administrative rights should receive a separate privileged account with its own multi-factor authentication, used only for administrative tasks. This is a direct expectation of least privilege under NIST SP 800-171 and limits what a phishing click on the daily account can do.
How do we onboard remote employees who never visit the office?
Enroll and configure the device before it ships. The laptop should leave your hands with encryption enabled, the endpoint agent reporting, patches current, and the standard account pre-staged. Run the MFA registration, first login, and orientation checklist over a video call. A device shipped unmanaged with instructions to install the agent later is the most common remote onboarding gap we find.
What is a role-based access template and why does it matter?
A role-based access template is a written list of the groups, applications, shares, and data locations a job function needs, approved in advance by the department head and the relevant data owners. Provisioning from the template instead of copying a coworker is what makes least privilege achievable. It also gives an assessor a reference point: granted access can be compared to the template, and any difference needs an approval record.
Is security awareness training required before a new hire gets access?
The frameworks our clients operate under expect it. NIST SP 800-171 awareness and training practices, the HIPAA Security Rule training standard, SOC 2, and PCI DSS all expect workforce members to be trained on their responsibilities, and assessors look for completion records per person. Complete initial training and policy acknowledgments before the person touches regulated data, then keep it current with ongoing training and simulated phishing.
How does onboarding affect CMMC or HIPAA compliance?
Onboarding is where several controls are first exercised for each person: access authorization, least privilege, identification and authentication with MFA, personnel screening, and awareness training under CMMC 2.0 and NIST SP 800-171; workforce security, information access management, and training under the HIPAA Security Rule. An assessor samples new hires and asks for the approval, provisioning record, MFA registration, and training completion. Without those artifacts the control is scored as not met.
What is the difference between onboarding and a user access review?
Onboarding is event-driven and applies to one person when they join. A user access review is periodic and applies to everyone, confirming that what was granted at onboarding, and everything added since, is still appropriate. Onboarding without access reviews lets first-week exceptions become permanent. Access reviews without disciplined onboarding mean reviewers spend their time removing permissions that should never have been granted.
Talk to a Registered Provider Organization
Petronella Technology Group has been securing regulated businesses from Raleigh since 2002, as a CyberAB Registered Provider Organization (RPO #1449) with a BBB A+ rating since 2003. We can review your onboarding process, write the role templates, and produce the evidence your framework requires.
Schedule a Free Consultation Call 919-348-4912Written by Craig Petronella, CMMC Registered Practitioner and NC Licensed Digital Forensics Examiner (License 604180-DFE), founder of Petronella Technology Group, Inc. in Raleigh, North Carolina. Questions about this checklist can be sent to info@petronellatech.com or 919-348-4912.
Last Updated: October 23, 2026 | Petronella Technology Group, Inc. | 5540 Centerview Dr., Suite 200, Raleigh, NC 27606 | 919-348-4912 | info@petronellatech.com