Most organizations without a formal incident response plan believe they'll simply figure it out if something happens. In practice, the middle of an actual security incident is the worst possible time to be deciding who's in charge, who needs to be called, and what "contained" even means. A plan doesn't need to be elaborate to be genuinely useful — it needs to exist and be known before it's needed.
The six phases
Most incident response frameworks, including NIST's widely referenced model, break down into six phases. Even a lightweight plan should touch each one:
| Phase | What it covers |
|---|---|
| 1. Preparation | Building the plan itself, defining roles, ensuring tools and backups are in place before anything happens |
| 2. Identification | Recognizing that an incident is actually occurring, and determining its scope |
| 3. Containment | Stopping the incident from spreading further — isolating affected systems without necessarily destroying evidence |
| 4. Eradication | Removing the actual cause — malware, a compromised account, an exploited vulnerability |
| 5. Recovery | Restoring affected systems to normal operation, with verification that the threat is actually gone |
| 6. Lessons learned | A honest post-incident review — what worked, what didn't, what changes as a result |
Roles even a small team needs to define ahead of time
You don't need a large dedicated security team to have clear roles. At minimum, decide in advance: who has the authority to take a system offline if needed, who communicates with employees and (if relevant) customers, and who's the external point of contact if you need to bring in outside help — a specialized incident response firm, legal counsel, or law enforcement.
The first-hour checklist
- Confirm it's real — is this an actual incident or a false positive?
- Contain without destroying evidence — isolate affected systems from the network rather than immediately wiping them
- Notify the predetermined internal team, not the entire company, until scope is understood
- Start a timeline log immediately — what was observed, when, and what actions were taken — this becomes invaluable during the lessons-learned phase and for any compliance or insurance requirements
- Assess whether this needs to be reported externally — depending on industry and data involved, there may be legal notification requirements with tight deadlines
Why the lessons-learned phase gets skipped, and shouldn't
After an incident is resolved, the instinct is often to move on as fast as possible. Skipping a genuine post-incident review means the same gap that allowed this incident often stays open for the next one. A short, honest debrief — not a blame exercise — closes that loop.
Building this from nothing? Start here.
Don't try to write a comprehensive 40-page plan on the first attempt. Write a one-page document naming who's in charge, who gets called, and what the first three actions are for the most likely scenario your business actually faces — often ransomware or a compromised email account. A short plan that exists and is known beats a thorough plan that's still in draft when something happens.