The incident response lifecycle

An incident is not the moment to invent a process. Teams that respond well decided roles, severity levels and communication channels long before something broke.

NIST SP 800-61PagerDuty / OpsgenieSlack or Teams incident channelticketing and case managementTheHiverunbooks in version control

The phases

NIST's incident handling guide describes a cycle that most programs adopt in some form. Treat it as a loop, not a line: what you learn feeds preparation.

Preparation: policy, an on-call rota, tools and access in place, logging that answers questions, practiced playbooks, contact lists (legal, communications, vendors, regulators).
Detection and analysis: recognize that something is wrong, decide whether it is an incident, scope it, and assign a severity.
Containment: stop it from spreading or getting worse, with the least disruption that works, while preserving evidence.
Eradication and recovery: remove the attacker's access and the cause, restore systems from known-good state, and watch closely as they come back.
Post-incident activity: a , lessons, and changes to detection, controls and playbooks.

Roles and communication

: owns the response, makes decisions, and does not do the hands-on work.
Technical leads: investigate and contain, one per workstream (endpoint, identity, cloud, network).
Communications: internal updates on a schedule, and external messages to customers, partners and regulators, approved by legal.
Scribe: keeps a timeline with timestamps in UTC of what was seen and done and by whom.
Use one channel as the source of truth, and one out-of-band channel in case the main one is compromised.

Severity and a record

Agree on severity levels in advance so people do not argue about them during the event, and open a record the moment you declare.

incident-record.ymlyaml

id: INC-2026-0142
declared_at: 2026-10-13T14:05:00Z      # always UTC
severity: SEV2                          # SEV1 customer data or core outage; SEV2 contained but serious; SEV3 minor
commander: a.silva
summary: Suspicious sign-ins to the admin console from a new country
scope:
  affected: [identity-provider, admin-console]
  data_at_risk: none confirmed
timeline:
  - { at: 2026-10-13T13:52:00Z, event: "Alert fired: impossible travel", by: detection }
  - { at: 2026-10-13T14:05:00Z, event: "Incident declared", by: a.silva }
next_update: 2026-10-13T15:00:00Z

Principles that hold in every incident

Preserve evidence before you change things: snapshot, copy logs, record what you did.
Contain proportionally: shutting down production is sometimes right and often an overreaction.
Assume the attacker is watching: do not announce the plan on the channel they may be reading.
Decide with incomplete information, then update as facts arrive.
Write it down as you go; memory under stress is unreliable.
Practice with tabletop exercises so the first time is not the real one.

Postmortemblameless reviewA written review of an incident that asks how the system allowed it, not who erred, and ends with owned actions.see in glossary →Incident commanderICThe person who owns the response and makes decisions, while others do the hands-on work. Keeping these roles apart prevents the leader from disappearing into the technical details.see in glossary →

connections on the map

The incident response lifecycleis carried out byTriage, scoping and containment
The incident response lifecycleis informed byThreat intelligence

updated on 14/10/2026 · sources to go deeper · report an error

in other domains

Crisis communication and security culturegrccommunication is a track of the same response cycle
Runbooks, response and post-incident hardeningsecopsrunbooks are the rehearsed, written-down cycle

Unlocks

test what you learned

Loading questions…