Device Loss or Theft

Device loss or theft creates immediate data exposure risk that escalates with each hour of delayed response. A lost laptop containing unencrypted beneficiary data or an unlocked mobile phone with cached email credentials represents a potential data breach regardless of whether malicious access occurs. This playbook establishes time-critical procedures to contain exposure through remote device control, assess data risk, execute wipe decisions, and complete incident documentation.

The response window is narrow. Modern device management platforms report that remote wipe commands succeed at rates exceeding 90% when issued within 4 hours of loss, dropping to under 60% after 24 hours as devices power down or lose connectivity. Every procedural step in this playbook is sequenced to maximise the probability of successful device control before that window closes.

Activation criteria

Invoke this playbook when any of the following conditions are confirmed or suspected:

The 30-minute search threshold for reported loss balances response urgency against false positives from devices misplaced in bags or vehicles. For theft reports or border confiscations, skip the waiting period and proceed directly to Phase 1.

Roles

For organisations with a single IT person, that individual serves as both incident handler and wipe authoriser. Document the dual role in incident records to maintain audit trail.

Phase 1: Immediate response

Objective: Prevent unauthorised access by locking the device and establishing location if possible Timeframe: Complete within 15 minutes of report

1. Record initial report details

   Capture essential information from the reporting user before any technical actions. Missing details at this stage create gaps that complicate later assessment.

   Report timestamp: _______________
   Device type and model: _______________
   Device serial/asset tag: _______________
   Last known location: _______________
   Last known time device was in possession: _______________
   Was device powered on when last seen: _______________
   Was device locked/unlocked when last seen: _______________
   Circumstances of loss (lost/stolen/confiscated): _______________
   Reporter contact number: _______________

2. Issue remote lock command

   Execute lock immediately through MDM or platform-specific tools. Do not wait for additional information or authorisation. Lock commands are reversible; data exposure is not.

   Microsoft Intune:

   Endpoint Manager admin center > Devices > [device name] > Remote lock

Jamf Pro (macOS/iOS):

   Jamf Pro > Devices > [device name] > Management > Lock Device
   Set recovery PIN: [generate 6-digit PIN and record]

Google Workspace (Android):

   Admin console > Devices > Mobile devices > [device] > More > Lock device

Apple Business Manager (direct):

   business.apple.com > Devices > [device] > Lock

3. Attempt device location

   Query current or last known location through MDM. Location data helps assess recovery likelihood and informs wipe timing decisions.

   Record location result:

   • Current location available: coordinates and timestamp
   • Last known location: coordinates, timestamp, and time since update
   • Location unavailable: device offline or location services disabled

   If location shows device at a recoverable location (user’s home, known office), contact user to verify before proceeding to wipe assessment.

4. Suspend device network access

   If your environment supports certificate-based network authentication, revoke the device certificate to prevent network access even if device is unlocked:

   # Example: revoke certificate in internal CA
   openssl ca -revoke /path/to/certs/device-serial.crt -config /etc/ssl/openssl.cnf

   # Regenerate CRL and distribute
   openssl ca -gencrl -out /path/to/crl/current.crl -config /etc/ssl/openssl.cnf

For cloud-only environments, disable the device record in your identity provider to prevent authentication:

Microsoft Entra ID:

   Entra admin center > Devices > [device] > Disable

5. Notify wipe authoriser

   Send immediate notification to the designated wipe authoriser with current status. Do not wait for authorisation to proceed with lock and location steps, but wipe execution requires explicit approval.

Decision point: If lock command succeeds and location shows device at recoverable location, pause wipe timeline for up to 2 hours to allow recovery attempt. If lock fails, location unknown, or theft confirmed, proceed immediately to Phase 2.

Checkpoint: Before proceeding, confirm:

• Lock command issued (record success/failure)
• Location queried (record result)
• Network access suspended where possible
• Wipe authoriser notified
• Initial report details captured

Phase 2: Data exposure assessment

Objective: Determine what data was accessible on the device and assess exposure severity Timeframe: Complete within 1 hour of Phase 1 completion

