ISO/IEC 27001

⌘K
  1. Home
  2. Docs
  3. ISO/IEC 27001
  4. Other Doc
  5. Lost/Stolen Asset Incident Form

Lost/Stolen Asset Incident Form

1. Purpose

The Lost/Stolen Asset Incident Form is used to record, assess, respond to, and close incidents involving lost, misplaced, or stolen organizational assets.

The objective is to ensure that the organization:

  • Responds quickly to lost or stolen assets
  • Protects organizational and customer information
  • Revokes or restricts associated access
  • Assesses potential information exposure
  • Preserves relevant evidence
  • Determines whether the event is a security or data incident
  • Completes recovery, replacement, and corrective actions
  • Maintains an auditable incident record

Key principle:

Report → Secure → Assess → Contain → Investigate → Recover → Document → Improve


2. When to Use This Form

Use this form when an organizational asset is:

  • Lost
  • Stolen
  • Misplaced and cannot be located
  • Left unattended in a public place
  • Lost during travel
  • Lost while working remotely
  • Lost during shipment or courier delivery
  • Stolen from an office
  • Stolen from a vehicle
  • Lost by an employee or contractor
  • Lost by a third-party service provider

Examples include:

  • Laptops
  • Mobile phones
  • Tablets
  • USB drives
  • External hard drives
  • Security keys
  • Smart cards
  • Access cards
  • Company documents
  • Printed records
  • Backup media
  • Network equipment
  • Other assets containing or providing access to organizational information

3. Incident Information

FieldDetails
Incident ID
Date Reported
Time Reported
Reported By
Employee/Contractor ID
Department
Manager
Asset Owner
IT/Security Owner
Incident TypeLost / Stolen / Misplaced
Date/Time Lost or Stolen
Location
Discovery Date/Time
Current StatusOpen / Investigating / Contained / Closed
Initial SeverityLow / Medium / High / Critical

4. Immediate Reporting

The person discovering the loss or theft should report it immediately through the organization’s approved incident-reporting channel.

Initial Actions

  • ☐ Manager notified
  • ☐ IT notified
  • ☐ Security/ISMS notified where required
  • ☐ HR notified where appropriate
  • ☐ Supplier notified where applicable
  • ☐ Customer notified where contractually required
  • ☐ Law enforcement contacted where appropriate
  • ☐ Insurance provider notified where applicable

Do not wait for the asset to be found before reporting the incident.


5. Asset Details

FieldDetails
Asset ID
Asset TypeLaptop / Mobile / Tablet / USB / Security Key / Document / Other
Asset Name
Manufacturer
Model
Serial Number
Service Tag / IMEI
Hostname
Assigned User
Asset Owner
Department
Location Normally Used
Information ClassificationPublic / Internal / Confidential / Restricted
Asset CriticalityLow / Medium / High / Critical
Encryption Enabled?Yes / No / Unknown
Device Management Enabled?Yes / No / Unknown

6. Incident Description

What happened?

Describe the circumstances clearly and factually.

Date/time of event:


Location:


Description:




Example

The company laptop assigned to an employee was reported missing after the employee left the device in a vehicle during travel. The employee noticed the loss approximately two hours later and immediately contacted IT.


7. Last Known Location

FieldDetails
Last Known Location
Date/Time Last Seen
Person Last in Possession
Location TypeOffice / Home / Vehicle / Airport / Hotel / Public Place / Other
Device Connected to Network?Yes / No / Unknown
GPS/Device Tracking Available?Yes / No
Tracking Status

8. Information Exposure Assessment

Determine what information may have been accessible through or stored on the lost/stolen asset.

Information Potentially Accessible

  • ☐ Corporate email
  • ☐ Customer information
  • ☐ Employee information
  • ☐ Personal data
  • ☐ Financial information
  • ☐ Source code
  • ☐ Business documents
  • ☐ Contracts
  • ☐ Security documentation
  • ☐ Credentials
  • ☐ API keys
  • ☐ VPN credentials
  • ☐ Cloud access
  • ☐ Authentication tokens
  • ☐ Security keys
  • ☐ Encryption keys
  • ☐ Local database
  • ☐ Backup data
  • ☐ Other sensitive information

Information Stored Locally

  • ☐ None known
  • ☐ Public information
  • ☐ Internal information
  • ☐ Confidential information
  • ☐ Restricted information
  • ☐ Unknown

