Only a quarter of UK businesses have a formal incident response plan in place, according to the UK government’s Cyber Security Breaches Survey covering 2025 and 2026, and the gap gets worse the smaller the company: just 21% of micro businesses have one, compared with 76% of large organizations. That gap shows up directly in the bill. IBM’s 2026 Cost of a Data Breach report puts the global average cost of a breach at $4.99 million, a roughly 12% jump over the prior period, and breaches where AI played a role in the attack averaged $6 million, about $1 million above the overall mean. Companies without a tested plan spend that extra time and money scrambling to figure out who’s in charge, what to shut down, and what to tell regulators, while the attacker is still inside the network.
This tutorial walks through building a working incident response plan from scratch: the team structure, the classification system, the tooling, the runbooks, and the legal notification clocks you’re now required to track under GDPR, NIS2, and SEC disclosure rules. By the end you’ll have a complete, versioned incident response plan package you can adapt to your own environment, plus the detection rules, automation scripts, and case-management setup to back it up. Expect to spend around 90 minutes working through the core steps, though building out full runbooks for every incident category will take longer.
Don't miss new tech stories on Google
Add Tech Insider once in the Google app and our stories appear in your news suggestions.
Why Your Company Needs a Formal Incident Response Plan in 2026
The math on incident response is blunt. IBM’s most recent Cost of a Data Breach data shows the mean breach lifecycle rising to 247 days, up from 241 the prior year, reversing five straight years of decline and still the better part of eight months of exposure. Every day added to that lifecycle adds cost, and organizations with mature, rehearsed incident response programs consistently report shorter lifecycles and lower total breach costs than organizations improvising in the moment. A written plan is the difference between “we have a process” and “we have a group chat.”
There’s also a regulatory dimension that didn’t exist five years ago. The SEC’s cybersecurity disclosure rules, which took effect for most public companies in the 2023-2024 reporting cycle, require registrants to describe their processes for identifying and managing cybersecurity risk and to disclose material incidents on a tight clock. The EU’s NIS2 Directive, which member states were required to transpose into national law by October 17, 2024, forces “essential” and “important” entities to maintain incident handling capabilities and formal reporting workflows, with enforcement ramping up through 2025 and 2026. Under GDPR, you generally have 72 hours from becoming aware of a personal data breach to notify your supervisory authority. None of those clocks are survivable without a plan you’ve already written, tested, and distributed before the incident happens.
If your organization has already deployed a SIEM platform or endpoint detection tooling, you’re halfway to having the visibility an incident response plan depends on. What’s usually missing is the connective tissue: who gets paged, what counts as a “major” incident versus a routine alert, and what happens in the first hour after someone says the word “breach” out loud.
There’s a business-continuity angle too, separate from the direct breach cost. Every hour a revenue-generating system stays down or quarantined while a team debates next steps is an hour of lost transactions, missed SLAs, and customer trust draining away. A written plan compresses that decision window because the choices, who calls it, what gets isolated, who talks to customers, are made in advance, not negotiated live while the clock is running. Teams that have already rehearsed a scenario close to what’s actually happening move through containment in minutes instead of hours, and that speed is consistently the biggest lever on total incident cost.
Incident Response Frameworks: NIST SP 800-61 Rev 3, SANS, and ISO 27035
You don’t need to invent an incident response methodology from scratch. Three frameworks cover almost every organization’s needs, and this tutorial borrows structure from all three.
NIST SP 800-61 Revision 3 is the current U.S. government reference, published April 3, 2025, and formally superseding Revision 2 from August 2012. The new revision is a substantial rewrite: instead of a standalone incident-handling manual, it’s framed as “Incident Response Recommendations and Considerations for Cybersecurity Risk Management,” explicitly mapped to the NIST Cybersecurity Framework 2.0. That means incident response is no longer treated as a bolt-on security function, it’s woven into the same risk-management profile you’d use for governance, asset management, and continuous monitoring. You can read the full publication at NIST’s CSRC site.
The SANS six-step model, taught through SANS Institute training and certification programs, is older but still the most widely used structure, and it’s the backbone this tutorial’s steps follow: Preparation, Identification, Containment, Eradication, Recovery, and Lessons Learned. It’s compact enough to fit on an incident commander’s cheat sheet and detailed enough to build runbooks around.
ISO/IEC 27035 is the international standard most relevant if your company operates in the EU or needs ISO 27001 certification, since 27035 is the incident-management companion standard auditors will expect you to reference.
| Framework | Publisher | Current Version | Core Structure | Best For |
|---|---|---|---|---|
| NIST SP 800-61 | NIST | Revision 3 (April 2025) | CSF 2.0-aligned risk management profile | U.S. federal contractors, CSF-aligned orgs |
| SANS Incident Handling | SANS Institute | Six-step model, ongoing updates | Preparation, Identification, Containment, Eradication, Recovery, Lessons Learned | SOC teams, IR certification training |
| ISO/IEC 27035 | ISO/IEC | Parts 1-3, current edition | Plan and prepare, detect and report, assess and decide, respond, learn | ISO 27001-certified organizations, EU operators |
Prerequisites and Tools Before You Start
You don’t need a fully staffed SOC to write a working incident response plan, but you do need a few things in place before you start:
- Executive sponsorship, ideally from the CISO or CTO, since you’ll need authority to make containment decisions like isolating production systems
- A current asset inventory (even a spreadsheet counts as a starting point) covering servers, cloud accounts, SaaS apps, and data stores
- Logging and detection tooling already producing alerts, whether that’s a SIEM, EDR agent, or cloud-native monitoring
- A case-management or ticketing system, such as TheHive (latest stable release) or Jira with a dedicated security project
- Contact information for legal counsel, your cyber insurance carrier, and any outside incident response retainer firm
- A communication channel that doesn’t depend on systems that might be compromised, such as a separate Slack workspace, Signal group, or phone tree
- Roughly 90 minutes for the initial draft of this plan, plus follow-up time to run a tabletop exercise and gather sign-off from stakeholders
If your detection stack is thin, pair this tutorial with a guide to vulnerability scanning tools and EDR platforms before you finalize your detection playbooks; a response plan is only as good as the alerts feeding it.
Budget doesn’t have to be a blocker. The tooling in this tutorial (TheHive, Shuffle, Velociraptor, osquery, Sigma-compatible rules) is open source, so a two- or three-person security team can stand up a working plan without a six-figure platform purchase. What that path costs instead is engineering time to run and patch the self-hosted stack, so weigh that tradeoff against your team’s bandwidth before committing to the fully open-source route versus a managed SOAR or MDR provider.
Step 1: Assemble Your Incident Response Team (CSIRT)
Every incident response plan starts with naming names, not job titles. Your Computer Security Incident Response Team (CSIRT) needs a designated incident commander, a technical lead, a communications lead, and a legal/compliance liaison, each with a named backup. Write down phone numbers, not just Slack handles, because Slack might be down when you need them.
The incident commander role is the one people skip, and it’s the one that matters most. During a live incident, someone has to own the decision to take a production database offline or fail over to a backup region, and that authority needs to be established in the plan document, not negotiated in the moment. Smaller companies often rotate this role among two or three senior engineers on an on-call schedule; larger organizations dedicate it to a security operations manager.
# incident-response-team.yaml
team:
incident_commander:
primary: "Jordan Reyes"
backup: "Priya Nair"
phone: "+1-555-0142"
technical_lead:
primary: "Sam Whitfield"
backup: "Alex Ortega"
communications_lead:
primary: "Dana Kim"
backup: "Marcus Webb"
legal_liaison:
primary: "Outside Counsel - Fenwick Group"
contact: "[email protected]"
cyber_insurance:
carrier: "Example Underwriters Ltd"
policy_number: "CYB-2026-88213"
claims_hotline: "+1-555-0199"
escalation:
sev1_page: ["incident_commander", "technical_lead", "cto"]
sev2_page: ["incident_commander", "technical_lead"]
sev3_ticket_only: trueKeep this file somewhere accessible even if your primary infrastructure is down, printed and in a physical folder, or in a password manager entry shared with the whole team. Update it quarterly; stale contact information is one of the most common reasons incident response plans fail during a real event.
Extended Roles for Larger Organizations
A four-person core team covers most incidents at a small or mid-size company, but larger organizations typically add a few more named roles once headcount allows. A forensics lead handles evidence collection and chain of custody, distinct from the technical lead who’s focused on stopping the bleeding. An external communications or PR liaison drafts customer- and press-facing statements so the incident commander isn’t also managing media inquiries mid-incident. An HR liaison becomes essential for insider-threat cases, since those investigations intersect with employment law in ways a purely technical runbook doesn’t cover. None of these roles need to be full-time; they just need to be named in advance, with a clear handoff point for when the core CSIRT should loop them in.
Step 2: Define Severity Levels and Escalation Paths
Not every alert is a crisis, and treating every alert like one burns out your team fast. Define three to five severity tiers with concrete, unambiguous criteria for what belongs in each one, so an on-call engineer at 3 a.m. doesn’t have to guess.
- Severity 1 (Critical): confirmed unauthorized access to production systems, active ransomware encryption, or confirmed exfiltration of regulated data. Pages the full CSIRT immediately.
- Severity 2 (High): suspicious lateral movement, a compromised credential with confirmed misuse, or a critical vulnerability under active exploitation in your environment. Pages incident commander and technical lead.
- Severity 3 (Medium): isolated malware detection on an endpoint, failed intrusion attempt blocked by existing controls, phishing email reported by a user with no click-through confirmed. Ticketed, reviewed within one business day.
- Severity 4 (Low): policy violations, expired certificates, low-confidence alerts requiring triage. Logged for weekly review.
Attach an escalation path to each tier: who gets paged, over what channel, and within what timeframe. Sev1 and Sev2 classifications should also trigger your regulatory notification clock immediately, since the 72-hour GDPR window and the SEC’s four-business-day disclosure requirement both start from when you become aware of the incident, not when you finish investigating it.
Step 3: Map Critical Assets and Data Flows
You can’t contain what you can’t find. Before you write a single runbook, inventory the systems that matter most: production databases, authentication services, payment processing, customer PII stores, source code repositories, and any system that would trigger a regulatory notification if compromised. For each asset, record its owner, its network location, its backup schedule, and whether it stores regulated data (PII, PHI, cardholder data).
This step is tedious and it’s the one most teams shortcut, which is exactly why it causes the most damage during a real incident. When an alert fires on a host you can’t immediately identify, you lose the first, most valuable hour of the response window just figuring out what you’re looking at. A basic osquery-based inventory script, scheduled to run daily, closes most of that gap cheaply.
-- osquery scheduled query: daily asset and process snapshot
SELECT
h.hostname,
h.uuid,
os.name AS os_name,
os.version AS os_version,
p.name AS process_name,
p.cmdline,
li.username
FROM
system_info h
JOIN os_version os
JOIN processes p
LEFT JOIN logged_in_users li ON li.pid = p.pid
WHERE
p.start_time > (strftime('%s','now') - 86400);Feed the results into your case management system or a searchable log store so that during an incident, your technical lead can pull up “what was running on this host in the last 24 hours” in seconds instead of SSH-ing in blind.
Step 4: Choose and Configure Detection Tooling
Your incident response plan is only as useful as the alerts that trigger it. Most mid-size and enterprise teams centralize detection through a SIEM, using Sigma rules (a vendor-neutral detection rule format) that translate cleanly across Splunk, Elastic, and Microsoft Sentinel. Below is a Sigma rule detecting a common early-stage indicator: a burst of failed logins followed by one success, a classic sign of brute-force or credential-stuffing activity.
title: Brute Force Followed By Successful Login
id: 7c6a1f2e-4b3d-4e9a-9f21-example0001
status: stable
description: Detects 10+ failed authentication attempts from one source followed by a success within 10 minutes
logsource:
category: authentication
detection:
failed_logins:
EventID: 4625
successful_login:
EventID: 4624
timeframe: 10m
condition: failed_logins | count() by SourceIP >= 10 and successful_login
level: high
tags:
- attack.credential_access
- attack.t1110If you’re comparing detection platforms before committing budget, our breakdown of Wazuh, Elastic, and Graylog covers open-source SIEM options, and the EDR vs XDR vs MDR comparison is worth reading before you decide whether to build detection in-house or outsource it to a managed provider.
Step 5: Write Incident-Specific Runbooks and Playbooks
A generic “respond to security incidents” document doesn’t help anyone at 2 a.m. Write separate runbooks for your most likely incident categories: phishing/business email compromise, ransomware, credential compromise, DDoS, insider threat, and third-party/vendor breach. Each runbook should follow the same skeleton so responders don’t have to relearn the format under pressure: trigger conditions, immediate actions, evidence to preserve, containment steps, communication template, and closure criteria.
# runbook: phishing-credential-compromise.yaml
name: Phishing-Induced Credential Compromise
severity_default: SEV2
trigger:
- user_reports_phishing_click
- siem_alert: impossible_travel_login
immediate_actions:
- disable_affected_account
- force_password_reset_all_sessions
- revoke_active_oauth_tokens
- preserve_email_headers_and_url
evidence_to_collect:
- mailbox_audit_log_last_30_days
- sign_in_log_last_7_days
- forwarding_rule_check
containment:
- block_sender_domain_at_gateway
- search_org_wide_for_same_sender
- quarantine_matching_messages
communication:
internal_template: "templates/user-account-locked.md"
regulatory_check: "Does this account have access to regulated data? If yes, start 72h GDPR clock."
closure_criteria:
- account_reset_confirmed
- no_lateral_movement_detected_48h
- lessons_learned_scheduledStore these runbooks in version control alongside your infrastructure code, not just in a wiki. Treating your incident response plan like code means every runbook change gets reviewed, and you can diff what changed after every tabletop exercise or real incident.
Step 6: Set Up Case Management With TheHive
Once you’re tracking multiple runbooks and a real incident hits, you need a central place to log the timeline, evidence, and decisions, both for your own postmortem and for regulators who will ask for a documented chain of custody. TheHive is the most widely used open-source case-management platform for security teams, pairing with the Cortex analysis engine for automated enrichment (IP reputation, hash lookups, sandbox detonation) and MISP for threat-intel sharing.
# docker-compose.yml - minimal TheHive + Cassandra + Elasticsearch stack
version: "3.7"
services:
cassandra:
image: cassandra:4.1
environment:
- MAX_HEAP_SIZE=1G
- HEAP_NEWSIZE=256M
volumes:
- cassandra-data:/var/lib/cassandra
elasticsearch:
image: docker.elastic.co/elasticsearch/elasticsearch:8.13.0
environment:
- discovery.type=single-node
- xpack.security.enabled=false
volumes:
- es-data:/usr/share/elasticsearch/data
thehive:
image: strangebee/thehive:5-latest
depends_on:
- cassandra
- elasticsearch
ports:
- "9000:9000"
command:
- --cql-hostnames
- cassandra
- --index-backend
- elasticsearch
- --es-hostnames
- elasticsearch
volumes:
cassandra-data:
es-data:Run docker compose up -d, wait for the health checks to pass, and TheHive will be reachable on port 9000. Create an organization, invite your CSIRT members, and build case templates that mirror the runbooks from Step 5, so opening a new case for a phishing incident auto-populates the evidence checklist instead of starting from a blank page.
Configuring Case Templates and Cortex Analyzers
Inside TheHive’s admin panel, build one case template per runbook, each with pre-defined tasks matching the “immediate actions” and “evidence to collect” fields you wrote in Step 5. When an analyst opens a new case from the phishing template, they should see a checklist already populated with tasks like “pull mailbox audit log” and “check for forwarding rules,” rather than typing them from memory under pressure. Pair TheHive with Cortex, its companion analysis engine, to automate the tedious enrichment work: submitting a suspicious IP for reputation scoring, checking a file hash against known-malware databases, or detonating an attachment in a sandbox. Cortex responders can also trigger containment actions directly from a case, like requesting an EDR isolation, which shortens the gap between “we found something” and “we acted on it.”
Step 7: Automate Response With SOAR
Security orchestration, automation, and response (SOAR) tooling turns your runbooks from documentation into executable workflows. Commercial platforms like Splunk SOAR, Palo Alto Cortex XSOAR, and Microsoft Sentinel’s built-in playbooks handle this at enterprise scale; smaller teams often start with Tines or the open-source Shuffle platform, both of which can trigger the same containment actions (disabling an account, isolating a host, blocking an IP at the firewall) from a visual workflow builder instead of custom scripts.
{
"workflow": "auto-isolate-endpoint",
"trigger": {
"source": "siem_webhook",
"condition": "alert.severity == 'critical' && alert.category == 'malware_execution'"
},
"actions": [
{
"step": 1,
"action": "edr.isolate_host",
"params": { "host_id": "{{alert.host_id}}", "reason": "Automated SEV1 containment" }
},
{
"step": 2,
"action": "case_management.create_case",
"params": { "template": "malware-execution", "priority": "critical" }
},
{
"step": 3,
"action": "chatops.notify",
"params": { "channel": "#incident-response", "message": "Host {{alert.host_id}} auto-isolated. Case {{case.id}} created." }
}
]
}Start automation with reversible, low-risk actions, host isolation and case creation are safe defaults, while anything that could disrupt production (like automatically killing a database process) should stay a human decision, at least until your playbook has been tested through several real incidents.
Step 8: Define Containment, Eradication, and Recovery Steps
This is the heart of the SANS model, and it’s where most of the real damage-control decisions happen. Containment splits into short-term (isolate the affected host or account without destroying evidence) and long-term (patch the vulnerability, rotate credentials, rebuild from known-good images). Eradication means removing every foothold the attacker established, backdoors, scheduled tasks, rogue admin accounts, not just the initial payload. Recovery means restoring systems to production under closer-than-normal monitoring, confirming no reinfection before declaring the incident closed.
Write explicit decision criteria into the plan for the hardest call any incident commander makes: when to take a system offline entirely versus monitor it live to gather more intelligence on the attacker. There’s no universal right answer, but the plan should specify who has authority to make that call and what factors weigh into it (data sensitivity, blast radius, whether customer-facing services are affected).
Step 9: Document Legal and Regulatory Notification Requirements
Regulatory deadlines don’t pause while you’re still investigating, so your plan needs pre-written notification templates and a clear table of which law applies to which type of incident. Miss the clock and you compound a technical incident with a compliance failure.
| Regulation | Applies To | Notification Window | Notify Whom |
|---|---|---|---|
| GDPR (Article 33) | Personal data of EU residents | 72 hours from awareness | Supervisory authority; affected individuals if high risk |
| EU NIS2 Directive | Essential/important entities in critical sectors | Early warning within 24h, full notification within 72h | National CSIRT / competent authority |
| SEC Cybersecurity Disclosure Rule | U.S. public companies | 4 business days after materiality determination | SEC via Form 8-K Item 1.05 |
| State breach notification laws (U.S.) | Varies by state, generally PII | “Without unreasonable delay,” often 30-60 days | State attorney general, affected residents |
Loop in legal counsel and your cyber insurance carrier during plan development, not after an incident starts. Many cyber insurance policies require notification to the insurer within a specific window too, and failing to follow the carrier’s incident response requirements can jeopardize coverage. Full text of the GDPR notification requirement is available at gdpr-info.eu, and the EU’s official NIS2 policy page at digital-strategy.ec.europa.eu covers member-state transposition status.
If you handle health information in the U.S., the HIPAA Breach Notification Rule adds another track: covered entities generally must notify affected individuals and the Department of Health and Human Services without unreasonable delay, and no later than 60 days after discovery of a breach involving unsecured protected health information. That’s a longer window than GDPR’s 72 hours, but the notification content requirements are more detailed, so build a separate template for HIPAA-covered incidents rather than trying to force one generic breach letter to satisfy every regulation your company falls under.
Step 10: Run Tabletop Exercises and Conduct Post-Incident Reviews
A plan that’s never been tested is a plan that will fail in ways you didn’t anticipate. Schedule a tabletop exercise at least twice a year: gather the CSIRT, present a realistic scenario (a ransomware note on a file server, a reported phishing click from someone in finance, an S3 bucket exposed publicly), and walk through the plan step by step without touching real systems. Time how long it takes to reach containment decisions and notice where the plan has gaps, usually around ownership ambiguity or missing contact information.
After every real incident and every tabletop, run a blameless post-incident review within a week while details are fresh. Document what triggered detection, how long each phase took, what worked, and what didn’t. SANS’s Lessons Learned step exists precisely because incident response plans that don’t incorporate feedback loops calcify into documents nobody trusts. Feed every finding back into the runbooks from Step 5 and re-version the plan.
Common Pitfalls When Building an Incident Response Plan
- Writing the plan once and never updating it. Team members leave, tools change, and a plan referencing a decommissioned SIEM or a former employee’s phone number is worse than no plan, because it creates false confidence.
- No designated incident commander authority. If nobody has pre-approved authority to take a production system offline, that decision gets debated in real time, burning the most valuable minutes of the response window.
- Storing the plan only on systems that might be compromised. If your incident response plan lives exclusively on the intranet wiki and the intranet is what’s down, you have no plan. Keep an offline or out-of-band copy.
- Skipping the regulatory notification mapping. Teams that focus purely on the technical response often blow through the GDPR 72-hour or SEC four-business-day windows because nobody was tracking the clock from the moment of awareness.
- Treating every alert as an incident, or the reverse. Without clear severity tiers, teams either burn out from alert fatigue or under-react to a real Sev1 because it looked routine at first glance.
- Never rehearsing the plan. A plan that exists only on paper reveals its gaps during a real breach, which is the most expensive possible time to discover them.
Troubleshooting Common Incident Response Plan Problems
Problem: The CSIRT can’t agree on who has final authority during an incident. Fix this before it happens by having the CISO or CTO sign off explicitly on the incident commander’s authority to take containment actions, including production downtime, without further approval during a declared Sev1 or Sev2.
Problem: Detection tooling generates too many false positives, so real alerts get ignored. Tune your Sigma rules and SIEM correlation logic on a monthly cadence, and track a false-positive rate metric per rule so noisy detections get fixed or retired instead of silently muted.
Problem: TheHive or your case management tool goes down during an incident. Keep a lightweight offline fallback, a shared incident log template in a format that doesn’t depend on your primary infrastructure, so you can still document actions and timestamps by hand if needed.
Problem: Legal and technical teams disagree on when the regulatory clock starts. Define “awareness” explicitly in the plan (typically when a person with authority to act confirms an incident is more likely than not to have occurred) so this isn’t debated live during an actual breach.
Problem: SOAR automation takes an unintended destructive action. Require human approval steps for any automated action beyond isolation or case creation until the playbook has run successfully through at least three real incidents or tabletop simulations.
Problem: Contact information in the plan is out of date. Assign an owner to review and re-confirm every contact quarterly, and tie that review to a recurring calendar reminder rather than relying on someone remembering.
Problem: Runbooks don’t match how the team actually works during a real incident. After every tabletop exercise, explicitly ask “did anyone deviate from the runbook, and why?” Deviations usually point to a step that’s unrealistic or missing, not a team that ignored the process.
Problem: The plan doesn’t cover third-party or vendor breaches. Add a dedicated runbook for supply-chain incidents, since a compromised vendor or SaaS provider can expose your data without any alert firing inside your own environment. Require key vendors to contractually commit to a notification window you can act on.
Problem: Post-incident reviews turn into blame sessions and people stop being candid. Explicitly frame reviews as blameless in the plan document itself, and have the incident commander (not a manager) run the review so it stays focused on process gaps, not individual performance.
Advanced Tips: AI-Assisted Detection and Threat Intel Integration
With roughly one in four malicious breaches now involving AI on the attacker’s side according to IBM’s 2026 report, defenders are leaning on AI-assisted triage to keep pace. Several SIEM and SOAR platforms now ship natural-language query assistants that let a Tier 1 analyst ask “show me all logins from this IP in the last 48 hours” instead of writing raw query syntax, cutting triage time on straightforward alerts. Treat these assistants as a first-pass filter, not a replacement for a human sign-off on containment decisions, since AI-generated triage summaries can miss context a trained analyst would catch.
Integrate threat intelligence feeds (MISP, commercial feeds, or ISAC memberships relevant to your industry) directly into your case management platform so that when a new indicator of compromise is published, it’s automatically checked against your historical logs rather than requiring a manual search. Pair this with a mature zero trust network architecture, since segmenting access by default dramatically shrinks the blast radius your containment runbooks need to cover, turning what could be a lateral-movement disaster into an isolated incident.
For open-source endpoint forensics at scale, Velociraptor and GRR Rapid Response both support fleet-wide queries during active incidents, letting you hunt for an indicator of compromise across thousands of endpoints in minutes instead of manually pulling artifacts host by host. Both integrate with the osquery-based inventory approach from Step 3.
One more habit worth building into the plan itself: schedule a recurring review of your detection coverage against current attacker techniques, not just a review of the document’s wording. Frameworks evolve, NIST’s shift to a CSF 2.0-aligned model in SP 800-61 Revision 3 is itself a sign that risk management and incident response are converging, so a plan that only gets touched after an incident will drift out of step with how your organization actually operates. Put a calendar reminder on it the same way you would a certificate renewal.
Complete Working Project: Sample Incident Response Plan Package
Below is the full folder structure for a working incident response plan package you can adapt directly, combining everything built in this tutorial: team roster, severity definitions, runbooks, and the automation and case-management configs.
incident-response-plan/
├── README.md # Plan overview, version, last review date
├── team/
│ └── incident-response-team.yaml # CSIRT roster and escalation paths (Step 1)
├── policy/
│ ├── severity-levels.md # Sev1-4 definitions (Step 2)
│ └── regulatory-notification.md # GDPR/NIS2/SEC deadlines and templates (Step 9)
├── assets/
│ └── asset-inventory-query.sql # osquery scheduled snapshot (Step 3)
├── detection/
│ └── rules/
│ └── brute-force-login.yml # Sigma detection rule (Step 4)
├── runbooks/
│ ├── phishing-credential-compromise.yaml
│ ├── ransomware.yaml
│ ├── ddos.yaml
│ ├── insider-threat.yaml
│ └── vendor-third-party-breach.yaml
├── automation/
│ ├── docker-compose.yml # TheHive case management stack (Step 6)
│ └── soar-auto-isolate.json # SOAR workflow definition (Step 7)
├── templates/
│ ├── user-account-locked.md
│ ├── customer-notification.md
│ └── regulator-notification.md
└── postmortems/
└── TEMPLATE-lessons-learned.md # Post-incident review template (Step 10)Commit this entire structure to a private Git repository with restricted access (the plan itself is sensitive, since it documents your defenses and gaps). Tag a release every time the CSIRT signs off on a revision, and require the incident commander and CISO to approve any change to the escalation or severity-level files through a standard pull-request review, just like production code.
Adapting the Package to Your Environment
Treat this structure as a starting skeleton, not a finished product. A five-person startup can strip it down to a single README, one team file, and three or four runbooks covering the incident types most relevant to its stack. A regulated enterprise will likely split the policy folder further, adding sector-specific runbooks (PCI DSS for payment data, SOX for financial reporting systems) and a dedicated folder for evidence-retention schedules tied to litigation-hold requirements. What shouldn’t change regardless of company size is the discipline of keeping the plan in version control, reviewing it on a fixed schedule, and running at least one tabletop exercise before you trust it to hold up during a real incident.
Incident Response Tools Compared
Choosing between commercial and open-source tooling depends on team size, budget, and how much engineering time you can dedicate to running the platform yourself.
| Tool | Category | License | Best For | Notable Feature |
|---|---|---|---|---|
| Splunk SOAR | SOAR | Commercial | Large enterprises already on Splunk | Deep integration with Splunk Enterprise Security |
| Palo Alto Cortex XSOAR | SOAR | Commercial | Enterprises standardizing on Palo Alto stack | Large pre-built playbook marketplace |
| Microsoft Sentinel | SIEM + SOAR | Commercial (consumption-based) | Microsoft/Azure-centric environments | Native playbooks via Azure Logic Apps |
| TheHive | Case management | Open source (AGPL) / commercial support | Teams wanting self-hosted, auditable case tracking | Pairs with Cortex for automated enrichment |
| Tines | SOAR | Commercial, free tier available | Lean security teams wanting no-code automation | Visual workflow builder, fast time-to-value |
| Shuffle | SOAR | Open source | Budget-constrained teams wanting SOAR without licensing cost | Self-hostable, community app library |
| Velociraptor | Endpoint forensics | Open source | Fleet-wide incident hunting | VQL query language for live endpoint triage |
Most teams that start with open-source tooling (TheHive, Shuffle, Velociraptor) eventually layer in a commercial SOAR or SIEM as headcount and incident volume grow, since the open-source stack demands more ongoing engineering maintenance. If you’re still evaluating your detection layer, our EDR vs XDR vs MDR breakdown and CrowdStrike vs SentinelOne vs Defender comparison cover the endpoint side of this decision in more depth.
Frequently Asked Questions
How long should an incident response plan be?
Long enough to be complete, short enough that people actually read it under pressure. Most working plans run 15-30 pages for the core document, with runbooks as separate, individually shorter appendices that responders can pull up one at a time.
Who should own the incident response plan inside a company?
Typically the CISO or head of security owns the document, but the incident commander role during an actual event can rotate among senior engineers or security analysts on an on-call schedule.
Do small businesses really need a formal incident response plan?
Yes, and the data backs this up: the UK’s 2025/2026 Cyber Security Breaches Survey found only 21% of micro businesses have one, which correlates with longer, more expensive incidents when they do get breached. A one-page plan with named contacts is far better than nothing.
How often should we test our incident response plan?
At minimum twice a year with a tabletop exercise, and after any significant infrastructure change (new cloud provider, new SIEM, team reorganization) that would affect the plan’s assumptions.
What’s the difference between an incident response plan and a disaster recovery plan?
An incident response plan focuses on detecting, containing, and eradicating a security threat. A disaster recovery plan focuses on restoring systems and data after any major disruption, security-related or not (natural disaster, hardware failure). They overlap in the recovery phase but serve different primary purposes.
Does GDPR require every company to have an incident response plan?
GDPR doesn’t mandate a specific document by name, but the 72-hour breach notification requirement under Article 33 is nearly impossible to meet without a pre-built process for detecting, assessing, and reporting incidents, which is functionally an incident response plan.
What free or open-source tools can a small team use to get started?
TheHive for case management, Shuffle for SOAR automation, Velociraptor or osquery for endpoint visibility, and a Sigma-rule-compatible SIEM like Wazuh cover most of the core tooling needs without licensing costs.
How does NIS2 affect companies outside the EU?
NIS2 applies based on where you provide services, not just where you’re headquartered, so non-EU companies offering essential or important services (cloud providers, managed service providers, critical infrastructure operators) to EU customers can fall under its scope and should review the directive’s requirements directly.
Related Coverage
- Wazuh vs Elastic vs Graylog: Free SIEM Saves 78% [2026]
- CrowdStrike vs SentinelOne vs Defender: 100% MITRE [2026]
- EDR vs XDR vs MDR: 17x Per-Endpoint Cost Gap [2026]
- Nessus vs Qualys vs OpenVAS: 4.9x Speed Gap, Free Tier [2026]
- Set Up Zero Trust Network Access: 15 Steps, 100 Min [2026]
- Data Breaches Top 471M Victims in H1 2026 [2026]