1. Retrieve device configuration profile

   Pull the device’s MDM profile to establish security baseline at time of loss:

   Configuration item	Finding	Exposure implication
   Full disk encryption	Enabled/Disabled	Disabled = data accessible to anyone with physical access
   Encryption recovery key escrowed	Yes/No	If no and encryption enabled, data likely protected
   Screen lock timeout	Value in minutes	>5 minutes increases exposure window
   PIN/password complexity	Strong/Weak/None	None = immediate access if device powered on
   Biometric enabled	Yes/No	Does not affect exposure if device unlocked at loss
   Remote wipe capability	Yes/No	No = limited containment options

2. Inventory data on device

   Review with device owner and relevant data owners what information was accessible. Work through categories systematically:

   Local storage:

   • Documents downloaded for offline access
   • Email cached on device (how many days of cache?)
   • Browser saved passwords and autofill data
   • Application data stored locally
   • Photos containing sensitive information

   Cloud access (if device unlocked):

   • Email access (full mailbox vs limited sync)
   • File storage access (SharePoint, Google Drive, OneDrive)
   • Business applications (CRM, case management, finance)
   • Messaging platforms (Teams, Slack) with message history

   Credentials on device:

   • Saved passwords in browser or credential manager
   • VPN certificates or credentials
   • SSH keys
   • API tokens in development tools

   Record inventory with sensitivity classification for each item discovered.

3. Determine encryption protection

   Encryption status determines whether physical access to storage enables data extraction:

   +------------------+----------------------+---------------------------+
   |  DEVICE STATE    |  ENCRYPTION STATUS   |  EXPOSURE ASSESSMENT      |
   +------------------+----------------------+---------------------------+
   |                  |                      |                           |
   |  Powered off     |  Encrypted           |  LOW - data protected     |
   |  when lost       |                      |  at rest                  |
   |                  |                      |                           |
   +------------------+----------------------+---------------------------+
   |                  |                      |                           |
   |  Powered off     |  Not encrypted       |  HIGH - disk readable     |
   |  when lost       |                      |  with physical access     |
   |                  |                      |                           |
   +------------------+----------------------+---------------------------+
   |                  |                      |                           |
   |  Powered on,     |  Encrypted           |  MEDIUM - encryption key  |
   |  locked          |                      |  in memory; sophisticated |
   |                  |                      |  attack possible          |
   |                  |                      |                           |
   +------------------+----------------------+---------------------------+
   |                  |                      |                           |
   |  Powered on,     |  Any                 |  CRITICAL - full data     |
   |  unlocked        |                      |  access without any       |
   |                  |                      |  technical barrier        |
   |                  |                      |                           |
   +------------------+----------------------+---------------------------+

4. Classify exposure severity

   Combine encryption status with data inventory to determine severity:

   Data present	Encryption protected	Severity
   No sensitive data	Any	Low
   Personal data (staff only)	Yes, device was off	Low
   Personal data (staff only)	Yes, device was on	Medium
   Personal data (staff only)	No	High
   Beneficiary/programme data	Yes, device was off	Medium
   Beneficiary/programme data	Yes, device was on	High
   Beneficiary/programme data	No	Critical
   Protection/safeguarding data	Any	Critical
   Financial/payment data	Any	Critical
   Credentials for critical systems	Any	Critical

   Critical severity requires escalation to senior leadership and potential activation of Data Breach Response.

Decision point: If severity is Critical and protection/safeguarding data is involved, activate Protection Data Breach Response in parallel with this playbook.

Checkpoint: Before proceeding, confirm:

• Device configuration profile retrieved
• Data inventory completed with device owner
• Encryption status determined
• Exposure severity classified
• Escalation completed if Critical severity

Phase 3: Remote wipe decision and execution

Objective: Execute wipe if appropriate, with proper authorisation and documentation Timeframe: Wipe decision within 2 hours of loss report; execution immediate upon approval

1. Apply wipe decision criteria

   The wipe decision balances data protection against device recovery possibility and user impact. Use this decision framework:

+-----------------------------------------------------------------------------------+
|                            WIPE DECISION FRAMEWORK                                |
+-----------------------------------------------------------------------------------+
|                                                                                   |
|                          +------------------------+                               |
|                          |   WIPE DECISION ENTRY  |                               |
|                          +-----------+------------+                               |
|                                      |                                            |
|                    +-----------------v-----------------+                          |
|                    |      Is device confirmed          |                          |
|                    |     stolen or confiscated?        |                          |
|                    +-----------------+-----------------+                          |
|                                      |                                            |
|                +---------------------+---------------------+                      |
|                |                                           |                      |
|              YES                                           NO                     |
|                |                                           |                      |
|                v                                           v                      |
|    +-----------------------+           +-----------------------+                  |
|    |   WIPE IMMEDIATELY    |           |   Is device location  |                  |
|    |    (no recovery       |           |       known and       |                  |
|    |      expected)        |           |     recoverable?      |                  |
|    +-----------------------+           +-----------+-----------+                  |
|                                                    |                              |
|                                          +---------+---------+                    |
|                                          |                   |                    |
|                                         YES                  NO                   |
|                                          |                   |                    |
|                                          v                   v                    |
|                            +-------------------+    +-------------------+         |
|                            |   Allow 2 hours   |    |    Is exposure    |         |
|                            |   for recovery    |    |  severity Medium  |         |
|                            |      attempt      |    |    or higher?     |         |
|                            +---------+---------+    +---------+---------+         |
|                                      |                        |                   |
|                                      v              +---------+---------+         |
|                            +-------------------+    |                   |         |
|                            |     Recovery      |   YES                 NO         |
|                            |    successful?    |    |                   |         |
|                            +----+---------+----+    v                   v         |
|                                 |         |   +-----------+     +--------------+  |
|                                YES       NO   |WIPE within|     |Allow 24 hours|  |
|                                 |         |   |  4 hours  |     | for recovery |  |
|                                 v         v   +-----------+     | then wipe    |  |
|                           +---------+ +---------+               +--------------+  |
|                           |  CLOSE  | |  WIPE   |                                 |
|                           | incident| |   NOW   |                                 |
|                           +---------+ +---------+                                 |
|                                                                                   |
+-----------------------------------------------------------------------------------+

2. Obtain wipe authorisation

   Submit wipe request to designated authoriser with:

   • Device identification (serial, asset tag, user)
   • Exposure severity assessment
   • Recovery likelihood assessment
   • Recommendation (wipe now, delay for recovery, or no wipe needed)

   For BYOD devices, wipe authorisation requirements differ based on your BYOD Policy. Selective wipe (organisational data only) typically requires only IT authorisation. Full device wipe on personal devices requires user consent unless policy explicitly permits organisation-initiated full wipe.

   Record authorisation:

   Authoriser name: _______________
   Authorisation timestamp: _______________
   Wipe type authorised: [ ] Full device  [ ] Selective/corporate only  [ ] No wipe
   Authorisation method: [ ] Email  [ ] Ticket  [ ] Verbal (document immediately)

3. Execute remote wipe

   Wipe commands vary by platform. Execute the authorised wipe type:

   Windows (Intune):

   Endpoint Manager > Devices > [device] > Wipe
   Options:
   - Wipe device, and continue to wipe even if device loses power: Yes
   - Retain enrollment state and user account: No (for full wipe)

   # For Autopilot devices, the device will re-enroll on next boot
   # if found. Record Autopilot hash for tracking.

macOS (Jamf Pro):

   Jamf Pro > Devices > [device] > Management > Wipe Computer
   Set PIN: [6-digit PIN required for recovery]
   Clear Activation Lock: Yes (if organisation-owned)

   Record PIN in secure location for potential recovery.

iOS (Intune or ABM):

   Endpoint Manager > Devices > [device] > Wipe
   - Remove device from enrollment: Yes
   - Retain eSIM data: No

   # Or via Apple Business Manager for Activation Lock:
   ABM > Devices > [device] > Erase Device

Android (Google Workspace or Intune):

   # Google Workspace admin:
   Admin console > Devices > Mobile > [device] > Wipe device
   Options: Wipe account (selective) or Wipe device (full)

   # Intune:
   Endpoint Manager > Devices > [device] > Retire (selective) or Wipe (full)