9. Security Control Assessment

Security ControlStatusEvidence / Remarks
Full-disk encryptionYes / No / Unknown
Screen lockYes / No / Unknown
Strong authenticationYes / No / Unknown
MFAYes / No / Unknown
Endpoint protectionYes / No / Unknown
Device managementYes / No / Unknown
Remote lockYes / No / Unknown
Remote wipeYes / No / Unknown
VPNYes / No / Unknown
Data Loss PreventionYes / No / Unknown
Local data storageYes / No / Unknown
Automatic backupYes / No / Unknown

10. Immediate Containment Actions

IT/Security should determine which actions are required.

Account and Access

  • ☐ User account disabled where required
  • ☐ SSO sessions terminated
  • ☐ MFA sessions revoked
  • ☐ VPN access revoked
  • ☐ Cloud access reviewed/revoked
  • ☐ SaaS sessions revoked
  • ☐ API tokens revoked
  • ☐ SSH keys revoked
  • ☐ Device certificates revoked
  • ☐ Privileged access reviewed
  • ☐ Passwords reset where necessary

Device

  • ☐ Device locked remotely
  • ☐ Device tracked
  • ☐ Remote wipe initiated
  • ☐ Device removed from management platform where appropriate
  • ☐ Device marked as lost/stolen
  • ☐ Endpoint security status reviewed

Physical

  • ☐ Building access card disabled where relevant
  • ☐ Security key disabled/revoked
  • ☐ Physical access reviewed

11. Credential and Secret Exposure

Determine whether the asset contained or provided access to:

  • ☐ Passwords
  • ☐ Password-manager access
  • ☐ API keys
  • ☐ Cloud access keys
  • ☐ SSH keys
  • ☐ VPN certificates
  • ☐ Authentication tokens
  • ☐ Encryption keys
  • ☐ Database credentials
  • ☐ Service credentials
  • ☐ Developer credentials

Where exposure is possible:

  • ☐ Credential revoked
  • ☐ Credential rotated
  • ☐ Token invalidated
  • ☐ Certificate revoked
  • ☐ Secret rotated
  • ☐ Dependent systems tested
  • ☐ Evidence retained

12. AWS / Cloud Security Assessment

If the asset had access to AWS, Azure, GCP, or another cloud platform:

  • ☐ Cloud SSO access reviewed
  • ☐ IAM roles reviewed
  • ☐ IAM user access reviewed
  • ☐ Access keys revoked
  • ☐ Temporary credentials addressed
  • ☐ SSH keys reviewed
  • ☐ Production access reviewed
  • ☐ Database access reviewed
  • ☐ Secrets access reviewed
  • ☐ Cloud console sessions terminated where applicable
  • ☐ Relevant CloudTrail/security logs reviewed
  • ☐ Cloud administrator access reviewed
  • ☐ Security incident escalation completed where required

Example

A lost laptop used by an AWS administrator should be treated differently from a lost laptop that contained only low-risk information.

The response should consider:

Device → Identity → MFA → AWS Roles → Production Access → Credentials → Data


13. Data Breach Assessment

A lost or stolen asset does not automatically mean that a data breach has occurred.

Assess:

  1. What information was on or accessible through the asset?
  2. Was the information encrypted?
  3. Was the device protected by authentication?
  4. Could an unauthorized person access the information?
  5. Was the device remotely locked or wiped?
  6. Were credentials stored on the device?
  7. Could the device provide access to customer or production systems?
  8. What categories of personal or confidential information were involved?
  9. What jurisdictions and contractual requirements apply?
  10. Is regulatory, customer, or individual notification potentially required?

Assessment Result

☐ No evidence of information exposure

☐ Potential information exposure

☐ Confirmed information exposure

☐ Data breach assessment required

☐ Security incident escalated


14. Regulatory / Contractual Assessment

Where information may have been exposed, assess applicable:

  • Privacy requirements
  • Data protection requirements
  • Customer contracts
  • Supplier contracts
  • Regulatory obligations
  • Insurance requirements
  • Internal notification requirements

Record the assessment:

RequirementApplicable?Assessment / ActionOwnerDate

Notification decisions should be based on the applicable legal, regulatory, contractual, and organizational requirements.


15. Law Enforcement / Insurance

Where appropriate:

  • ☐ Police/law enforcement report filed
  • ☐ Report/reference number recorded
  • ☐ Insurance provider notified
  • ☐ Courier/shipping provider notified
  • ☐ Building/security team notified
  • ☐ Travel/hotel security notified
  • ☐ Supplier notified
