Incident response plan for a small business: one page is enough
When something goes wrong you should not be improvising. One page for a small business: who does what, in what order, rehearsed once a year.
The short answer
When a website is hacked, an email account is taken over or a key leaks, the first hour decides much of the damage, and it gets spent finding out who has the passwords. An incident response plan replaces that hour of improvisation with a page written in advance: who does what, whom to call, the first six actions in order, where the evidence and access live, who is told what and when, and how the incident is closed. One page is enough. Its value is decided before the incident, by whether the names are current, the access works and the page can be found when the systems it describes are down.
The one page
| Section | Contents |
|---|---|
| Roles | Incident owner, deputy, technical lead (usually your partner), communications, decision maker for money and legal |
| Contacts | Phone numbers for all roles, the partner’s escalation contact, hosting and registrar support, insurer, legal or privacy advisor, bank |
| Severity | Three levels with examples: critical (data exposed, site serving malware, payments affected), high (compromise contained, no known exposure), medium (suspicious activity, no confirmed compromise) |
| First six actions | Contain, preserve evidence, assess scope, decide communications, restore from clean, rotate all access |
| Where things are | The setup document, the password manager, backups and how to restore, logs and monitoring dashboards |
| Communication | Who tells staff, customers, partners, authorities, and when; the templates for each; who is the only voice externally |
| Legal and notification | What triggers a data breach notification obligation, the deadline, and who decides; check with a privacy specialist for your jurisdiction |
| Closing | Post-incident review within a week: timeline, cause, what changes, who owns each change |
The first six actions, always in this order
- Contain. Take the compromised system offline or behind a holding page; disable the compromised account; revoke the leaked key. Stop the bleeding before understanding it fully.
- Preserve evidence. Copy logs, take snapshots, note times. Do not wipe or reinstall yet; you will need to know how they got in.
- Assess scope. What was accessed, changed or taken? Which systems and accounts are connected to the compromised one?
- Decide communications. Based on scope: who needs to know now, and whether a notification obligation is triggered. One external voice.
- Restore from a known-clean state. Backup from before the compromise, or a clean rebuild. Close the entry point before going back online.
- Rotate all access. Every credential the compromised system touched, and two-factor on everything that lacked it.
Writing it in an hour
Fill in the table above with real names and numbers. Ask your partner for their on-call arrangement and the restore procedure, and link the setup document. Decide the external voice. Check with a privacy specialist what notification obligations apply to your data and write the trigger and deadline on the page. Print it, store it, put the yearly tabletop in the calendar. Then update it whenever a name or a system changes, which is the owner’s job.
What this means for you
One page, written in an hour, reachable when everything is down, rehearsed once a year. It turns the worst hour of a bad day into a sequence people follow instead of a scramble for passwords. If you have a partner, they will help write it and hold the technical role. If you do not have the page, write it this week; the incident does not wait for the plan.
Frequently asked questions
We are five people. Do we really need an incident plan?
You need one page that says who does what when the site is hacked or the email is compromised, because on that day five people will otherwise be asking each other for passwords. The plan is the conversation you would have anyway, held in advance and written down. It takes an hour to write and saves the first, most expensive hour of the incident.
What counts as an incident?
Anything that compromises the confidentiality, integrity or availability of your systems or data: a hacked website, a compromised email account, a lost laptop with access, a leaked key, a ransomware note, a data exposure. The plan's first step is to classify severity, and the same page handles all of them.
Who should own the plan?
One named person inside the business, with a deputy, and your partner as the technical lead. The owner keeps the page current, the deputy can act when the owner is away, and the partner has the access and the monitoring. Ownership is the difference between a plan and a document.
Sources
- NCSC-NL: Incidentresponsplan (Nederlandstalig) (accessed 2026-09-14)