Skip to content
← Insights

Most MSSPs Pass the Demo. Far Fewer Pass an Actual Incident.

May 26, 2026 · 8 min read

AI Summary
Generating summary…

What you are buying from an MSSP, when you really get down to it, is a promise. The promise is that someone will watch your environment, see attackers earlier than you would alone, and respond when the bad thing happens. The contract describes those promises in language nobody can really test before signing — coverage windows, telemetry sources, severity tiers, response SLAs, all dressed up as numbers without much room for the parts that actually matter. The demo goes well. The reports for the first six months read reasonably. Then something real happens, and you find out which of the promises were operational and which were marketing.

I have sat in too many rooms in the weeks after a real incident, listening to clients describe the way they thought their MSSP worked and the way it actually worked. The gap is rarely small, and it is almost never about a single technical failure. It is about a relationship that was sold as detection and turned out to be data collection. Or sold as twenty-four-seven that turned out to be a pager rotation. Or sold as monitoring of your environment, where it turned out the monitoring was of a slice of the environment nobody had ever quite agreed on the edges of. The patterns are consistent enough now to be worth saying out loud.

The Nine Months Nobody Was Looking

The single most expensive lesson the MSSP industry has ever been handed was SolarWinds Sunburst. From March 2020 until December 2020, a Russian state actor sat inside SolarWinds Orion deployments across roughly eighteen thousand organisations, including federal agencies and Fortune 500s. Many of those organisations had contracts with MSSPs whose job was to detect exactly this kind of thing. None of those MSSPs noticed.

What finally cracked it open was not anyone's detection regime. It was that FireEye, a security company with its own internal team better than most MSSPs, happened to notice that its red-team tooling had been stolen. From that, FireEye walked the cause back to a poisoned Orion update and made the disclosure. Without that, the campaign would almost certainly have run longer.

What I take from that story, and from the dozen smaller versions of it I have watched since, is that detection at scale is not a problem MSSPs have solved. It is a problem they have agreed to be paid to work on. The contract describes the work. It does not describe the result. The gap between watching and noticing is much larger than the brochure makes it sound.

The Watchers Were Watching the Wrong Thing

The more recent version of that story is Snowflake in the spring of 2024. A threat actor catalogued as UNC5537 by Mandiant logged into the Snowflake instances of roughly a hundred and sixty-five organisations using valid customer credentials. The credentials had been quietly harvested over the previous four years by infostealer malware on contractor devices. None of the activity required an exploit. The attackers simply logged in. Ticketmaster lost data on around five hundred and sixty million users. AT&T's call records went out the door. Santander, Advance Auto Parts, and a long list of others followed.

The MSSPs monitoring most of those organisations were not asleep. They were watching the wrong place. SOC playbooks at the time were built around endpoint telemetry, Active Directory logs, and firewall flows — the things MSSPs have always sold and always invoiced. Cloud SaaS authentication was not in the monitoring scope of a great many contracts, and where it nominally was, the alerts were rate-limited or de-prioritised, because legitimate cloud logins look identical to illegitimate ones unless you have done the careful work to distinguish them. Nobody had done the work.

The same gap shows up in the MGM incident from September 2023. The Scattered Spider group called MGM's IT help desk pretending to be an employee they had picked off LinkedIn, spent about ten minutes on the phone, and walked out with the credentials and administrative access to MGM's Okta tenant. From there it was lateral movement. MGM's internal security team noticed unusual activity the following day. By the time anyone understood what they were looking at, it was too late to contain it without taking systems offline, which is what they ended up doing, at a cost of around a hundred million dollars in the quarter. The SOC playbook that should have caught the initial intrusion did not exist, because identity-provider compromise via social engineering of the help desk did not look like the kind of attack the playbook was tuned for.

Two very different attacks with the same shape underneath. The MSSP was watching the things its tooling had been built to watch. The attackers came in through the doors the tooling did not cover. And the monthly reports kept describing the watching, accurately and even impressively, while the noticing was not happening at all.

"Twenty-Four Seven" Is a Marketing Term, Not an Operating Model

The other place these relationships disappoint is at three in the morning. The contract says twenty-four seven. The reality, in many MSSPs, is a tier-one analyst in a low-cost region whose job is to look at the alert, decide whether it crosses a threshold, and either page someone more senior or close it. The someone more senior is on call, not at a desk. The page goes out. Time passes. The senior analyst opens the laptop, reads the context, decides whether to call you. Time passes again. Eventually someone calls your designated contact, who is also asleep.

In a real incident, fifteen minutes against three hours is the difference between an incident and a breach. And most contracts measure the wrong thing. They measure time-to-acknowledge, which is an analyst clicking a button to take ownership of the ticket. They do not measure time-to-triage, or time to an actual containment action, or time to a senior person on a call with someone at your company who can make a decision. The acknowledgement SLA gets met. The customer is still bleeding.

I have asked dozens of prospective MSSPs to walk me through, with names and times, what happens between a high-severity alert firing at two-thirty in the morning and someone with authority being on a call with the client. The number who can answer that question without hedging is small. The number who can answer it accurately, with the actual median time their staffing produces, is smaller.

What You Cannot See, You Cannot Tune

The other quiet failure mode is opacity. Most MSSP contracts describe the service in outcomes — "we detect threats," "we respond to incidents" — and not in mechanics. You can pay an MSSP for three years and never see the underlying detection rules, the hunting hypotheses they are running against your data, the false-positive rate by alert type, or the tuning history of the platform on your environment. The monthly report shows a triage volume. The triage volume goes up. Nothing about that tells you whether your particular risks are being covered.

