Incident Response Plan Builder
Build a complete, written incident response plan from a short questionnaire. Enter your org name, IR team roles, in-scope incident types, severity tiers and notification needs, and the builder assembles a structured plan organised around the NIST SP 800-61 lifecycle — Preparation; Detection & Analysis; Containment, Eradication & Recovery; and Post-Incident Activity. Copy it or download it as Markdown. Everything runs in your browser; nothing is uploaded. It's a general template to adapt, not legal advice.
Leave a contact blank to emit a [TBD] placeholder in the plan.
What this tool is
- A free, in-browser incident response plan (IRP) template builder: answer a short questionnaire and generate a complete, written IR plan you can copy or download as Markdown.
- The generated plan is structured around the four phases of the NIST SP 800-61 computer-security incident-handling lifecycle: Preparation; Detection & Analysis; Containment, Eradication & Recovery; and Post-Incident Activity.
- You fill in the parts only your organisation knows — org name, IR team roles and contacts, in-scope incident types, severity and escalation tiers, notification list, and which regulatory regimes apply — and the builder supplies sensible defaults for everything else.
- In-scope incident types (ransomware, business email compromise, data breach, credential compromise, DDoS, insider threat) each add type-specific containment and recovery guidance to the plan.
- Everything runs client-side — nothing you type is sent anywhere. This is a general template to adapt, not legal advice; have counsel review your actual notification obligations.
Why a written incident response plan matters
A security incident is the worst time to be inventing your process. Under pressure, people hesitate over questions that have obvious answers in calmer moments: who is allowed to declare an incident, who speaks to customers and regulators, when do we isolate a production system, who approves taking a service offline. A written incident response plan settles those questions in advance so the response is fast, consistent and defensible. It is also increasingly expected of you — cyber-insurance underwriters, enterprise customers' security questionnaires, and common frameworks all ask whether a formal, exercised IR plan exists.
The NIST SP 800-61 lifecycle
This builder structures the plan around the four phases of the incident-handling lifecycle described in NIST Special Publication 800-61 (the Computer Security Incident Handling Guide). The phases form a loop, not a one-way line — in a real incident, detection and containment iterate as you learn more.
- Preparation. Everything you do before an incident: the plan itself, the team and their authority, tooling and logging, training, and tabletop exercises. The strength of this phase decides how the others go.
- Detection & Analysis. Recognising that an incident is happening, triaging the signal, classifying its severity, scoping what is affected, and documenting the timeline as you go.
- Containment, Eradication & Recovery. Limiting the damage (short- and long-term containment while preserving evidence), removing the attacker and the root cause, and restoring systems to verified-clean normal operation with heightened monitoring.
- Post-Incident Activity. The lessons-learned review: what happened, what worked, what to change — feeding concrete improvements back into Preparation so the next response is better.
What belongs in the plan
The generated document fills out each of the sections a working IR plan needs, from your answers plus sensible defaults:
- Purpose & scope — what the plan covers and the systems and people it applies to.
- Roles & responsibilities — the IR team roster: incident lead, communications, legal, executive sponsor and technical responders, each with a named contact.
- Severity & escalation tiers — a classification scheme so the response matches the stakes, with target response times and escalation targets.
- In-scope incident types — with type-specific containment and recovery guidance for the scenarios you select.
- Communications & notification — internal and external, including a generic description of regulatory notification regimes you flag as relevant.
- Contact list & plan maintenance — key contacts to fill in, and a schedule to review and exercise the plan.
Not legal advice. The generated plan is a general template to adapt to your organisation. Its regulatory-notification section describes common regimes (for example GDPR's 72-hour expectation and US state breach-notification laws) generically — your actual obligations depend on your jurisdictions, the data involved and your contracts. Have qualified legal counsel review the notification obligations before you rely on the plan.
Frequently asked questions
What is an incident response plan?
An incident response plan (IRP) is a written document that defines how an organisation detects, responds to, and recovers from a cybersecurity incident. It names the incident response team and their roles, sets out how incidents are classified by severity and escalated, describes the step-by-step process for handling an incident, and lists who must be notified — internally and externally — and when. A written, tested plan matters because incidents are high-pressure and time-sensitive: deciding who declares an incident, who talks to regulators, and when to isolate a system during the event itself wastes the hours that matter most. Frameworks such as NIST SP 800-61 exist precisely so organisations do that thinking in advance.
What is the NIST SP 800-61 incident response lifecycle?
NIST Special Publication 800-61 (the Computer Security Incident Handling Guide) describes incident response as a continuous lifecycle with four phases. Preparation covers everything done before an incident: the plan itself, the team, tooling, training and exercises. Detection & Analysis is identifying that an incident is occurring, triaging it, determining scope and severity, and documenting it. Containment, Eradication & Recovery is limiting the damage, removing the attacker and the root cause, and restoring systems to normal, verified operation. Post-Incident Activity is the lessons-learned review that feeds improvements back into Preparation. The phases are a cycle, not a straight line — detection and containment often iterate as an incident unfolds. This builder produces a plan organised around these exact four phases.
Why do I need a written incident response plan?
During an incident, people act faster and more consistently when the decisions have already been made. A written plan removes ambiguity about who has authority to declare an incident, who owns communications and legal, how severity is judged, when systems get isolated, and which external parties must be told. It also supports obligations that increasingly expect a documented, tested plan: cyber-insurance applications, customer and vendor security questionnaires, and regulatory and framework requirements all commonly ask whether a formal IR plan exists and is exercised. Having the plan is step one; rehearsing it with tabletop exercises is what makes it work under pressure.
What should an incident response plan include?
At minimum: a clear purpose and scope; the incident response team roster with named roles and contacts (IR lead, communications, legal, executive sponsor, and technical responders); a severity-classification and escalation scheme so the response matches the stakes; the handling process across the NIST SP 800-61 phases (preparation, detection & analysis, containment/eradication/recovery, and post-incident review); a communications and notification plan covering internal stakeholders, customers, law enforcement and regulators; contact lists for everyone who might need to be reached; and a maintenance schedule for reviewing and exercising the plan. Type-specific guidance for your most likely incidents — ransomware, business email compromise, data breach and so on — makes the plan actionable rather than generic.
Is the generated plan legal advice, and does it cover breach-notification law?
No. The output is a general-purpose template to adapt to your organisation, not legal advice. It describes common regulatory notification regimes generically — for example that the EU/UK GDPR generally expects notification of a personal-data breach to the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware, and that all US states have their own data-breach notification laws with varying timelines — but your actual obligations depend on where your affected individuals are, the data involved, and your contracts. Always have qualified legal counsel review the notification sections against the specific laws and regulators that apply to you. Nothing you type into this tool is transmitted; it runs entirely in your browser.