A lost laptop or phone is rarely just a hardware loss: it can hold cached data, signed-in sessions, saved passwords and, on developer machines, SSH keys and cloud tokens that keep working long after the device is gone. This template gives you a response procedure and checklist for lost or stolen laptops, phones and tablets, from the first call to the service desk through remote lock and wipe, credential and token revocation, the personal data breach decision and replacement. It is written for service desk, endpoint, identity, security and privacy teams, and draws on NIST SP 800-124 Rev. 2, NCSC and ICO guidance and vendor documentation. Adapt the roles, tools and times in square brackets before adoption.
How to use this template
- Replace text in square brackets, such as [Organisation] and [UEM console], with your own terms. "Must" is mandatory; "should" is recommended.
- Load the checklist tables in sections 5 to 10 into your ticketing tool as a task template, so each step is assigned, timed and evidenced.
- Timings run from the moment the loss is reported. Set the bracketed targets to what your teams can meet out of hours.
- Product examples (Microsoft Intune, Microsoft Entra ID, Apple MDM) illustrate each step; use the equivalent action in your own tools.
1. Purpose
This procedure sets out how [Organisation] responds when a device that stores or can access [Organisation] data is lost, stolen or cannot be accounted for. It aims to cut off access from that device fast, decide whether a notifiable personal data breach has occurred, keep an evidence trail and get the user working again. NIST treats device loss and theft as a core mobile threat, noting that "the portability of mobile devices makes them more likely to be lost or stolen than traditional desktop systems", and lists EMM, remote wipe, revocation of enterprise access and strong authentication as its mitigations.
2. Scope
- Laptops, desktops in transit, phones, tablets and removable media owned by [Organisation], and personally owned devices enrolled under [BYOD policy] or used to access [Organisation] data.
- Hardware security keys and smart cards issued by [Organisation].
- Loss, theft, devices left with a third party, devices not returned by leavers, and devices seized at a border, for employees, contractors and third parties.
A device that is suspected to be compromised but still in the user's hands is handled under [Incident Response Procedure]. See the Incident Response Guide.
3. Roles and responsibilities
- Device user: reports the loss immediately through [phone number / portal]. NCSC tells users to contact the IT helpdesk immediately, because "the faster you get in contact, the better".
- [Service desk]: verifies the caller, opens the incident and starts the 15-minute actions in section 7.
- [Endpoint team]: runs lock, Lost Mode, wipe or retire actions and holds encryption recovery keys.
- [IAM team]: revokes sessions and tokens, disables the device object, resets credentials and MFA.
- [Security operations]: monitors for use of the device or its credentials.
- [Privacy team / DPO]: runs the breach assessment in section 9 and owns any notification.
- Incident owner: [named role] accountable for closure and the section 10 records.
4. Definitions
- Lost Mode: on supervised iPhone and iPad, Managed Lost Mode "locks the current user out of the device", shows a custom message and lets an administrator request location, even if location services are off. Only the administrator can turn it off.
- Wipe: a factory reset removing all data, apps and settings. Retire (selective wipe): removes [Organisation] apps, data, profiles and certificates but leaves personal data, for personally owned devices.
- Personal data breach: a breach of security leading to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data (GDPR Art. 4(12)). The ICO lists "computing devices containing personal data being lost or stolen" as an example.
5. Report intake
Record at first contact; never delay containment to complete it.
| ID | Item to record | Owner | Timing |
|---|---|---|---|
| IN-1 | Caller verified by [call-back to registered number / manager confirmation]. Attackers also claim a lost phone to get MFA reset. | [Service desk] | At contact |
| IN-2 | User, device asset tag or serial, device type and OS, ownership (corporate or BYOD). | [Service desk] | At contact |
| IN-3 | When and where last seen, lost or stolen, and whether the device was powered off, asleep, locked or signed in. | [Service desk] | At contact |
| IN-4 | What else was with it: security key, smart card, written passwords, building pass. | [Service desk] | At contact |
| IN-5 | Incident ticket opened with priority [P2], incident owner assigned and [Security operations] and [Privacy team] notified. | [Service desk] | Within [15 minutes] |
6. Triage
Pull answers from [UEM console], [IdP] and the asset register rather than the user's memory.
| Factor | Check | How it changes the response |
|---|---|---|
| Encryption state | UEM report: BitLocker, FileVault, LUKS or mobile data protection on; recovery key escrowed. | Unencrypted with personal data: assume exposure. Encrypted and locked: strong mitigation (section 9). |
| Management | Enrolled in [UEM]? Supervised (Apple) or fully managed (Android)? Last check-in. | Unmanaged: identity-side revocation and app data wipe only. |
| Ownership | Corporate or personally owned. | Corporate: full wipe allowed. BYOD: retire or selective wipe only, unless [BYOD agreement] permits more. |
| Data on device | Classification of synced folders, mail cache and local files. | Special category or bulk customer data raises breach risk. |
| Credentials on device | Saved browser passwords, password manager, VPN and Wi-Fi certificates, SSH keys, cloud CLI tokens, API keys, .env files, code signing keys. | Treat as exposed and rotate (section 7.3), always if the device was unlocked. |
| Privilege | Administrator, developer, executive or finance approver? | Escalate to [Security operations] lead at once. |
| Circumstances | Targeted theft versus loss in transit. | Targeted theft raises the likelihood of attempted data access. |
7. Immediate containment
Run identity and device actions in parallel. NIST advises administrators to "remotely lock the device if it is suspected that the device is lost", but also warns that organisations "should not rely on remote wipe as the sole security control", because native wipe needs the device to be powered on and connected. Microsoft notes that an offline device "still has access to any locally stored data". Identity-side revocation works whether or not the device reconnects.
7.1 Device actions
| ID | Action | Owner | Timing |
|---|---|---|---|
| DV-1 | Send a remote lock. On supervised iPhone and iPad, enable Managed Lost Mode with a return message and request location. Do not attempt recovery from a location yourself; pass it to police. | [Endpoint team] | Within [15 minutes] |
| DV-2 | Confirm the recovery key is escrowed before any retire or delete. Microsoft warns that retiring or deleting a BitLocker-protected Entra joined device removes key protectors and suspends BitLocker on the OS volume. | [Endpoint team] | Within [1 hour] |
| DV-3 | Corporate device stolen, or lost and not found in [24 hours]: full wipe. In Intune for Windows, Microsoft describes "Wipe device, and continue to wipe even if device loses power" as ideal for lost or stolen devices; never use "keep enrollment state and associated user account", which preserves user data. | [Endpoint team], approved by [incident owner] | [Immediately if stolen / 24 hours if lost] |
| DV-4 | BYOD: retire or selectively wipe [Organisation] apps and data. Intune Retire runs at the next check-in, so it does not protect data while the device stays offline. | [Endpoint team] | Within [1 hour] |
| DV-5 | Keep Activation Lock (Apple's anti-theft lock, manageable through MDM for organisation-owned devices) or the equivalent on, so a wiped device cannot be reactivated by the thief. | [Endpoint team] | At wipe |
| DV-6 | Record when each command was sent and confirmed; alert on the device checking in. | [Endpoint team] | Ongoing |
See the UEM Buyer's Guide and the Mobile Device Security Guide.
7.2 Identity actions
| ID | Action | Owner | Timing |
|---|---|---|---|
| ID-1 | Revoke the user's refresh tokens and sign-in sessions. In Microsoft Entra ID: Revoke sessions on the user page, or Revoke-MgUserSignInSession. Equivalent session revocation in [other IdP]. | [IAM team] | Within [15 minutes] |
| ID-2 | Disable the device object so Conditional Access device-based rules fail. In Entra ID: Update-MgDevice -DeviceId <id> -AccountEnabled:$false. | [IAM team] | Within [15 minutes] |
| ID-3 | Close the gap after revocation: Entra access tokens last 1 hour by default and Entra cannot revoke session tokens issued by applications, so sign the user out of [critical SaaS apps] directly. Continuous Access Evaluation narrows this for CAE-capable apps. | [IAM team] | Within [1 hour] |
| ID-4 | Reset the user's password if it was saved on the device, written down with it, or the device was unlocked when lost. | [IAM team] | Within [1 hour] |
| ID-5 | Remove the lost device's MFA methods (authenticator app registration, platform passkey, Windows Hello for Business key) and any lost hardware key or smart card. Re-register on the replacement only after identity verification. | [IAM team] | Within [1 hour] |
| ID-6 | Revoke device certificates used for VPN, Wi-Fi (802.1X) or device trust. | [PKI team] | Within [4 hours] |
| ID-7 | Watch in [SIEM / ITDR] for sign-ins from the device ID or the user from new locations for [30 days]. | [Security operations] | Within [4 hours] |
See the Token and Session Security Guide and the Conditional Access Guide.
7.3 Developer, administrator and machine credentials
The most damaging content of a stolen developer laptop is often non-human credentials: keys and tokens that reach production with no MFA prompt and that user session revocation does not touch.
| ID | Action | Owner | Timing |
|---|---|---|---|
| NH-1 | Remove the user's SSH public keys from servers, bastions and Git hosting, and issue new keys from the replacement device. Revoke any SSH user certificates issued to the old key. | [Platform team] | Within [4 hours] |
| NH-2 | Revoke personal access tokens and CLI sessions for [Git hosting, cloud, package registries, CI/CD]; treat cached cloud CLI credentials as stolen. | [Platform team] with user | Within [4 hours] |
| NH-3 | Rotate any API keys, service account keys, database passwords or secrets found in local config, .env files or repositories cloned on the device, using the [secrets inventory] to find owners. | [Secret owners] | Within [24 hours] |
| NH-4 | Revoke code signing certificates or signing keys held on the device and check for signatures issued after the loss. | [Release engineering] | Within [24 hours] |
| NH-5 | Privileged admins: rotate any break-glass or vaulted credentials checked out to the user and review [PAM] session logs. | [PAM team] | Within [4 hours] |
See the SSH Key Management Guide, the Secrets Management Guide and the Leaked Credential Response Playbook.
8. Police report and recovery
- For theft, the user must report it to police [within 24 hours] and give the crime reference to [Service desk]; insurers usually require it.
- Location data from Lost Mode or tracking goes to police. Staff must not try to recover a device themselves.
- A found device goes to [Endpoint team], not the user, and is treated as untrusted: inspect, then reimage before reissue. Devices seized at a border are handled the same way and reported to [Legal].
9. Breach assessment
[Privacy team] decides whether a personal data breach occurred and must be notified. Under UK GDPR and GDPR, a notifiable breach must be reported to the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of it. Individuals must be told without undue delay where the breach is likely to result in a high risk, but Art. 34(3)(a) removes that duty where the data was protected by measures, such as encryption, that render it unintelligible to anyone not authorised to access it.
| Situation | Likely outcome | Evidence needed |
|---|---|---|
| Strong full disk encryption on, device powered off or locked, key not with the device | Breach recorded internally; regulator notification usually not required and Art. 34(3)(a) applies to individuals. Decision documented. | UEM encryption status at time of loss, key escrow record, user statement on device state. |
| Encrypted, but unlocked or signed in when lost, or password written down with it | Treat as unencrypted. The ICO warns that if an encrypted device is left unlocked while a user is signed in, "an attacker can gain access to the decrypted material". | User statement, last unlock and check-in times. |
| Unencrypted with personal data | Risk assessment; regulator notification likely; individuals if high risk. | Data inventory of the device, number of people and data types. |
| Remote wipe confirmed before likely access | Reduces risk; Art. 34(3)(b) may apply where later measures make high risk unlikely. | Wipe confirmation timestamp versus time lost. |
| Credentials on device used after the loss | Now an account compromise incident; scope widens beyond the device. | Sign-in and audit logs. |
For a reported theft, awareness is usually the report time. Use the [Data Breach Notification Procedure] to notify. Failing to notify the ICO when required can lead to a fine of up to £8.7 million. See the Encryption Guide and the GDPR Compliance Guide for Security Teams.
10. Evidence and records
| ID | Record | Owner | Timing |
|---|---|---|---|
| RC-1 | Timeline: loss, report, each containment action sent and confirmed. | Incident owner | During incident |
| RC-2 | UEM export of the device's last compliance state, encryption status and last check-in, captured before any wipe or delete. | [Endpoint team] | Within [1 hour] |
| RC-3 | IdP and SaaS sign-in logs for the user and device since last seen, preserved. | [Security operations] | Within [24 hours] |
| RC-4 | Breach assessment and decision, with reasons, recorded in the [breach register] whether or not notified. The ICO says to "record all breaches, regardless of whether or not they need to be reported". | [Privacy team] | Within [72 hours] |
| RC-5 | Crime reference, insurer claim and asset register status (lost, stolen, wiped, recovered). | [Service desk] / [Asset management] | Within [5 days] |
11. Replacement and closure
- Issue a replacement with fresh enrolment; restore data from managed sync, not from a backup of the lost device's disk. Register new MFA methods only after identity verification under [Account Recovery Procedure].
- Delete the old device object in [IdP] and [UEM] after [retention period], keeping the recovery key record in case the device is found.
- Close the incident only when every section 7 action is confirmed and section 10 records are complete. Log losses of unencrypted or unmanaged devices as control gaps.
12. Lessons learned and measurement
[Security team] reports quarterly on:
- Time to report: median time from loss to report.
- Time to contain: median time from report to sessions revoked and device locked (target [under 1 hour]).
- Encryption at loss: percentage of lost devices confirmed encrypted with escrowed keys (target [100]%).
- Unmanaged losses: lost devices with no remote action possible.
- Secret rotation completion: share of developer device losses where every exposed key was rotated within target.
- Notifiable breaches: device losses that required regulator or individual notification.
13. Source references
- NIST: SP 800-124 Rev. 2, Guidelines for Managing the Security of Mobile Devices in the Enterprise
- NCSC: End user devices, advice for end users
- Microsoft Learn: Revoke user access in an emergency in Microsoft Entra ID
- Microsoft Learn: Wipe devices with Microsoft Intune
- Microsoft Learn: Device action, retire
- Apple Platform Deployment: Managed Lost Mode and Activation Lock
- ICO: Personal data breaches, a guide
- ICO: Encryption and data storage
- legislation.gov.uk: UK GDPR Article 34, communication of a personal data breach to the data subject
Implementation guidance
The procedure only works if the controls it depends on are already in place. Put them in this order:
- Make reporting easy: one 24/7 number and portal, known to every user. Make clear that fast reporting is never penalised.
- Close the prerequisites: enforce encryption with escrowed keys, UEM enrolment and supervision before devices are issued. A device you cannot wipe or prove was encrypted turns every loss into a breach assessment with no evidence.
- Script the identity steps: wrap session revocation, device disable and MFA method removal in one runbook so the service desk can run it out of hours. Test it monthly on a pilot account.
- Inventory developer secrets: you cannot rotate what you cannot list. Move developers to short-lived credentials and SSO-based CLI login so a lost laptop holds tokens that expire in hours, not keys that last years.
- Exercise it: run a timed tabletop with service desk, endpoint, IAM and privacy teams twice a year and fix the slowest step first.
- Keep wipe deliberate: wipe cannot be undone, so keep the approval step for "lost, may be found" cases and wipe at once only for theft or high-risk devices.
Small organisations can run this from one UEM console and the IdP portal with two or three named people. Larger organisations should automate the identity steps from the ITSM ticket and route developer and privileged-user losses to security operations by default. Related guidance: Device Trust and Posture Guide for compliance-based access, Account Recovery and Help Desk Security Guide for verifying callers, and Hardware Security Keys Guide for lost authenticators.
This template is provided for guidance and must be adapted to your organisation. Related NHI Mgmt Group resources: Mobile Device Security Guide · UEM Buyer's Guide · Endpoint Security Guide · Token and Session Security Guide