Independent MSSP and MDR selection: the buyer-side playbook

Most MSSP and MDR selections fail before the RFP is written. The buyer starts from a vendor list, sits through demonstrations, and lets the most persuasive pitch define the requirements. The result is a provider chosen on chemistry and price, with a scope that mirrors the vendor's catalogue rather than the buyer's actual gaps.

The same optimism bias that distorts internal maturity scoring distorts procurement. SOC-CMM 2026 report data shows self-assessments overestimate maturity by roughly 0.6 points on the 0-5 scale. A team that believes it is stronger than it is will buy the wrong service: too narrow where it is weak, redundant where it is already capable. An independent, third-party view of the current state corrects the baseline before money moves.

This playbook sets out eight steps. Each one produces a documented artifact: a requirements catalogue, a long-list with exclusion criteria, a scorecard, a Proof of Value report, a contract annex, a signed recommendation. Regulators reviewing third-party ICT decisions under DORA and NIS2 ask for exactly this trail.

Step 1 is to translate SOC-CMM findings into concrete service requirements. The 2026 domain averages explain why this matters: Technology scores around 2.7 while Services sits at 2.2 and People at 2.3. Many organizations do not need more tooling from an MSSP; they need sustained operating discipline, coverage outside business hours, and documented service delivery. The maturity profile tells you which.

• Use cases and log sources: which detection scenarios the provider must cover, fed by which of your sources.
• Service levels expressed in detection and response terms, not just ticket acknowledgement.
• Geography, data residency and working languages, including the language of board-facing reports.
• Integrations with your SIEM, ticketing and identity stack, with ownership of each interface stated.
• Exit conditions defined as requirements from day one: handover, data return, runbook portability.

Step 2 builds the long-list: 8 to 12 candidates filtered by explicit exclusion criteria such as no presence in your jurisdiction, no support for a mandatory log source, or no verifiable references in your sector. Write the exclusions down. A long-list without documented criteria is the first thing an auditor will challenge.

Capability is whether a service element exists and how well it is designed. Maturity is how consistently it is performed, measured and improved. The SOC-CMM separates the two, and your pre-filter questionnaire (step 3) and detailed RFP to the 3 or 4 finalists (step 4) should as well. Every provider will pass the capability test on paper. The differences appear under maturity questions.

• Show service-level performance for the last 12 months for a client of our size and sector, not a marketing average.
• How often are detection runbooks reviewed, by whom, and where is the change history?
• What is analyst attrition over the last year, and will we have a named team or a pooled first tier?
• What is the detection engineering cadence: new and tuned use cases delivered per quarter, with examples?
• If you claim ATT&CK coverage, which techniques exactly, and how was coverage validated? Self-reported figures around the 60% average mean little without the technique list.
• Provide a redacted incident report and a redacted monthly report as delivered to a real client.

Score only what is evidenced. A claim without an artifact behind it scores zero. Two raters score independently, divergences above one point are discussed and resolved in writing, and the weighted matrix is shared with the steering committee before responses arrive, so weights cannot be adjusted to favor a preferred vendor afterwards.

Run a Proof of Value with 2 or 3 finalists on a realistic slice of your environment. The metrics are defined and agreed before the PoV starts. A PoV whose success criteria are written afterwards proves nothing; it only generates material for the vendor's case study.

• Time from log source connection to first validated detection.
• False positive rate and escalation quality on injected test scenarios.
• Responsiveness and substance of analyst communication during the exercise.
• Readability of the resulting report by a non-technical executive, tested by actually giving it to one.

Negotiate the contract against the same outcome metrics used in the PoV. An SLA that measures time-to-acknowledge tells you how fast a ticket changes state. It tells you nothing about whether a real intrusion would be detected and contained. Each contractual service level should map to a metric you can independently verify from your own data, with service credits attached and an audit right over the provider's reported figures.

Response SLA is not detection SLA. The most expensive confusion in MSSP contracts: a 15-minute response SLA usually means a ticket was acknowledged in 15 minutes. Detection performance, triage quality and containment are separate obligations. If the contract only defines response, the provider can meet every SLA during a breach it never detected.

• Exit and handover period long enough to transition without coverage gaps, with provider cooperation obligations stated.
• Return of logs and case data in open, documented formats, with retention guaranteed through the transition.
• Ownership and transfer of runbooks and detection content developed for you during the contract.
• Reversibility tested on paper before signature: walk the exit scenario with the provider and record the answers.

Signature is the start of supervision, not the end of the project. DORA (Regulation (EU) 2022/2554) makes ICT third-party risk management a continuing obligation for financial entities, and NIS2 (Directive (EU) 2022/2555) extends supply chain security duties to essential and important entities. Both expect you to demonstrate that the outsourced capability is monitored, not just contracted.

The practical mechanism is a periodic independent SOC maturity assessment of the outsourced scope against the SOC-CMM, the model created by Rob van Os in 2016, now at version 2.4, covering five domains and 27 aspects on a continuous 0-5 scale. Assessing the provider-operated service with the same yardstick used for your internal baseline gives the board a single trend line: is the maturity you bought actually being delivered, and is it improving year over year? The eighth step closes the loop: documented decision, signed recommendation, and a scheduled re-assessment date before the first renewal conversation.