What a SOC actually does at 3 AM: a day in the life.

Most business owners have never seen the inside of a security operations center. Which is fine — you're not supposed to. But when your MSSP proposal has a line item for “24/7 SOC monitoring,” it's fair to ask what that actually means at 3 AM on a Tuesday. So here's the honest answer, drawn from anonymized incidents we've handled for Charlotte-area SMBs in the last twelve months.

The example below is a composite — details changed, timing preserved. What did not change is the sequence, because SOC work follows a repeatable playbook. That repeatability is the whole point.

02:47 — The alert fires

A workstation belonging to “Amanda” in the accounting group at a 60-person NC professional services firm generates an EDR alert:

• Detection: `powershell.exe` spawned by `winword.exe`.
• Behavior: outbound HTTPS to a first-seen IP hosted in Sofia, Bulgaria.
• Signal quality: high. MITRE ATT&CK T1059.001 (PowerShell) chained with T1105 (external tool transfer).

The alert lands in the SOC queue with a severity of “critical.” No human touched it yet — the EDR (see EDR in Plain English) generated the correlation because the pattern — Office spawning a scripting engine that calls out — is the signature of a document-borne loader.

02:48 — The analyst picks it up

SOC Tier 2 analyst on shift sees the alert land. First action: pull the process tree. What she sees:

winword.exe → powershell.exe -nop -w hidden -e <base64 blob> → outbound TCP/443 to 5.181.x.x

Decoded, the base64 is a small downloader. This is not a false positive. This is a real attempted intrusion. The Word document that started this? Amanda opened an email attachment at 02:44 — she is a night owl catching up on invoices — and the document contained a macro that Windows Defender's macro-block policy should have caught, but didn't, because the file was received via a personal-email side channel that bypassed the corporate mail gateway.

None of that matters yet. Right now the analyst has to stop the bleeding.

02:49 — Isolation

From the EDR console, the analyst clicks one button: network-isolate the endpoint. Amanda's workstation loses connectivity to everything except the EDR management channel. The outbound TCP session dies. Whatever the downloader was going to fetch next — almost certainly a Cobalt Strike beacon or an SMB worm — is now unable to complete.

Total elapsed from alert to isolation: 2 minutes 12 seconds. This is the number that matters most in a SOC report and the number no vendor voluntarily shares unless they're proud of it. Industry medians per the Verizon DBIR are measured in hours or days, not minutes.

02:51 — Blast radius

Isolation stops that one host. Now the question is: did anything move? The analyst runs three parallel queries against the SIEM:

1. Lateral movement. Any authentication events from Amanda's account or workstation to another endpoint in the last hour? No.
2. Credential access. Any suspicious LSASS access, `mimikatz` signatures, or Kerberos anomalies? No — the loader never got that far.
3. Data staging. Any unusual file-copy volume to `\temp`, cloud, or removable media? No.

The blast radius is one host. That's the outcome you want. A SOC that catches the first stage keeps you out of the news; a SOC that catches the fifth stage puts you in the news anyway, just with a smaller ransom.

03:07 — The IOC hunt

With the immediate threat contained, the analyst starts hunting. The IP, the domain the loader called, the SHA-256 of the malicious document, and the base64 payload all go into an IOC (indicator of compromise) sweep across the entire tenant. Every endpoint gets checked for the same domain, the same hash, the same PowerShell pattern.

Nothing else lights up. Amanda's laptop was the only one that got hit. But the IOCs get shared into WHT's threat-intel feed so that if the same infrastructure is used against another client tomorrow, the detection is preemptive.

03:20 — Evidence collection

Before anything gets cleaned up, the analyst pulls a full forensic snapshot: memory image, disk timeline, EDR event history, network telemetry, email header for the delivery message. This packet becomes the record if the incident later needs an insurance claim, an OCR audit response, a client notification, or an FBI report.

The rule inside a good SOC is collect first, remediate second. Rebuild a host too fast and you destroy the evidence that proves nothing was exfiltrated — which is what your cyber insurance carrier will ask you to prove.

03:34 — Client alert

The client's designated after-hours contact gets a text and an email. Not a marketing template — a specific, factual note:

• What happened (macro-borne loader on one endpoint).
• What we did (isolated, hunted, no lateral movement, no data loss).
• What's still open (the endpoint remains isolated pending rebuild).
• What we need from you (nothing until 8 AM — go back to sleep).

Half our clients read the notification at 4 AM and reply “thanks.” The other half don't see it until 7. Both are fine, because the actual response is already complete.

05:00 — Rebuild queued

The affected workstation is flagged for a full reimage. In parallel, the SOC pushes a temporary tenant-wide policy tightening: block PowerShell for standard users on any endpoint where Office spawns a scripting engine. This closes the exact door the loader used, tenant-wide, for the next 72 hours while the client's IT lead reviews the permanent change.

08:00 — Handoff

Day-shift Tier 2 takes the case at the morning stand-up. By 9 AM the client has a written incident report, evidence chain of custody, the reimage schedule for Amanda's workstation, and one recommendation: a company-wide policy blocking macros from Internet-origin documents, which will kill this attack class entirely.

By noon the reimage is done and Amanda is back in her mailbox. She has no idea any of this happened until her IT lead tells her.

What this means for a small business

A few things are worth noting from that timeline:

• The first two minutes did most of the work. Isolation is the moment the attack stops. Everything after is investigation, cleanup, and hardening. A SOC that can't isolate an endpoint from the console in under 5 minutes is a SOC that will lose to real ransomware.
• Nobody called Amanda. Users get blamed a lot in security writing; in reality, humans make mistakes at 2:44 AM. The system should assume that. The SOC's job is to make the mistake survivable.
• Evidence beats speed. If the analyst had wiped the workstation at 02:50 instead of imaging it first, the client would be unable to prove to their insurance carrier that no data was exfiltrated — which usually determines whether the notification obligations under NC 75-65 trigger. See our summary of what NC breach notification looks like in practice.
• The IOC feed compounds. The infrastructure used to attack this firm gets watched for every other WHT client for at least the next 30 days. One incident, correctly triaged, protects the whole client base.

What WHT recommends

If you already have someone monitoring your environment 24/7, ask them these five questions this week — the answers will tell you very quickly whether you have a real SOC or a mailbox that alerts get dumped into:

1. What's your median time-to-isolate? A real answer is a number in minutes.
2. Can you show me an anonymized incident timeline from the last 30 days? If nobody can produce one, nobody is doing the work.
3. Who is on shift at 3 AM tonight? The answer should be a person, not “we get paged.”
4. How do you preserve evidence before remediation? Memory image, disk timeline, EDR history — those are the right words.
5. What was the last real (not test) incident you handled for a client my size? Confidentiality is fine; specificity of process should still be answerable.

If you don't have 24/7 coverage today — and most 20-to-150-employee firms in NC still don't — the honest calculus is that the loader Amanda downloaded runs in 90 seconds. Whatever monitoring wakes up at 8 AM to review overnight alerts is monitoring a fait accompli.