You asked a simple question and got 113 answers, which is functionally the same as getting none. Half the thread named a provider. A quarter said the provider someone else named was terrible.

The crowd cannot answer because the question is underspecified.

When companies are disappointed by an MSSP, it is almost never a capability failure. It is a scope mismatch: the buyer thought they were purchasing detection and response, and they purchased alert forwarding. Both are legitimate products, they cost different amounts, and the sales conversation frequently does not distinguish them. A provider who emails you a P2 ticket at 3:14am and then waits has not breached your contract. Go and read it.

So before you collect MSSP recommendations, decide what you need the provider to actually do.

Four different services all get sold as “a SOC”

These are not tiers of quality. They are different products, and a vendor can be excellent at one while being the wrong purchase for you.

• Monitoring and alert forwarding. They ingest telemetry, run detections, notify you when something fires. Triage depth ranges from “an analyst looked at it” to “the rule fired, here is the ticket.” All action is yours. For a company whose internal team just needs eyes overnight, this is the correct buy.
• Managed detection and response with containment authority. They hold credentials in your tooling and take action: isolating a host, killing a session, blocking a hash. You get handed a contained problem, not an alert. This is what most buyers picture when they say MDR.
• Co-managed SOC. You own the platform, licence and data. They bring analysts, shift coverage and often detection content, working inside your tenant. You keep portability and everything you build, plus platform health and log source onboarding, which does not disappear because you hired analysts.
• Full outsourced security operations. Monitoring, response, detection engineering, onboarding, tuning, platform administration, reporting, often vulnerability management too. They own the function. Least internal drag, least control.

One question sorts a sales deck into one of those four boxes faster than any RFP: who clicks the isolate button at 3am, and do they need my permission first?

Ask it exactly that way. “We’ll work with you on containment” means no. “We escalate to your on-call engineer with recommended actions” means no, and is a perfectly good service if that is what you wanted. “Our analyst isolates the host under these pre-agreed conditions and notifies you within fifteen minutes” means yes. If containment comes back to you, you still need someone reachable and competent at 3am.

The split is not a marketing invention. FIRST’s CSIRT Services Framework (version 2.1) treats monitoring and detection, incident analysis, and mitigation and recovery as separate services in separate service areas, precisely because a team can provide one without the others. Write your requirements against that structure and the sales process cannot blur it.

Containment authority is the term the whole deal turns on

Everything else in an MSSP contract is negotiable detail. This one decides whether you bought a product or a mailing list.

Letting a third party disconnect your systems feels reckless, so companies withhold it by default. Then an attacker moves laterally for forty minutes while an analyst waits on an unanswered phone. Blanket authority really is dangerous. The workable answer is narrow pre-authorised actions with explicit blast-radius limits:

• Endpoint isolation of a single host, with the management channel preserved so the machine can still be investigated and released.
• Identity actions: force sign-out, revoke refresh tokens, require re-authentication, disable an account. Session revocation is the highest-value pre-authorisation in a token-theft world and the least likely to break anything.
• Blocking and revoking: a file hash, domain or IP at the endpoint agent or firewall; a phishing campaign purged from delivered mailboxes; an exposed API key or service principal disabled.

Then the limits that make granting them sane. Name an exclusion list of systems never touched without a human on the phone: domain controllers, the ERP database, the EHR or PACS in a clinical setting, OT historians and HMIs, the till system in retail. Cap unilateral actions by volume, so three isolations are pre-authorised and thirty trigger a mandatory call, which also protects you from a provider misfiring at scale. Require notification of every unilateral action within a fixed number of minutes, to a channel that is not email. Define reversal: who releases an isolated host, how fast, by what route. And name two reachable humans on your side, with an obligation to answer inside a defined window and a written default for when neither does. That default should not be “nothing happens.”

An MSSP can only see what you feed it

The second-biggest source of disappointment is visibility. Buyers assume the provider watches their company. The statement of work covers named log sources, and that list is narrower than the conversation implied. Get a written yes or no against each of these:

• Identity. Authentication, MFA events, conditional access, privilege grants, directory changes, federation. Most intrusions touch identity first.
• Endpoint. Your EDR’s alerts only, or its process telemetry too? Alert-only consumption caps their detection quality at your endpoint vendor’s and makes any threat hunting claim thin.
• Network. Firewall, VPN and ZTNA sessions, DNS, proxy. Often scoped to perimeter devices only.
• Cloud control plane. CloudTrail, Azure activity logs, Google Cloud audit logs. Management events at minimum; data events only where a named detection needs them.
• SaaS audit logs. Microsoft 365 and Google Workspace, then the ones nobody scopes: the identity provider, the code repository, the CRM, the file sharing platform, the HR system. Business email compromise and data theft happen here, and it is routinely out of scope.
• OT and ICS, if you have it. Different protocols, different content, different rules about what may ever be touched. Assume out of scope unless the contract names it.

