Published 2026-04-08

A Primer on Incident Response

Published 2026-04-08 | Originally published February 2002, updated for 2026

We first published this article in February 2002 — six months after 9/11 and in the middle of the Code Red and Nimda worm outbreaks. The four-phase incident response framework we described then anticipated what later became the standard model used by NIST (SP 800-61), SANS, and every major IR framework since.

Twenty-four years later, the threats are different — ransomware, supply chain attacks, AI-augmented phishing — but the fundamentals haven't changed. No matter how much time, money, and technology you throw at your security program, Mr. Murphy will eventually get the last laugh. The question is whether you're ready when he does.

What Is a Security Incident?

An incident is any condition or activity that compromises, or may lead to the compromise, of the confidentiality, integrity, or availability of your information systems. That includes obvious events like ransomware infections and data breaches, but also the subtle ones: a misconfigured cloud storage bucket, an employee clicking a phishing link and entering credentials, or a vendor whose own breach exposes your data.

The definition matters because it sets the threshold for your response. If your definition is too narrow ("a breach is when data leaves the network"), you'll miss the early warning signs that would have prevented the breach entirely.

The Four Phases

Phase 1: Detection

Early detection is the difference between a contained incident and a catastrophe. Threat agents — whether automated tools or human adversaries — spend hours, days, or weeks in preparatory intelligence gathering before the actual attack. This reconnaissance is detectable if you're looking for it.

What's changed since 2002: We now have SIEM platforms, EDR/XDR, threat intelligence feeds, and AI-powered anomaly detection. These tools are valuable. But the fundamental truth hasn't changed: a diligent human reviewing alerts and logs catches things that automated systems miss. Too often, organizations collect terabytes of log data and never look at it — the SOC dashboard is green, so everything must be fine.

Detection requires both technology and human vigilance. Invest in both.

Phase 2: Response

Response is a cycle of assessment and containment, repeated until the incident is controlled. Each cycle answers two questions: how bad is it? and what can we contain right now?

Response requires:

• A plan that people have actually read. It's not enough to write policy documents. Your IR plan must be understood by everyone who will execute it — including non-IT staff who may be the first to notice something wrong.
• Clear escalation paths. Who makes the call to isolate a system? Who notifies the board? Who talks to the press? These decisions need to be made in advance, not during the incident.
• Cross-functional involvement. Incident response is not just an IT function. Legal, communications, compliance, clinical operations (in healthcare), and executive leadership all have roles.
• Immediate documentation. Document everything as it happens. Memory is unreliable under stress, and you'll need the timeline for regulators, law enforcement, and your own post-incident analysis.

What's changed since 2002: The 72-hour regulatory reporting requirement (now adopted or proposed by HIPAA, NCUA, SEC, and others) means your response process must identify, classify, and report incidents faster than ever. If your IR plan doesn't account for regulatory notification timelines, it's incomplete.

Phase 3: Recovery

Recovery restores lost functionality. But you face a fundamental tension: evidence preservation versus business continuity.

Evidence priority: Isolate affected systems without altering them. Preserve logs, disk images, and memory dumps. Engage forensic investigators. This takes time — days, weeks, sometimes months — and the affected systems remain offline throughout.

Recovery priority: Rebuild from clean backups on fresh hardware. Get the business running again as fast as possible. This may destroy evidence that would have been useful for prosecution or root cause analysis.

In most cases, business recovery takes precedence. But make the decision deliberately, not by default. And ensure your backup and recovery procedures are tested — a backup you've never restored is a hypothesis, not a plan.

What's changed since 2002: Ransomware with data exfiltration creates a new dimension. Restoring from backup addresses the encryption, but the exfiltrated data is already gone. Recovery now includes assessing what was taken, who's affected, and what notification is required — not just getting systems back online.

Phase 4: Analysis

After the incident is contained and systems are recovered, analyze what happened. Not to assign blame, but to improve. What did the detection systems miss? Where did the response plan break down? What would you do differently?

This phase is the one most organizations skip. The crisis is over, everyone's exhausted, and there's pressure to move on. Resist that pressure. The analysis phase is where incidents become institutional knowledge instead of recurring nightmares.

What we said in 2002 that's still true: "You will never eliminate incidents, but you can become very good at responding to them." That remains the goal.

What Hasn't Changed in 24 Years

• Human judgment is irreplaceable. Automated tools detect patterns. Humans understand context. You need both.
• Communication is the hardest part. Technical responders are rarely the best communicators. Plan for this.
• Documentation must happen in real time. Not reconstructed from memory a week later.
• Testing is non-negotiable. An untested IR plan is a wish list. Run tabletop exercises. Run them annually at minimum.
• Good IR doesn't require enormous budgets. Human factors matter more than technology. A well-trained team with a clear plan outperforms a poorly organized team with a $2M SIEM.