Learn · Incident Response

Incident Response

The process a SOC follows from first alert to closed incident, the frameworks that describe it, and how each case on the Range practices one part of it.

Not yet read in this browserSign in to see where you have applied this.

Why it matters

Every organization with something worth protecting eventually has an incident. What separates a controlled response from a chaotic one is a process people know before they need it, not individual heroics.

The frameworks give a team a shared vocabulary. When you say an incident is contained but not eradicated, everyone in the room should know what is done and what is not.

What analysts see

In a working SOC the process shows up as three things.

A case or ticket that moves through phases: reported, triaged, investigated, contained, closed.
Decisions with trade-offs: isolate a host now, or watch a little longer to learn more.
Reporting duties that run alongside the technical work: who must be told, how fast, and through which channel.

A case on the Range starts at investigation: the attack is over, and your job is to establish what happened and what it touched.

Core concept

SANS: the practitioner's steps. Preparation, Identification, Containment, Eradication, Recovery and Lessons Learned. This is the sequence most analysts think in while an incident is live. The judgment calls sit between the steps: when containment is safe, when eradication is really complete, when recovery is not premature.

NIST CSF 2.0: the organization's frame. Six functions: Govern, Identify, Protect, Detect, Respond and Recover. Govern, added in 2024, makes cybersecurity risk a leadership responsibility rather than something IT handles alone.

NIST SP 800-61 Rev. 3: incident response inside CSF 2.0. Published in April 2025, it supersedes the older four-phase guide. Govern, Identify and Protect are preparation. Detect, Respond and Recover are the response itself. Improvement runs through all of it, so what one incident teaches feeds straight into the next.

ISO/IEC 27001: the international standard. Its incident controls form one loop: plan and prepare, assess and decide, respond, learn, and collect evidence properly. Organizations certified to it run that loop alongside any local requirements.

Reporting is its own layer. Separate from the technical work, every mature organization defines who must be notified, how fast and through which channel. Some are binding, such as DoDI 8530.03 for U.S. defense networks. Knowing the layer exists matters wherever you work.

The frameworks work together. In a real response, the SANS steps guide the hands-on work, CSF 2.0 and SP 800-61 set the organizational posture, ISO 27001 frames certified processes, and reporting runs in parallel. The Range practices the investigative core: identify what happened, establish scope, and back each conclusion with evidence.

Annotated examples

An incident record at handover

A synthetic incident record of the kind an analyst passes to the next shift. Every value is invented.

phase:: Containment (note 1)
first_activity:: 2026-05-11T02:07:44Z (note 2)
last_activity:: 2026-05-11T06:31:09Z
hosts_in_scope:: wks-example-03, srv-example-01 (note 3)
accounts_in_scope:: l.moreau
notified:: IT operations; system owner (note 4)

Note 1: Say which phase the incident is in, so the next shift knows what is already done.
Note 2: Activity bounds come from evidence, not from when the alert fired. They frame every later search.
Note 3: Scope is a list, not a feeling. Anything not on it has been checked or is still open, and the record should say which.
Note 4: Reporting runs alongside the technical work. Record who was told, and when.

A good record lets someone who was not there carry on without repeating your work: what phase it is in, when it started and ended, what it touched, and who knows.

How to investigate

1.
Identify.
Confirm the alert or report reflects real malicious activity before you spend the team's time.
2.
Bound it in time.
Find the first and last related activity in the evidence.
3.
Scope it.
List every host and account involved, and check the neighbors of each.
4.
Recommend containment.
Say what to isolate or disable, and what that will disrupt.
5.
Confirm eradication.
Check that the attacker's access and persistence are gone, not only the visible symptom.
6.
Record and report.
Write what you found, with evidence, and make sure the people who must be told have been.

Common mistakes

Mistake: Containing before you know the scope.
InsteadScope first where you can, so you don't alert the attacker and miss a host.
Mistake: Taking the alert time as the start of the incident.
InsteadFind the first activity in the evidence.
Mistake: Treating a removed symptom as eradication.
InsteadConfirm access and persistence are gone.
Mistake: Leaving the record in your head.
InsteadWrite phase, bounds, scope and who was told.
Mistake: Forgetting reporting until the end.
InsteadRun it alongside the technical work.
Mistake: Treating lessons learned as one meeting.
InsteadFeed each finding into preparation for the next incident.

Field references

Field	What it tells you	Seen in
@timestamp	When the event happened, in UTC	Every data view
host.name	The machine that recorded the event	Windows event logs, Sysmon, Linux audit
user.name	The account the activity ran under	Windows event logs, Sysmon
source.ip	Where a connection came from, such as `192.0.2.44`	Network records
destination.ip	Where a connection went	Network records

Apply it in a Case

On your next case, keep a handover record as you go: phase, first and last activity, hosts and accounts in scope. Compare it with your report at the end.

Browse every case on the Range →

References

SP 800-61 Rev. 3: Incident Response Recommendations and Considerations · NIST
NIST Cybersecurity Framework (CSF) 2.0 · NIST
Incident Handler's Handbook · SANS Institute