Free interactive tool · no account

Build an incident response plan you could actually run at 2 a.m.

Most incident response plans are written to satisfy an auditor and have never been read by the person who would have to use one. This builds the other kind. Nine steps, fifty-eight sections you choose from, thirteen diagrams, and a formatted Word document at the end with your own logo on the cover.

About 40 minutes
9 steps
58 sections
13 diagrams
Word, HTML or PDF
No login

Everything you type stays in your browser. No account, no upload, no server. We never see your plan, your contact roster or your gaps — and you do not have to take our word for it. Open your browser's developer tools, watch the Network tab, and work through the whole thing: the planner makes no requests. Your plan is yours, and it leaves only when you export it.

Works best on a laptop · your progress is saved in this browser

Built your plan? The next step is testing it.

A plan nobody has exercised is a document, not a capability. If you would like a second pair of eyes on what you have just written — or a tabletop run against it — we will spend thirty minutes on it with you. You bring the plan; we never had a copy.

Book a 30-minute review See the other tools

What the planner actually produces

Nine steps, in this order. Each one writes a section of the finished document; you choose which of the fifty-eight sections you want and skip the rest.

01 Company information
02 Governance and roles
03 Contact roster
04 Severity model
05 Communications
06 Preparation
07 External resources
08 Playbooks and sections
09 Review and export

The output is a formatted Word document with your own logo on the cover, plus HTML and print options. It is a document you own, not a subscription you rent.

Why most incident response plans fail

Not because they are wrong. Because of how they are built and where they live. Three failure modes are documented well enough to design against, and the planner is shaped around them.

The plan nobody can reach

A plan that exists only in the document management system is a plan that exists only until the document management system is encrypted, and the same is true of the contact roster. CISA and the FBI put it plainly in their joint guidance: maintain up-to-date hard copies of plans so responders can access them if the network is inaccessible. That is why this planner exports a printable document rather than keeping your plan on our server.

Severity levels with nothing attached to them

Severity exists to attach a response obligation to an incident, fast and without argument. A level with no obligation attached is decoration — a label people argue about at 2 a.m. instead of a trigger that wakes somebody up. Step 4 asks you to define what each level actually obliges, not just what it is called.

Containing what you can see

The best-documented failure in incident response is premature containment. Responders find the compromised systems they know about, remove them, and feel productive. Mandiant's articulation, from Black Hat USA 2012, is that each defensive action may prompt the adversary to react: responders tip their hand, the attacker abandons the burned tooling, keeps the access nobody found, and the organization stays blind — usually until an outside party tells it, again, that it is still compromised. A plan that does not say who may authorize containment, and when, produces exactly this.

The playbooks that go inside it

Step 8 is where the plan stops being a policy document and becomes something runnable. A plan tells you who decides; a playbook tells you what to do. Fourteen of them are published free, in full, on this site — written so somebody who has never read the book can open one mid-incident and run it.

The fourteen scenario playbooks → Ransomware, business email compromise, account takeover, identity provider compromise, supply chain, insider threat, data breach, DDoS, deepfake fraud, Kubernetes, AI systems, edge devices, web applications and OT. Chapter 13 — The Incident Response Lifecycle → The model behind this planner: severity, incident command, containment, evidence, recovery, and the documented failure modes above in full. Appendix B — The Playbook Template → The blank template, a worked example, and the review checklist to run before you publish a playbook of your own. The Blast Radius → If you hold administrative access into other companies' estates, the plan above is only half of it. The companion volume is written for that case.

All of it free and in full, with no email wall — part of The 2026 InfoSec Playbook, a 288,000-word field manual by Daniel Ramos with every claim cited to a primary source.

What this tool does not do

It does not make the plan true. It produces a well-structured document from what you tell it, and every name, number and deadline in it still has to be confirmed with the person whose name is against it. An untested contact tree is a list of hopes. Dial it, twice a year, on a day nobody expects.

It also does not replace counsel. Regulatory notification deadlines vary by jurisdiction, sector and what was taken; the plan should record who your lawyer is, not what your lawyer would say.