Missing Bag, Calm Hands: The Lost-Laptop Routine for Teams With No Helpdesk
It is 19:05 on a wet Tuesday. Someone from your team is standing on a platform, bag open, doing the pat-down that never works. The 18:42 has gone. So, possibly, has a laptop.
The instinct is either to panic or to promise that it will all be fine. Neither is a procedure. What you need is a short routine you have already walked through once, so the first time is not the real time. No blame, no heroics, no assuming the device is definitely in lost property.
First, name the situation
A missing device is not one event. It is at least three: left behind, lost, or stolen. The response overlaps, but the evidence trail does not.
If it was left on a train, contact the train operator’s lost property team and the station as soon as you can. Keep the case reference. If it was taken from a bag or a table, report it to the police and get a crime reference number. Do not go looking for the device yourself, and do not send a junior member of staff to confront anyone. That is not a security control.
Write down the time the loss was noticed, who noticed it, the device asset tag or serial number, and the last known location. If the device is a phone, note the IMEI. This sounds bureaucratic. It is actually the difference between a calm update and a messy scramble three days later.
Freeze access before you chase the hardware
Your first job is not the laptop. It is the account on the laptop.
Disable the user’s sign-in, revoke active sessions, reset the password and check for any new MFA methods or forwarding rules. If you use Microsoft 365 or Google Workspace, this is a ten-minute job once you know where the buttons are. If you do not know where the buttons are, that is the real finding.
For a phone, use Find My on iPhone or Find Hub on Android to lock the device and view its last location. Take screenshots of anything useful: location, time, battery level, lock status. Then stop refreshing the page every thirty seconds. Location data is evidence, not a live show.
If you have an MDM tool, use it to mark the device as lost, force a lock and check whether encryption and passcode policies are actually switched on. A remote wipe command is not a magic spell. It only lands when the device next connects.
Wipe or preserve? Usually both, in the right order
A remote wipe is a response, not a reflex. If the device is encrypted and locked, the immediate data risk is lower than the noise suggests. That does not make it zero. It does mean you can take fifteen minutes to capture the facts before you pull the plug.
Preserve the timeline, the asset record, the encryption status and any location screenshots. If the police are involved, ask them whether they want the device left alone if it turns up. If client data is on the device and you believe it could be accessed, wiping is usually the safer call. If the device is sitting in lost property and encrypted, you may have room to collect it instead. Make that a decision, not a mood.
Document why you chose to wipe or not wipe. That note will matter more than you think if the incident later needs to be explained to a client, an insurer or the Information Commissioner’s Office.
The UK reporting question
Under UK GDPR, a personal data breach that is likely to result in a risk to people’s rights and freedoms must be reported to the ICO within 72 hours of becoming aware of it. A lost encrypted laptop with no evidence of access may not meet that threshold. A lost unencrypted laptop with client records on it probably does. You do not have to make that call alone in your head at 21:00.
Use a simple decision record: what personal data was on the device, was it encrypted, was the account locked, is there any sign of access, who could be affected, and what is the likely harm? If the answer is ‘we are not sure’, treat it as a serious possibility and get advice. The ICO’s own guidance and small-business helpline are there for exactly this kind of moment. Keep your reasoning either way.
A client message you can send before you need it
Write this now, save it as a template, and agree who is allowed to send it. Something like:
Quick update: one of our work laptops was left on a train this evening. We have locked the account, revoked active sessions and started the remote-wipe process. The device was encrypted and protected by a passcode. At this stage we have no evidence that client data has been accessed. We are treating it as a security incident and will update you by [time] tomorrow. If you see anything unusual, please reply to this email or call [number].
That message does three useful things. It shows control, it avoids overpromising, and it gives the client a route to ask questions. It also stops five different people inventing five different versions.
Send a shorter internal note too: what happened, what is being done, who is leading it, and where to send questions. Do not turn it into a blame email. The person who lost the laptop already knows.
The fifteen-minute test that proves it works
This is the part most small teams skip. Remote wipe and encryption are lovely ideas until you discover the MDM agent was never enrolled, the recovery key is in a spreadsheet nobody can open, or the backup has not run since March.
Once a quarter, take a spare or test device and do this:
- Confirm encryption is on. On Windows, check BitLocker status. On a Mac, run
fdesetup status. On phones, confirm a passcode is set and the OS is current. - Send a remote lock from your MDM or device management console. Time how long it takes to apply.
- On a test device with no real data, send a remote wipe. Confirm the command queues and completes when the device is online.
- Restore one file from backup to prove the backup is not decorative.
- Write down who holds admin rights, who has the recovery keys and who to call out of hours.
Fifteen minutes. One named incident lead. One backup. That is the whole service desk you need for this particular scenario.
After the bag comes back
If the device turns up, do not just hand it back and move on. Treat it as untrusted until it has been checked. Preserve the logs, review sign-in activity, replace the device if there is any doubt, and update the asset register.
Then do the least glamorous thing of all: read your own runbook. If a step was missing, add it. If a password was in the wrong place, fix it. If the client message sounded cold, rewrite it. The 18:42 will run again tomorrow. Your job is to make sure the next missing bag is a procedure, not a panic.