4. Verify wipe execution

   Monitor wipe status through MDM. Wipe commands queue until device connects to network.

   Status	Meaning	Action
   Pending	Command queued, device not yet online	Monitor; set 24-hour reminder
   In progress	Device received command, wipe executing	Monitor for completion
   Completed	Device confirmed wiped	Document and proceed to Phase 4
   Failed	Command failed (device offline, error)	Document failure; assess alternatives

   If wipe remains pending after 24 hours, the device is likely powered off or destroyed. Document status and proceed to Phase 4 regardless.

5. Handle wipe failure scenarios

   When wipe cannot be executed (device offline, MDM not installed, technical failure):

   • Revoke all credentials associated with the device user (proceed to Phase 4 step 1 immediately)
   • Disable device record in identity provider
   • Add device serial to organisation’s blocklist
   • For unmanaged devices: rely on encryption (if verified) and credential revocation
   • Document that wipe was not possible and containment relies on credential rotation

Decision point: If wipe fails and exposure severity is High or Critical, escalate to senior leadership and consider Data Breach Response activation.

Checkpoint: Before proceeding, confirm:

• Wipe decision made per criteria
• Authorisation obtained and documented
• Wipe command executed (or failure documented)
• Wipe status monitored and recorded

Phase 4: Credential rotation and follow-up

Objective: Eliminate access risk from cached credentials and complete administrative requirements Timeframe: Complete within 24 hours of wipe execution

1. Rotate user credentials

   Even with successful wipe, rotate credentials that may have been cached or accessible on the device:

   Required rotations:

   • User password (identity provider)
   • MFA re-enrollment (revoke existing factors, require new enrollment)
   • VPN certificates (revoke and reissue)
   • Email app-specific passwords (if used)
   • Any passwords saved in browser sync (advise user to audit and rotate sensitive passwords)

   Conditional rotations (if used on device):

   • SSH keys
   • API tokens
   • Service account credentials managed by user
   • Third-party application passwords

   Execute password reset forcing change at next login:

   Microsoft Entra ID:

   # PowerShell
   Set-AzureADUser -ObjectId user@example.org -PasswordProfile @{
       Password = "TemporaryPassword123!"
       ForceChangePasswordNextLogin = $true
   }

   # Revoke all refresh tokens
   Revoke-AzureADUserAllRefreshToken -ObjectId user@example.org

Google Workspace:

   Admin console > Users > [user] > Security > Require password change
   Admin console > Users > [user] > Security > Sign out user from all sessions

2. File insurance report if applicable

   For organisation-owned devices with insurance coverage, file claim within policy timeframe (commonly 30 days):

   • Device details (make, model, serial, purchase date, purchase price)
   • Circumstances of loss
   • Police report reference (if obtained)
   • Proof of ownership documentation

   Coordinate with finance or operations team responsible for insurance claims.

3. File police report if theft

   For confirmed theft, file police report if:

   • Required by insurance
   • Device value exceeds reporting threshold (commonly over £500)
   • Required by organisational policy
   • Criminal investigation desired

   Police reports in most jurisdictions can be filed online for property theft. Obtain reference number for insurance and records.

4. Update asset register

   Mark device status in asset management system:

   Device serial: _______________
   Previous status: Deployed
   New status: Lost/Stolen
   Status change date: _______________
   Assigned user: _______________
   Wipe status: Confirmed/Pending/Failed
   Police report ref: _______________
   Insurance claim ref: _______________

5. Provision replacement device

   If user requires replacement:

   • Issue from available stock or procure new device
   • Configure per standard deployment procedures
   • Ensure replacement has full disk encryption enabled before deployment
   • Conduct user briefing on incident (non-punitive, focused on prevention)
   • Update asset register with new assignment

   Replacement timing depends on user role criticality and device availability. Target same-day replacement for critical roles, within 3 working days otherwise.

Checkpoint: Before proceeding to Phase 5, confirm:

• User credentials rotated
• MFA re-enrollment required
• Insurance report filed (if applicable)
• Police report filed (if applicable)
• Asset register updated
• Replacement provisioned (if required)

Phase 5: Post-incident

Objective: Complete documentation, determine if data breach notification required, identify preventive improvements Timeframe: Complete within 5 working days

