Guide

Incident Response Plan Template: A Step-by-Step Walkthrough

How to write an incident response plan for a small business: the roles, steps, and notification rules to set before an incident happens, walked through with a template.

By SecureBusinessHub Editorial, International cybersecurity desk — · 7 min read

An incident response plan is the document that tells your team what to do in the first hour of a security incident, before anyone has time to think clearly. It names who is in charge, what gets done first, and who needs to be told. Most small businesses do not have one, and most small businesses find that out at the worst possible time: mid-incident, arguing about who should call the bank while a ransomware note is still on screen. This guide walks through what an incident response plan needs to contain and gives you a template structure you can fill in directly.

This plan is the response to an event that is already happening. If you want the steps to take after a ransomware attack specifically, our ransomware survival guide covers recovery in more depth. If your priority is stopping the attack before it starts, our guide to ransomware protection for small businesses covers prevention. The plan below is the general playbook that sits behind both: the roles, steps, and decisions that apply whether the incident is ransomware, a stolen laptop, or a compromised email account.

Why you need this written down before you need it

During an actual incident, people do not think as clearly as they do on a normal Tuesday. Adrenaline narrows focus, and decisions that would take five minutes on a calm day take an hour when someone is also worried about losing customers or their job. A written plan removes the need to invent a process under pressure. Instead of arguing about who calls the insurer, you open the document and it already says who does that and in what order.

There is also a coverage angle. Cyber insurance policies increasingly ask whether you have a documented incident response process, and some make prompt notification to the insurer a condition of the policy. A plan that names who calls the insurer and by when is not just good practice. It is often the difference between a claim that gets paid and one that gets contested on a technicality.

The roles a small plan actually needs

A large company has a dedicated incident response team. A ten-person business does not, and does not need one. What it needs is a short list of roles, each assigned to a real person by name, so nobody has to figure out who is responsible while the clock is running.

  • Incident lead. The person who makes the call on what happens next and keeps everyone else informed. Usually the owner or whoever runs IT.
  • Technical responder. Whoever can actually get into the affected systems, disconnect a machine from the network, or reset compromised accounts. This might be an outside IT provider.
  • Communications contact. The person who talks to staff, customers, and the press if it comes to that. One voice, so the message stays consistent.
  • Insurer and legal contact. Whoever calls the cyber insurance provider and, if needed, a lawyer. Have the policy number and the insurer's incident hotline written into the plan itself, not buried in an inbox.

One person can hold more than one of these roles in a small business, and that is fine. What matters is that every role has a name next to it, not a department. "IT handles this" is not a plan. "Maria handles this, and if Maria is unreachable, call James" is.

The steps, in order

Most incident response frameworks describe the same five stages, and a small business plan should walk through each one with specific, local detail rather than generic advice copied from a textbook.

  • Identify. How you first notice something is wrong, whether that is an alert, a locked screen, or an employee reporting something odd, and who they tell first.
  • Contain. Disconnect the affected device from the network immediately. Do not turn it off if ransomware is suspected, since that can destroy evidence needed for recovery or a claim; disconnecting the network cable or wifi is usually enough.
  • Eradicate. Remove the cause, whether that is malware, a compromised account, or an open vulnerability, once you understand what happened.
  • Recover. Restore systems from clean backups, reset credentials, and bring services back online in a deliberate order rather than all at once.
  • Review. Once things are stable, work out what let the incident happen and update the plan and your defenses so it does not repeat.

Write each stage as an action a specific person takes, not a description of a concept. "Technical responder disconnects the affected machine from the network within fifteen minutes of confirmation" is something a person can actually do under pressure. "Systems should be contained promptly" is not.

Who to notify, and when

Notification is where small businesses most often freeze, because the rules vary by what happened and where you operate. Your plan should list, in advance, the categories of people you might need to tell and roughly when: your cyber insurer, usually within a short window set by your policy; affected customers, if their data was exposed, within whatever timeframe your jurisdiction's data protection law requires; a regulator, if the incident meets the threshold for mandatory reporting; and law enforcement, for anything involving extortion or fraud.

You will not always know the full picture in the first hour, and that is fine. The plan does not need to answer every legal question in advance. It needs to name who makes the notification decisions (usually the incident lead, with the legal contact) and where they go to get the current answer, whether that is your insurer's breach coach or a lawyer you already have a relationship with. Deciding who asks the question in advance saves the hour you would otherwise lose figuring out who should be asking it.

A worked example

It helps to see the plan applied. An employee at a twelve-person accounting firm opens an attachment that turns out to be malware, and by mid-morning several shared drive folders show files with a new, unfamiliar extension. She tells the office manager, who is also the incident lead under the plan. The plan says: disconnect the affected laptop from the network first, which the technical responder (an outside IT contractor on retainer) does within ten minutes by phone. The incident lead checks the plan's notification section, sees the cyber insurance policy requires notification within twenty-four hours, and calls the insurer's incident line that afternoon.

By the next morning, the technical responder has confirmed which files were encrypted and that backups from two days earlier are clean. Because the plan already named the recovery order, systems for client billing come back first, then email, then the shared drive last, restored from the clean backup rather than paid for. The whole sequence took a day and a half instead of the week it might have taken if the firm had spent the first afternoon deciding who was in charge.

