How to Read a SOC Playbook Before You Buy One

Published 18 March 2026 · Cybersecurity · ~6 min read

Every MSSP deck looks identical. There is a slide with concentric circles and the words "people, process, technology." There is a slide with a diagram of EDR + SIEM + SOAR feeding into a 24×7 control room. There is the case-study slide with a logo collage. And there is the pricing slide with three tiers and a column called "best value."

What none of those decks reliably tells you is what happens at 2:14 AM on a Tuesday when the alert fires.

After running our own SOC and reviewing playbooks from a dozen vendors during procurement engagements, here are the six questions we now ask of every SIEM/SOC proposal — internal or external — before signing.

1. Show me the runbook for T1078 Valid Accounts.

This is MITRE ATT&CK technique T1078 — credential abuse. It is the most common attacker behaviour in real-world breaches and the hardest to detect well. Ask the vendor to walk you through their actual runbook for it. You are looking for: which log sources, which detection rules, what the SOC analyst sees in their console, what they do in the first ten minutes, and what they escalate to whom.

If the runbook is generic ("the analyst will investigate the alert and contact the customer"), you do not have a SOC. You have an alert-forwarding service.

2. What's the median time-to-acknowledgement, and over what window?

There is a difference between SLA ("we acknowledge within 15 minutes") and reality ("our median over the last 90 days was 4 minutes 18 seconds"). Ask for the actual measured number, the window, and the percentile distribution. A SOC that cannot tell you its 95th-percentile MTTA confidently does not measure itself, and a SOC that does not measure itself does not improve.

If the answer is "we hit our SLA 99% of the time," that is the wrong answer. The right answer is a number followed by a unit followed by a date range.

3. Who decides when to isolate a host?

This is the most important contractual question in any managed-EDR engagement and the one most often handwaved. Three patterns exist:

• Vendor decides, vendor acts. The MSSP isolates a host without calling you. Fast, but blast-radius incidents will happen — they will isolate your CFO's laptop during a board meeting.
• Vendor recommends, customer approves. The MSSP calls a designated on-call engineer; the customer approves; the action is taken. Safer, but adds 5–30 minutes during a live incident.
• Vendor acts on a pre-approved playbook. A negotiated, signed list of conditions under which isolation is automatic, with everything else requiring human approval. This is the only model we have seen work at scale.

If the proposal does not address this, you are not yet looking at a real proposal.

4. What's the cost to remove a false-positive rule?

False positives are the single largest hidden cost of running a SOC. Ask the vendor: when a rule produces 30 false positives a week and you want it tuned out for your environment, what is the process and the turnaround? "We will look at it" is not a process. "Customer success ticket, reviewed in our weekly tuning sync, deployed within 5 business days" is.

If tuning is friction-heavy, your team will start ignoring real alerts to keep their inbox sane. The cost of poor tuning is not money — it is the breach you missed because alert fatigue is real.

5. How do you handle log gaps?

Networks lose logs. Endpoints disconnect. Cloud APIs rate-limit. The question is not whether you will have gaps; it is whether the SOC notices. Ask the vendor what happens when a log source goes silent for 15 minutes. There should be an alert on the absence of logs, not just the presence of bad ones. Most SOCs do not have this. The few that do are noticeably more expensive and noticeably more competent.

6. Show me a post-incident report you've written.

Redact the customer name. We just want to see how you write up an incident — the chronology, the root cause, the lessons learned, the action items, the assigned owners. A SOC that produces good post-incident documentation is a SOC that is improving. A SOC that delivers an incident summary as a single paragraph is a SOC that has not yet learned that the value of a SOC is not the alert, it is the institutional memory it builds.

What a good answer feels like

A vendor giving good answers to these six questions will sound less polished than the slick deck you walked in with. They will pause. They will say "let me actually pull the number" and screenshare a Grafana dashboard. They will admit a tuning workflow that takes longer than they would like. They will be specific about which automation actions require human approval at your tier.

That is what good looks like. The deck is the easy part.

— SRI INFOIT, Visakhapatnam · Security Operations practice