The Incident Response Process: The 6 Phases Every SOC Analyst Should Know

Something's wrong. An alert fired, a laptop is acting weird, and now everyone's looking at you. What do you actually do?

That's what the incident response process is for. It's the playbook that turns a chaotic "we've been hacked" moment into a calm, repeatable set of steps.

If you want a SOC job, you need to know these six phases cold. Interviewers ask about them constantly, and once you're on the job, you'll live inside them. Let's walk through it.

Wait—What Even Counts as an "Incident"?

Quick definition first, because people trip on this.

An event is anything that happens on a system—a login, a file download, a service restart. Millions happen every day. Most are totally boring.

An incident is an event (or series of events) that actually threatens security. A confirmed malware infection. A stolen credential being used. Data walking out the door.

The job of a SOC analyst is separating the boring events from the real incidents—and when it's a real one, kicking off the response process.

The 6 Phases of Incident Response

The most widely taught model comes from SANS, and it's got six phases. (NIST uses four, but they cover the same ground—don't stress about the difference.)

Here's the whole lifecycle.

Phase 1: Preparation

This is everything you do before anything goes wrong.

Writing playbooks, setting up logging, building an asset inventory, making sure people know who to call. Boring? A little. But this is the phase that decides whether an incident is a bad afternoon or a bad month.

The teams that handle incidents well aren't lucky. They prepared.

Phase 2: Identification

Something looks off—now you confirm whether it's real.

This is where you live as a SOC analyst. An alert fires, you dig into the logs, you check the endpoint, and you answer one question: is this an actual incident or a false alarm?

Good identification means knowing what normal looks like so the abnormal jumps out. If you've never seen what a real investigation feels like, this is the phase that eats most of your day.

Phase 3: Containment

You've confirmed it's real. Now stop the bleeding.

Containment is about limiting damage without destroying evidence. That might mean isolating a machine from the network, disabling a compromised account, or blocking a malicious domain.

There's short-term containment (stop it now) and long-term containment (keep it stable while you plan the cleanup). The instinct to "just wipe everything" is usually wrong—you need to understand the attack first.

Phase 4: Eradication

Now you actually remove the threat.

Delete the malware, close the vulnerability that let them in, kill the persistence mechanisms, reset the credentials the attacker touched. The goal is making sure they can't just walk back in through the same door.

This is where understanding the full attack matters. Miss one backdoor and you're right back where you started.

Phase 5: Recovery

Get the business back to normal—carefully.

Restore systems from clean backups, bring services back online, and watch them like a hawk to make sure the attacker doesn't return. You don't flip everything back on at once; you do it in a controlled way and keep monitoring.

The big question here: "are we sure it's clean?" Rushing recovery is how organizations get re-compromised a week later.

Phase 6: Lessons Learned

The part everyone skips—and shouldn't.

Within a week or two of closing the incident, the team gets together and asks: what happened, how did we do, and what do we change? The findings feed straight back into Phase 1 (Preparation), which is why people draw this whole thing as a loop.

This is also where good detection improvements come from. A missed alert here becomes a new detection rule tomorrow—the heart of detection engineering.

Why Is This a Loop, Not a Line?

Because incident response never really "ends."

Every incident teaches you something. That lesson makes your preparation better, which makes your next identification faster, which makes containment cleaner. Round and round.

The best SOC teams treat every incident as free training. The attacker showed you a gap—now you close it before the next one.

Where Does a SOC Analyst Actually Fit?

Real talk: as an entry-level analyst, you're not running the whole show.

You'll spend most of your time in Identification—triaging alerts, confirming incidents, and escalating the real ones. You'll help with Containment under guidance. Senior analysts and IR specialists usually own Eradication and Recovery.

But you need to understand all six phases, because you're the first link in the chain. If you miss an incident during identification, none of the other phases ever happen. That's a big part of what your day looks like in your first SOC job.

A Quick Example: Phishing Turns Into an Incident

Let's make it concrete.

A user reports a weird email. You investigate (Identification) and find they clicked the link and entered their password. Confirmed incident.

You disable their account and isolate their laptop (Containment). You remove the malware that got dropped and force a password reset (Eradication). You restore their machine from a clean image and monitor their account for a few days (Recovery). Then the team meets and decides to roll out phishing-resistant MFA (Lessons Learned).

Six phases, one real scenario. That's the job.

TL;DR – Six Phases, One Loop

Incident response runs in six phases: Preparation, Identification, Containment, Eradication, Recovery, and Lessons Learned. As a SOC analyst you'll mostly live in Identification and Containment, but you need to understand the whole loop. Every incident feeds lessons back into preparation—that's what makes the process get smarter over time.

---

FAQs

What's the difference between the SANS and NIST incident response models?

SANS uses six phases; NIST uses four (Preparation; Detection & Analysis; Containment, Eradication & Recovery; Post-Incident Activity). They describe the same lifecycle—NIST just groups some phases together. Learn the six-phase version and you'll understand both.

Which incident response phase do entry-level SOC analysts work in most?

Identification. You'll spend the bulk of your time triaging alerts and confirming whether something is a real incident. You'll assist with containment too, but eradication and recovery are usually led by senior analysts and IR specialists.

Do I need to memorize the phases for a SOC interview?

Yes—this is one of the most common SOC interview questions. Know the six phases in order, be able to explain each in a sentence, and have a simple example ready (like walking a phishing incident through all six).

---

Sources & References:

- SANS Incident Handler's Handbook

- NIST SP 800-61: Computer Security Incident Handling Guide

- CISA Incident Response Resources

---

Final thought: Incident response isn't about being a hero who saves the day. It's about being calm and methodical when everyone else is panicking. The process is what keeps you calm—so learn it until it's second nature.

How EpicDetect Can Help

Want to practice this for real—not multiple choice, an actual investigation? Adventures Season Zero drops you into a story-driven SOC case where you'll work an incident from first alert to containment. It's completely free.

Want structured lessons alongside it? Head to the EpicDetect Atlas for SIEM fundamentals, log analysis, and MITRE ATT&CK-tagged challenges.

New here? Sign up and start for free. No credit card required.