Draft an Incident Response Plan

You've spent weeks hardening your code, locking down dependencies, and running threat models on your architecture. But when the alarm fires at 2 a.m. — a database exfiltration, a leaked API key, a ransomware note on a production server — do you actually know what to do next? Most teams freeze, not because they lack security skills, but because they never wrote the incident response plan that tells them who does what, when, and how. Without a plan, every minute of chaos costs data, trust, and money. In this lesson, you'll learn to draft a security incident response plan — a living document that turns panic into procedure.

The problem this lesson solves

The cost of improvisation

When an incident strikes, your brain doesn't think in terms of logs, playbooks, or escalation paths — it thinks in terms of fight or flight. Without a pre-defined plan, teams wing it: the on-call engineer guesses who to call, the security lead tries to remember the backup location, and the comms manager starts drafting a tweet without knowing what's actually public. This improvisation leads to delayed containment, destroyed evidence, and inconsistent messaging.

Why you need a plan before you need a plan

A security incident response plan is not bureaucracy — it's a fire escape route for your systems. It answers the five Ws: Who is on the response team, What constitutes an incident, When to escalate, Where evidence lives, and Why every action is logged. The plan exists to make the right decision the default decision, even when adrenaline is high.

Pro tip: If you can't answer "who do I call at 3 a.m. for a suspected breach?" without opening a spreadsheet, you don't have a plan yet — you have a hope.

Core concept / mental model

The incident response lifecycle

Think of incident response not as a single event, but as a loop — a cycle that repeats and improves. The industry-standard model, from NIST SP 800-61, defines four core phases:

1. Preparation — Build the plan, train the team, stock the tools.
2. Detection & Analysis — Identify the incident, contain it, and figure out scope.
3. Containment, Eradication & Recovery — Stop the spread, remove the threat, restore services.
4. Post-Incident Activity — Learn, document, and improve the plan.

Your plan is the handbook for this loop. It doesn't stop at "call someone" — it maps each phase to concrete actions, owners, and deadlines.

Plan vs. playbook: what's the difference?

People often confuse the two. A plan is the high-level strategy: who, what, when, where. A playbook is the tactical checklist for a specific incident type (e.g., "Ransomware Playbook" or "Credential Leak Playbook"). Your plan references your playbooks; it's the table of contents for your entire response capability.

How it works step by step

Step 1: Assemble your response team

Start by naming the core roles. You don't need a full SOC — even a two-person startup needs clear ownership:

• Incident Commander — the single decision-maker who coordinates.
• Lead Investigator — owns technical analysis (log analysis, memory forensics).
• Communications Lead — handles internal and external updates (including legal/PR).
• Scribe — logs every action and timestamp for the post-mortem.

Define who is primary and who is backup for each role. In a small team, one person may wear multiple hats, but the plan must state which hat is worn first.

Step 2: Define what counts as an incident

A plan is useless if it doesn't say when to activate it. Create a simple severity matrix — for example, Critical (active data exfiltration), High (known vulnerability exploited in production), Medium (suspicious but unconfirmed), Low (noise/investigation). Define criteria: "If data was likely accessed by an unauthorized party, escalate to Critical immediately." State explicitly how to report an incident — a ticketing system, a dedicated Slack channel, or a phone tree.

Step 3: Outline detection and analysis procedures

Specify exactly what to do when an alert fires:

1. Triage — Verify the alert is real, not a false positive.
2. Preserve evidence — Snapshot the machine, copy logs, and capture memory before rebooting.
3. Analyze — Identify the entry point, lateral movement, and data affected.
4. Contain — Isolate affected systems (disconnect from network, revoke keys).

Step 4: Define containment, eradication, and recovery steps

For each incident type, list the immediate actions: kill switch processes, rotate credentials, apply patches, restore from clean backups, and verify system integrity. Always sequence containment before eradication — you can't clean a system if the attacker is still inside.

Step 5: Specify communication and notification

Who needs to know, and when? Include:

• Internal: executive team, legal, HR, affected departments.
• External: customers, partners, regulators, law enforcement.
• Template messaging so you don't write a press release under stress.

Check your legal obligations — data breach notification laws (GDPR, HIPAA, CCPA) have strict deadlines. Your plan should list those deadlines.

Step 6: Build the post-incident review process

Every incident ends with a post-mortem. Schedule it within 5 days, out number what happened, what worked, what didn't, and update the plan. This is how the loop closes.

Hands-on walkthrough

Now you'll draft a minimal incident response plan as a structured Markdown file — something you can version-control with your team.

Create the template

Start with a skeleton file:

# Incident Response Plan

## 1. Team & Contacts
| Role | Name | Primary Contact | Backup Contact |
|------|------|----------------|----------------|
| Incident Commander | TBD | TBD | TBD |
| Lead Investigator | TBD | TBD | TBD |
| Comms Lead | TBD | TBD | TBD |
| Scribe | TBD | TBD | TBD |

