Incident response plan: the first hour decided in advance

An incident response plan sets out what happens when something goes wrong with your systems or data: who leads, how severity is judged, what is done first, who must be told and by when. Its purpose is narrow and important — to remove decisions from the worst possible moment to make them, which is while the incident is running and everyone is anxious.

The plan does not need to cover every kind of incident. Most small companies face a short list: an account compromised, ransomware or malware, data sent to the wrong recipient, a supplier breached, an outage of something customers depend on. Write for those.

What the plan must decide in advance

• What counts as an incident, and severity levels defined in consequences rather than adjectives — customers affected, data involved, service unavailable.
• Who leads. One named role with a deputy, empowered to make decisions including spending money.
• Who communicates, internally and externally. Not the same person as the one leading the technical work.
• Who records what happens, with timestamps. This is a real job and it is always forgotten.
• How anyone reports a suspected incident — one route, known to everyone, that works out of hours.
• Immediate containment actions per scenario, with the authority to take them without waiting for approval.
• Notification obligations and their deadlines, which in many jurisdictions are measured in hours for personal data breaches.
• Who to call outside the company: your IT provider, your insurer, a lawyer, and — where required — the regulator.
• How you decide the incident is over, and who says so.
• The post-incident review: when, who attends, and that its purpose is causes rather than blame.

Find out your notification deadlines before you need them. Many data-protection regimes require notifying a regulator within a short fixed window of becoming aware of a personal-data breach, and contracts often impose their own, shorter obligations to notify customers. These are jurisdiction- and contract-specific — establish yours in advance and write them into the plan, because working them out during an incident is how deadlines get missed.

Writing it so it works under pressure

1. Keep it to two pages plus contacts. Nobody reads more at 2am.
2. Define severity by consequence, and put the definition where the responder sees it.
3. Write the first-hour actions as a checklist per scenario, in order, in the imperative.
4. Give explicit pre-authorisation for containment — disconnecting a machine, disabling an account, taking a service offline — so nobody hesitates waiting for permission.
5. Include the contact list, and keep a copy reachable when your systems are not.
6. Say what not to do: do not wipe the machine, do not delete the phishing email, do not discuss it publicly before the communication is agreed. Preserving evidence matters and instinct runs the other way.
7. Prepare holding statements for staff and customers now, when you can choose the words calmly.
8. Test it as a tabletop once a year, and after any real incident hold the review within a week.
9. Review annually and whenever your systems or obligations change.

The record is part of the response

Someone should be writing down what happened and when, from the first minute: what was observed, what was decided, who was told, what was changed. It matters for three reasons — regulators and insurers ask for a timeline, the post-incident review is worthless without one, and memory reconstructs events wrongly under stress. It is a boring job that nobody volunteers for, which is why the plan should name the role rather than hope someone starts.

In Ettex, the plan itself lives in Ettex Docs — two pages with version history, threaded comments while it is agreed, and a share link so it is reachable rather than buried. The incident log is a table in Ettex Records: timestamp, observation, decision, who was notified, all with revision history so the record itself is auditable. Contacts sit in Ettex Contacts and should be exported to a copy outside your systems, holding statements are drafted in advance in Ettex Docs, and Ettex Chat carries the internal coordination as long as the incident does not affect it — which is exactly why the contact list must also exist offline.

The boundary, plainly: Ettex is not a security product. There is no monitoring, detection, alerting or paging, no SIEM, no forensics, no on-call rota, and nothing here will tell you an incident is happening. It holds the plan, the log and the contacts. Detection and technical response come from your IT provider or security tooling — and if your plan depends on Ettex being available, keep an offline copy.

Where response goes wrong

• No named lead, so the first hour is spent deciding who is in charge.
• Severity defined with adjectives, which produces argument instead of action.
• Containment delayed while someone seeks permission nobody had pre-granted.
• Notification deadlines discovered mid-incident, after they have started running.
• Evidence destroyed by instinct — machines wiped, emails deleted — before anyone looked.
• Communication improvised, producing statements that later have to be corrected.
• No timeline kept, so the review and any regulatory account are reconstructed from memory.
• Post-incident review skipped because everyone is exhausted, which guarantees the same incident twice.

An incident response plan is two pages that remove decisions from the worst moment: who leads, what severity means, what to do in the first hour, who to tell and by when. Write it calmly, keep it reachable offline, and rehearse it once a year.