Testing the plan so it actually works

A plan that has never been tested is a guess dressed up as a document. The only way to know whether your roles, contact numbers, and steps hold up is to walk through them deliberately, before a real incident forces the question. Our guide to running a ransomware tabletop exercise covers exactly how to do that: a scripted scenario, run with your actual team, that exposes the gaps in an afternoon instead of during a live event.

Update the plan after every test and after every real incident, however small. Contact numbers go stale, people change roles, and the technical detail of "how we disconnect a machine" can change when you switch office wifi providers. A plan reviewed once a year and after anything that touches it stays useful. One written three years ago and never opened since is a false sense of security.

Where this plan fits

This incident response plan is the general playbook behind the recovery steps in our ransomware survival guide and the practice run in our guide to running a ransomware tabletop exercise, which is the fastest way to find out whether this plan actually works for your team. If you would rather start from a structured document than build one from a blank page, our editable policy template pack includes an incident response playbook written for small businesses, ready to fill in with your own roles, contacts, and systems.

NIS2 requirements: the second regime to know about

Data protection law is not the only European regime a business gets asked about. The NIS2 directive sets baseline cybersecurity and incident-reporting obligations for organisations in a defined list of sectors, and it is the source of most of the security questions that now arrive attached to contracts. The two regimes cover different ground: data protection law governs personal data and what people can ask you to do with it, while the NIS2 requirements govern the security and resilience of network and information systems, whether or not personal data is involved. A single incident can engage both, on separate clocks, to separate authorities.

The directive applies to organisations in its listed sectors that are at least medium-sized, meaning broadly fifty or more employees or turnover and balance sheet above ten million euros. That size rule puts most small businesses outside its direct scope, and the honest answer for a ten-person company is usually that the directive does not regulate it. What the size rule does not do is keep the requirements away, because one of them is supply chain security: organisations inside scope are expected to consider the security practices of their direct suppliers, and the way that expectation shows up in the world is as a questionnaire in your inbox.

The measures the directive names are a reasonable checklist for any business, which is why they are worth knowing even when they do not apply to you directly. They cover risk analysis and written security policies, incident handling, business continuity and backups, supply chain security, secure development and vulnerability handling, basic cyber hygiene and training including for management, encryption and access control policies, and multi-factor authentication. Reporting is staged and fast for the organisations it covers: an early warning within twenty-four hours of becoming aware of a significant incident, a fuller notification within seventy-two hours, and a final report within one month.

Because the directive is national law in each member state rather than a single rulebook, the details of scope, thresholds and reporting differ by country. For a fuller explanation of the instrument itself, see our guide to what the NIS2 directive is, and for the supplier side of the supply chain obligation, our walkthrough of vendor risk assessment. The reporting clocks that run alongside data protection deadlines are covered in data breach notification requirements.

Frequently asked questions

Does NIS2 apply to a small business?

NIS2 generally applies to organisations in its listed sectors that are at least medium-sized, meaning broadly fifty or more employees or turnover and balance sheet total above ten million euros. Most smaller businesses fall outside its direct scope, unless a member state has specifically designated them or they sit in one of the size-independent categories such as DNS service providers or trust service providers. Being outside scope does not stop the directive reaching you through customers who are inside it.

What is the difference between GDPR and NIS2?

GDPR governs personal data: what you may collect, why you may hold it, and what rights people have over it. NIS2 governs the security and resilience of network and information systems in specific sectors, whether or not personal data is involved. One incident can engage both regimes at once, on separate reporting clocks and to separate authorities.

How long do you have to report a data breach?

Under the European model, a personal data breach is reported to the supervisory authority without undue delay and, where feasible, within seventy-two hours of becoming aware of it, and affected individuals are told without undue delay where the risk to them is high. Organisations in scope of NIS2 carry a separate obligation: an early warning within twenty-four hours, a fuller notification within seventy-two hours, and a final report within one month.

Does a small business need a data protection officer?

Under GDPR a data protection officer is required where the organisation is a public authority, where its core activities involve regular and systematic monitoring of people on a large scale, or where its core activities involve large-scale processing of special category or criminal offence data. Most small businesses meet none of those tests and are not required to appoint one, though naming someone internally as the contact for privacy questions is worth doing regardless.

What should a small business do when a client's security questionnaire asks about NIS2?

Answer what you actually do rather than what you think the client wants to hear. The questions usually cover written security policies, incident handling and how fast you would notify them, multi-factor authentication, access control when staff join and leave, backup and recovery arrangements, and which of your own subprocessors touch their data. Gaps are common, and disclosing one with a date for closing it lands far better than an answer that does not survive the follow-up question.

Do these rules reach a business based outside the EU?

They can. GDPR reaches organisations outside the EU that offer goods or services to people in the EU or monitor their behaviour, and other regions have their own regimes with their own triggers. NIS2 obligations follow the sectors and the member states that transpose it, but its supply chain expectations travel through contracts, which is how they reach suppliers anywhere in the world.

Related reading