The worst moment to decide who is in charge, where to talk and whether to shut a server down is in the middle of an incident. Under pressure, people improvise, evidence gets destroyed by well-meant cleanup, and three different stories reach customers. A runbook written in advance removes most of those decisions.

Incident response is a structured approach to detecting, responding to and recovering from security incidents, with the goal of limiting impact and restoring normal operations. This post turns the standard lifecycle into a runbook for a small company. It is deliberately short; a runbook nobody reads is worse than none.

The lifecycle

The widely used NIST model describes incident response as a cycle. Its 2025 revision maps the work onto the Cybersecurity Framework functions, but the practical phases remain recognisable:

  1. Preparation: people, tools and plans in place before anything happens.
  2. Detection and analysis: noticing something and deciding what it is.
  3. Containment: stopping the damage from spreading.
  4. Eradication: removing the attacker's access and the cause.
  5. Recovery: restoring normal service safely.
  6. Post-incident activity: learning and improving.

The phases overlap. You often contain one part of an incident while still analysing another.

Preparation: what must exist before day one

  • An incident channel and bridge that does not depend on systems that might be compromised. A separate chat workspace or a phone bridge works; keep the details printed or in a password manager everyone can reach.
  • A contact list: on-call engineers, management, legal counsel, insurer, cloud provider support, key vendors, and the regulator's breach notification channel.
  • Access for responders: break-glass accounts with MFA, tested quarterly, for cloud accounts and identity provider.
  • Logging in place with enough retention to investigate, protected from deletion.
  • Backups that are isolated and tested by restoring.
  • This runbook, plus short playbooks for the most likely incident types: account takeover, ransomware, data exposure, lost device, malicious insider.

Severity levels

Agree on levels in advance so everyone knows what "SEV1" means:

Level Definition Response
SEV1 Confirmed breach of sensitive data, ransomware, or attacker with admin access All hands, incident commander, leadership and legal informed within 1 hour
SEV2 Confirmed compromise of a limited account or system, no evidence of data access yet Incident commander and on-call, leadership informed same day
SEV3 Suspicious activity under investigation On-call security owner
SEV4 Policy violation or low-impact event Ticket, normal working hours

Start high when unsure. Downgrading is easy; catching up after under-reacting is not.

Roles

Even with three people, assign roles explicitly. One person can hold more than one in a small incident.

  • Incident commander (IC): owns decisions and priorities, keeps the timeline moving, does not do hands-on investigation.
  • Technical lead: coordinates investigation and containment work.
  • Scribe: records the timeline, decisions and evidence locations as they happen.
  • Communications lead: drafts internal and external messages, works with legal.
  • Subject matter experts: engineers for the affected systems, pulled in as needed.

Detection and analysis

When an alert or report arrives:

  1. Open an incident record with time, reporter and initial facts. Start the timeline.
  2. Assign an IC and a severity.
  3. Answer the first questions: what is affected, since when, is it ongoing, what data or systems are at risk?
  4. Preserve evidence before changing anything (see below).
  5. Define the scope: identities, hosts, accounts and data involved. Expect the scope to grow.

Keep hypotheses and facts separate in the notes. "We think the key leaked from CI" is a hypothesis until a log proves it.

Evidence handling

Evidence decides what you can prove later to customers, insurers, regulators and possibly courts.

  • Take snapshots of affected disks and volumes before rebuilding instances.
  • Export relevant logs to a separate, write-protected location and record where and when.
  • Capture volatile data such as running processes and network connections from live hosts if you have the tooling; it disappears on reboot.
  • Record the hash of each evidence file and who handled it, a simple chain of custody.
  • Do not "clean up" an attacker's tools or accounts until they are documented.

If the incident may involve law enforcement or litigation, bring in an external forensics firm early; your insurer may require a specific one.

Containment

Containment buys time. Short-term actions stop active damage; longer-term actions keep the attacker out while you prepare eradication.

Typical short-term actions:

  • Disable compromised accounts and revoke all their sessions and tokens.
  • Isolate affected hosts from the network using EDR or security groups, rather than powering them off, so memory evidence survives.
  • Block attacker IP addresses and domains at the edge.
  • Rotate exposed secrets, starting with the most privileged.

Balance containment against intelligence. Cutting off an attacker you have only partly scoped can make them switch to access you have not found yet. The IC makes that call explicitly.

Eradication

Remove everything the attacker added and close the way in:

  • Delete persistence: new users, keys, scheduled tasks, startup items, OAuth grants, inbox rules.
  • Rebuild compromised hosts from known-good images instead of trying to clean them.
  • Patch or reconfigure the vulnerability that allowed entry.
  • Rotate all credentials the attacker could have seen, not only those you know were used.

Recovery

Restore service in stages and watch closely:

  • Restore data from backups taken before the compromise, verified clean.
  • Bring systems back gradually, with extra monitoring on the affected areas.
  • Define what "back to normal" means and who decides it.
  • Keep heightened monitoring for weeks; returning attackers are common.

Communication

Prepare templates in advance and get legal review for external messages. Three audiences:

  • Internal: what happened, what employees should do (or not do), where to ask questions. Keep details need-to-know while the investigation runs.
  • Customers and partners: facts, impact on them, what you are doing, what they should do, when you will update next. No speculation.
  • Regulators and authorities: many privacy laws have short deadlines, such as 72 hours under GDPR from becoming aware of a personal data breach. Know yours before you need it.

A good update rhythm during a SEV1 is internal updates every hour and external updates at agreed times, even if there is nothing new.

Post-incident review

Within two weeks, hold a blameless review:

  1. Build the full timeline from the scribe's notes and logs.
  2. Identify what went well, what went badly and where luck played a part.
  3. Find contributing causes in process and technology, not individuals.
  4. Agree on actions, each with an owner and a date, and track them like any other work.
  5. Update the runbook and playbooks with what you learned.

Also record the final report: impact, scope, root cause, notifications made, and evidence locations. Keep it with the evidence for the retention period your legal team sets.

The one-page version

Print this and put it where the team can find it:

  1. Open an incident record and start a timeline.
  2. Assign an incident commander and a severity.
  3. Move to the incident channel; invite only who is needed.
  4. Preserve evidence before changing systems.
  5. Contain: disable accounts, isolate hosts, rotate secrets.
  6. Inform leadership and legal per severity.
  7. Eradicate persistence and close the entry point.
  8. Recover in stages with extra monitoring.
  9. Communicate with prepared templates and fixed update times.
  10. Review within two weeks and track the actions.

Key takeaways

  • Decide roles, severity levels and channels before an incident, not during one.
  • Preserve evidence before containment actions destroy it.
  • Containment stops damage, eradication removes access, recovery restores service; they overlap.
  • Communication needs templates, legal review and a fixed rhythm.
  • A blameless review with tracked actions is what makes the next incident smaller.

References