Incident Response
How to Build an Incident Response Plan Before You Need One
The core structure every incident response plan needs, regardless of company size.
LOZULA Senior Security Research Team
2026-03-17
8 min read
Key Takeaways for Security Teams
- The best incident response plans are tested before an incident, not written during one.
- Clear decision authority prevents the most common early mistake: nobody empowered to make a fast call.
- Evidence preservation needs to be a deliberate step, not an afterthought once systems are already being cleaned up.
An incident response plan written during an actual breach is written under panic, with no time to think clearly. The plans that actually work are the ones drafted, tested, and rehearsed well before they are needed.
The Core Sections Every Plan Needs
A workable plan does not need to be long, it needs to be specific enough that someone can follow it under pressure.
- •Roles and decision authority: who declares an incident, who can take systems offline
- •A communication tree with contact details that stay current, including out-of-band channels if primary systems are affected
- •Containment steps specific to your architecture, not generic advice
- •A predefined evidence-preservation procedure so forensic analysis is not compromised by well-meaning cleanup
Why Tabletop Exercises Matter
A plan nobody has rehearsed is a plan nobody actually follows correctly under real pressure.
- •Run a tabletop exercise at least twice a year with a realistic scenario for your stack
- •Include non-engineering stakeholders, legal and communications decisions matter as much as technical ones
- •Update the plan based on what the exercise actually reveals, not just what looks good on paper