What Your MSSP Isn't Telling You

After two decades working inside security operations — building them, running them, inheriting broken ones — I've noticed a consistent pattern. The things that matter most to a buyer are rarely the things an MSSP puts in a proposal.

This isn't always deliberate. Sometimes it's because the provider genuinely doesn't know. More often, it's because nobody asked. And asking the wrong questions at the wrong time — during procurement, while the sales deck is still warm — rarely yields honest answers.

Here's what your MSSP is unlikely to volunteer, and what you should be probing instead.

1. Whether their detection coverage actually fits your environment

Every MSSP will tell you they have a comprehensive detection library. What they won't tell you is that 80% of it is generic, vendor-default content that fires on activity patterns unrelated to your actual attack surface.

The question isn't "do you have detections?" It's "which of your detections have been tuned to our specific environment, and how do you know they're working?" Ask for a use-case catalogue. Ask which rules were custom-built versus pulled from a vendor feed. If they can't show you, the coverage isn't there.

2. What happens during triage when the analyst isn't sure

The gap between a fired alert and a meaningful escalation is where most MSSPs quietly fail. The SLA says they'll respond within 15 minutes. It doesn't say a qualified analyst will think carefully about what the alert means.

Ask to see sample closed alert records — anonymised, from a live engagement. Look for analyst reasoning: what did they consider, what did they rule out, why did they escalate or suppress? If the records are empty, or show only a status change with no commentary, you're looking at a ticket factory, not a security operation.

3. Their real false positive rate

False positive rates are rarely published and almost never discussed in renewal conversations. They should be. A high false positive rate means analysts are burning time on noise, genuine signals are being missed, and your team is spending time triaging alerts that should never have left the SOC.

Ask for a trend graph over the last 12 months. Ask what actions they've taken to reduce it. If they don't track it, that's your answer.

4. What changes when your key contacts leave

Security relationships are intensely personal. The analyst who knows your environment, the account manager who understands your risk tolerance, the escalation contact who picks up the phone — these people leave. Ask what happens when they do. What's the knowledge transfer process? Where is the institutional knowledge documented? How long before a new analyst reaches operational fluency on your account?

If the answer is "it's all in their heads," you have a continuity risk your contract almost certainly doesn't protect you from.

5. What their coverage looks like at 3am on a bank holiday

24/7 monitoring is standard in any MSSP proposal. What it means in practice varies enormously. Is the overnight shift the same analysts, or a reduced team on a different continent? What's the escalation path if the first-line analyst is out of their depth? What's the SLA for bank holidays versus normal business hours?

These questions make providers uncomfortable. That discomfort is information.

6. The conditions under which they'll exit the contract without penalty

Exit terms are buried in schedules and rarely read until they matter. Some MSSPs have data return clauses that effectively lock in your log history. Some have notice periods that leave you exposed if the relationship breaks down. Some charge significant fees for transferring data to a new provider.

Ask for a plain-English summary of what happens if you choose to leave 18 months in. Ask who owns the data. Ask what leaving costs. The answers will tell you a great deal about how the provider thinks about the relationship.

The pattern underneath all of this

None of these questions are adversarial. A good MSSP will answer them clearly, with evidence. The purpose of asking isn't to catch someone out — it's to establish whether the operating model behind the sales deck is real.

ServiceSignal's assessment framework is built around exactly these questions: structured, evidence-led, scored. Not because scoring is the point, but because having a consistent framework stops the conversation from being won by whoever presents better slides.

The best time to run this assessment is before you sign. The second best time is now.