1. Complete incident documentation

   Compile full incident record including:

   • Initial report timestamp and details
   • All actions taken with timestamps
   • Wipe authorisation record
   • Wipe execution result
   • Credential rotation record
   • Exposure severity assessment
   • Data inventory findings
   • Insurance and police references
   • Replacement details

   Store in incident management system with appropriate access controls.

2. Determine breach notification requirement

   Based on Phase 2 exposure assessment, determine if data breach notification is required:

   Condition	Notification requirement
   No personal data on device	No notification required
   Personal data present, encryption confirmed effective	Likely no notification (document rationale)
   Personal data present, encryption ineffective or unknown	Assess per GDPR Article 33/34 or applicable regulation
   Beneficiary data with risk to individuals	Notification likely required
   Protection/safeguarding data	Specialist assessment required

   If notification is required or uncertain, engage data protection lead and transition to Data Breach Response.

3. User debrief

   Conduct non-punitive debrief with device owner to understand circumstances and identify any systemic issues. Cover:

   • How loss/theft occurred
   • Whether security practices were followed (device locked when not in use)
   • Any environmental factors (travel, field work, shared spaces)
   • User’s suggestions for prevention

   Document findings for trend analysis without attributing blame for honest losses.

4. Identify preventive improvements

   Review incident for systemic improvement opportunities:

   • Was encryption enabled? If not, why was device deployed unencrypted?
   • Was MDM coverage adequate for remote wipe?
   • Could shorter lock timeout have reduced exposure?
   • Are BYOD policies clear on wipe authority?
   • Does travel guidance address device security adequately?

   Submit improvement recommendations to IT management or security governance.

5. Close incident

   Mark incident closed when:

   • All containment actions complete
   • Documentation finalised
   • Breach notification decision made and executed
   • User restored to full productivity
   • Improvement recommendations submitted

Field-specific considerations

Device loss in field contexts presents additional complications that modify standard procedures.

Border confiscation occurs when authorities retain devices during crossing. This scenario differs from theft because the confiscating entity may have technical capability to bypass encryption through legal authority or coercion. When a device is confiscated at a border:

1. Assume all data on device is accessible regardless of encryption status
2. Execute wipe immediately if device has connectivity (unlikely once confiscated)
3. Treat all credentials on device as compromised
4. Assess whether user was compelled to provide unlock codes
5. If protection or programme data was accessible, escalate to senior leadership and consider Protection Data Breach Response

For staff travelling to high-risk jurisdictions, pre-travel preparation reduces exposure. Issue travel devices with minimal data load, disable biometric unlock (jurisdictions may compel fingerprint but not passcode), and brief users on device surrender procedures. See Data Protection at Borders for comprehensive travel data protection guidance.

Hostile environment loss includes theft by state or non-state actors who may target the organisation specifically. In these scenarios:

1. Assume technical capability to extract data regardless of encryption
2. Treat all information on device as compromised for planning purposes
3. Assess whether device contents reveal operational information (staff locations, beneficiary identities, programme activities)
4. Consider immediate communication with potentially exposed individuals
5. Coordinate with security team on physical safety implications

Remote field office loss may occur where connectivity is limited. If the lost device cannot receive wipe commands:

1. Rely on encryption as primary protection (verify encryption was enabled before deployment)
2. Execute credential rotation immediately for all accounts accessible from device
3. Document wipe as pending; set reminder to check status when device might regain connectivity
4. If device returns to network, wipe will execute; if not, encryption remains sole protection

Communications

Internal notification

To IT management (immediate):

Subject: Device Loss/Theft - [User Name] - [Device Type]

A [device type] assigned to [user name] was reported [lost/stolen] at
approximately [time] on [date].

Location of loss: [location]
Circumstances: [brief description]

Current status:
- Remote lock: [Issued/Pending/Failed]
- Device location: [Known/Unknown]
- Remote wipe: [Pending authorisation/Authorised/Executed/Failed]

Exposure assessment: [Severity level]
- Encryption status: [Verified/Unverified/Not encrypted]
- Sensitive data present: [Yes - describe/No/Under assessment]

Immediate actions required:
- [Wipe authorisation needed / None]

I will provide updates as the situation develops.

[Your name]

To affected user (after initial containment):

Subject: Your [device type] - Next Steps

