It’s 3:12 a.m. on a Sunday. Your endpoint tool flags an encoded PowerShell command on a laptop in finance. What happens next is the entire product you’re buying.
In one version, your managed SOC opens a ticket, marks it high severity and emails your on-call engineer: “please investigate.” In the other, an analyst decodes the script, sees it’s pulling a payload from an unfamiliar domain, isolates the laptop, checks whether any other machine reached the same domain, resets the user’s credentials and only then calls you, with the incident already contained.
Both providers will tell you they offer “24×7 managed detection and response.” After years running a SOC, here is how I’d tell them apart.
Ask to see a real escalation
This is the single most revealing thing you can request in an evaluation. Ask for a redacted escalation from a real incident. A good one tells you what happened, what the analyst checked, what they already did and what they need from you. If what you get back is a raw alert with a severity label, you’re looking at an alert-forwarding service with a SOC logo on it.
Find out what they’re allowed to do without you
A SOC without authority to act is an expensive notification system. Before you sign, agree on pre-approved containment: isolating an endpoint, disabling an account, forcing a password reset, blocking a malicious domain or file. Every minute spent waiting for someone to answer the phone is a minute the attacker keeps.
A SOC without authority to act is an expensive notification system.
“Blocked” is not the same as “done”
Most SOCs close an alert the moment the security tool reports a block. But a blocked phishing link on one laptop is often the first sign of a wider campaign. The question I’d ask every provider: when a malicious URL is blocked on one device, do you check whether it succeeded on any other device before the block took effect? That one question separates triage from investigation. On our manufacturing engagements, validating blocked web and email events is a standing process, precisely because a block is where an investigation should start.
Your credentials leak outside your walls
Some of the most dangerous alerts never come from your own network. Employee passwords turn up in third-party breaches every week, and an attacker can use them against your email or VPN without touching anything you monitor. The metric that matters here is the time between exposure and reset. Ask whether the SOC correlates breach intelligence with real sign-in activity and drives the reset itself, or simply forwards you a list.
Do the coverage math
A year has 8,760 hours. One analyst per shift with no backup means gaps during holidays, sick days and long investigations, exactly when you can least afford them. Ask how coverage holds up when an analyst is pulled into a four-hour incident. We run a shared analyst pool for this reason: there’s always surge capacity, and an attack pattern spotted in one client’s environment informs every other environment the same week.
Hunting should produce detections
Threat hunting is easy to claim and hard to verify. Real hunting starts with a hypothesis tied to how attackers target your industry, such as abuse of remote-access tools in manufacturing, and ends with a new detection so the same behavior is caught automatically next time. Ask how many hunts became permanent detections last quarter. A vague answer tells you what you need to know.
Expect a noisy first month, and ask for the plan
No SOC knows your environment on day one. Your administrators run legitimate scripts that look exactly like attacker tooling until someone learns the difference. A good partner will show you a tuning plan: how they learn what normal looks like, how quickly false positives fall, and when you’ll get your first service review.
Ignore the vanity metrics
“Alerts processed” tells you nothing. Ask instead for time to triage, time to contain, the share of escalations that needed your action, and how many detections were added or tuned each month. Those numbers describe a SOC that is getting better. Volume just describes a SOC that is busy.
Run the 3 a.m. test on every provider you evaluate. Hire the one that can show you what happens at 3:12 a.m.