How to Build an Incident Response Plan (SMB Guide with Templates)

Why every SMB needs an incident response plan (and which regulations require it)

Small and mid-size businesses frequently assume that incident response planning is an enterprise concern — something for organisations with a dedicated CISO and a security operations centre. This is a costly misconception. Every regulated SMB is legally required to have documented incident response capability, and the regulatory penalties for failing to notify the relevant authority within the required timeframe can exceed the cost of the incident itself.

Here is the regulatory landscape as of 2026:

GDPR (UK and EU)

Article 32 of GDPR requires controllers and processors to implement technical and organisational measures to ensure an appropriate level of security, which explicitly includes "a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing." An IRP is not optional under GDPR — it is part of the baseline technical and organisational measures. Article 33 requires notification to the supervisory authority (the ICO in the UK, the relevant Data Protection Authority in each EU member state) within 72 hours of becoming aware of a personal data breach, unless the breach is unlikely to result in a risk to individuals' rights and freedoms. Article 34 requires direct notification to the individuals affected when the breach is likely to result in a high risk to those individuals.

NIS2 Directive (EU)

The Network and Information Security 2 Directive, which became enforceable across EU member states from October 2024, significantly expands the scope of mandatory incident reporting compared to the original NIS Directive. Under NIS2, covered entities — which now includes many mid-size businesses in sectors including digital infrastructure, managed services, financial market infrastructure, and professional services — must report significant incidents to their national competent authority within 24 hours of becoming aware (early warning), with a full incident notification within 72 hours, and a final report within one month. NIS2 penalties can reach €10 million or 2% of global annual turnover for essential entities.

DORA (EU Financial Services)

The Digital Operational Resilience Act, which became applicable from January 2025, requires financial services firms — banks, investment firms, insurance companies, payment institutions, crypto-asset service providers, and their ICT third-party service providers — to maintain comprehensive incident response and recovery capabilities. DORA mandates specific incident classification criteria, detailed reporting timelines (initial notification within 4 hours of classification for major incidents), and regular testing of digital operational resilience including threat-led penetration testing (TLPT) for larger firms.

SOC 2

The AICPA's SOC 2 framework, under the Availability and Security trust service criteria, requires covered organisations to have incident response procedures that include identifying, documenting, and addressing incidents. SOC 2 auditors will specifically test whether the IRP has been documented, whether staff have been trained on it, and whether it has been tested within the audit period. An undocumented or untested IRP is a finding that will prevent a clean SOC 2 Type II report.

The 6 phases of incident response (NIST framework adapted for SMBs)

The National Institute of Standards and Technology (NIST) Special Publication 800-61 (Computer Security Incident Handling Guide) defines the authoritative framework for incident response. It is a US government standard, but it is widely adopted globally and is the framework referenced by SOC 2, most cyber insurance underwriters, and many national incident response guidelines. NIST SP 800-61r3, updated in 2024, organises incident response into six phases. Here is how each phase works for an SMB without a dedicated security team.

Phase 1: Prepare — what this looks like in practice for a small team

Preparation is where most SMBs fall short. The IRP document exists, but it has never been tested, the contact numbers are out of date, and the team has never practised their roles. Effective preparation requires five concrete outputs:

1. A documented IRP with current contact details — names, personal mobile numbers (not just office numbers), and backup contacts for every role. This document must be accessible even when your primary systems are down (print copies and an offline/out-of-band copy stored in a password manager or secure offline location).
2. Pre-approved communication templates — internal notification, regulatory notification, client notification, and press statement. These must be reviewed and approved by legal and senior leadership before an incident occurs. Drafting them under pressure leads to inaccurate disclosures and legal risk.
3. A tested backup and recovery procedure — backups that have never been tested are not backups, they are archives of unknown reliability. Test recovery from backup at least quarterly.
4. An out-of-band communication channel — if your primary email and messaging are compromised, how does the incident response team communicate? A separate Signal group, a personal mobile number chain, or a pre-established conferencing number should be designated and tested.
5. A relationship with an incident response retainer or managed security provider — for most SMBs, a cyber incident will exceed internal technical capacity within hours. Having a pre-negotiated retainer with an IR firm means you can escalate immediately rather than spending critical hours searching for a vendor during a live incident.

Building your incident response team (even with 5 people)

Many SMBs assume they cannot build a proper incident response team because they do not have dedicated security staff. The reality is that incident response roles do not require specialised security engineers — they require designated individuals who know their responsibilities and have practised them. A 5-person team can cover all necessary IRP roles.

The core roles in an SMB incident response function are:

• Incident Response Lead (IR Lead): The decision-maker during an incident. Coordinates the response, makes containment and communication decisions, and escalates to senior leadership or the board when required. In most SMBs, this is the IT manager, operations director, or a senior technical manager. Does not need to be a security expert — needs to be a good decision-maker under pressure.
• Technical Lead: The person with the deepest system access who executes containment and eradication actions. In a small team without a dedicated IT function, this may be an external IT provider or managed security provider. The IRP must name the external provider and include their escalation contact, not just an internal staff member.
• Data Protection Officer / Compliance Lead: Responsible for assessing the regulatory notification obligations, preparing and submitting notifications to the ICO or relevant DPA, and advising on legal obligations. In firms where the DPO is external (many SMBs appoint an external DPO under GDPR), this person must be reachable within hours.
• Communications Lead: Responsible for internal communications to staff, external communications to clients, and coordination with external PR or legal counsel for media enquiries. In most SMBs, this is the Managing Director, CEO, or Operations Director.
• Legal Counsel: Reviews client notifications, advises on privilege, and manages any litigation or regulatory enforcement risk arising from the incident. For most SMBs, this is an external solicitor with data protection expertise who has been briefed on the IRP in advance.

Role assignments and escalation matrix

Severity classification (P1–P4)

Consistent severity classification ensures that the correct level of response is triggered immediately. Without a pre-defined classification system, teams either over-respond to minor events (causing alert fatigue) or under-respond to serious incidents (causing regulatory breach). The following P1–P4 framework is aligned with common practice and the materiality thresholds referenced in DORA and NIS2.

Communication templates

Pre-approved templates are the single highest-leverage preparation action your organisation can take. The following templates are provided as starting points — they must be reviewed by your DPO and legal counsel before an incident occurs, and adapted to reflect your organisation's specific regulatory context, client relationship model, and jurisdiction.

Template 1: Internal incident notification (to all staff)

Template 2: Regulatory notification — GDPR Article 33 (to supervisory authority)

Template 3: Client notification — GDPR Article 34 (high-risk breaches)

Template 4: Press statement (if media enquiries arise)

Tabletop exercise guide

A tabletop exercise is a facilitated discussion in which the incident response team walks through a simulated incident scenario in a meeting room — no systems are actually affected. It is the minimum viable testing method for organisations without dedicated security staff, and it is what SOC 2 auditors and cyber insurance underwriters expect to see evidenced.

How to run a tabletop exercise (90-minute format)

Step 1 — Choose a scenario (10 minutes before the session): Select a realistic scenario based on your most likely threat vectors. Good SMB scenarios include: ransomware affecting your file server over a weekend; a phishing attack that compromised a staff member's email account and was used to send fraudulent payment instructions to clients; or a former employee accessing a client portal after their access should have been revoked.

Step 2 — Introduce the scenario (10 minutes): The facilitator (IR Lead or an external consultant) describes the initial discovery: "It is Monday morning. Your IT provider has called to say they cannot connect to the file server and are seeing ransom notes on the desktop. What do you do first?"

Step 3 — Work through the phases (60 minutes): The facilitator injects new information every 10–15 minutes (the attacker is also in the email system; the incident occurred three days ago, not this morning; a journalist has called asking for comment). The team discusses what they would do at each stage, who they would contact, what decisions need to be made, and what templates they would use.

Step 4 — Debrief (20 minutes): What went well? What was unclear? Where were the gaps in the IRP? What information was missing when you needed it? Document findings and assign owners for each improvement action.

Testing cadence

• Tabletop exercise every 6 months — different scenario each time, same roles
• IRP document review and update every 6 months (contact details, role changes, system changes)
• Full backup restoration test every quarter — recover a sample dataset from backup to verify integrity
• Phishing simulation every quarter — test whether staff identify and report phishing correctly
• Full technical incident simulation (live fire drill) every 12 months — IT team actually executes containment and recovery steps in a test environment
• External penetration test every 12 months (required for SOC 2 Type II; recommended for NIS2 essential entities)
• Review cyber insurance coverage annually — ensure coverage limits match your realistic incident cost exposure

Tool requirements for SMB incident response

You do not need an enterprise security operations stack to respond effectively to incidents. These are the minimum tool categories an SMB incident response capability requires:

Logging and audit trail

Every system that holds or processes client data — your client portal, CRM, email platform, file storage — must produce access logs that are centralised and retained for at least 12 months (longer for regulated sectors). Without logs, you cannot determine what data an attacker accessed, when, or for how long. This is the single biggest evidence gap in most SMB incident investigations. Microsoft Sentinel (or the free Microsoft Defender for Business log collection) and Google Chronicle are accessible options for SMBs.

Endpoint detection and response (EDR)

Every managed device should have an EDR agent installed. Microsoft Defender for Business (included in M365 Business Premium) provides enterprise-grade EDR at an SMB price point. CrowdStrike Falcon Go and SentinelOne Singularity are strong alternatives. An EDR tool provides the telemetry you need to understand how an attacker moved through your environment.

Backup and recovery

The 3-2-1 rule remains the standard: 3 copies of data, on 2 different media types, with 1 copy offsite and offline (air-gapped from your network). For most SMBs, this means your primary SaaS systems (Microsoft 365, Google Workspace) plus a daily backup to an immutable cloud storage provider (Backblaze B2, AWS S3 with Object Lock, or Azure Blob Storage with immutability policies). The backup must be tested — untested backups are not backups.

Out-of-band communications

Signal (end-to-end encrypted) for an incident response group containing all IR team members. Personal mobile numbers for all team members and key external contacts (DPO, legal counsel, IR retainer). A pre-arranged bridge number for conference calls that does not depend on your primary telephony.

Incident tracking

