Runbooks

Authored by:

Isaac Patka

SEAL | Shield3

🔑 Key Takeaway: Runbooks cut cognitive load during active incidents. Customize every command and contact for your stack; untested generic runbooks can be worse than none.

Step-by-step guides for specific incident types. Use these during active incidents to reduce cognitive load and ensure consistent response.

These runbooks are examples and starting points. They contain generic guidance that must be adapted to your specific protocol, infrastructure, and team. Review each runbook carefully and customize the commands, contacts, and procedures before relying on them during an actual incident. Untested runbooks can be worse than no runbook at all.

What this framework covers

Critical (P1)

1. Smart Contract Exploit: active exploit or critical vulnerability.
2. Key Compromise: private key or signer compromise.
3. Frontend Compromise: website/UI compromise (routes to specialized runbooks below).
4. DNS Hijack: domain/DNS compromise.
5. CDN/Hosting Compromise: CDN or hosting provider compromise.
6. Dependency Attack: npm/package supply chain attack.
7. Build Pipeline Compromise: CI/CD compromise.

High/Moderate (P2-P3)

1. DDoS Attack: denial of service attacks.
2. Third-Party Outage: external provider issues.

Creating New Runbooks

Use Runbook Template as your starting point.

Good runbooks:

• Are concise. Responders need quick answers
• Include actual commands and links
• Get tested in tabletop exercises
• Get updated after real incidents

Suggested Runbooks to Add

Consider creating runbooks for:

See Incident Response Policy for the overall response process.

Further reading

• Incident Response Template overview: how the template pieces fit together
• Incident Response Policy: severity levels, roles, and escalation
• Runbook Template: the blank structure for writing your own
• Incident Management overview: how the pages of this framework fit together