SOCaaS, MDR, MSSP or managed SOC? The label tells you far less than the contract does, so here’s what to ask before you sign.
Two providers can both promise a 15-minute response time and be describing completely different things.
One might be measuring time to analyst triage, another time to containment, and a third time to notify you that something has been spotted. Same number. Very different service.
That’s the problem with buying managed security. Gartner estimates more than 600 providers claim to offer MDR services alone, before you count the ones selling SOCaaS, managed SOC, MSSP or co-managed services, often in combination. In this article, we’ll explore what those labels actually mean, which questions expose what a provider will really do, and give you a due-diligence checklist to work through before anything gets signed.
SOCaaS, MDR, MSSP: Why The Label Won’t Tell You Much
On paper, the categories look distinct.
Rapid7 describes SOC-as-a-service as fully outsourced operations with defined service levels, while co-managed SOCs blend internal and external capabilities. An MSSP, according to IBM, provides outsourced monitoring and management of security devices and systems, such as managed firewalls, VPNs and antivirus.
MDR is meant to go further. Gartner’s market definition describes MDR providers delivering 24/7 threat monitoring, detection and lightweight response, combining technology with human expertise in investigation and response.
In practice, the lines blur. Because the market has grown so quickly, many managed security services now use the term MDR, and Rapid7’s summary of Gartner’s guidance warns buyers to watch for providers mimicking it.
None of these terms has a universally standardised definition. Treat the label as the start of the conversation.
The NCSC is clear that there is no one-size-fits-all SOC. If you haven’t yet worked out what yours needs to do, start with your SOC operating model before you start comparing providers.
What Will The Provider Actually See?
A provider can only defend what it can see.
A SOC typically draws data from endpoints, networks, cloud workloads, identities and applications, but a managed service may only cover some of them. Ask exactly which assets are in scope, and whether that includes SaaS platforms and third-party telemetry.
Then ask how the provider plugs into what you already run. Does it work with your existing SIEM and EDR or XDR tooling, or does it expect you to adopt its own stack? Are integrations built on documented APIs, or on custom work that only the provider understands?
This matters more than it sounds. A SLA measured against a single EDR platform tells you nothing about detection across identity, email or network layers.
It works the other way too. The Canadian Centre for Cyber Security recommends asking what network and system access, and what data, a provider needs to deliver the service. Coverage and access should be scoped together.
What Can The Provider Actually Do?
This is where two services with the same name start to look very different.
Watching Versus Acting
Monitoring and triage are the baseline. Investigation, threat hunting and detection engineering are where providers separate. Rapid7 notes that mature SOCs rely on threat hunters and detection engineers to uncover emerging risks and refine detection logic, so ask who does that work for you and how often your detections are tuned.
Ask, too, how much of triage is automated. AI is already reshaping security operations, and you’ll want to know where a human analyst steps in.
Who Is Allowed To Contain A Threat?
Response is the biggest variable of all.
Gartner’s market definition calls response a defining element of MDR, but notes the depth varies, with services including different degrees of lightweight, remote incident response. Its 2025 Market Guide expects MDR providers to deliver immediate remote mitigation and containment that goes beyond alerting.
Even then, there are limits. Palo Alto Networks notes that MDR providers investigate and take or coordinate authorised action, but do not typically hold unlimited response authority over production systems.
So get specific. Can the provider isolate an endpoint, disable an account or block an IP without calling you first? Who handles full remediation and recovery? And is major incident response part of the service, or a separate retainer?
How that authority works day to day, once the provider is live in your environment, is a bigger governance question. For now, make sure it’s written down.
Read The SLA Before You Trust The Headline Number
“Response time” is the most overloaded phrase in managed security.
Enhanced.io suggests five questions to ask every provider:
- What does the clock start on: data arriving, or an analyst confirming a threat?
- Which action does the SLA actually cover?
- How are breaches of the SLA measured and reported?
- What is the remedy when an SLA is missed?
- Does the SLA apply across your whole environment or a single data source?
Push for each commitment to be defined separately. Availability, detection, acknowledgement, investigation, escalation, containment and reporting are different things, and failing to distinguish between time to detect, time to acknowledge and time to recover hides where the real bottleneck sits.
The Canadian Cyber Centre’s guidance says your SLA should specify turnaround times, communication methods, escalation processes, performance metrics and penalties for missing them.
Notification deserves its own line. A joint advisory from the UK’s NCSC and its Five Eyes partners says contracts should detail how and when a provider notifies the customer of an incident affecting their environment.
Your Data, Your Evidence, Your Exit
Every investigation your provider runs creates records. You need to know who owns them.
Start with logs. The same joint advisory recommends organisations store their most important logs for at least six months, because incidents can take months to detect. Check whether your provider’s retention matches that, and your own regulatory requirements.
The Canadian Cyber Centre advises confirming where your data is stored, that your organisation retains legal ownership of it, and that the provider can support your retention policy. Ask about investigation records and evidence too, not just raw telemetry.
Then plan the ending before the beginning.
The Canadian Cyber Centre warns that vendor lock-in occurs when it isn’t financially feasible to move data to another provider, and recommends discussing data portability before you sign. Its questions include what happens to your data if the provider goes bankrupt.
Watch the commercial side of leaving as well. Expel notes that data egress charges can be substantial if you need to export security data or migrate to another provider.
And don’t forget access. The joint advisory points out that disabling provider accounts can be overlooked when a contract terminates.
For regulated firms, this isn’t optional. Under DORA, financial entities must have an exit strategy where third-party providers support critical or important functions.
Check The Provider, Not Just The Service
You’re giving an outside team privileged access to your environment. That makes the provider part of your attack surface.
The NCSC-backed advisory warns that threat actors can use a vulnerable MSP as an initial access vector into multiple customer networks. It recommends customers ensure contracts require MFA on all provider accounts accessing their environment, and that providers don’t reuse admin credentials across customers.
Independent assurance helps. The Canadian Cyber Centre suggests asking for third-party evaluation against standards such as ISO 27001, and for SOC 2 Type 2 reports, which providers may only share under an NDA. In the UK, CREST’s SOC accreditation assesses a provider’s ability to deliver security monitoring, incident detection and response.
Look at the people behind the service as well. Who are the analysts, what are their specialisms, do they know your sector, and where are they based? The Canadian guidance also recommends asking who the provider’s own suppliers are, since subcontractors extend your supply chain further.
Finally, test resilience. Ask how the provider’s own operations fail over, and whether it will take part in your disaster recovery testing.
How Managed Security Pricing Works
Pricing models vary as much as the services do.
Expel identifies per-endpoint pricing as the most common MDR model, alongside per-user pricing, tiered service levels, data-volume pricing and hybrids that mix several units. It also notes that technology licensing can sit inside or alongside the headline price.
The catch is usually in the growth curve. Expel warns of extra charges for data ingestion beyond set thresholds, premiums for integrating less common tools, and tier pricing that jumps at certain endpoint counts.
So model the cost at your expected size in three years, not just today. Ask what happens during an ingestion spike, whether incident response is included or billed separately, and what counts as an “additional service”.
The cheapest quote is only cheap if it covers what you need. A lower price that excludes containment, or caps the data you can send, may just be a narrower service.
The Managed Security Provider Due-Diligence Checklist
These are the questions you should be able to answer before you sign. There’s no scoring here: a provider that can’t answer them clearly has told you something already.
Service Definition and Scope
- What does the provider call its service, and what does that include in practice? Labels like MDR aren’t applied consistently across the market, so get the scope in writing.
- Which endpoints, identities, networks, cloud environments and applications are in scope? A SOC typically draws data from all of them.
- Is telemetry from SaaS and other third-party platforms covered? The NCSC’s cloud security principles expect cloud services to provide audit information that’s good enough to investigate incidents. Check that your provider can actually ingest and use it.
- Who is responsible for which log sources? Event logging guidance from the NCSC and its international partners says logging policies should account for responsibilities shared between service providers and the organisation.
Operational Capability
- Who handles monitoring, triage, investigation, threat hunting and detection engineering? Rapid7 identifies hunting and detection engineering as distinct SOC roles, so ask who does each one for you.
- What containment actions can the provider take without your approval? MDR providers typically take or coordinate authorised action, not unrestricted action on production systems.
- Who owns remediation, recovery and major incident response, and is any of it billed separately? Gartner describes the response in many MDR services as “lightweight”.
Integration
- Does the service work with your existing SIEM, EDR/XDR, identity and cloud tooling, or does it need its own stack? As enhanced.io points out, an SLA tied to one EDR platform says nothing about identity, email or network coverage.
- Can you query, export and archive the data yourself? The NCSC’s cloud principles favour providers that offer APIs and tooling to query, process and archive audit information.
SLAs
- Is each commitment (availability, detection, acknowledgement, investigation, escalation, containment, reporting) defined separately? Blurring detection, acknowledgement and recovery times hides where the delays sit.
- When does each clock start, which action does it cover, and how are misses reported and remedied? These are enhanced.io’s tests for whether an SLA means anything.
- Does the SLA set turnaround times, communication methods, escalation routes, performance metrics and penalties, as the Canadian Centre for Cyber Security recommends?
- Does the contract say how and when you’ll be told about an incident? The NCSC’s supplier assurance questions ask for reporting timescales, contacts and expected actions to be written into the contract. The joint advisory on MSP threats says the same.
Data, Evidence and Exit
- Where is your data stored and processed, including offshore support? The NCSC asks whether any part of a supplier’s service is offshored, and whether you’ll be told if locations or offshore subcontractors change.
- How long are logs kept? The joint advisory recommends keeping your most important logs for at least six months.
- Who owns investigation records and evidence, and will they stand up to a forensic investigation? The NCSC’s cloud principles expect audit information to carry enough detail for forensics and to be protected from deletion during a defined retention period.
- What happens at contract exit? The NCSC suggests contracts cover secure deletion or return of your data and transfer to another supplier. The Canadian Cyber Centre adds proprietary data formats and switching penalties to the list, and Expel warns that data egress charges can be substantial.
- How will the provider’s access be removed? The joint advisory notes this is easily overlooked when a contract ends.
Provider Assurance
- Has the provider suffered any material security breaches it should declare? This question comes straight from the NCSC’s question set.
- Which certifications does it hold, such as Cyber Essentials Plus or ISO 27001, and does their scope cover the service you’re buying? The NCSC recommends checking scope as well as the certificate. The Canadian Cyber Centre suggests asking for a SOC 2 Type 2 report, which providers may only share under NDA.
- Is its SOC independently accredited? CREST’s SOC accreditation assesses monitoring, detection and response capability.
- Does it commission independent tests, such as tests, and fix what they find? This is another NCSC question.
- Which subcontractors are involved, must your security requirements flow down to them, and will you be told if they change? Do you have a right to audit? Both questions appear in the NCSC’s contractual considerations.
- How are the provider’s accounts secured in your environment? The joint advisory calls for MFA on provider accounts, no reuse of admin credentials across customers, and least privilege.
- Who owns security at the provider, and are its people suitably skilled and background-checked? The NCSC covers both governance and personnel security.
- How will it keep your service running if it suffers an incident itself, such as ransomware? The NCSC asks for a business continuity plan that maintains minimum service levels.
- What happens to your data if the provider goes out of business? This is one of the Canadian Cyber Centre’s exit questions.
Commercials
- What is the pricing unit (endpoint, user, data volume or tier), and how does cost change as you grow? Expel identifies per-endpoint as the most common model.
- What sits outside the core fee? Expel flags ingestion overages, integration premiums and tier jumps as the costs to watch.
Outsourcing security operations changes who does the work. It doesn’t change who’s accountable for it. The NCSC is blunt that accountability for your security is the one thing you can’t hand to a supplier.
Comments ( 0 )