An incident response plan is a short written guide that tells your team what to do when something goes wrong, such as an outage, a payment failure, a data breach or ransomware. It names who leads, who communicates, how to contain the problem and how to recover, then review it. A plan written calmly beforehand saves precious time when you are under pressure.
Key takeaways
- An incident is any event that threatens the availability, integrity or confidentiality of your systems or data, or your ability to serve customers.
- The lifecycle is detect, triage, contain, eradicate, recover and review. Each step has a purpose.
- Name an incident lead, a technical lead, a communications owner and a decision maker, and keep a contact tree that works outside office hours.
- Keep a first-hour checklist and preserve evidence before you start deleting or rebuilding things.
- Communicate honestly and promptly. Legal duties after a breach vary by country and sector, so take qualified legal advice in advance.
- Practise with a tabletop exercise, and hold a blameless review after every real incident.
What counts as an incident?
Not every glitch is an incident, but these usually are:
- Site or app down. Customers cannot reach your service, or it is so slow that it is unusable.
- Payment failures. Checkout errors or a payment provider problem that stops sales.
- Data breach. Customer, staff or business data seen or taken by someone who should not have it.
- Ransomware or malware. Files locked or systems behaving strangely, often with a demand.
- Account takeover. An attacker controlling an email, admin, hosting or social account.
- Accidental loss. A deleted database or a misconfigured storage bucket exposing files.
Write your own list so that staff know that reporting early is encouraged.
What are the stages of the incident response lifecycle?
- Detect. Spot the problem through monitoring alerts, customer reports or staff noticing something odd. Good monitoring and observability shortens this stage.
- Triage. Decide what happened, what is affected and how serious it is. Assign a severity level.
- Contain. Limit the damage. Isolate infected machines, disable compromised accounts, block malicious traffic or switch off a failing feature.
- Eradicate. Remove the cause: delete malware, close the vulnerability, rotate stolen credentials.
- Recover. Restore services and data from clean sources, test carefully and bring systems back in a controlled order.
- Review. Learn what happened and fix the weaknesses so it is less likely to recur.
Skipping containment and eradication is how problems come back an hour later.
Who does what: roles and a contact tree
Even a business of five people needs named roles. One person can hold several, but each must be covered.
- Incident lead: coordinates the response, keeps a timeline and makes sure tasks are owned.
- Technical lead: investigates, contains and recovers. This may be an in-house developer or your external provider.
- Communications owner: writes customer, staff and public updates, and answers enquiries.
- Decision maker: has authority to take services offline, spend money, call lawyers or notify authorities.
- Scribe: records times, actions and decisions as they happen.
Build a contact tree: who is called first, who is next and who covers if someone is unreachable. Include mobile numbers, hosting, domain and payment provider support routes, your insurer if you have cover, and a lawyer. Keep a printed copy, because email might be the thing that is down.
How do you set severity levels without numbers?
Use plain-language levels tied to impact, not to guesswork about technical detail:
- Low: a minor problem with a workaround. Fix in working hours.
- Medium: a noticeable problem affecting some customers or one function. Respond promptly.
- High: a major outage, a payment problem or suspected data exposure. Start the full plan now, including out-of-hours contact.
- Critical: active attack, confirmed data loss or theft, or the whole business unable to operate. Everyone listed in the contact tree is alerted and the decision maker is in the room.
When in doubt, rate it higher at first and lower it later.
What goes in a first-hour checklist?
Print this and adapt it:
- Confirm the incident and note the time it was noticed.
- Alert the incident lead and open a dedicated channel or call for the response.
- Assign the roles above.
- Rate the severity.
- Contain: disconnect affected devices, disable suspect accounts, pause the affected feature. Change passwords from a clean device.
- Preserve evidence (see below) before cleaning up.
- Check whether data is involved and, if so, what kind.
- Decide on first communications to staff and customers.
- Contact your provider, insurer or specialists if the plan says to.
- Set a time for the next status update, and keep to it.
How do you preserve evidence?
If there may be a breach or crime, careful handling matters:
- Do not wipe or rebuild affected systems until you have saved logs, disk images or snapshots as advised by your technical lead or a forensic specialist.
- Record timelines, screenshots, ticket numbers and who did what.
- Keep logs somewhere an attacker cannot alter them, and restrict who can access the evidence.
What should you tell customers and regulators?
Customers and staff
Be prompt, plain and honest. Say what happened as far as you know, what is affected, what you are doing, what they should do (for example, change a password) and when you will update them next. Do not speculate, blame or promise what you cannot deliver.
Regulators and legal duties
Duties to notify authorities, customers or partners after a breach differ by country, state and sector, and they change over time. Contracts and insurance policies may add their own obligations. Do not guess. Identify a qualified legal adviser in advance, ask them what applies to your business and record the answer in your plan, so that you are not researching it mid-crisis. Our guide to cookie consent and privacy policies is a useful companion for the data-handling side.
Status page
A simple status page, hosted away from your main systems, lets customers check for updates. Post short, timestamped updates, even when the update is "still investigating".
How do backups fit in?
Recovery is only as good as your backups. Know where they are, who can restore them, how long a restore takes and whether you have tested it. Keep at least one copy that an attacker with your admin password cannot delete. Write a short restore runbook with the order in which systems come back. Our guide to a backup and disaster recovery plan for small businesses covers this in detail.
What is a blameless post-incident review?
Within a few days of resolution, meet to answer:
- What happened, in time order?
- How did we notice, and could we have noticed sooner?
- What worked well, and what slowed us down?
- What was the root cause, and what contributed to it?
- What changes will prevent or reduce a repeat, and who owns each one?
Blameless does not mean consequence-free. It means you look at processes and conditions, not at the individual who clicked the link. People hide mistakes in blame cultures, and that makes the next incident worse. Training helps as well; see employee cybersecurity awareness and phishing defence.
How do you practise the plan?
Run a tabletop exercise once in a while. Gather the people in the contact tree, describe a made-up scenario, such as "customer data found on a public web page", and talk through who does what at each step. You will find missing numbers and unclear authority within an hour.
Template outlines
Incident log
- Date and time noticed
- Reported by
- What was observed
- Systems and data affected
- Severity and who set it
- Actions taken, with times and owners
- Current status and next update time
Customer update
- What happened, in plain words
- Who and what is affected
- What we have done so far
- What you need to do, if anything
- When we will next update you
- How to contact us
A worked example
Imagine a small online shop whose checkout starts failing on a Saturday evening. Monitoring alerts the technical lead, who notifies the incident lead. They rate it high because sales have stopped, then find a recent change broke the payment connection. They roll it back, test an order and post a short status note. The following week a blameless review adds a checkout test to the release process.
FAQ
What is an incident response plan?
It is a short written procedure that explains how your organisation detects, handles and recovers from problems such as outages, breaches and ransomware. It names roles, contacts, steps and communication rules so people act quickly and consistently.
What should I do first when my website is hacked?
Alert your incident lead, contain the problem by disabling compromised accounts and isolating affected systems, and preserve logs and evidence before cleaning up. Then change credentials from a clean device and contact your hosting provider and technical specialists. Take qualified advice if personal data may be involved.
Do I have to report a data breach?
It depends on your country, sector and the kind of data involved, and the rules change. Take qualified legal advice in advance so that you know which authorities and individuals you may need to notify and by what process.
How often should we test our incident response plan?
Review the plan and contact details regularly and whenever people, systems or suppliers change. A tabletop exercise with the people named in the plan is an inexpensive way to find gaps before a real incident does.
Related reading
- Backup and Disaster Recovery Plan for Small Businesses
- Employee Cybersecurity Awareness and Phishing Defence
- Monitoring and Observability Basics for Small Teams
Next steps
Write down your four key roles, add the contact tree to a printed page and run a thirty-minute tabletop exercise this month. Then check that you can actually restore a backup. If you would like help with monitoring, backups or hardening your systems, contact us.
