TL;DR
Somebody messages at nine on a Saturday to say their laptop is gone. What happens in the next few hours decides whether a lost or stolen laptop is an inconvenience or an incident. The order of the steps matters more than the speed of any one of them, and the step people get wrong is the first.
- Revoke sessions before you lock the device. Accounts travel further than hardware.
- Write down what was on it while the person still remembers.
- Report it to the police if stolen. Insurance and records both need the reference.
- Encryption changes the assessment. Evidence of it changes it more.
- Get them working again the same week, or they will improvise.
- Notification duties differ by jurisdiction. Have the contact ready in advance.
The first hour after a lost or stolen laptop
Five steps, and the order is the part that gets reversed.
| Order | Step | Why it is here |
|---|---|---|
| 1 | Revoke active sessions and rotate credentials | Access is the real exposure |
| 2 | Lock or wipe the device remotely | Only works if it connects |
| 3 | Record what was on it | Memory fades within a day |
| 4 | Report to police if stolen | Needed for insurance and records |
| 5 | Get the person working again | Prevents improvised workarounds |
Why sessions come before the device
Because a remote lock only reaches a machine that comes online, and somebody who took a laptop deliberately is not going to connect it to the internet with your management agent running.
Active sessions, refresh tokens and saved credentials do not need the device to be online to be useful to somebody. Revoking them works immediately and does not depend on the hardware cooperating.
Teams that lock first and revoke an hour later have spent that hour protecting the part that was never the exposure. Incident handling guidance such as NIST Special Publication 800-61 on computer security incident handling makes the same general point about containment: act on what you control, not on what you hope to reach.
Then try the device anyway
Lock and wipe commands are worth issuing even with low expectations, because a genuinely lost machine often does come online when somebody finds it and opens the lid.
Queue the command and leave it queued. It costs nothing and occasionally works.
Write down what was on it, today
This is the step that gets skipped and the one that matters most a month later, when somebody asks what was exposed and nobody can answer.
Ask the person directly, the same day, while it is fresh. Four questions.
- What was saved locally rather than in synced folders or cloud services.
- What was logged in, including anything with a saved password in the browser.
- Any customer or personal data, including exports, spreadsheets and attachments.
- Anything downloaded recently for a specific piece of work, which is where the surprises live.
Write the answers down in the incident record, dated. A week later the recollection will be vaguer and more optimistic, which is human and unhelpful.
Encryption is the assessment, and evidence of it is the point
A machine with full disk encryption enabled and a strong credential is a very different situation from one without, and the difference usually determines how the rest of the week goes.
The useful word there is evidence. Believing a device was encrypted is not the same as being able to show the enrolment record proving it was, which is why the UK National Cyber Security Centre device security guidance treats the recorded management state as the control rather than the intention. If your management platform can produce a report showing that device’s encryption status on the day before it went missing, you have something to stand on. If it cannot, you are guessing in a conversation where guessing is expensive.
Check that you can produce that report before you need it. It takes ten minutes now and it is unobtainable during an incident.
Who to tell, and what not to decide yourself
Disclosure: RemoAsset, named below, is owned by the same people who publish PeopleOpsHQ. It is described with its limitations stated, on the same terms as every other supplier. This site takes no vendor money.
Three audiences, and only the first is automatic.
The person’s manager, immediately, because they will need to cover work and because the person reporting this is usually embarrassed and needs somebody on their side.
Whoever owns security or legal in your company, same day, with the record from the previous section attached. If that is nobody, it is the founder, and this is the moment to notice that gap.
Regulators or affected individuals, where that applies. This is the decision not to make alone and not to make quickly from a blog post, including this one.
Why this article will not tell you whether to report it
Because the answer depends on the jurisdiction, the data, the circumstances and the specific arrangement, and anybody giving you a general rule is giving you a rule that is wrong somewhere.
What is useful is knowing where the published position lives and having the contact ready. Where European personal data is involved, the obligations sit in the consolidated text of the General Data Protection Regulation itself, and supervisory authorities publish their own practical guidance, such as the UK Information Commissioner guidance on reporting a personal data breach in the United Kingdom. Read those with your own counsel, in advance, and write down who makes the call.
The failure mode worth avoiding is not under-reporting or over-reporting. It is reaching the decision point with nobody named to make it, on a Saturday.
Prepare the one page before you need it
A single page with four things on it: who to contact in each jurisdiction you employ in, who decides, where the incident record lives, and the police reporting route per country. Written once, reviewed yearly.
Nobody writes this page during an incident. Everybody wishes they had.
Keep it with the rest of your incident material rather than in a security folder nobody opens, and name a deputy for every decision on it. A lost or stolen laptop does not wait for the one person who knows the answer to come back from leave.
The decision table
| Situation | Scale | Setup | Primary pain | Recommended starting point |
|---|---|---|---|---|
| Left in a taxi, encrypted, enrolled | Any | MDM with reporting | Replacement speed | Revoke, queue wipe, ship a replacement |
| Stolen, encryption unproven | Any | No enrolment evidence | Cannot assess exposure | Treat as exposed, escalate same day |
| Missing, not clear when | Any | Weak register | No known timeline | Record what is known, do not guess dates |
| Customer data on the device | Any | Local exports common | Notification decision | Legal owns the call, you own the facts |
| Happens repeatedly | 100 plus | Heavy travel | Pattern, not incident | Reduce local storage, not travel |
Get them working again this week
The security steps get attention and this one does not, which is backwards, because a person without a working machine for three weeks improvises, and the improvisation is the next incident.
They will borrow a family computer, work from a phone, email files to a personal address, or buy something themselves and claim it later. All four are worse than the original loss.
So treat the replacement as part of the incident response rather than as a separate procurement ticket. Two things make that possible.
A spare, or a supplier who can ship fast. Holding one or two machines against a fleet of a hundred is cheap insurance, and for distributed teams a supplier who can get a configured device to an address in days is the equivalent. Procurement and delivery of a configured machine to a named address is the mechanism; the limitation worth stating is that lead times vary by country, so ask what yours are before the week you need them.
A rebuild that does not need the old machine. If getting somebody productive depends on anything that only existed locally, the loss of a laptop becomes the loss of work. That is a backup and tooling question, and it is worth testing deliberately rather than discovering during an incident.
Do not charge them for it
Some companies deduct the cost, formally or informally. It reliably produces the one outcome you most want to avoid, which is people not reporting losses promptly.
An hour of delay in revoking sessions costs more than the laptop. Make reporting free, say so out loud, and treat repeated carelessness as a management conversation rather than a billing one.
Then look for the pattern
One loss is an event. Four in a year among a team that travels constantly is a design problem, and the fix is reducing what sits locally on travelling machines rather than reducing travel.
Where a machine is eventually recovered, it still needs handling before reuse: a documented wipe against a standard such as NIST Special Publication 800-88 on media sanitization rather than a quick reset, because you no longer know what happened to it. Our guide to kit for conferences and offsites covers the travelling case that produces most of these events in the first place.
See how a replacement reaches somebody in days at equipment procurement and delivery to a named address, or read our guide to event and offsite kit.
Frequently asked questions
What is the first thing to do?
Revoke active sessions and rotate credentials, before touching the device. A remote lock only reaches a machine that comes online, and anybody who took a laptop deliberately will not connect it with your management agent running. Sessions, refresh tokens and saved credentials do not need the hardware to cooperate, so acting on them works immediately.
Should we still try to lock or wipe it?
Yes, with low expectations. Queue the command and leave it queued, because a genuinely lost machine often does come online when somebody finds it and opens the lid. It costs nothing and occasionally works. Just do not let it be step one, since the hour spent waiting for it is an hour not spent on the access that was the real exposure.
Why record what was on the device?
Because a month later somebody will ask what was exposed and nobody will remember. Ask the person the same day what was saved locally rather than synced, what was logged in with a saved password, whether any customer or personal data was on it, and what was downloaded recently for a specific job. Write the answers in the incident record, dated.
How much does encryption change things?
A great deal, and evidence of it changes things more than the encryption itself. Believing a device was encrypted is not the same as producing the enrolment record showing its status the day before it went missing. Check that your management platform can generate that report before you need it, because it takes ten minutes now and is unobtainable during an incident.
Do we have to notify a regulator?
That depends on the jurisdiction, the data and the circumstances, and any general rule is wrong somewhere, so it is not a decision to take from an article. What helps is knowing where the published obligations live and having the contact ready in advance. Read them with your own counsel, and write down in advance who makes the call.
Should the person pay for the replacement?
No. Charging for losses, formally or informally, reliably produces the one outcome you most want to avoid, which is people delaying the report. An hour of delay in revoking sessions costs more than the laptop. Make reporting free, say so out loud, and handle repeated carelessness as a management conversation rather than a billing one.
What if it keeps happening?
One loss is an event and four in a year among a team that travels constantly is a design problem. The fix is reducing what sits locally on travelling machines rather than reducing travel, because the exposure comes from local storage and saved credentials. Event and conference equipment produces a disproportionate share of these, which is where to look first.
PeopleOpsHQ covers the operational side of distributed work. We describe suppliers with their limitations stated, and we take no vendor money.
