Building an Incident Response Plan with Makefiles and Mustache Templates

Hook

When attackers breach your systems at 2 AM, your incident response plan shouldn't require a search party to find it. Yet most organizations either have no plan at all, or one so bloated with compliance theater that security teams ignore it during actual emergencies.

Context

The incident response paradox has plagued security teams for decades: comprehensive plans sit unused because they're too complex, while simple checklists lack the specificity needed for actual incidents. Industry frameworks like NIST SP 800-61 provide excellent guidance but read more like academic papers than operational playbooks. Commercial platforms solve coordination problems but lock teams into proprietary ecosystems and subscription models that small teams can't justify.

The counteractive/incident-response-plan-template emerged from this gap, created by security consultants who saw the same pattern repeatedly: organizations needed actionable, customizable documentation that could be version-controlled, reviewed, and deployed quickly. Rather than building another SaaS platform, they took a developer-centric approach—treating the incident response plan as code that could be built, tested, and deployed using familiar engineering tools. The result is a template system that generates multi-format response plans from modular markdown files, bridging the gap between heavyweight frameworks and inadequate ad-hoc procedures.

Technical Insight

At its core, this project implements a documentation build pipeline that transforms modular content into multiple output formats. The architecture separates content (markdown files), configuration (YAML), templating (Mustache), and build orchestration (Make). This separation allows teams to maintain organization-specific details separately from the universal incident response structure.

The build process starts with info.yml, where you define your organization's critical variables:

company_name: Acme Corporation
security_email: security@acme.com
security_phone: +1-555-0100
escalation_contact: Jane Doe (CISO)
escalation_phone: +1-555-0101
business_hours: 9 AM - 5 PM Pacific
after_hours_oncall: PagerDuty rotation

These variables populate throughout the template using Mustache syntax. For example, the during.md file contains sections like:

## Initiate

When you suspect an incident has occurred:

1. [ ] Stay calm and start documenting
2. [ ] Contact security team: {{security_email}} or {{security_phone}}
3. [ ] Escalate to {{escalation_contact}} if during business hours ({{business_hours}})
4. [ ] For after-hours: {{after_hours_oncall}}

The Makefile orchestrates the transformation pipeline. When you run make, it processes templates with mo (a Mustache implementation), concatenates sections, and invokes Pandoc for format conversion:

all: pdf html docx

pdf: build/plan.pdf
html: build/plan.html
docx: build/plan.docx

build/plan.md: $(wildcard *.md) info.yml roles/*.md playbooks/*.md
	cat before.md > $@
	mo during.md info.yml >> $@
	cat roles/*.md >> $@
	cat playbooks/*.md >> $@
	mo after.md info.yml >> $@

build/plan.pdf: build/plan.md
	pandoc $< -o $@ --toc --pdf-engine=xelatex

The modular structure shines in the playbooks directory. Rather than a one-size-fits-all approach, teams create threat-specific playbooks as separate markdown files. A phishing playbook might look like:

# Playbook: Phishing Response

## Indicators
- Suspicious emails reported by users
- Unusual login patterns after email interaction
- Credential harvesting site flagged

## Response
1. [ ] Identify affected users from email logs
2. [ ] Force password reset for confirmed victims
3. [ ] Check authentication logs for unauthorized access
4. [ ] Block sender domain/IP at email gateway
5. [ ] Send organization-wide awareness alert
6. [ ] Review MFA enrollment for affected accounts

This modularity means teams maintain only the playbooks relevant to their threat model. A fintech company might have playbooks for wire fraud and transaction manipulation, while a healthcare provider focuses on ransomware and data exfiltration scenarios.

The roles directory follows similar principles, defining specific responsibilities during incidents. Instead of vague "incident commander" descriptions, you get actionable checklists:

# Role: Incident Commander

**Who:** {{escalation_contact}}

## Responsibilities
- [ ] Declare incident severity level
- [ ] Assemble response team
- [ ] Make containment/recovery decisions
- [ ] Authorize external communications
- [ ] Coordinate with legal/PR if needed
- [ ] Call all-clear when resolved

The beauty of this approach is version control integration. Your incident response plan lives in Git alongside infrastructure code and runbooks. Changes go through pull requests. You can tag releases, diff versions, and maintain separate branches for testing versus production plans. When compliance auditors ask for your incident response documentation, you generate a timestamped PDF from a specific commit.

Gotcha

The biggest hurdle is the toolchain requirement. Generating the plan requires Make, Mustache (mo), Pandoc, and LaTeX for PDF output—tools that security teams often don't have installed or understand. While the repository provides a Word document alternative, that defeats the automation and version control advantages. Organizations without DevOps culture may find the barrier too high, even though the README includes installation instructions for multiple platforms.

More fundamentally, this template provides structure, not content. You still need deep organizational knowledge to populate critical sections. Who actually has authority to authorize a datacenter shutdown? What's the REAL after-hours escalation path, not the org chart fiction? Which assets are truly critical versus those teams CLAIM are critical? The template can't answer these questions—it just makes their absence glaringly obvious through placeholder text. Teams expecting a fill-in-the-blanks form will be disappointed; this requires serious stakeholder interviews and decision-making. The template's value is organizing those decisions consistently, not making them for you.

Verdict

Use if: You're a mid-sized organization (50-5000 employees) establishing or modernizing incident response capabilities, your team values infrastructure-as-code principles and uses Git workflows, you need audit-ready documentation without commercial platform costs, or you're a consultant needing consistent deliverable templates across clients. The build automation pays off when you maintain multiple variants (different business units, acquired companies, client engagements) or update plans quarterly as your infrastructure evolves. Skip if: Your security team lacks command-line comfort and won't invest in learning the toolchain, you need real-time collaboration features during active incidents (this generates static documents, not war room dashboards), you're in a highly regulated industry requiring prescriptive compliance mappings (HIPAA, PCI-DSS) beyond generic best practices, or you have fewer than 20 employees where informal processes still work. Also skip if you've already invested in platforms like PagerDuty or Atlassian Jira Service Management—this template solves documentation problems, not incident coordination workflow.