Building Incident Response Plans as Code: The Counteractive Template Approach
Hook
Most incident response plans are comprehensive documents gathering dust—lengthy files that no one reads until it’s too late. Counteractive Security’s template flips this: a concise, directive plan built like software.
Context
Security teams face a documentation paradox. Compliance frameworks like NIST SP 800-61r2 demand comprehensive incident response plans, yet these documents rarely get used during actual incidents. When ransomware hits at 2 AM, responders need checklists, not theoretical frameworks. They need to know who to call, what to isolate, and how to preserve evidence—not wade through pages of policy. Traditional IR plans fail because they’re optimized for compliance audits rather than crisis response.
Counteractive Security recognized this gap and built a template that treats incident response documentation as code. Rather than starting from a blank Word document or copying a consultant’s generic plan, teams get a modular system built on developer-familiar tools: Makefiles for builds, YAML for configuration, Mustache for templating, and Markdown for content. The result is a plan that lives in version control, supports peer review through pull requests, and outputs multiple formats (HTML, PDF, DOCX) from a single source of truth. With 764 GitHub stars, it’s become a widely-adopted resource for security teams who think like engineers.
Technical Insight
The template’s architecture separates content, configuration, and build logic cleanly. At the foundation sits info.yml, a YAML configuration file containing organization-specific variables that populate placeholders throughout the Markdown templates. These placeholders use Mustache syntax—the same double-brace convention familiar from templating engines across dozens of languages.
The configuration drives customization through template variables. The README describes info.yml as containing values for template strings throughout the plan, with placeholders that {{LOOK_LIKE_THIS}}. The Makefile orchestrates the entire build pipeline, invoking mustache to perform variable substitution, then pandoc to convert the merged Markdown into multiple output formats.
The Makefile workflow performs these steps:
# Install dependencies
sudo apt-get install make ruby-mustache pandoc
# For PDF format
sudo apt-get install texlive-latex-base texlive-fonts-recommended texlive-fonts-extra texlive-latex-extra
# Build the template
makeThis merges the template components, combines them with your custom data from info.yml, and outputs all supported formats in the public/ directory.
The modularity extends to content organization. The template divides the plan into distinct phases and concerns: during.md contains the core of the plan with actions taken during incident response, after.md covers after-action review (also known as hotwash, debrief, or post-mortem), and the playbooks/ directory holds threat-specific runbooks following the convention playbook-[THREAT].md. Each playbook includes investigation, remediation, and communication suggestions for specific incidents. The roles/ directory defines responsibilities for each incident response role, with files following the convention role-[ORDER]-[NAME].md, containing descriptions of each role along with duties and training notes.
This structure enables incremental improvement. A team might start with the base template and generic playbooks, then add custom playbooks for incidents that are highly likely or highly damaging for their organization. They commit it to git, another team member reviews via pull request, and the next make run incorporates it automatically. The plan evolves alongside the organization’s threat landscape.
The templating approach also solves a critical operational problem: consistency across formats. Security teams need HTML versions for internal wikis, PDFs for executive briefings, and DOCX files for compliance auditors who demand editable documents. Maintaining three separate files guarantees drift. With pandoc’s format conversion, the team edits one Markdown source and generates all three formats identically. When organization details change, updating info.yml and running make propagates the change everywhere.
For teams uncomfortable with command-line builds, the repository provides a pre-built Word version (plan.docx) in the examples directory. Organizations can download this Word file and customize directly, though the Makefile path provides better long-term maintainability for teams comfortable with these tools.
Gotcha
The toolchain dependencies create real friction for some organizations. Running make successfully requires installing make, ruby-mustache, and pandoc—manageable on Linux/Mac but painful on Windows without WSL. PDF generation compounds this by requiring a full LaTeX distribution (texlive-latex-base, texlive-fonts-recommended, texlive-fonts-extra, texlive-latex-extra), adding substantial dependencies. For security teams working in locked-down Windows environments where installing open-source tooling requires enterprise approval cycles, this becomes a non-starter.
More importantly, the template provides structure, not content. The playbooks include TODO prompts for likely areas to customize, and organizations need to create playbooks for any incidents that are highly likely or highly damaging for their organization. What’s your actual ransomware response? Which file shares get disconnected? Who has authority to take production systems offline? These critical decisions aren’t something a template can provide. Expect to invest significant effort customizing playbooks with your architecture details, escalation paths, legal requirements, and communication protocols. The template accelerates plan creation by providing structure and best practices, not by delivering finished content. It’s scaffolding, not a turnkey solution.
The README emphasizes filling in organization-specific information, particularly the critical information list (data you want to protect) and critical asset list (systems you want to protect). If you don’t have this information, that’s worth fixing before attempting to deploy any incident response plan.
Verdict
Use if: You’re building or modernizing an IR plan and want something concise that your team will actually reference during incidents. Your security engineers are comfortable with developer workflows (git, Make, Markdown) and value version-controlled documentation. You need multi-format output from a single source and want to avoid the drift that comes from maintaining separate Word/PDF/HTML files. You understand this is a framework requiring substantial customization, not finished documentation. Skip if: You need a fully-written plan ready to use without extensive customization work—this template demands you fill in organization-specific details and create playbooks for your threat landscape. Your team works exclusively in Windows without WSL access or ability to install open-source CLI tools like Make, Mustache, and Pandoc. You need only a Word document and prefer to work directly in that format without version control—the examples directory provides a pre-built DOCX version that may better suit this workflow. You require comprehensive compliance documentation beyond tactical response procedures—this template prioritizes actionable, directive guidance over exhaustive policy coverage.
