Incident Response

Incident response is the disciplined process of handling a security incident so that damage is minimized and recovery is fast. Two frameworks dominate, and they agree far more than they differ.

The SANS model defines six phases, memorized as PICERL:

1. Preparation — build the capability before you need it.
2. Identification — determine that an incident is actually occurring and scope it.
3. Containment — stop the bleeding; limit spread.
4. Eradication — remove the attacker and their footholds.
5. Recovery — restore systems to normal, monitored operation.
6. Lessons Learned — capture what happened and improve.

The NIST model (SP 800-61) uses four phases that map cleanly onto the same work: Preparation; Detection & Analysis; Containment, Eradication & Recovery; and Post-Incident Activity.

Every experienced responder will tell you the same thing: incidents are won or lost in Preparation, long before the pager goes off. This is the unglamorous work that determines whether the response is a controlled operation or a panicked scramble.

Preparation includes:

• A written, approved Incident Response Plan and named Incident Commander role.
• A trained CSIRT (Computer Security Incident Response Team) with a clear on-call rotation.
• Playbooks for common scenarios — ransomware, BEC, data exfiltration, account compromise.
• Tooling ready to go: EDR deployed, logging centralized, forensic and out-of-band communication tools staged.
• Backups that are tested for real restores, kept offline or immutable so ransomware cannot encrypt them.
• Retainer relationships with external IR firms and legal counsel, plus contact trees.

Once an incident is confirmed and scoped, the operational core begins. Containment comes first — stop the spread before removing anything. Responders distinguish short-term containment (isolate a host, block a C2 domain, disable an account) from long-term containment (temporary fixes that let business limp on while you prepare eradication).

Eradication removes the root cause and every artifact: malware, persistence mechanisms, attacker-created accounts, backdoors, and the vulnerability that let them in. If you eradicate the malware but leave the unpatched entry point, you are simply scheduling the next incident.

Recovery restores systems to production under heightened monitoring, validating they are clean and watching for the attacker's return. Recovery is deliberate and staged — rushing infected systems back online is how a "resolved" incident reignites. A key decision is whether to rebuild from known-good images (safest) or clean in place (faster, riskier).

An incident is also a potential legal and regulatory event, so how you handle evidence matters. Chain of custody is the documented, unbroken record of who collected, handled, transferred, and stored each piece of evidence, and when. If that chain is broken, the evidence may be inadmissible in court or unusable for attribution and insurance claims.

Preserve first, analyze second. You can always decide not to prosecute, but you can never un-destroy the evidence you overwrote.

Practically, this means working on forensic copies (write-blocked images), hashing evidence to prove integrity, and logging every action with timestamps and handler names.

Communication during an incident is its own discipline. Internally, a single Incident Commander coordinates and a defined cadence of updates prevents chaos and duplicated effort. Externally, obligations pile up fast: breach-notification laws (GDPR's 72-hour rule for supervisory authorities, US state laws, sector rules like HIPAA), regulators, customers, law enforcement, and cyber-insurers who often require early notice. Legal counsel is typically looped in immediately, sometimes to shelter the investigation under privilege.

The final phase — Lessons Learned (NIST: Post-Incident Activity) — is where mature teams pull real value from a bad day. Within a couple of weeks of resolution, the team runs a blameless postmortem: a factual reconstruction of the timeline, root cause, what worked, what failed, and concrete, owned action items with deadlines.

Blameless is the operative word. If people fear punishment, they hide facts, and you lose the truth you need to improve. The target is the system that allowed the incident, not the individual who clicked the link. Those action items then flow back into Preparation — new detections, closed gaps, updated playbooks — closing the loop.

You do not have to wait for a real breach to practice. Tabletop exercises are facilitated, discussion-based simulations where the team walks through a realistic scenario ("ransomware just hit finance; the CEO's laptop is encrypted; a journalist is calling") and talks through decisions. They are cheap, expose broken assumptions — a stale contact list, an ambiguous decision authority, an untested backup — and build the muscle memory that makes real responses calm.