OrganizationContacted DateReference No.Contact PersonStatus

16. Investigation

The investigation should establish, where possible:

  • When the asset was last known to be available
  • Where it was last seen
  • Who had custody
  • How it became lost or stolen
  • Whether unauthorized persons may have accessed it
  • What information was accessible
  • Whether credentials were exposed
  • What security controls were active
  • Whether logs provide useful evidence
  • Whether other assets/accounts may be affected

Evidence Collected

  • ☐ Device logs
  • ☐ MDM records
  • ☐ EDR records
  • ☐ Identity logs
  • ☐ VPN logs
  • ☐ Cloud logs
  • ☐ Physical security records
  • ☐ CCTV where applicable
  • ☐ Police report
  • ☐ Employee/contractor statement
  • ☐ Supplier statement
  • ☐ Other

17. Asset Recovery

If the asset is recovered:

  • ☐ Recovery date recorded
  • ☐ Physical condition checked
  • ☐ Chain of custody recorded where appropriate
  • ☐ Device isolated if compromise is suspected
  • ☐ Security inspection performed
  • ☐ Malware/security scan performed
  • ☐ Credentials reviewed
  • ☐ Device reimaged where required
  • ☐ Security configuration verified
  • ☐ Asset returned to service or retired
  • ☐ Asset register updated

Do not automatically reconnect a recovered device to production systems if compromise is suspected.


18. Replacement Asset

If the asset cannot be recovered:

FieldDetails
Replacement Asset ID
Asset Type
Assigned User
Issue Date
Security Configuration VerifiedYes / No
Previous Asset StatusLost / Stolen
Asset Register UpdatedYes / No

19. Corrective Actions

Identify actions required to prevent recurrence.

Action IDCorrective ActionReasonOwnerDue DateStatus

Possible actions:

  • Enable full-disk encryption
  • Improve device management
  • Enforce MFA
  • Implement conditional access
  • Reduce local data storage
  • Improve remote-wipe capability
  • Improve employee awareness
  • Update remote-working requirements
  • Review BYOD controls
  • Strengthen access controls
  • Rotate exposed credentials
  • Improve asset tracking
  • Update travel security guidance

20. Risk Register Update

Where the incident reveals a material or recurring risk:

  • ☐ Existing risk reviewed
  • ☐ New risk created
  • ☐ Risk score reassessed
  • ☐ Treatment plan updated
  • ☐ Control improvement identified
  • ☐ Risk owner notified
  • ☐ Management escalation completed where required
Risk IDRiskChange RequiredOwnerStatus

21. Incident Severity

The organization should classify severity according to its documented incident-management methodology.

SeverityExample
CriticalLost device with highly privileged production access or confirmed exposure of highly sensitive information
HighLost device with customer/confidential information or significant system access
MediumLost device with protected organizational information but strong controls limiting exposure
LowLost asset with little/no sensitive information and limited security impact

These categories are examples. The organization should define its own criteria based on business context and risk.


22. Final Incident Assessment

Asset Status

☐ Recovered

☐ Not Recovered

☐ Replaced

☐ Retired

Security Impact

☐ No significant security impact identified

☐ Potential security impact

☐ Confirmed security impact

☐ Security incident escalated

Data Impact

☐ No data exposure identified

☐ Potential data exposure

☐ Confirmed data exposure

☐ Privacy/data breach assessment completed

Corrective Action

☐ No additional action required

☐ Corrective actions completed

☐ Corrective actions remain open


23. Incident Closure Criteria

The incident may be closed when:

  • ☐ Asset status is known
  • ☐ Immediate containment completed
  • ☐ Relevant access revoked
  • ☐ Credentials/tokens addressed
  • ☐ Information exposure assessed
  • ☐ Regulatory/contractual assessment completed where applicable
  • ☐ Required notifications completed
  • ☐ Investigation completed
  • ☐ Evidence retained
  • ☐ Replacement/retirement completed where applicable
  • ☐ Corrective actions assigned
  • ☐ Risk register updated where required
  • ☐ Management/security review completed where required

24. Incident Closure Record

FieldDetails
Final Incident Status
Asset Status
Information Exposure
Data Breach Assessment
Notifications Required
Notifications Completed
Root Cause / Contributing Factors
Corrective Actions
Risk Register UpdatedYes / No / N/A
Lessons Learned CompletedYes / No
Closed By
Closure Date
Security Approval
Management Approval, if required

