How to Build an Incident Response Plan: A Complete Guide
A security incident is not a matter of "if" but "when". Organisations that respond quickly and methodically suffer less damage, recover faster, and maintain client trust. This guide walks you through building a comprehensive incident response plan based on the NIST framework, complete with team roles, communication templates, severity classifications, and playbooks for the most common incident types.
Why Every Organisation Needs an IR Plan
Without a documented incident response plan, teams waste critical time deciding who does what during a crisis. The average cost of a data breach continues to rise year over year, and regulatory bodies increasingly expect organisations to demonstrate that they have a tested, repeatable process for handling security events.
An incident response plan is not just a compliance checkbox. It directly reduces the blast radius of an attack, shortens recovery time, and protects your organisation's reputation. Here is what you gain by having one in place:
- Faster containment that limits financial and operational damage
- Clear ownership so nobody assumes someone else is handling it
- Consistent communication with stakeholders, regulators, and customers
- Evidence preservation for forensic analysis and potential legal proceedings
- Compliance with frameworks such as ISO 27001, SOC 2, GDPR, and NIS2
- Continuous improvement through structured post-incident reviews
The 6 NIST Incident Response Phases
The NIST Computer Security Incident Handling Guide (SP 800-61) defines a lifecycle that every IR plan should follow. Each phase feeds into the next, creating a continuous loop of preparation and improvement.
Build your IR team, define roles, deploy monitoring tools, establish communication channels, and create playbooks before an incident occurs. Preparation also includes ensuring you have adequate logging, backups, and network segmentation in place. This phase is where 80% of your IR investment should go.
- Document asset inventories and network diagrams
- Deploy endpoint detection and response (EDR) tooling
- Establish an out-of-band communication channel (not reliant on corporate email)
- Pre-arrange contracts with external forensics and legal counsel
Detect and confirm that an incident has occurred. This involves monitoring alerts from SIEM, EDR, and IDS/IPS systems, triaging events, and determining whether an alert is a true positive that warrants activation of the IR plan.
- Correlate alerts across multiple data sources
- Assign initial severity based on affected assets and indicators of compromise
- Document the timeline from first indicator to confirmation
- Notify the IR lead and begin the communication chain
Stop the incident from spreading. Short-term containment actions (isolating hosts, blocking IPs) happen immediately. Long-term containment involves applying temporary fixes that allow business operations to continue while you prepare for eradication.
- Isolate compromised systems from the network
- Block malicious IP addresses and domains at the firewall
- Revoke compromised credentials and rotate API keys
- Preserve forensic images before making changes to affected systems
Remove the root cause. This could mean deleting malware, patching vulnerabilities, closing backdoors, or rebuilding compromised systems from known-good images. Do not rush this phase; incomplete eradication leads to re-compromise.
- Identify and remove all attacker persistence mechanisms
- Patch the vulnerability that was exploited for initial access
- Scan the environment for additional indicators of compromise
- Verify eradication with a secondary analyst or external team
Restore systems to normal operations. Bring services back online in a controlled manner, monitor closely for signs of re-compromise, and validate that business functions are working correctly before declaring the incident resolved.
- Restore from verified clean backups
- Implement enhanced monitoring on previously affected systems
- Gradually restore network connectivity and user access
- Confirm service stability with application and infrastructure owners
Conduct a blameless post-incident review within 5 business days of resolution. Document what happened, what went well, what failed, and what needs to change. Update your IR plan, playbooks, and detection rules based on the findings.
- Hold a structured post-mortem meeting with all responders
- Produce a written incident report with timeline and root cause
- Create action items with owners and deadlines
- Update detection signatures and playbooks
Building Your IR Team
Your incident response team should include both technical responders and business stakeholders. Every member must understand their role before an incident occurs, not during one.
Owns the response end to end. Makes containment decisions, coordinates the team, manages the timeline, and provides status updates to leadership. This person has authority to take systems offline if necessary.
Perform triage, forensic analysis, and threat intelligence correlation. They investigate the scope of the compromise, identify indicators of compromise, and recommend containment and eradication actions.
Execute containment actions such as isolating hosts, blocking network traffic, rotating credentials, and restoring from backups. They ensure business-critical services remain available during the response.
Advise on regulatory notification obligations, evidence preservation requirements, and liability considerations. They determine whether the incident triggers mandatory disclosure under GDPR, HIPAA, or other regulations.
Manage external messaging to customers, media, and partners. They prepare holding statements, coordinate with the legal team on disclosure language, and monitor social media for reputational impact.
A C-level or senior leader who has authority to approve budget, make business decisions (e.g., paying a ransom, shutting down a service), and communicate with the board. They are briefed regularly but do not manage the technical response.
Communication Plan
Poor communication during an incident causes as much damage as the incident itself. Define your escalation paths and notification templates before you need them.
Internal Escalation
- SOC analyst detects the event and classifies severity
- IR Lead is notified within 15 minutes for P1/P2 incidents
- IR team assembles on the designated war room or video call
- Executive sponsor is briefed within 1 hour for P1 incidents
- Status updates are shared every 30 minutes (P1) or 2 hours (P2)
External Notification
- Regulatory bodies: GDPR requires notification within 72 hours of becoming aware of a personal data breach
- Affected customers: Notify without undue delay once the scope is confirmed
- Law enforcement: Report if criminal activity is suspected (ransomware, fraud, espionage)
- Cyber insurance provider: Notify as early as possible to activate coverage and access panel firms
- Third-party partners: Inform supply chain partners if they may be affected or if shared systems are involved
Regulatory Timelines
- GDPR: 72 hours to notify the supervisory authority
- NIS2: 24-hour early warning, 72-hour full notification
- HIPAA: 60 days to notify affected individuals
- PCI DSS: Immediate notification to the acquiring bank and payment brands
- SEC (US public companies): 4 business days after determining materiality
Severity Classification (P1 - P4)
Assign a priority level immediately upon identification. This drives response times, escalation paths, and resource allocation.
Active compromise with confirmed data exfiltration, ransomware execution, or complete loss of a business-critical system. Requires all-hands response within 15 minutes. Executive sponsor notified immediately. Status updates every 30 minutes.
Examples: Active ransomware, confirmed data breach, complete infrastructure compromise
Confirmed compromise with limited scope, or a vulnerability under active exploitation that could escalate. IR team responds within 1 hour. Status updates every 2 hours.
Examples: Compromised user account with elevated privileges, targeted phishing with payload delivery, exploited external vulnerability
Suspicious activity that requires investigation but has no confirmed impact. Security team investigates within 4 hours. Daily status updates until resolved or escalated.
Examples: Unusual login patterns, malware detected and quarantined by EDR, policy violations
Minor security events that do not indicate compromise. Handled during normal business hours. Logged for trend analysis.
Examples: Failed brute-force attempts (blocked), informational alerts, vulnerability scan findings on non-critical assets
Playbooks for Common Incidents
Generic IR plans are too vague to be useful during a crisis. Create specific playbooks for the incident types your organisation is most likely to face. Each playbook should include step-by-step actions, decision trees, and pre-approved containment measures.
Ransomware Playbook
- Immediately isolate affected systems from the network (pull the cable, disable Wi-Fi, block at switch level)
- Do not power off encrypted systems as volatile memory may contain decryption keys
- Identify the ransomware variant using ransom notes, file extensions, or threat intelligence platforms
- Check for available decryption tools (No More Ransom project, vendor advisories)
- Determine the scope: how many systems are affected and is the encryption still spreading?
- Engage legal counsel to advise on ransom payment decisions and regulatory obligations
- Restore from offline backups after confirming they are not compromised
- Reset all credentials across the domain, starting with privileged accounts
- Conduct root cause analysis: how did the attacker gain initial access?
Data Breach Playbook
- Confirm the breach: what data was accessed or exfiltrated, and how much?
- Classify the data involved (personal data, financial records, health information, intellectual property)
- Contain the data flow by revoking access, blocking exfiltration channels, and disabling compromised accounts
- Engage legal to determine notification obligations based on data type and jurisdiction
- Preserve all relevant logs, access records, and forensic artifacts
- Prepare notification letters for affected individuals (work with legal and communications)
- Notify the relevant supervisory authority within the required timeframe
- Offer affected individuals appropriate remediation (credit monitoring, password resets)
DDoS Attack Playbook
- Confirm the attack by analysing traffic patterns and differentiating from legitimate load spikes
- Activate DDoS mitigation services (cloud-based scrubbing, CDN protections, ISP null routing)
- Implement rate limiting and geo-blocking if the attack originates from specific regions
- Communicate with affected users via status page and social media
- Monitor for secondary attacks: DDoS is often used as a distraction while other systems are targeted
- Document attack vectors, peak traffic volumes, and duration for post-incident analysis
- Review and update DDoS protection thresholds based on the attack profile
Insider Threat Playbook
- Engage HR and legal before taking any technical action against the suspected insider
- Preserve evidence covertly: enable enhanced logging and monitoring on the user's accounts and devices
- Review access logs, DLP alerts, and file transfer records for the suspect's accounts
- Determine whether the activity is malicious, negligent, or a false alarm
- If confirmed, revoke access and secure all systems the individual had access to
- Conduct a forensic review of the individual's devices and cloud storage
- Work with HR on disciplinary or legal action as appropriate
- Review access controls and least-privilege policies to prevent recurrence
Testing Your Plan: Tabletop Exercises
An untested plan is an unreliable plan. Tabletop exercises and red team exercises are the most cost-effective ways to validate your IR process, identify gaps, and build muscle memory in your team.
A tabletop exercise is a discussion-based simulation where you walk through a realistic scenario and each team member describes what they would do at each stage. No systems are actually affected.
How to Run a Tabletop Exercise
- Choose a realistic scenario based on your threat model (e.g., ransomware via phishing email targeting finance)
- Define the scope and objectives: which parts of the IR plan are you testing?
- Invite all IR team members plus representatives from IT, legal, HR, and communications
- Present the scenario in stages (inject new information every 15-20 minutes to simulate an evolving incident)
- Ask probing questions: "Who do you call first?" "Where is this documented?" "What if the primary contact is unavailable?"
- Document findings: gaps in the plan, unclear ownership, missing tools or runbooks
- Produce an action report with prioritised improvements and assign owners
Tools for Managing Incidents
Your IR plan should reference the specific tools your team will use during a response. Having the right tooling pre-configured eliminates friction when every minute counts.
Centralised logging and alerting. Your SIEM is the primary source for detection and timeline reconstruction during an investigation.
Endpoint detection and response for real-time visibility into host-level activity, process execution, and lateral movement.
Track incidents from detection through resolution. Maintain an audit trail of all actions taken, decisions made, and evidence collected.
An out-of-band channel (separate from corporate email and chat) for sensitive incident communications. Assume your primary systems may be compromised.
Disk imaging, memory acquisition, and analysis tools. Pre-install these on a dedicated forensic workstation that is not connected to the corporate domain.
For consultancies and managed security providers, a platform like SecPortal lets you create dedicated incident response engagements, log findings in real time, track remediation progress, and generate client-ready reports with full timeline and evidence.
Key Takeaways
- Start with preparation. The time you invest before an incident determines how well you respond during one.
- Follow the NIST lifecycle. Preparation, Identification, Containment, Eradication, Recovery, and Lessons Learned give you a proven structure.
- Define clear roles. Everyone on the IR team must know their responsibilities before the pager goes off.
- Build specific playbooks. Generic plans fail under pressure. Create step-by-step guides for the incidents you are most likely to face.
- Test regularly. Tabletop exercises expose gaps that no amount of documentation review can find.
- Improve continuously. Every incident and every exercise should result in measurable improvements to your plan.
Manage incident response engagements with SecPortal
Create IR engagements, log findings as they emerge, coordinate with your team in real time, and generate polished incident reports. Free to get started.
Get Started Free