TL;DR
An incident response policy written from a template assumes intrusion, ransomware and forensics. The incident most companies actually have is a laptop that went missing, and the path for that is usually undescribed.
- Treat a missing device as an incident until assessed otherwise.
- Name one decision maker and a deputy, chosen for availability.
- Say reporting fast is expected and nobody is blamed for an honest loss.
- Encryption changes the assessment. It does not end it.
- Record the reasoning even when you decide not to report.
- Rehearse once a year. The failure is usually something mundane.
When a one page version is enough
Four stages, and the first is fine with very little.
A few people, no customer data. Write down who to tell and keep going. A full policy describes machinery you do not have.
Best tools for HR Operations
Holding customer or employee data. Now an incident has consequences beyond you. One page covering report, decide, contain and record is proportionate.
Remote staff with devices everywhere. Physical loss becomes the likely scenario rather than the exotic one, and the response depends on information you must have gathered beforehand.
Regulated, certified or contractually bound. You have notification obligations with clocks attached. The policy now has to be executable under time pressure by whoever is available.
Why an incident response policy skips the common case
Templates are written by security people describing security incidents. Intrusion, malware, data exfiltration. Those are the scenarios the discipline was built around and they are genuinely serious.
But they are not what most companies experience. A laptop is left in a taxi. A bag is stolen from a car. Somebody leaves and the machine never comes back. Each of those is a potential data incident and none of them looks like the thing the policy describes, so the person holding the problem does not recognise it as in scope.
That recognition failure is the whole issue. The response is not technically hard. The delay comes from somebody spending two days deciding whether a mislaid laptop is really an incident, and the clock on any notification obligation does not pause while they think.
Incident management expectations in ISO/IEC 27001 cover events affecting information in any form, and the incident handling guidance published by the National Institute of Standards and Technology is built around preparation rather than heroics. Preparation here means deciding, in advance, that a missing device counts.
The five clauses worth writing
- What counts. A short list in plain words that explicitly includes a lost, stolen or unreturned device. Ambiguity here costs days.
- How to report. One route, available out of hours, with a stated expectation of hours rather than days.
- Who decides. A named person and a named deputy. Availability beats seniority.
- Immediate actions. What happens in the first hour: suspend sessions, attempt remote wipe, confirm encryption status, start the record.
- The assessment and its record. What was on the device, what controls applied, the reportability decision and the reasoning, kept whichever way it goes.
Five clauses on one page. If somebody cannot follow yours at nine on a Friday evening, it is a description rather than a procedure.
Five questions before you draft
Could you prove a specific laptop was encrypted? That record is made at issue or not at all, and it is the first thing you will want.
Who takes the call at the weekend? If the answer is a shared inbox, the answer is nobody.
Do you know what people store locally? Ask one person to look. The policy assumes you know and usually you do not.
What is your notification clock? It depends on jurisdiction and contract, and it is worth knowing before the day you need it.
When did you last talk one through? Thirty minutes a year finds the mundane gap that would otherwise cost you a day.
How teams prepare, and the trade-offs
A one page plan in the handbook. Best for small teams and far better than nothing. It struggles under pressure, because a page nobody has read is not a plan, it is a document.
Device management with remote wipe. Best for the laptop that is still online and genuinely closes many cases. It struggles with a machine never powered on again, which is the scenario you most need covered.
Full disk encryption plus evidence. Best value of anything here, because it changes the assessment itself. It struggles only when you cannot demonstrate it applied to the specific device, which is a record problem rather than a control problem.
An external incident retainer. Best for genuine intrusion and worth having above a certain size. It struggles on proportionality for a mislaid laptop, where you mostly need your own records rather than a forensics team.
A recovery route for unreturned devices. Disclosure: RemoAsset is owned by the same people who publish this site. It handles retrieval and certified wiping across 80 or more countries, which matters because an unreturned laptop is an open incident until it is recovered or written off deliberately. Where it struggles: it is not an incident response service and will not assess reportability, notify a regulator or investigate anything. The narrow part it covers is turning an unrecovered device into a recovered and wiped one.
The decision table
| Situation | Scale | Setup | Primary pain | Recommended starting point |
|---|---|---|---|---|
| Few people, no customer data | Under 15 | No owner | Little at stake | Who to tell, written down |
| Holding personal data | 15 to 50 | Part time owner | Nobody calls it | Define what counts as an incident |
| Remote staff, devices out | 50 plus | IT owner | Physical loss likely | Write the lost device path |
| Cannot prove encryption | Any | Any | Assessment impossible | Record encryption at issue |
| Notification obligations | Any | Legal owner | Clock starts at loss | Name the decision maker |
| Unreturned devices open | Any | Any | Incidents never close | Recover, or close deliberately |
What an untested policy costs
The first cost is the delay before anybody acts. Somebody loses a laptop on Thursday, mentions it on Monday because they were embarrassed, and a manager spends two more days deciding whether it matters. Four days gone, and nothing about the policy prevented any of it.
The second is the assessment you cannot complete. Asked what was on the device, a team with no record of local storage guesses, and the guess is what goes into the file. That file is the thing that gets read later, by somebody with more time than you had.
The third is the unprovable control. You believe every laptop is encrypted. Showing that this specific machine was, on the date it went missing, requires a record somebody had to create when it was issued. Without it, your strongest mitigating factor is an assertion.
The fourth is the incident that never closes. An unreturned device from a leaver eighteen months ago is still, technically, an open exposure. Nobody tracks it as one because it arrived through offboarding rather than through the incident process, so it sits outside both.
So the useful question is not whether you have an incident response policy. It is what would actually happen if somebody messaged at seven tonight to say their work laptop was stolen an hour ago.
The records you need before the incident
Almost everything that makes a lost device response go well was created months earlier. The policy cannot generate it on the day.
Three records carry most of the weight. Which device that person held, by serial. Whether it was encrypted, recorded at issue rather than assumed. And what the device management system last reported about it. If those exist, the assessment takes an hour. If they do not, it takes a week and ends in a guess.
The same records are what let you close out the slow version of this incident, the unreturned laptop. Without them you cannot even say which devices are currently unaccounted for, which means you cannot tell an open exposure from a closed one.
It is worth checking before you rewrite anything, because the drafting is the easy half. Seeing how device records are held against people and serials shows what the response path actually depends on.
See how device state is recorded against each person
Read our guide to unreturned equipment
Related reading
- The information security policy
- Unreturned equipment
- The data protection policy
- The access control policy
- Evidencing equipment compliance
Frequently Asked Questions
What should an incident response policy cover?
How an incident is reported, who decides it is one, who leads, how it is contained and recorded, and when it has to be escalated externally. For a small company the hardest of those is the second, because somebody has to call it before anybody will act.
Is a lost laptop an incident?
Treat it as one until shown otherwise. Whether it becomes reportable depends on encryption, on what was stored locally and on your jurisdiction, but the assessment has to happen and it has to start fast. Treating it as a hardware matter is how the clock gets lost.
How quickly should somebody report one?
Within hours, and the policy should say so in plain language with a route that works out of hours. People delay because they feel at fault, so the wording matters: make clear that reporting fast is the expected behaviour and that nobody is penalised for an honest loss.
Does encryption mean it is not reportable?
It changes the assessment substantially but does not answer it for you, and the position differs by jurisdiction and by the data involved. You also have to be able to demonstrate the device was encrypted, which is a record you either kept at issue or do not have now.
Who should lead a small company’s response?
One named person with a named deputy, chosen for availability rather than seniority. The most common failure in small teams is not a bad decision; it is that nobody believed it was their call to make, so nothing happened for two days.
What has to be recorded?
What happened, when it was reported, what was on the device, what you did and when, and the reasoning behind the reportability decision. Record the reasoning even when you decide not to report, because the decision you cannot explain later is the one that causes problems.
Should we practise it?
Once a year, with a thirty minute walkthrough rather than a full exercise. Use a plausible scenario such as a laptop left on a train and talk through it. Most policies fail on something mundane, like nobody knowing the out of hours number, and a short rehearsal finds that.