25. Lessons Learned

What happened?


What worked well?


What could be improved?


What control/process should change?


Training or awareness required?


Risk or control updates required?



26. Audit Evidence

Maintain relevant evidence such as:

  • Completed Lost/Stolen Asset Incident Form
  • Asset Inventory record
  • Employee/contractor report
  • IT/security ticket
  • Device management records
  • Remote lock/wipe evidence
  • IAM/SSO records
  • Cloud access records
  • Credential/token revocation records
  • EDR/security logs
  • Police report
  • Supplier/courier correspondence
  • Customer notification
  • Regulatory notification
  • Data breach assessment
  • Risk assessment
  • Corrective action records
  • Replacement asset record
  • Lessons-learned record

27. Roles and Responsibilities

Employee / Contractor

  • Report loss or theft immediately
  • Provide accurate incident details
  • Cooperate with investigation
  • Protect information and credentials
  • Follow security instructions

Manager

  • Confirm business impact
  • Coordinate with IT/Security
  • Support investigation
  • Confirm business continuity

IT

  • Secure the device
  • Disable/revoke access
  • Lock/wipe device where possible
  • Replace/reconfigure asset
  • Update asset records

Security / ISMS

  • Assess security impact
  • Coordinate incident response
  • Review information exposure
  • Coordinate breach assessment where required
  • Maintain incident evidence
  • Track corrective actions

Privacy / Legal / Compliance

  • Assess applicable legal and contractual obligations
  • Advise on notification requirements where applicable
  • Maintain regulatory records where required

Asset Owner

  • Confirm asset criticality
  • Confirm information stored/accessed
  • Support risk assessment
  • Approve recovery/replacement/retirement decisions

28. Relationship With Other ISMS Documents

This form should work together with:

  • Asset Inventory
  • Asset Ownership Register
  • Asset Lifecycle Management Procedure
  • Asset Return Checklist
  • IT Asset Handover Form
  • Employee Offboarding Checklist
  • Contractor Offboarding Checklist
  • Access Revocation Checklist
  • Information Classification Policy
  • Data Inventory
  • Acceptable Use Policy
  • Employee IT Usage Policy
  • Remote Working Policy
  • BYOD Policy
  • Access Control Policy
  • Incident Response Plan
  • Security Incident Management Procedure
  • Data Breach Response Procedure
  • Risk Assessment and Risk Register
  • Corrective Action Procedure

The overall relationship is:

Lost/Stolen Asset → Incident Report → Access Revocation → Information Exposure Assessment → Containment → Investigation → Recovery/Replacement → Corrective Action → Closure


29. Startup-Friendly Response

For a small SaaS company, the immediate response can be simple:

1. Report immediately
↓
2. Lock/Wipe the device
↓
3. Revoke user/cloud/VPN access
↓
4. Rotate exposed credentials
↓
5. Assess information exposure
↓
6. Determine breach/notification requirements
↓
7. Recover or replace asset
↓
8. Record evidence
↓
9. Review root cause
↓
10. Close and improve

For a lost laptop used by an AWS administrator, for example, the response should not stop at replacing the laptop. The organization should also review AWS access, IAM roles, credentials, MFA, tokens, SSH keys, production access, and relevant logs.


30. ISO 27001 Connection

Lost or stolen assets can affect multiple information-security processes, including:

  • Asset management
  • Information classification
  • Access control
  • Authentication information
  • Endpoint security
  • Remote working
  • Incident management
  • Data protection
  • Cloud security
  • Business continuity
  • Risk management
  • Corrective action and continual improvement

The exact controls applicable to the organization should be determined through its risk assessment and Statement of Applicability (SoA).


31. Final Audit Trail

An auditor should be able to select a lost/stolen asset incident and trace:

Incident Report
↓
Asset Identification
↓
Information & Risk Assessment
↓
Access Revocation / Containment
↓
Investigation
↓
Data Breach Assessment
↓
Recovery / Replacement
↓
Corrective Action
↓
Risk/Control Improvement
↓
Closure & Evidence

Final Principle

Report → Secure → Revoke → Assess → Contain → Investigate → Recover → Document → Learn → Improve

How can we help?

Leave a Reply

Your email address will not be published. Required fields are marked *