Two things follow. Coverage is bounded by your own logging decisions, an architecture and cost problem on your side that no provider fixes by being good. And somebody has to notice when a log source silently stops sending, a boring failure behind a whole category of “why didn’t you see it” conversations. Make log source health a monitored obligation with a named alert, in the contract rather than an email.

Turn response promises into numbers with a remedy attached

“Rapid response” and “24/7 expert eyes” are not obligations. Three clocks are, each in writing, each with a defined start:

• Time to notify. Detection to you being told. Does the clock start when telemetry reaches their platform, or when the event happened on your endpoint? Log shipping latency sits outside their measurement and inside your reality.
• Time to triage. Notification to a human having assessed it and assigned severity. This separates a real SOC from a rule engine with a ticketing system.
• Time to contain. Only meaningful if they hold containment authority. If they do not, this is describing your response time and does not belong in their contract.

Then the distinction that decides whether any of it is real. A service level agreement carries a defined remedy when the provider misses it. A service level target carries none. Vendors publish targets and let buyers read them as agreements. Ask directly: what happens when you miss this? A service credit, escalation to a named executive, and a termination-for-cause right after a stated number of misses in a quarter are all acceptable answers. A paragraph about why the target is industry-leading is not.

Two more things. Who assigns severity, because the vendor usually does, which hands the vendor the denominator of its own SLA. And how performance is measured: whose data, what audit rights, what reporting cadence. A number you cannot verify is not an SLA. It is a feeling.

Five artifacts to demand before you sign

Reference calls are curated and demos are theatre. Ask for objects instead.

• A redacted real incident report. Not a case study. An actual report, names removed. Read it for timestamps, for what they saw first, for the reasoning between observation and action, and for how much work it leaves with the customer. Three bullets and a screenshot is what arrives at 4am on your worst day.
• Their detection engineering process. Who writes detections, what happens when a major new threat is published, whether content is version controlled and peer reviewed, whether rules are global or tuned per tenant, who owns a detection you paid for, and how often content ships. Quarterly deployment is a different animal to weekly.
• How they map coverage. MITRE ATT&CK is the common language, currently at v19.2 (28 April 2026). Since v18 in October 2025 it carries Detection Strategies and Analytics as first-class objects with defined data component requirements, which gives you a sharper question than “do you map to ATT&CK.” Ask which analytics their detections implement and which data components those need, then compare against the sources you agreed to send. A green heat map claims a rule exists in their library, not that it would fire on your telemetry.
• False positive handling. What daily alert volume should a customer your size expect after ninety days of tuning? What is the turnaround on a suppression request, and do they track detection precision? A provider who cannot give a rough volume has never measured one.
• What they do when they are wrong. Every SOC misses things; the behaviour afterwards is the differentiator. Is there a contractual duty to disclose a missed detection they find themselves later, who runs the post-incident review, and does the customer see it? Ask for a real example.

The first ninety days are noisy before they are useful

This is where value is won or lost, and where most disappointment is manufactured. A new MSSP arrives with generic content pointed at an environment it has never seen. Your vulnerability scanner looks like reconnaissance. Your RMM tool looks like an attacker with remote access, because it is remote access. All of it alerts, and all of it is the detection engine behaving correctly. Say that to your own leadership before go-live: if month one’s volume is a surprise, internal trust in the service dies in week three and never comes back.

Four things decide how it goes:

• Log source integration is mostly your work. Firewall rules, service accounts, API permissions, agent deployment, tenant consent. Each needs a change approval; none proceeds without you. Put the integration plan, with dates and named owners, in the contract schedule.
• The asset inventory you probably do not have. NIST CSF 2.0 puts it plainly at ID.AM-01: inventories of hardware managed by the organisation are maintained. An alert on an unidentified host is untriageable and comes straight back to you as a question. Ownership tags, criticality ratings and business context turn a detection into a decision, and no provider supplies them.
• Baseline tuning needs a named internal owner with allocated hours, not goodwill. Without one, onboarding stalls at whichever sources needed no approvals and stays there.
• Define a go-live gate that is not the contract start date. Named sources verified as ingesting, health monitoring live, alert volume under an agreed daily number, detections confirmed firing on deliberately generated test activity. Run a few atomic tests against real techniques and watch for the alert. Until then you are paying for a service you have not proven exists.

The gaps nobody owns are the ones that breach you

