How to Build an Incident Response Plan: A Template for Irish SMEs

NIS2 Article 21 requires organisations to have measures in place for incident handling. GDPR requires a documented process for responding to personal data breaches. ISO 27001 includes incident management as a core control domain.

Despite this, most Irish SMEs have no documented incident response plan. When an incident occurs, the response is improvised — which is the worst possible time to be figuring out who does what.

This guide provides a clear template structure for building an incident response plan that satisfies regulatory requirements and actually works under pressure.

What an Incident Response Plan Is — and Isn't

An incident response plan (IRP) is a documented set of procedures for detecting, responding to, containing, and recovering from security incidents. It defines roles, establishes communication chains, and sets out the steps your team takes from the moment an incident is detected to the point where normal operations are restored.

It is not a technical playbook for every possible attack type. It is a framework with clear roles, decision points, and escalation paths — detailed enough to follow under pressure, simple enough that the right people can execute it without training immediately before an incident.

The Five Phases of Incident Response

Phase 1: Preparation

Everything that happens before an incident occurs. Your IRP should document:

  • The incident response team — who is in it, their roles, contact details, and backups for each
  • Definitions — what categories of incident you recognise (security breach, data breach, ransomware, DDoS, insider threat) and the severity tiers you use
  • Tools and resources — what access and tooling the response team has (forensic tools, communication channels, backup access, system admin credentials)
  • External contacts — your incident response retainer if you have one, legal counsel, the NCSC, DPC notification portal, cyber insurance contact
  • Regulatory obligations — the notification timelines that apply to your organisation (NIS2: 24hr/72hr; GDPR: 72hr)

Phase 2: Detection and Analysis

How incidents are identified and confirmed:

  • Detection sources — what monitoring is in place and who reviews alerts (SIEM, EDR, staff reports, external notification)
  • Initial triage — the process for determining whether a detected event is a genuine incident and its initial severity classification
  • Evidence preservation — immediate steps to preserve logs, system states, and forensic evidence before any remediation action

Phase 3: Containment

Stopping the incident from spreading:

  • Short-term containment — isolating affected systems while preserving evidence
  • Long-term containment — implementing workarounds that allow the business to continue operating while the root cause is addressed
  • Decision authority — who can approve isolating a production system, revoking access, or taking services offline

Phase 4: Eradication and Recovery

Removing the threat and restoring normal operations:

  • Eradication steps — removing malware, closing the attack vector, patching the vulnerability exploited
  • Recovery process — restoring from backup, rebuilding systems, re-enabling services
  • Validation — confirming that eradication was successful before returning systems to production
  • Communication — internal and external communications throughout recovery, including customer notification where required

Phase 5: Post-Incident Review

What happens after the incident is resolved:

  • Root cause analysis — what happened, how it was detected, what allowed it to happen
  • Lessons learned — what the response team would do differently
  • IRP updates — any changes to the plan, tools, or processes identified during the review
  • Regulatory reporting — final incident report under NIS2 (30-day deadline) and GDPR (where applicable)

Required Documentation

Your IRP should include or reference:

  • The current version of the plan and its review date
  • Contact directory for the incident response team and external parties
  • Severity classification matrix — criteria for classifying an incident as low, medium, high, or critical
  • Regulatory notification summary — a one-page reference to your NIS2/GDPR notification obligations and deadlines
  • Communication templates — pre-approved draft notifications for internal escalation, customer communication, and regulatory notification
  • Evidence chain of custody log — where to record what evidence was collected, when, and by whom

Testing Your IRP

A plan that has never been tested will fail when used. At minimum, run an annual tabletop exercise — walk the incident response team through a realistic scenario and identify gaps in the plan. Document the exercise and its outcomes. Update the IRP accordingly.

For NIS2-regulated entities, the ability to demonstrate a tested incident response capability is increasingly expected during supervisory review.

How ShieldIQ Supports Incident Response

ShieldIQ's incident management module provides a structured incident log with severity classification, NIS2 and GDPR notification timelines tracked automatically, AI-drafted regulatory notifications, and a tamper-evident activity trail. BCDR test records can be linked to your incident response exercises.

Run a free NIS2 assessment to see your incident response posture →