A simple shared document or incident log (even a Google Doc or Microsoft SharePoint page accessible from personal devices) where the IR Lead records a time-stamped chronology of events, decisions, and actions during the incident. This record is what regulators will review and what supports your Article 33 notification.

Common IRP mistakes

Mistake 1: The IRP is a document that no one has read. A written IRP that was never tested and that most of the IR team has never reviewed is not an operational capability — it is a compliance artefact. If your team cannot walk through the core actions without referring to the document, the document is not working.

Mistake 2: Waiting for full investigation before notifying regulators. As covered above, the 72-hour GDPR clock starts when you become aware of a likely breach — not when the investigation concludes. Submit a provisional notification, clearly marked as preliminary, and update it as facts emerge. Regulators consistently treat proactive notifiers more favourably than those who delay notification while "completing their investigation."

Mistake 3: Sending client notifications without legal review. A client notification that makes incorrect factual claims, overstates the scope of the breach, or inadvertently admits liability can create significant legal exposure. Every client notification under Article 34 must be reviewed by legal counsel before it is sent. This is why pre-approved templates reviewed before an incident are so important — they dramatically shorten the review time during the incident.

Mistake 4: Recovering systems before eradicating the attacker. Restoring from backup without first removing the attacker's persistence mechanisms — backdoors, compromised credentials, rogue admin accounts, malware that survives the restore — means you restore an infected environment. Eradication must be completed and verified before recovery begins.

Mistake 5: No post-incident review. The lessons-learned phase is the phase most SMBs skip. The reason is understandable — by the time recovery is complete, the team is exhausted and relieved it is over. But the lessons-learned review is what converts a painful incident into a resilience investment. Block two hours within two weeks of incident closure. Document what worked, what did not, and what specific IRP improvements will be made before the next incident. Without this step, you will make the same mistakes in the next incident.

Frequently asked questions

How long should our incident response plan document be?

Length is not the goal — usability is. An IRP that is 80 pages long and cannot be navigated under pressure is worse than a 15-page document that everyone has read and that contains the information the team actually needs during an incident. The minimum viable IRP contains: a severity classification table, the role matrix with current contact details, containment checklists for your most likely incident types (ransomware, credential compromise, accidental disclosure), the communication templates, and a chronological log template. If your full IRP document is more than 30 pages, extract a 2–3 page "quick reference card" that contains only the information needed in the first four hours. That quick reference card is what gets used during the actual incident.

Do we need to notify clients for every security incident?

No — GDPR Article 34 requires notification to data subjects only when a breach is likely to result in a high risk to their rights and freedoms. Not every security incident meets this threshold. The DPO must assess each P1 and P2 incident against the Article 34 test: what is the nature of the data? What harm could realistically follow for affected individuals? What mitigating factors exist (encryption, rapid containment)? This assessment must be documented. Where the threshold is not met, you still document the incident internally and record the basis for your decision not to notify. The ICO can later review your decision-making — documented reasoning is far better than no reasoning.

What is the difference between an incident response plan and a business continuity plan?

They are related but distinct. An incident response plan (IRP) covers how you detect, contain, eradicate, and recover from security incidents — its primary focus is the security event and its regulatory obligations. A business continuity plan (BCP) covers how you maintain or restore critical business operations during any significant disruption — including non-security events like key staff illness, office loss, or supplier failure. Your IRP should feed into your BCP: the recovery phase of the IRP connects directly to the BCP's restoration procedures. Regulated firms typically need both documents, and both need to be tested. If you only have resource to build one first, start with the IRP — the regulatory obligations around incident response are more immediately enforceable than those around business continuity for most SMBs.

What should we do immediately after discovering a potential breach, before we have classified the severity?

Three things immediately: preserve evidence (do not switch off affected systems without guidance from your Technical Lead — powered-off systems destroy volatile memory forensics); stop the obvious bleeding (if you know an account is compromised, reset its credentials; if a device is actively exfiltrating data, isolate it from the network); and convene your IR team. Do not wait until you know the full scope before gathering the team — the first 30 minutes of a real incident are almost always information-gathering under uncertainty. The IR Lead declares an incident when there are reasonable grounds to believe one has occurred, not after confirmation. Acting on a suspected P1 that turns out to be a P3 costs you an afternoon. Failing to act on a real P1 because you were waiting for certainty costs you the regulatory notification window.

How do we handle incidents that involve our third-party service providers (cloud vendors, MSPs)?

Third-party incidents are one of the most challenging scenarios for SMBs. If your cloud provider, payment processor, or managed service provider suffers a breach that affects your client data, you are still the data controller under GDPR — you still have the notification obligation, even though the breach occurred on a third party's infrastructure. Your GDPR Data Processing Agreements (DPAs) with each sub-processor must include an obligation for them to notify you promptly upon becoming aware of any breach affecting your data. Review all your supplier DPAs and confirm this obligation exists. If a supplier cannot produce a DPA containing breach notification obligations, that is a significant compliance risk that needs to be resolved before a breach occurs, not after. Your IRP should have a specific scenario covering "third-party supplier breach" with the actions your team takes when you are dependent on the supplier's timeline and information.