Template
IT onboarding checklist template
An IT onboarding checklist for Google Workspace runs across 3 windows: 5 working days before the start date, day one, and the end of week one. Splitting it that way is what prevents a new starter spending their first morning waiting for a group membership to propagate.
Last checked · template reviewed against the current admin console · See what changed
| Windows | 3: pre-start, day one, end of week one |
|---|---|
| IT steps | 16 across the three windows |
| Propagation allowance | Up to 24 hours for role and sharing changes |
| Access model | Group membership, not per-file sharing |
| Security baseline | 2-step verification enrolled before first data access |
| Format | Plain text, adopt or adapt freely |
Copy the template
Free to use and adapt, including commercially. Every bracketed placeholder is meant to be replaced before the document is adopted.
IT onboarding checklist — plain text
IT ONBOARDING CHECKLIST
New starter: [NAME] Role: [ROLE] Start date: [DATE]
Manager: [NAME] Buddy: [NAME] Completed by: [NAME]
WINDOW 1 - FIVE WORKING DAYS BEFORE START
[ ] Confirm start date, role and manager with HR.
[ ] Create the account in the correct organisational unit:
[OU PATH]. The OU decides which policies apply.
[ ] Set a temporary password; require change at first sign-in.
[ ] Add to the groups their role requires: [GROUP LIST].
Access flows from groups, not from individual file shares.
[ ] Add to the relevant shared drives via group membership.
[ ] Assign the licence tier: [EDITION].
[ ] Order and enrol the device; apply [ENDPOINT POLICY].
[ ] Create accounts in non-Google systems: [SYSTEM LIST].
[ ] Allow 24 hours before the start date for role and sharing
changes to propagate across all services.
WINDOW 2 - DAY ONE
[ ] Hand over device and temporary credentials in person or by an
agreed out-of-band channel. Never both by email.
[ ] Walk through first sign-in and enrol 2-step verification before
any company data is opened.
[ ] Issue and record backup codes or a security key.
[ ] Confirm mail delivery, calendar visibility and shared drive access
together while you are still with them.
[ ] Add to the internal directory and org chart.
[ ] Point at [ACCEPTABLE USE POLICY]; collect the acknowledgement.
[ ] Explain how to report a suspicious message and to whom.
WINDOW 3 - END OF WEEK ONE
[ ] Ask what they still cannot access; fix by adjusting group
membership rather than by sharing individual files.
[ ] Confirm the device is reporting into [ENDPOINT MANAGEMENT].
[ ] Remove the temporary password requirement flag.
[ ] Confirm no admin role was granted that the role does not need.
[ ] Record completion: [NAME], [DATE].
NOTES
Do not grant admin roles during onboarding. If the role requires one,
raise it as a separate, approved change after week one.Three windows, because propagation is not instant
The common failure in onboarding is doing everything on the morning somebody starts. Role assignments, sharing policy changes and group memberships can take up to twenty-four hours to apply across all Workspace services, so an account built at nine o'clock on day one produces a new starter who cannot open the drive their manager just linked them to.
Building the account five working days ahead removes that entirely and costs nothing, because the account sits unused until the temporary password is handed over. It also creates room for the parts that genuinely need lead time, notably device ordering and enrolment.
Organisational unit and group membership do the work
Two decisions determine most of the new starter's experience. The organisational unit the account is created in decides which policies apply to them, from sharing defaults to which applications they can install. Putting an account in the wrong unit produces symptoms that look random for weeks.
Group membership decides what they can reach. Granting access through groups rather than by sharing individual files means a single membership change opens every shared drive, calendar and mailing list the role needs, and a single membership removal closes them again on the day the person leaves.
- Create in the correct organisational unit; policy inheritance follows it
- Grant access through groups, never file by file
- Allow a full day for role and sharing changes to propagate
- Enrol 2-step verification before the first data access, not later
- Hand over device and credentials through two different channels
- Grant no admin role during onboarding
Day one security decisions that are hard to revisit
Enrolling two-step verification during the first sign-in, while somebody is sitting with the new starter, converts a task that otherwise generates months of reminder emails into a two-minute exercise. Backup codes issued and recorded at the same moment prevent the account lockout that otherwise arrives with the first replacement phone.
Resist granting admin roles as a convenience during setup. Roles granted in the first week are rarely reviewed, and admin role sprawl traced back to onboarding shortcuts is one of the most common findings in tenant audits.
What we see that others don't say
Group membership rather than individual file sharing is what determines whether a new starter is productive on day one, because access granted through a group applies immediately across every shared drive and calendar the group already holds, while file-by-file sharing produces weeks of small access requests.
What this doesn't cover
- This covers the Google Workspace and device layer only; role-specific application access needs its own list.
- Propagation timings are Google's published guidance and vary with tenant size.
- Credential handover practices must fit your own security policy; the template assumes an out-of-band channel exists.
- Console paths were verified on the date shown and move between Google releases.
Want this done for you?
Three fields. We come back with whether this is a 20-minute fix or a project, and what it costs.
Prefer to talk? Call +44 20 7183 3436 (Mon–Fri 08:00–18:00 GMT), or message WhatsApp +44 7403 423563.
Questions we get asked
- What should an IT onboarding checklist include?
- Account creation in the correct organisational unit, group-based access, licence assignment, device enrolment, two-step verification at first sign-in, policy acknowledgement, and an end-of-week access review.
- How far in advance should a new starter account be created?
- Five working days. Role and sharing changes can take up to 24 hours to propagate across Workspace services, so an account built on the morning of day one reliably produces access failures.
- Should new starters be given admin access?
- No. Admin roles granted during onboarding are rarely reviewed afterwards and are a common source of the role sprawl found in tenant audits. Raise them as a separate approved change.
How this page is verified
Reviewed by Workspace Migration Services migrations desk, Google Workspace migration engineers. Last checked .
- Propagation guidance of up to 24 hours for role and sharing changes is Google's published value as of 2026-08-07.
- Checklist ordering reflects Workspace Migration Services onboarding runs across managed tenants to 2026-08-07.
Sources you can check
Cite this page
Free to reuse with attribution. Copy whichever form your publication needs.
Plain citation
Workspace Migration Services, "IT onboarding checklist template", https://workspacemigration.services/templates/it-onboarding-checklist-template (last checked 2026-08-07).HTML with source link
<p>Granting a new Google Workspace starter access through group membership applies across every shared drive the group holds at once, whereas file-by-file sharing produces weeks of individual access requests. Source: <a href="https://workspacemigration.services/templates/it-onboarding-checklist-template">IT onboarding checklist template</a> — Workspace Migration Services.</p>Embed this table
<table>
<caption>IT onboarding checklist template — Workspace Migration Services, 2026-08-07</caption>
<tr><th>Windows</th><td>3: pre-start, day one, end of week one</td></tr>
<tr><th>IT steps</th><td>16 across the three windows</td></tr>
<tr><th>Propagation allowance</th><td>Up to 24 hours for role and sharing changes</td></tr>
<tr><th>Access model</th><td>Group membership, not per-file sharing</td></tr>
<tr><th>Security baseline</th><td>2-step verification enrolled before first data access</td></tr>
<tr><th>Format</th><td>Plain text, adopt or adapt freely</td></tr>
</table>
<p><a href="https://workspacemigration.services/templates/it-onboarding-checklist-template">IT onboarding checklist template</a> — data maintained by Workspace Migration Services.</p>Related pages
Want starters ready before their first morning?
A managed retainer builds accounts against your own group and organisational unit structure ahead of each start date, so the new starter signs in once and everything is already there.