A missing laptop creates two separate jobs: limiting exposure and getting the employee working again. Buying a replacement addresses only the second. Your first priority is to establish what happened, what the device could access and which protective actions can actually reach it.

This checklist is for business owners and IT coordinators responding to a lost company Windows laptop. It is a preparation and response guide, not evidence that a particular incident has been contained. Platform, enrolment and licence differences affect the available controls.

Illustration: AI-generated concept of a missing laptop and a pending management action, not an authentic management screen or client installation. Technical sources reviewed on 3 October 2026.

1. Report the loss and capture a usable incident record

Give IT the employee's name, device asset number or serial number if available, last known location, approximate time of loss and whether the machine was locked, shut down or in active use. Record whether a phone, security key or written password was lost with it.

List the likely business exposure: locally saved documents, synchronised folders, email, browser sessions, remote-access tools and any privileged accounts used on the device. Mark unknowns explicitly. An uncertain answer about encryption should remain uncertain until IT checks the record.

Assign one incident owner and keep a timestamped action log. If theft is suspected, follow the organisation's reporting process and appropriate local reporting channels. Employees should not attempt a physical recovery based on a device-location estimate.

2. Verify encryption and management status

Microsoft describes BitLocker as protection against data exposure from lost, stolen or improperly decommissioned devices. Its purpose is to protect stored data; it does not make an already unlocked session harmless.

Ask IT for the last recorded encryption status, last management check-in and the device's registered owner. Also check whether the recovery key is safely held in the approved administrative system. Do not paste it into the incident chat or send it to the missing device.

Use the evidence to prioritise the response. A powered-off device with verified encryption has a different exposure profile from an unlocked laptop containing local customer exports. Neither situation justifies assuming that all accounts and data are safe without investigation.

3. Contain account access from a trusted device

IT should review active access and decide whether to block sign-in, revoke sessions, reset credentials or rotate exposed secrets. Coordinate these actions so the employee does not independently make changes that obscure the incident timeline.

Microsoft's emergency access guidance explains that identity controls and application sessions are not identical. Revocation does not mean every application session disappears instantly. Third-party systems may need their own session termination or credential changes.

Consider the systems the person actually used: CRM, accounting, password manager, VPN and administrative portals. Record who owns each containment step and verify the result where possible. Protecting the Microsoft 365 account alone does not automatically resolve access to every service.

4. Choose a device action, then check its status

An authorised administrator should confirm the device identity and ownership before issuing any destructive command. Intune device actions depend on platform support, enrolment, connectivity and administrative permissions. Do not assume a Windows laptop has the same lock or location capabilities as a managed phone.

A remote command is not proof of completion. Microsoft's troubleshooting guidance notes that an offline device can remain in a pending wipe or retire state. Keep account containment and data-exposure assessment running while you wait for evidence.

Read the exact wipe option before approving it. Microsoft documents Windows wipe variants, including one that preserves user data and another with more destructive recovery implications. A data-preserving reset is not a suitable assumption for removing confidential data from a stolen device. Select the action under your incident policy, with the device's circumstances understood.

Preserve the management record and available logs while IT evaluates the response. Deleting an inventory entry to tidy the console is not the same as proving that the missing laptop has been erased.

5. Assess exposure and restore work separately

Build a short evidence summary: information potentially present, encryption evidence, session state, observed sign-ins, actions issued, actions confirmed and remaining unknowns. Escalate possible exposure to the responsible security or privacy lead so they can assess applicable obligations. Do not promise that encryption or a submitted wipe request removes all reporting duties.

Prepare a replacement through the normal managed-device process. Restore approved business data, reinstall required applications and test the employee's essential workflow. Verify synchronisation and backups instead of assuming that every local file was protected. The backup restore-testing checklist explains how to confirm usable recovery.

Prepare before the next loss

  • Keep device ownership and serial-number records current.
  • Verify encryption and recovery-key access during routine device reviews.
  • Minimise unnecessary local exports and persistent privileged sessions.
  • Give employees a clear reporting route they can use without their work laptop.
  • Practise the response with a spare test device and a documented recovery plan.

For a practical readiness review, see ITZ's cybersecurity services and describe your device-management requirements. Include your device count and management platform; keep passwords, recovery keys and sensitive incident records out of the enquiry form.