What Is Incident Response?

The phases: NIST 800-61 and SANS PICERL

The two reference frameworks - NIST SP 800-61 and the SANS incident handling process, often abbreviated PICERL - describe the same work with different groupings:

The difference is bookkeeping, not substance. What matters is that your team can name the phase it is in - each phase has a different goal, and mixing them (eradicating before you have finished scoping, for instance) is how attackers survive response efforts.

1. Preparation. Everything you do before an incident: contact lists, playbooks, logging that actually covers critical systems, access to forensic tooling, and practice. This is the phase most teams underfund - and the one that decides how the others go.
2. Identification. Confirm that an event is an incident, scope it - which systems, which accounts, since when - and classify severity. Resist the urge to fix things during this phase: every change can destroy evidence and tip off the attacker.
3. Containment. Limit the blast radius: isolate hosts, disable accounts, block attacker infrastructure. Short-term containment stops the bleeding; longer-term containment keeps the business running while you prepare eradication.
4. Eradication and recovery. Remove the attacker's access and presence - malware, persistence mechanisms, compromised credentials - then restore systems from known-good state and watch closely for re-entry.
5. Lessons learned. Within days, while memory is fresh: what happened, what worked, what did not, and what changes - new detections, closed gaps, updated playbooks. This phase separates teams that improve from teams that repeat.

Severity triage: not every incident is a crisis

Treating everything as critical is as damaging as treating nothing that way: people burn out, and real crises drown in the noise. Most teams use three or four severity levels, assigned at identification and revisited as scope changes. Four questions do most of the work:

• Data sensitivity - does the affected system hold regulated, confidential or customer data?
• Spread - is this one workstation, or credentials that work across the whole environment?
• Business impact - is revenue-generating or safety-relevant operation affected?
• The regulatory clock - does this trigger notification duties (GDPR's 72 hours, sector rules), and when did the clock start?

Severity decides tempo. A low-severity incident can wait for business hours; a critical one activates the full team, an incident lead and executive communication - immediately.

The first 48 hours

The opening hours of a serious incident set the tone for everything after. A rough map of what good looks like:

• Hours 0-2: confirm the incident is real, open a dedicated out-of-band communication channel, name an incident lead, and start a timeline log - every action, every time, every decision.
• Hours 2-12: scope before you fix. Which accounts, hosts and data are touched? Apply short-term containment where the risk of spread outweighs the value of quiet observation.
• Hours 12-24: brief leadership with facts, not speculation. Involve legal if regulated data may be affected, and preserve forensic evidence - disk images, volatile memory - before rebuilding anything.
• Hours 24-48: move from reaction to plan: eradication steps, recovery order, communication cadence. If the incident exceeds your capacity or crosses legal thresholds, external IR support should already be engaged by now - not under consideration.

The most common early mistake is quiet remediation: wiping a machine before scoping is done. It feels productive, and it destroys exactly the evidence you need to answer the question that matters most - are they still in?

Who does what: roles in an incident

Titles vary; functions do not. A workable minimum, even in a small team where one person wears several hats:

• IR lead (incident commander) - owns decisions and tempo, and shields the technical team from status-meeting overhead.
• Communications lead - one voice toward leadership, legal, regulators and customers. Nobody else communicates outward.
• Forensics and analysis - establishes what actually happened: entry point, lateral movement, persistence, exfiltration.
• Scribe - keeps the timeline. It sounds clerical; it is priceless in the post-incident review and in any legal aftermath.

Measuring response: MTTD, MTTR and what they hide

Two metrics dominate IR reporting: MTTD, mean time to detect - how long attackers dwell before you notice - and MTTR, mean time to respond or to recover, depending on who is speaking; define which one you mean. Both are worth tracking. Neither tells the whole story, because averages hide outliers, and a single unnoticed intrusion sits outside both numbers entirely.

Close the loop: response is how defense improves

The phases end with lessons learned for a reason. Every real incident is ground truth about your environment that no vendor report can match: it tells you which detections fired and which should have, which playbook steps worked, and which assumptions failed.