Windows, Mac or both from one template
Conditional logic reads the platform and image answers on the first task, so a Mac-only shop never sees Autopilot choices and the image refresh appears only while you still keep an image.
Laptop Provisioning & Imaging Checklist Template
Most broken laptop builds worked the last time someone tested them. Then a new model arrived with a different network driver, Windows moved on a version, and the spares on the shelf kept last spring’s apps.
This free laptop provisioning checklist is for IT teams and MSPs who own the standard build for Windows laptops, Macs or both. It defines what every managed laptop gets, from the OS version and app set to encryption, local admin rights, the device name and the asset tag. It then proves the build on each approved model, pilots it and releases it as a numbered version under a named approver. Finally it keeps spares stock-ready and books the next re-validation. It stops before any device is handed to a named person.
Golden Image or Modern Provisioning: Someone Still Owns the Build
Provisioning used to mean imaging: build one perfect machine, capture it and copy it onto every new laptop. Modern provisioning starts from the operating system the manufacturer shipped and turns it into a business-ready device over the internet. On Windows that is Windows Autopilot with Intune, which Microsoft describes as transforming the existing installation so that custom images and drivers don’t need maintaining for every model. On a Mac it is Automated Device Enrollment with an MDM such as Intune or Jamf Pro. Since macOS 11 the system volume has been cryptographically signed by Apple, so a Mac build is configuration layered on top rather than a disk copied underneath.
Neither approach decides what the build should contain. A missing VPN client is just as missing whether it came from an image or a policy. That decision, and proving it works, is what this checklist runs.
Golden image
Capture once, copy everywhere
Strength: builds offline, and every disk starts identical.
Cost: an image to patch, re-capture and test, often per model, and stale from the day it is captured.
Still fits: training rooms, isolated networks and specialist hardware.
Modern provisioning
Configure the factory install from the cloud
Strength: no image to maintain, and it works for a laptop shipped straight to a home.
Cost: needs a good connection at setup, and every required app adds minutes and a failure point.
Fits: most office, hybrid and remote fleets.
This page covers the device, never the person. How a device gets under management in the first place is in the MDM Enrollment Checklist. Creating accounts and handing a built laptop to a new starter is in the new hire IT setup guide. Moving the fleet you already have to a new OS version belongs to the Operating System Upgrade Rollout Checklist.
What the Laptop Provisioning Checklist Covers
Seven phases take the standard build from scope to stock-ready spares. The platforms chosen in Phase 1 show only the Windows or Mac tasks you need, an image task appears only if you still maintain one, and a named approver releases each version. Run it twice a year as a scheduled review, and again whenever a new hardware model or OS version arrives.
Phase 1
Phase 1: Scope, Roles & Current Standard
The platform and image answers on task 1 decide which Phase 2 tasks appear.
- Open the run and record platforms, the reason for it and the approver — Windows, Mac or both; new standard, new model, new OS version or scheduled review; and whether a custom Windows image is still in use
- List the role profiles the standard must cover — standard office, finance, developer, shared device; each extra profile is another build to test
- Pull the current standard and its change log — the version number and what changed since the last run
- Confirm the approved hardware models and their support end dates — a model past its end date should leave the list, not be re-tested
- Collect build problems raised since the last run — service desk tickets tagged as build issues are the first test cases
Phase 2
Phase 2: Build Method & OS Version
Tasks 1 and 2 appear for Windows, task 3 for Mac, and task 6 only when a custom Windows image is still in use.
- Confirm the Windows build path: Autopilot on the factory install or an image — an image is a second product to maintain, so keep one only for a stated reason
- Choose classic Autopilot or device preparation for each role profile — device preparation needs Windows 11 and Entra join; classic adds pre-provisioning and self-deploying mode
- Set the Mac build through Automated Device Enrollment — which Setup Assistant screens to skip, how the user account is created and how the managed admin is handled
- Pin the target OS version for each platform — the version you validate is the version you ship
- Set the minimum OS version a device must reach before it counts as built — factory stock arrives older or newer than the pinned version
- Refresh the custom image with current patches and drivers — and record the capture date, because an old image installs months of updates on first boot
Phase 3
Phase 3: Apps, Profiles & Identity
- Define the core app set every laptop gets — browser, office suite, security agent, VPN or zero-trust client and the remote support tool
- Define the extra apps for each role profile — assigned by group, never installed by hand
- Mark which apps must finish during setup and which can follow — keep the blocking list short; each one adds time and a way for setup to fail
- Set configuration profiles for Wi-Fi, certificates, VPN and browser — certificate-based Wi-Fi means nobody types a shared password
- Apply the naming convention through a name template — a prefix plus serial number keeps names unique and traceable to the register
- Record serial, asset tag, order number and warranty end in the asset register — before the device leaves stock, not after the first fault
Phase 4
Phase 4: Security Baseline
- Turn on disk encryption with recovery keys escrowed — BitLocker keys in Microsoft Entra ID, the FileVault personal recovery key in the MDM
- Remove standing local admin rights and manage the local admin password — Windows LAPS rotates it and backs it up; Macs get a managed admin account
- Turn on the firewall and stop users switching it off — set by profile on both platforms, not left at the factory default
- Install the endpoint detection and response agent — and confirm the device appears healthy in its console
- Apply the security baseline and resolve conflicts — a baseline that requires a TPM startup PIN stops BitLocker enabling silently
- Set screen lock, sign-in method and update rings — an idle lock of 5 to 15 minutes is a common default to tune
Phase 5
Phase 5: Reference Hardware Validation
- Build one device of every approved model from out of the box — on a home-grade connection, because that is what a remote starter will have
- Time each build from power-on to desktop and log every failure — a model that takes twice as long as the rest has a driver or app problem
- Check firmware, drivers and security settings after the build — Secure Boot on, TPM present, firmware current
- Verify encryption, admin rights, security agent and compliance on each device — screenshot the compliant status as evidence
- Sign in as a test user and open every role app — a standard account, never an admin one, or permission problems stay hidden
- Reset one device and rebuild it without touching it — it should come back to the same state on its own
Phase 6
Phase 6: Pilot, Approval & Versioning
The approver named in Phase 1 records a decision on task 4, and the checklist halts until they do.
- Release the candidate build to a pilot group — IT plus a few willing staff from each role profile, for two to four weeks of real work
- Fix or formally accept every pilot issue — each with an owner and a note in the change log
- Write the build standard with a version number and change log — what every device gets, by role and model, and what changed
- Approve the build standard for release — the approver named in Phase 1 records Approved or Not approved; nothing is built to it until they do
- Retire the previous version and brief the service desk — what changed, what users will notice and how to spot an old build
Phase 7
Phase 7: Stock-Ready Spares & Re-validation
- Confirm every spare is registered and pointed at the right profile — check by serial in Autopilot or Apple Business before it goes on the shelf
- Update spares that were built or unboxed more than a month ago — patches, apps and the standard all move on while a laptop sits in a cupboard
- Label each spare with model, build version and date checked — so the next person knows whether it needs touching
- Check stock against the reorder point for each model — weekly demand times supplier lead time, plus a buffer, is a sensible starting point
- Book the next re-validation and note what would trigger one early — a new model, a new OS version or a change to the security baseline
What the Build Standard Records, and How Each Line Is Proved
Every line of a build standard should be checkable on a real device. This is a starting layout for the document Phase 6 versions.
| Component | Windows | Mac | Proved in Phase 5 by |
|---|---|---|---|
| OS version | Pinned with an Intune feature update policy, which takes effect at the first update scan after Autopilot setup | Target and minimum macOS set through MDM software update settings | Version check on each reference device |
| Disk encryption | Silent BitLocker, which needs a TPM, UEFI, Secure Boot and the Windows Recovery Environment | FileVault, on during Setup Assistant by default from macOS 26.4, with the key escrowed | Recovery key visible in the console |
| Local admin | Users as standard accounts; Windows LAPS manages the local admin password | Managed admin account; users as standard where the role allows | Test user cannot elevate |
| Firewall and security agent | Firewall on and locked; agent installed in setup | Same | Agent healthy in its console |
| Apps | Core set plus role set; short blocking list | Same, delivered at enrolment | Test user opens each one |
| Name and asset record | Name template; register entry | Same | Name matches the register |
Two details catch teams out. Microsoft notes that Entra ID administrators are always local administrators, whatever the Autopilot profile says, so test admin removal with an ordinary account. And because feature update policies don’t apply during Autopilot setup, a laptop can reach the desktop on whatever version the factory installed and only move to your pinned version afterwards. That is why Phase 2 sets a minimum version as well as a target.
Version the standard like software: a number and date such as 2026.2, a change log, and one approved version live at a time. Windows feature updates typically ship once a year and Apple releases a major macOS each year, so a twice-yearly review catches each one with time to spare. Treat that cadence as a default to tune, and bring the run forward for a new model or a security baseline change.
Why Run Your Build Standard in CheckFlow?
Every version has an approver
Release goes to the approver picked in Phase 1, and the checklist halts until they decide. Template versioning keeps the checklist in step with each version of the standard, and reference-device screenshots attach to their tasks as evidence.
Approved models as reference data
Keep hardware models, support end dates and reorder points in a data set that fills the validation table on each run. A recurring schedule opens the review twice a year, with due dates counted from the start.
The build standard is what the per-person process draws on. CheckFlow’s IT onboarding software runs each new starter’s setup, and the new hire IT setup checklist picks up where this page stops: a stock-ready laptop meeting a named person. Getting devices under management first is the job of the MDM Enrollment Checklist.
New apps added to the standard roll out to existing users through the New Software Implementation Checklist. The IT Asset Management Checklist keeps the register Phase 3 writes to, and models dropped from the approved list leave through the IT Asset Disposal (ITAD) Checklist.
Frequently Asked Questions
What is laptop provisioning?
It is preparing a laptop to your organisation’s standard so it is secure and ready to use: the right OS version, apps, settings, encryption and security agent, a standard name and a record in the asset register. It can be done by copying a disk image or, more often now, by configuring the factory install through Windows Autopilot or Apple Automated Device Enrollment and an MDM.
Do you still need a disk image with Windows Autopilot?
Usually not. Autopilot uses the Windows installation the manufacturer shipped and configures it through Intune, so there is no image to patch or re-capture per model. Images still make sense for offline builds, training rooms and some specialist hardware. If you keep one, give it an owner, a capture date and a refresh step in every review.
What should a standard laptop build include?
At minimum: a pinned OS version, disk encryption with escrowed recovery keys, users without standing admin rights, a managed local admin password, a firewall, an endpoint detection and response agent, the core app set, Wi-Fi and VPN profiles, a name template and an asset register entry. Role profiles then add apps by group rather than creating whole new builds.
How often should the standard build be reviewed?
Twice a year is a sensible default, timed to land after each major Windows and macOS release. Run it early whenever a new hardware model joins the approved list, the security baseline changes or the service desk sees a pattern of build faults.
How do you keep spare laptops ready to deploy?
Keep them sealed where you can and registered to the right profile, so they build themselves when switched on. Anything already built or unboxed should be powered on and updated every month or so, and labelled with the build version and date checked. Hold enough of each model to cover weekly demand across the supplier’s lead time.
Is CheckFlow free for this template?
14-day free trial, no card required. The Business plan is $10 per user per month after the trial. Full details at checkflow.io/pricing.