When you ask to see more, the answer is usually some version of "that is our intellectual property" or "we will share what you need to know in a customer review." The translation is that the MSSP is protecting itself from scrutiny, not protecting you from attackers. A confident provider can show you their detection coverage mapped to MITRE ATT&CK, name which techniques they have telemetry for and which they do not, and tell you honestly where the blind spots are in your particular deployment. The marginal provider gives you a heat-map graphic with everything coloured in green.

Co-managed is the marketing word that does the most work for the most opaque providers. Co-managed in the brochure means your team and theirs are working together on detection. Co-managed in practice often means you have read access to a portal nobody on your side has time to understand, no ability to write or tune detections, and no visibility into what is being chosen not to alert on. If you cannot tune what you are paying for, you do not really own it. You are renting an opinion.

The Day the Incident Becomes a Scope Discussion

The most expensive surprise inside many MSSP contracts is the meaning of "incident response included." On the day you actually need it, what was advertised as included often turns out to be triage and ticket escalation, not the engagement of a forensic team with the authority and the headcount to actually run the response. The forensic team is a separate line item, billed hourly, scheduled through a queue, possibly subcontracted to a partner that may or may not have availability in the next ten days.

This is the part of the contract where the language is vague on purpose. "Incident response" can mean anything from "we will help you with the alert" to "we will deploy a team on-site by tomorrow morning." Almost nobody asks, before signing, which one of those it actually means. The clarification happens on day one of a real incident, in the form of a scope quote that arrives by email while you are in a war room.

A serious MSSP will tell you, before you sign, exactly what their IR engagement looks like in scope, in cost, and in lead time. They will name the team. They will tell you what scenarios are included and what scenarios are billable. They will give you a sample engagement letter. They will not be irritated that you asked. The ones who hedge here are usually hedging because they do not actually have the capacity they implied, and you do not want to find that out in the worst week of your year.

What Good Actually Looks Like

It would be possible, from everything above, to conclude that all MSSPs are unserious. They are not. The good ones materially shorten your detection times, materially improve your response capacity, and materially reduce the chance that an attacker sits inside you for nine months. They tend to share a handful of traits.

They tell you what they cannot see. The first conversation includes an honest description of the parts of your environment their tooling does not cover and what would have to change to cover them. They do not pretend their stack is universal, and they do not pretend that monitoring your SaaS, your identity provider, your cloud workloads, and your endpoints are the same problem. Those are four problems, often with four different teams, and a serious provider says so.

Detections are mapped to a framework you can actually audit. MITRE ATT&CK is the obvious one. The map shows which techniques have telemetry behind them, how confident the provider is in each, and where the gaps are — honestly, in greys and reds, not in a comforting wash of green. It gets updated as your environment changes, because it has to.

The SLAs are tied to useful events. Not "time to acknowledge," which is meaningless on its own, but time to triage, time to a senior analyst, and time to an action that helps you. Numbers get reported monthly with actuals against targets. When they breach an SLA, they tell you about it before you notice yourself.

The incident playbook is on the table on day one of the contract, not the day you need it. The playbook is specific to your environment. It names the people on your side they will contact, the order they will contact them in, the actions they are pre-authorised to take, and the actions that require a call. And it gets rehearsed at least annually, so the first time it runs is not a real incident.

When you ask who would actually lead the response on the worst day of your year, they have a name. The bench depth is described. The lead time is honest, not aspirational. The cost in the scenarios you actually face is something they will quote in writing before you ever need it. The contract does not depend on a partner you have never spoken to.

And they are honest about what they do not do. The provider who tries to be your MSSP and your DFIR firm and your GRC consultancy and your tabletop facilitator is usually best at none of those things. The serious providers tell you what they are excellent at, name the partners they use for the rest, and let you keep the freedom to pick your own.

The Questions That Get You the Truth

There is a separate MSSP Vetting Checklist alongside this article with the specific questions worth putting in front of a prospective or current MSSP, and what good and bad answers actually sound like in each case. The short version is this. Ask them to show you a real alert timeline from a real incident, sanitised. Ask them to name the techniques in MITRE ATT&CK they have telemetry for, and the ones they do not. Ask them what twenty-four seven means in their staffing model, with median times to a senior analyst on a call. Ask them to walk through what happens between a Sev-1 alert and a useful action. Ask them to name the firm that does their forensic work, the lead time, and the cost. Ask them when their detections were last tested by an external red team. The providers worth signing with will answer those questions in detail. The ones to walk away from will tell you the methodology is proprietary.

A companion checklist with the specific questions worth asking, the good and bad answers laid out side by side, and a place to record what the provider actually said.

Download the MSSP Vetting Checklist

What This Means for Whoever Is Signing the Contract

What you are buying from an MSSP, when it works, is the difference between sitting blind and sitting informed when something serious happens. That is a real thing, and it is worth real money. It is also not what most of the contracts on offer actually deliver. The default product is data collection sold as detection, and a pager rotation sold as an operations centre. The serious providers exist. They are not the cheapest ones. They are the ones who can describe their work in detail, who will tell you what they cannot see, who are not insulted when you ask about response times, and who can put a real incident playbook on the table on the day you sign.

The cost of getting this wrong is not the monthly fee. It is the nine months you may be sitting compromised before anyone notices. It is the hundred-million-dollar quarter when nobody catches the help desk call. It is the breach notification that has to admit your data was leaving through a logging blind spot you were technically paying someone to monitor. The MSSP market has not yet been priced to reflect any of that. Until it is, the work of telling the serious providers from the rest sits squarely with the buyer.

The cost of getting this wrong is not the monthly fee. It is the nine months you may be sitting compromised before anyone notices. Until the MSSP market is priced to reflect that, the work of telling the serious providers from the rest sits squarely with the buyer.

Next Step

Ready to strengthen your organization's resilience?

A 30-minute discovery call to discuss your cybersecurity posture, incident readiness, and whether advisory support is the right fit.