A security operations center takes an alert from first signal to a closed case in a repeatable sequence: triage, scoping, containment, eradication, recovery and review. This post walks one constructed alert through that sequence. The company, people and details are invented for illustration and are not a real incident.
The setup (constructed)
Northwind Freight is a made up mid sized company with a three person security team and an after hours managed service. At 02:14 an alert fires: a laptop belonging to a finance analyst, Dana, has started a command line tool that is not normally used on finance machines, and it is contacting an address nobody has seen before.
Step 1: triage (02:14 to 02:30)
The managed analyst's first questions are narrow. Is the alert real? How bad if it is? Who owns the asset? They check the asset record, see a finance laptop, and look at the last ten minutes of activity around the process. The tool was launched by a spreadsheet application, which is unusual.
Triage ends with a decision, not an answer. They rate it "likely malicious, medium confidence" and open a case. The case template forces a severity, an owner and a clock. Many cases die here as false positives, which is fine if the reason is written down.
Step 2: scoping (02:30 to 03:20)
Scoping asks what else is affected. The analyst searches for the same destination across other hosts and finds one more: a second finance laptop contacted it an hour earlier, with no alert. They search email for the attachment name and find three recipients. They check Dana's sign in history: no unusual logins yet.
NIST describes indicators of compromise as technical artifacts or observables suggesting that an attack is imminent or underway, or that a compromise may already have occurred. The destination address and file name are the case's first indicators. The analyst records them with a note on how they were found, because indicators age.
Step 3: containment (03:20 to 03:45)
Two laptops are in scope. The runbook allows the analyst to isolate a laptop from the network without approval, keeping the management channel open. They do so for both, block the destination at the firewall, and ask the mail system to pull the message from the three mailboxes. They page the on call security lead only because credentials may be involved.
The lead decides to force a password reset and token revocation for the two users. That is a business impact decision, which is why it is the lead's call and not the analyst's.
Step 4: eradication and recovery (morning)
The team captures disk and memory images before reimaging, in case the case needs evidence. Both laptops are rebuilt from a clean image. The users get new credentials and are told what to watch for. Finance leadership is informed that two staff were without laptops for half a day.
The team checks that the destination address has no further hits for seven days, and that the mail rule that delivered the attachment was tightened.
Step 5: review (the following week)
A short, blameless review answers four questions. What detected it? One endpoint rule, after the second laptop had already been hit. What slowed us down? The asset record did not show the second laptop's owner. What did we get lucky on? No finance credentials were used. What changes? Add the attachment type to mail filtering, fix asset ownership data, and add a detection for the spreadsheet launching a command line tool.
NIST's incident response publication, SP 800-61 Rev. 3, frames this learning as part of improving risk management over time, not as an afterthought.
What the example shows
Triage is a decision with a clock. Scoping is where most of the value sits, because it finds the second laptop. Containment rules decided in advance let a night analyst act in minutes. And the review turns one alert into three fixes.
Notice what was not in the example: any need for a named threat actor. The team never needed to know who sent the file to act correctly.
Where Safeguard fits
SOC tooling is not a Safeguard product, and we do not replace it. We focus on the application and software supply chain side. If an alert like this one starts from a malicious package or a tampered build, the SOC needs dependency and build records to scope it, and that is the part we speak to.
What to do
- Write a triage template with severity, owner and a clock.
- Keep an accurate asset record with owners.
- Pre approve containment actions an analyst can take alone.
- Record every indicator with how it was found.
- Preserve evidence before rebuilding systems.
- Hold a blameless review within a week and track the fixes.
Quick check
Is the Northwind case a real incident?
No. It is a constructed example written to illustrate the steps. The company and people are invented.
Where do most SOC cases add value?
In scoping, which finds other affected hosts and accounts that raised no alert of their own.
Sources
Last reviewed: 18 October 2026.
