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
| Field | Details |
|---|---|
| Incident ID | |
| Date Reported | |
| Time Reported | |
| Reported By | |
| Employee/Contractor ID | |
| Department | |
| Manager | |
| Asset Owner | |
| IT/Security Owner | |
| Incident Type | Lost / Stolen / Misplaced |
| Date/Time Lost or Stolen | |
| Location | |
| Discovery Date/Time | |
| Current Status | Open / Investigating / Contained / Closed |
| Initial Severity | Low / 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
| Field | Details |
|---|---|
| Asset ID | |
| Asset Type | Laptop / 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 Classification | Public / Internal / Confidential / Restricted |
| Asset Criticality | Low / 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
| Field | Details |
|---|---|
| Last Known Location | |
| Date/Time Last Seen | |
| Person Last in Possession | |
| Location Type | Office / 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 Control | Status | Evidence / Remarks |
|---|---|---|
| Full-disk encryption | Yes / No / Unknown | |
| Screen lock | Yes / No / Unknown | |
| Strong authentication | Yes / No / Unknown | |
| MFA | Yes / No / Unknown | |
| Endpoint protection | Yes / No / Unknown | |
| Device management | Yes / No / Unknown | |
| Remote lock | Yes / No / Unknown | |
| Remote wipe | Yes / No / Unknown | |
| VPN | Yes / No / Unknown | |
| Data Loss Prevention | Yes / No / Unknown | |
| Local data storage | Yes / No / Unknown | |
| Automatic backup | Yes / 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:
- What information was on or accessible through the asset?
- Was the information encrypted?
- Was the device protected by authentication?
- Could an unauthorized person access the information?
- Was the device remotely locked or wiped?
- Were credentials stored on the device?
- Could the device provide access to customer or production systems?
- What categories of personal or confidential information were involved?
- What jurisdictions and contractual requirements apply?
- 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:
| Requirement | Applicable? | Assessment / Action | Owner | Date |
|---|---|---|---|---|
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
| Organization | Contacted Date | Reference No. | Contact Person | Status |
|---|---|---|---|---|
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:
| Field | Details |
|---|---|
| Replacement Asset ID | |
| Asset Type | |
| Assigned User | |
| Issue Date | |
| Security Configuration Verified | Yes / No |
| Previous Asset Status | Lost / Stolen |
| Asset Register Updated | Yes / No |
19. Corrective Actions
Identify actions required to prevent recurrence.
| Action ID | Corrective Action | Reason | Owner | Due Date | Status |
|---|---|---|---|---|---|
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 ID | Risk | Change Required | Owner | Status |
|---|---|---|---|---|
21. Incident Severity
The organization should classify severity according to its documented incident-management methodology.
| Severity | Example |
|---|---|
| Critical | Lost device with highly privileged production access or confirmed exposure of highly sensitive information |
| High | Lost device with customer/confidential information or significant system access |
| Medium | Lost device with protected organizational information but strong controls limiting exposure |
| Low | Lost 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
| Field | Details |
|---|---|
| Final Incident Status | |
| Asset Status | |
| Information Exposure | |
| Data Breach Assessment | |
| Notifications Required | |
| Notifications Completed | |
| Root Cause / Contributing Factors | |
| Corrective Actions | |
| Risk Register Updated | Yes / No / N/A |
| Lessons Learned Completed | Yes / 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
