Generate an incident response playbook or operational runbook from twelve templates. Add your contacts, roles and frameworks, export to Markdown or PDF.
Most organisations that lack an incident response plan do not lack one because they think it is unnecessary. They lack one because writing the first draft from an empty page is miserable, and the generic templates you find online are too abstract to follow at 2 a.m. This generator starts you from a structured, phase-by-phase template for the specific incident type you care about, layers your organisation’s context and contact details onto it, and exports a document you can circulate.
The whole process runs in your browser. Contact names, phone numbers, organisation details and the finished playbook never leave your device — which matters, because a completed IR playbook is a map of who to call and what your response capability is, and that is not a document to paste into an online service.
State the obvious up front: the output is a starting template, not a finished plan. It has not been reviewed by your legal counsel, it does not know your regulatory obligations, your architecture, your contractual notification deadlines or your cyber-insurance policy’s requirements. Treat it as a first draft to be reviewed, corrected and exercised before it is relied upon.
Two modes, twelve templates:
Each template is broken into phases with concrete, ordered steps. The ransomware playbook, for example, runs through Preparation (verify backup integrity, document critical assets), Detection & Analysis (confirm the infection, determine scope), Containment (isolate infected systems, secure backups), Eradication (remove the ransomware, reset all credentials), Recovery (restore from backup, gradual network reconnection) and Post-Incident (conduct a review, implement improvements). Templates carry the compliance frameworks and external guidance they map to — the ransomware template references NIST SP 800-61r3 and the CISA Ransomware Response Guide.
Incident response playbooks generated here follow the lifecycle from the NIST Computer Security Incident Handling Guide: Preparation, Detection & Analysis, Containment, Eradication & Recovery, and Post-Incident Activity. Structuring a playbook this way is not box-ticking — each phase answers a different question, and skipping one is how incidents go wrong.
Preparation is the phase that determines everything else, and it is the only one you can do before an incident. Detection & Analysis is about establishing what is actually happening and how far it goes, which is where most responses lose time. Containment, Eradication & Recovery is deliberately a single grouped phase because the three overlap in practice: containing without understanding scope leaves you eradicating the same intrusion twice. Post-Incident Activity is the phase most often skipped and the only one that improves your next response.
Worth knowing: NIST published SP 800-61 Revision 3 in April 2025, which rewrote the guidance around the six CSF 2.0 functions — Govern, Identify, Protect, Detect, Respond, Recover — and shifted emphasis toward incorporating incident response into ongoing cybersecurity risk management, with continuous improvement running throughout rather than a single lessons-learned meeting at the end. The four-phase lifecycle these playbooks use remains the practical operational structure and maps cleanly onto the newer functions; if you are formally profiling against CSF 2.0, read Revision 3 directly.
Incident response playbooks include an evidence preservation checklist, because the instinct during an incident — reboot it, reimage it, get it back — destroys exactly what you need for investigation, insurance claims, regulatory notification and any legal action. The checklist covers documenting the scene, capturing volatile data such as RAM, running processes and network connections before anything else, taking forensic disk images with write-blockers before making changes, preserving system, application, security and network device logs, maintaining chain-of-custody documentation, hashing evidence with SHA-256 and recording it in an evidence log, and storing evidence on write-protected media in a secure location.
The ordering matters more than the list. Volatile data is gone the moment the machine is powered off, so it comes first. If your organisation has cyber insurance or is likely to need law enforcement, agree in advance who decides when to pull a machine off the network versus leave it running for capture — that decision is much harder to make well under pressure.
| Incident response playbook | Operational runbook | |
|---|---|---|
| Triggered by | An adversary or a security event | A planned change or a service failure |
| Scope | Uncertain at the start; discovered as you go | Known in advance |
| Key pressure | Evidence, notification deadlines, containment | Change control, rollback, uptime |
| Who leads | Incident Commander | Change or service owner |
Both benefit from being written down in advance; they are just different documents. The generator supports both because most teams need both and the discipline of writing them is the same.
Named people, not job titles. “The Security Team” is not a phone number. Every role should have a primary and a backup with contact details that were verified this quarter.
Decision authority stated explicitly. Who can take production offline? Who authorises paying a ransom, or refusing to? Who speaks to press? Deciding this during an incident wastes the hours that matter most.
An out-of-band communication channel. If your response plan lives in the systems the attacker has compromised, and your coordination happens in the chat tool that is now down or untrusted, you have no plan. Print it, and agree a fallback channel.
Exercised, not filed. A playbook that has never been walked through in a tabletop exercise is a hypothesis. The exercise is where you discover the on-call number belongs to someone who left, the backup restore takes eleven hours rather than two, and nobody knows who calls the insurer.
Reviewed on a schedule. Annually at minimum, and after every real incident and every significant architecture change.
Pair the playbook with a policy from the security policy generator, size the exposure it addresses with the quantitative risk analysis tool, and check your programme coverage against the framework with the NIST CSF mapper. During a live phishing incident, the phishing email analyzer and email header analyzer help with the analysis step.
No. It is a structured starting template. It needs review by your security, legal and operations leads, correction against your actual architecture and obligations, and a tabletop exercise before you rely on it.
Six incident response scenarios — ransomware, data breach, DDoS, phishing campaign, insider threat and supply chain compromise — plus six operational runbooks covering production deployment, service outage, database failover, backup and restore, security patching and planned maintenance.
Markdown, which drops straight into Confluence, Notion, a Git repository or a wiki, and PDF for printing and distribution. Keep a printed copy somewhere reachable when your systems are not.
No. Everything runs in your browser and the export is generated locally. Contact details, organisation name and the finished playbook never leave your device.
It helps you produce the document those requirements expect, and it lets you tag which frameworks apply. It does not certify anything. Frameworks such as SOC 2, ISO 27001, HIPAA and PCI-DSS also require that the plan be maintained, communicated and tested — the document alone is not the control.
Incident response playbooks are structured around the standard lifecycle — Preparation, Detection & Analysis, Containment/Eradication/Recovery, and Post-Incident Activity — and templates reference the guidance they draw on. Revision 3, published in April 2025, reorganises the guidance around the CSF 2.0 functions; read it directly if you are building a formal CSF profile.
At least annually, after every real incident, and whenever people or architecture change. Stale contact details are the single most common defect in an otherwise good plan.
A playbook responds to a security incident where scope is initially unknown and evidence handling matters. A runbook executes a known operational procedure such as a failover or a deployment. The generator produces either.
An incident response playbook is a documented, step-by-step procedure for detecting, containing, eradicating, and recovering from a specific type of security incident. Unlike a general incident response plan (which defines roles, escalation paths, and overall strategy), a playbook provides tactical instructions for a particular scenario — ransomware, data breach, phishing compromise, insider threat, or DDoS attack.
Playbooks transform incident response from improvisation under pressure into repeatable, tested procedures. Organizations with documented playbooks reduce mean time to respond (MTTR), minimize damage from incidents, and meet compliance requirements for incident response documentation.
| Phase | Activities | Key Outputs |
|---|---|---|
| Preparation | Tools ready, team trained, contacts documented | Readiness verification checklist |
| Detection & Analysis | Identify indicators, confirm the incident, assess scope | Incident classification and severity |
| Containment | Stop the spread — short-term and long-term containment | Containment confirmation |
| Eradication | Remove the threat — malware, compromised accounts, backdoors | Clean system verification |
| Recovery | Restore systems, verify functionality, monitor for recurrence | Systems restored to normal |
| Post-Incident | Lessons learned, timeline documentation, improvements | Post-incident report |
| Playbook | Trigger | Critical First Actions |
|---|---|---|
| Ransomware | Encryption detected, ransom note found | Isolate affected systems, preserve evidence, assess backup status |
| Phishing compromise | User reports clicking link, credential theft suspected | Reset credentials, check email rules, scan for lateral movement |
| Data breach | Unauthorized data access or exfiltration detected | Identify affected data, contain access, begin breach notification assessment |
| DDoS attack | Service degradation, traffic spike | Activate DDoS mitigation, implement rate limiting, notify CDN/ISP |
| Insider threat | Anomalous data access, policy violation detected | Preserve evidence, restrict access, coordinate with HR/Legal |
| Business email compromise | Fraudulent email from compromised executive account | Lock account, notify finance, reverse fraudulent transactions |
The Incident Response Playbook Generator is a free tool that helps organizations create customized security incident response playbooks and operational runbooks. It guides you through a 5-step wizard to select templates, add organization context, assign team roles, customize procedures, and export professional documentation in PDF or Markdown format.
You can create two types of playbooks: Security Incident Response playbooks for handling ransomware, data breaches, DDoS attacks, and phishing incidents, or Operational Runbooks for deployments, service outages, database failover, backup and restore, patching, and planned maintenance windows. Each type has multiple pre-built templates to choose from.
The templates include guidance aligned with major compliance frameworks including HIPAA, PCI DSS, SOC 2, NIST CSF, GDPR, ISO 27001, CCPA, and CMMC. You can select which frameworks apply to your organization, and the generated playbook will include relevant compliance considerations and notification requirements.
Yes, the tool allows you to assign primary and backup contacts for each team role including Incident Commander, Technical Lead, Communications Lead, Security Analyst, IT Operations, Legal Counsel, and Executive Sponsor. You can add names, email addresses, phone numbers, and Slack or Teams handles for each role.
You can export your completed playbook in two formats: PDF for a professional, print-ready document that can be stored offline and shared with stakeholders, or Markdown for easy integration with documentation systems like Confluence, GitHub wikis, or other knowledge management platforms.
Your playbook data is saved locally in your browser using localStorage so you can resume editing later. However, no data is transmitted to our servers. Your organization details, team contacts, and customizations remain entirely on your device until you choose to export the final document.
After exporting, store your playbook in an easily accessible location such as a shared drive or wiki. Conduct tabletop exercises to validate the procedures with your team. Review and update the playbook at least annually or after any actual incident. Ensure all team members know where to find the playbook and keep contact information current.
Build detection queries for Splunk SPL, Elastic KQL, and Microsoft Sentinel. Includes presets for authentication, network, malware, and threat hunting with MITRE ATT&CK mappings.
Extract indicators of compromise (IOCs) like IPs, domains, URLs, hashes, and emails from text for threat intelligence
Aggregate threat intelligence from multiple feeds and look up IPs, domains, and file hashes across sources in one place.