Building an Incident Response Plan: The Template and Process That Actually Works Under Pressure

Incident Response Frameworks Compared

Phase 1: Preparation — Before the Incident

Preparation is the phase that determines whether everything else works. An organization that has invested in preparation responds to incidents in hours; one that has not responds in weeks — if it detects the incident at all. Preparation is not just writing the plan document. It includes establishing the IR team and communication channels, deploying detection and logging capabilities, building relationships with external resources (legal counsel, forensics firms, law enforcement contacts), and rehearsing the plan through exercises.

The IR Team and RACI Matrix

Every incident response plan must define who is involved and what their specific responsibilities are. A RACI matrix eliminates ambiguity during high-stress situations by assigning four roles for each IR activity:

• Responsible: The person or team that executes the task. During a ransomware incident, the security engineer who isolates affected systems is Responsible for containment.
• Accountable: The single person who makes the decision and owns the outcome. The CISO or VP of Engineering is typically Accountable for incident classification and major response decisions.
• Consulted: Subject matter experts who provide input before a decision is made. Legal counsel is Consulted on breach notification decisions. The database team is Consulted before shutting down a production database for forensic imaging.
• Informed: Stakeholders who need to know about decisions and progress but are not involved in making them. The CEO, board, and customer success team are Informed at defined intervals.

The RACI must include roles from outside the security team: legal, communications/PR, customer support, human resources (for insider threat incidents), and executive leadership. Incidents that escalate beyond severity level 2 invariably involve non-technical stakeholders, and discovering who should be in the room during an active incident is a preparation failure.

Phase 2: Severity Classification

Severity classification determines what resources are activated, what communication cadence is followed, and what escalation timelines apply. Ambiguous severity criteria are the most common failure point in IR plans — responders waste critical time debating whether an event is a "Level 2" or "Level 3" instead of executing the plan.

Define severity levels with objective, measurable criteria:

• SEV-1 (Critical): Active data exfiltration confirmed, ransomware spreading across systems, complete loss of a production service, or compromise of authentication infrastructure. Response: all-hands war room within 30 minutes, executive notification within 1 hour, external forensics engaged immediately.
• SEV-2 (High): Confirmed compromise of a single system or account, exploitation of a critical vulnerability in production, or unauthorized access to sensitive data without confirmed exfiltration. Response: IR team assembled within 2 hours, executive notification within 4 hours.
• SEV-3 (Medium): Suspicious activity requiring investigation — anomalous login patterns, malware detected and contained by endpoint protection, phishing email with credential harvest attempt. Response: IR team lead assigns investigation within 4 hours, status update within 24 hours.
• SEV-4 (Low): Security events that need tracking but not immediate response — failed brute-force attempts blocked by rate limiting, vulnerability scan results, policy violations without security impact. Response: logged and reviewed during regular security operations.

Phase 3: Communication Templates

During an active incident, writing communications from scratch consumes time and introduces risk — a poorly worded customer notification or a premature public statement can cause more damage than the incident itself. Pre-written templates for every communication type eliminate this pressure.

The communication templates your IR plan needs include:

• Internal escalation notification: A concise format for alerting the IR team and leadership — what happened, current severity, immediate actions taken, next steps, and when the next update will be.
• Customer notification (confirmed breach): Pre-approved language that describes the incident, what data was affected, what the organization is doing about it, and what the customer should do. Have legal counsel review this template in advance — not during the incident.
• Regulatory notification: Templates for GDPR (72-hour notification to supervisory authority), state breach notification laws, HIPAA breach reporting, and any other regulatory obligations. Include the specific information each regulator requires.
• Public statement / press response: A holding statement for media inquiries that acknowledges the situation without speculating about scope or cause. This buys time for investigation without creating a communications vacuum.
• Status update (internal): A standard format for regular updates during an active incident — current status, actions completed since last update, actions in progress, blockers, and ETA for next update.

Phase 4: Escalation Procedures

Escalation procedures define the criteria for increasing incident severity and engaging additional resources. These must be specific enough that an on-call engineer at 3 AM can make the escalation decision without waiting for a manager's approval. Time-based escalation triggers are critical: if a SEV-3 investigation has not determined root cause within 4 hours, it automatically escalates to SEV-2 and the full IR team is activated.

External escalation triggers should also be predefined: when to engage outside forensics firms (any SEV-1, or any SEV-2 involving potential data exfiltration), when to notify law enforcement (confirmed criminal activity, ransomware with ransom demand), when to activate cyber insurance (any incident that may result in a claim), and when to engage legal counsel (any incident involving regulated data or potential litigation exposure).

Evidence Preservation

Evidence preservation is where technical execution intersects with legal requirements. Digital evidence that is not properly preserved — with documented chain of custody, forensic imaging before remediation, and tamper-evident storage — may be inadmissible in legal proceedings and insufficient for regulatory investigations.

The IR plan should include specific evidence preservation procedures: image affected systems before wiping or rebuilding them, preserve logs from the earliest available timestamp (SIEM, cloud audit logs, application logs, network flow data), document the timeline of discovery and response actions with timestamps, and photograph or record physical evidence if relevant. Store forensic images on write-once media or in tamper-evident cloud storage with restricted access.

Critical detail: Ensure log retention policies are sufficient before an incident occurs. If your SIEM retains logs for 30 days and the attacker has been in the environment for 60 days, you have lost half the investigation timeline. Set log retention to at least 90 days for security-relevant logs, and 365 days for authentication and access logs.

Post-Incident Review

The post-incident review (also called a retrospective or lessons-learned meeting) is the mechanism that converts incidents into security improvements. Every incident at SEV-3 or above should have a formal review within two weeks of resolution. The review should be blameless — focused on process failures, detection gaps, and response improvements rather than individual performance.

Structure the review around five questions: What happened (factual timeline)? How did we detect it (and how could we have detected it sooner)? What went well in the response? What did not go well? What specific changes will we make to prevent recurrence or improve response? Document the answers and assign action items with owners and deadlines. Track these action items to completion — a post-incident review that generates recommendations no one implements is theater.

Tabletop Exercise Design

A tabletop exercise is a discussion-based simulation of an incident scenario. The facilitator presents an evolving scenario, and the participants walk through their response decisions using the IR plan. Tabletop exercises validate that the plan is understood, identify gaps in procedures or role assignments, and build the decision-making muscle memory that responders need during real incidents.

Effective tabletop exercises share several characteristics: they use realistic scenarios based on current threat intelligence (not hypothetical attacks that would never target your organization), they include participants from all relevant functions (not just security), they introduce complications as the scenario progresses (the backup system is also compromised, the media calls, a key responder is unavailable), and they end with a structured debrief that captures findings and action items.

Run at least two tabletop exercises per year with different scenarios. Rotate participants to ensure broad organizational preparedness. Document each exercise and the improvements it identified. Auditors for SOC 2, ISO 27001, and other frameworks increasingly expect evidence of regular tabletop exercises as part of incident response program maturity.

For help building, testing, and refining your incident response plan — including facilitated tabletop exercises with realistic attack scenarios — contact Lorikeet Security. Our team designs IR programs that are built for actual incidents, not just auditor review.

Lorikeet Security Team

Penetration Testing & Cybersecurity Consulting

We've completed 170+ security engagements across web apps, APIs, cloud infrastructure, and AI-generated codebases. Everything we publish here comes from patterns we see in real client work.