## 2. Severity Definitions
- **Critical**: Active exploitation or confirmed data exfiltration.
- **High**: Exploited vulnerability without active data loss.
- **Medium**: Suspicious activity, unconfirmed.
- **Low**: False positive or no impact.

## 3. Incident Reporting
- Report via: [security@example.com] or [Slack #incident]
- On-call phone: [NOC number]

## 4. Response Workflow
1. **Triage**: Verify alert, assign severity.
2. **Preserve**: Snapshot affected systems, copy logs.
3. **Contain**: Isolate, revoke access.
4. **Eradicate**: Remove threat, apply patches.
5. **Recover**: Restore from clean backups, verify integrity.
6. **Post-mortem**: Schedule review and update plan.

## 5. Communication Plan
- Internal: Email executive team within 1 hr.
- External: Template messages for customers/regulators.
- Legal: Check notification deadlines (GDPR: 72 hrs).

## 6. Post-Incident Review
- Schedule review within 5 days.
- Document lessons learned, update plan.

Pro tip: Use a Markdown table for contacts — it renders clearly in GitHub and Confluence.

Automate part of the plan with Python

Let's write a small Python script that generates a checklist from your plan when an incident is declared. This gives you a structured checklist to follow — no more panic about forgetting steps.

import dataclasses
from dataclasses import dataclass, asdict
import json
import datetime

@dataclass
class Incident:
    id: str
    severity: str
    reported_at: str
    steps: list

    def checklist(self):
        return [f"{i+1}. {step}" for i, step in enumerate(self.steps)]

# Define the steps based on your plan's workflow
STEPS = [
    "Triage: Verify the alert is real.",
    "Preserve: Snapshot systems and copy logs.",
    "Contain: Isolate affected systems.",
    "Eradicate: Remove threat and apply patches.",
    "Recover: Restore from clean backups.",
    "Post-mortem: Schedule review.",
]

# Simulate declaring an incident
incident = Incident(
    id="INC-001",
    severity="HIGH",
    reported_at=datetime.datetime.now(datetime.timezone.utc).isoformat(),
    steps=STEPS,
)

print(f"Incident {incident.id} declared at {incident.reported_at}")
print("\n".join(incident.checklist()))

# Optionally save as JSON for a web dashboard
with open("incident_checklist.json", "w") as f:
    json.dump(asdict(incident), f, indent=2)

Expected output:

Incident INC-001 declared at 2025-01-01T09:00:00+00:00
1. Triage: Verify the alert is real.
2. Preserve: Snapshot systems and copy logs.
3. Contain: Isolate affected systems.
4. Eradicate: Remove threat and apply patches.
5. Recover: Restore from clean backups.
6. Post-mortem: Schedule review.

Test your plan with a tabletop exercise

The real test of a plan is a tabletop exercise — a simulated incident where you walk through the steps with your team, no actual systems harmed. Use a scenario like: "A developer's laptop was infected with a keylogger, and credentials were sent to an external IP. What do you do?" Your plan should guide every action, from informing the Incident Commander to rotating API keys.

Compare options / when to choose what

Design styles for incident response plans

Single document vs. modular playbooks

• Single document — simpler for small teams, but becomes brittle as it grows.
• Modular playbooks — better for larger orgs; each incident type gets a separate playbook that the main plan links to. Choose modular if your team has more than ~10 members or several product areas.

Troubleshooting & edge cases

Common pitfalls

• Trying to write the perfect plan before any incident — perfect is the enemy of good. Start minimal, then iterate after real events.
• Forgetting to include the 24/7 contact list — your plan is useless if you can't reach anyone at 2 a.m.
• Over-engineering severity definitions — a 5-level matrix confuses more than it helps; stick to 3–4 levels.
• Not testing the plan — a plan that has never been exercised will have gaps. Run a tabletop drill quarterly.

Edge cases to plan for

• Unavailable primary contact — always define backups.
• Cloud provider outage — your plan should include instructions for contacting your cloud provider's security team.
• Local legal requirements — notify deadlines vary by region; include them explicitly.

What you learned & what's next

You now know how to draft a security incident response plan — a structured document that defines your team, severity levels, reporting processes, and a complete response workflow. You've seen a ready-to-use template, and you've automated part of the process with a Python checklist generator. You've also learned that the plan is a living artifact that must be tested and refined.

Key takeaways for this lesson

• Incident response is a cycle: prepare, detect, contain, eradicate, recover, and review.
• The plan defines roles, severities, workflow, and communication — it's the fire escape route for your systems.
• A plan without testing is just paper — run tabletop exercises regularly.
• Automation can help — but automation is only as good as the plan it follows.
• The plan must be versioned and stored where the team can find it — next to your README, not in a forgotten wiki.

What's next in this track

In the next lesson, you'll learn how to conduct a post-incident review — turning incidents into improvements. You'll apply the post-mortem step from your plan to real-world scenarios, so you can continuously strengthen your security posture. This is where the loop closes and your plan gets smarter every time.