Thank you for reporting the [loss/theft] of your [device type] promptly.
We have taken the following protective actions:

- Issued remote lock command to prevent unauthorised access
- [Executed remote wipe / Scheduled remote wipe for [time]]
- Disabled the device's network access

You will need to:
1. Reset your password at [link] - this is required before you can
   access any organisational systems
2. Re-enroll your MFA by [instructions]
3. Review any personal passwords you may have saved in your browser
   and change any sensitive ones

Regarding a replacement device:
[Replacement details and timeline]

If you remember any additional details about the loss or recall
specific sensitive files that were on the device, please let me know.

This is not a punitive process - prompt reporting helps us protect
organisational data effectively.

[Your name]
[Contact details]

Escalation notification

To senior leadership (for Critical severity):

Subject: URGENT - Device Loss with Critical Data Exposure Risk

A device loss incident requires leadership awareness due to the
sensitivity of data involved.

Summary:
- Device: [Type] assigned to [User]
- Lost/stolen: [Date/time] at [Location]
- Status: [Lock/wipe status]

Critical exposure concern:
[Description of sensitive data - protection cases, financial data,
credentials, etc.]

Assessment:
- Encryption: [Status and effectiveness]
- Data breach threshold: [Likely met / Under assessment / Unlikely]
- Notification timeline: [If GDPR applies: 72 hours from awareness]

Recommended actions:
1. [Specific recommendations]
2. [Escalation path]

I am [continuing response / awaiting guidance] and will update you
by [time].

[Your name]

Evidence preservation

Preserve the following for potential legal proceedings, insurance claims, or breach documentation:

Export MDM logs within 48 hours of incident as some platforms have limited log retention. Screenshot wipe confirmation status including timestamp and device identifier.

Response timeline summary

+--------+--------------------------------------------------+-------------+
| TIME   | ACTION                                           | OWNER       |
+--------+--------------------------------------------------+-------------+
|        |                                                  |             |
| 0 min  | Loss reported                                    | User        |
|        |                                                  |             |
+--------+--------------------------------------------------+-------------+
|        |                                                  |             |
| 5 min  | Remote lock issued                               | IT handler  |
|        |                                                  |             |
+--------+--------------------------------------------------+-------------+
|        |                                                  |             |
| 10 min | Device location queried                          | IT handler  |
|        |                                                  |             |
+--------+--------------------------------------------------+-------------+
|        |                                                  |             |
| 15 min | Network access suspended, wipe authoriser        | IT handler  |
|        | notified                                         |             |
|        |                                                  |             |
+--------+--------------------------------------------------+-------------+
|        |                                                  |             |
| 1 hr   | Exposure assessment complete                     | IT handler  |
|        |                                                  |             |
+--------+--------------------------------------------------+-------------+
|        |                                                  |             |
| 2 hr   | Wipe decision made, authorisation obtained       | Authoriser  |
|        |                                                  |             |
+--------+--------------------------------------------------+-------------+
|        |                                                  |             |
| 2.5 hr | Wipe executed (or recovery window started)       | IT handler  |
|        |                                                  |             |
+--------+--------------------------------------------------+-------------+
|        |                                                  |             |
| 4 hr   | Recovery window expires if applicable; wipe      | IT handler  |
|        | executed if deferred                             |             |
|        |                                                  |             |
+--------+--------------------------------------------------+-------------+
|        |                                                  |             |
| 24 hr  | Credential rotation complete, follow-up actions  | IT handler  |
|        | in progress                                      |             |
|        |                                                  |             |
+--------+--------------------------------------------------+-------------+
|        |                                                  |             |
| 5 days | Incident closed, improvements documented         | IT handler  |
|        |                                                  |             |
+--------+--------------------------------------------------+-------------+

See also

• Data Protection at Borders -comprehensive guidance for device security during travel
• MDM Rollout -establishing remote management capabilities
• Data Breach Response -escalation when data exposure is confirmed
• Protection Data Breach Response -specialist procedures for protection data
• Account Compromise -if credentials rather than device were compromised
• BYOD Policy -wipe authority and user consent for personal devices
• Evidence Collection -forensic procedures if criminal investigation required
• Incident Triage Matrix -severity classification reference