Hiring an MSSP creates a boundary, and things fall down boundaries. The fix is a written responsibility split mapped to a published framework, so nothing is assumed. Use CISA’s Cross-Sector Cybersecurity Performance Goals (version 1.0.1, March 2023 update) as the checklist: short, concrete, free, and it already puts log collection (2.T) and secure log storage (2.U) on your side of the fence by default. One caveat, its CSF references use CSF 1.1 identifiers, since it predates CSF 2.0 (February 2024), so translate rather than assume. Walk the goals and assign each to you, the provider, or a third party, in writing. The ones behind real incidents:

• Patching. CPG 1.E asks that known exploited vulnerabilities, as listed in CISA’s Known Exploited Vulnerabilities catalog, are patched or mitigated in internet-facing systems within a risk-informed period. An MSSP that reports a vulnerability has not remediated it. Did you buy reporting, or remediation? If reporting, name who acts and within what window.
• Identity hygiene. CPGs 2.A to 2.E and 2.H cover default passwords, unique credentials, separating user and privileged accounts, revoking credentials for departing staff by their departure day, and phishing-resistant MFA. Detection substitutes for none of it.
• Backup verification. CPG 2.R covers regular backups of systems necessary for operations, with restoration tested. Detecting ransomware is not recovering from it. Almost no MSSP contract makes backup verification anyone’s job, and almost every ransomware recovery turns on it.
• Asset onboarding. Someone spins up a cloud subscription or builds a server: who tells the provider? Unmonitored new assets are the most reliably exploited thing in any estate.

CSF 2.0 supplies the governance language for the relationship itself. GV.SC-05 calls for supply chain cybersecurity requirements to be integrated into contracts with suppliers. GV.SC-07 calls for supplier risk to be monitored over the course of the relationship, not assessed once at signing. GV.SC-08 calls for relevant suppliers and third parties to be included in incident planning, response and recovery activities. That last one is a direct instruction: run your tabletop with the MSSP in the room. Three hours of that surfaces more scope gaps than three weeks of questionnaire.

Write the exit terms while they still want your business

MSSP relationships end, yours included, whether through a bad year, an acquisition or a price rise. CSF 2.0 puts this at GV.SC-10: plans should include provisions for activities that occur after the conclusion of a service agreement. Four things:

• Your log data. Export all of it in what format, at what cost, within how many days? How long is it retained after termination, and can you pull it during the notice period? Raw data in an index you cannot extract from is data you rented.
• Detection content. If you paid for custom detections, are they yours? Get that in writing, with an export in a portable form. Vendor rule syntax does not travel; the logic does, and a Sigma-style export or even documented pseudocode beats starting from nothing.
• Tooling licences. If the provider supplies the EDR, SIEM or SOAR under their own agreement, you lose the tooling the day you lose the provider. That is usually the real switching cost and it is invisible in the monthly fee. Ask whether licences can be assigned to you, and price the replacement if not.
• Case history. Incident tickets, investigation notes and reports are your institutional memory and sometimes your evidence. Specify the export mechanism.

On timing: a transition is the onboarding project again, same integration work, same tuning curve, same noisy first weeks. Plan a comparable window and overlap the two providers rather than attempting a hard cutover. So the notice period has to be long enough to stand up a replacement, and the notice date goes in a calendar the day you sign, not the month you get annoyed. Auto-renewal clauses catch people who meant to leave and forgot to say so in time.

Do this in order and the original question answers itself. Once you have written down the tier, the containment authority, the log sources, the three clocks with remedies and the responsibility split, most shortlists collapse on their own, because half the vendors cannot commit to your document and will say so in the first call. That is not a wasted conversation. That is the recommendation you were asking the internet for.

If you would rather have someone read the proposal with you, that is work AB7 Solutions does. We run SOC monitoring and co-managed detection cover, including the out-of-hours shift capacity that makes the 3am question answerable, and we do VAPT and firewall and server security for the scope an alert-forwarding contract leaves sitting with you. Send us the statement of work and the SLA schedule you have in front of you and we will mark up the containment authority, the log source list and the gaps in the responsibility split, including the cases where the honest answer is that you need one analyst and a tuned alert set rather than a managed service. Call +1 321 341 7733, email ab@ab7solutions.com or director@ab7solutions.com, or start at www.ab7solutions.com.

Sources: CISA, Cross-Sector Cybersecurity Performance Goals (version 1.0.1, March 2023 update), goals 1.E, 2.A-2.E, 2.H, 2.R, 2.T and 2.U, and the Known Exploited Vulnerabilities Catalog; NIST, Cybersecurity Framework 2.0 (NIST CSWP 29, February 2024), subcategories ID.AM-01, GV.SC-05, GV.SC-07, GV.SC-08 and GV.SC-10; NIST, SP 800-61r3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile (April 2025); FIRST, CSIRT Services Framework version 2.1; MITRE, ATT&CK version history (v19.2 current, released 28 April 2026) and ATT&CK v18 release notes (28 October 2025).