MDR vs MSSP: Service Models, Response and Contracts

Organisations outsourcing security operations often sign with a provider expecting someone to stop an attack, and find later that the contract only promised to tell them about it. That gap is the practical difference between managed detection and response (MDR) and a managed security service provider (MSSP). An MDR service is built around detecting threats and taking response actions, usually on its own or a chosen technology stack. An MSSP typically runs and monitors a broader set of security tools, such as firewalls, SIEM, vulnerability scanning and email filtering, and escalates alerts for the customer to act on. The labels overlap and providers use them loosely, so this guide compares the service models, not providers: what each covers, who does what during an incident, and the contract questions that settle it. It is for security leaders, procurement and risk teams choosing or renewing an outsourced service.

Key takeaways

Response authority is the dividing line. MDR is defined by the provider investigating and acting, such as isolating hosts or disabling accounts; MSSP services traditionally manage devices and monitor, then notify you.
MSSP breadth, MDR depth. An MSSP may operate many controls across the estate; MDR concentrates on threat detection, hunting and incident handling, often centred on endpoint and identity telemetry.
Read the service description, not the label. Many MSSPs sell MDR tiers and many MDR providers manage a SIEM. Contract wording on actions, hours, telemetry and notification decides what you get.
You keep the risk. CISA's guidance for MSP customers states that outsourcing does not absolve an organisation of risk management responsibilities; define a shared responsibility model in writing.
The provider is a privileged third party. Its accounts and tooling reach into your environment, so treat provider access as a high-risk identity: least privilege, MFA, logging you control, and fast removal at exit.

The short answer

Choose MDR when your priority is having qualified people detect and contain attacks around the clock and you can grant them authority to act. Choose an MSSP when you need a partner to operate and maintain a range of security technologies and provide monitoring and reporting, and you have an internal team (or a separate responder) to take action on escalations. Many organisations combine them: an MSSP for device management and compliance reporting, and MDR or an incident response retainer for detection and response. See the MDR Guide and the Cybersecurity for MSPs and MSSPs Guide.

ASD's joint guidance with CISA on SIEM and SOAR adds an important caution for both models: it recommends in-house operation where an organisation handles sensitive information or provides critical services, because outsourcing can create visibility gaps, duplicated work and communication difficulties. If you outsource, the contract must close those gaps.

Side-by-side comparison

Dimension	MDR	MSSP
Core outcome	Threats detected, investigated and contained	Security technology operated, monitored and reported on
Typical scope	Endpoint, identity, cloud and email detection; threat hunting; incident handling	Firewalls, VPN, IDS/IPS, SIEM, email filtering, vulnerability scanning, device patching and configuration
Response	Provider takes agreed actions (isolate host, kill process, disable account, block indicator) and guides remediation	Alerts and tickets escalated to the customer; actions often limited to devices the MSSP manages
Technology	Usually the provider's own or preferred EDR or XDR stack, sometimes your existing tools	Often your existing tools, or the provider's SIEM and managed devices
Human analysis	Analysts investigate each alert and hunt proactively	Analysts triage alerts; depth varies by tier
Typical reports	Incident narratives, root cause, containment taken, hunt findings	Device health, alert volumes, SLA performance, compliance reports
Commercial model	Per endpoint or per user, sometimes with log volume	Per device, per service or per log volume
Customer effort	Approve action policy, fix root causes, own communications	Act on escalations, run incident response, own remediation

Related models fill the space between: a co-managed SOC shares tooling and work with your own analysts, and SOC-as-a-service provides a full outsourced SOC. See the Co-Managed SOC and SOC-as-a-Service Guide.

Response scope: who does what

Write a responsibility matrix before signing. The example below shows a common default for each model; your contract should replace it with named actions.

Activity	MDR (typical)	MSSP (typical)	Customer (always)
24/7 alert monitoring	Provider	Provider	Confirms coverage of named sources
Investigation of an alert	Provider, to a conclusion	Provider triage; deep investigation often extra	Supplies business context
Host isolation	Provider, under pre-approved policy	Customer, unless MSSP manages the EDR	Sets exclusions for critical systems
Account disable or session revoke	Provider, if granted identity access	Customer	Defines which accounts are out of scope, including service accounts
Firewall or proxy block	Varies	Provider, on devices it manages	Approves change policy
Eradication and recovery	Guidance; hands-on often extra or by retainer	Customer or separate responder	Owns restoration
Regulatory and customer notification	Supplies facts	Supplies facts	Decides and notifies

NIST CSF 2.0 RS.MA-01 expects the incident response plan to be executed in coordination with relevant third parties once an incident is declared; the matrix is how you make that real. See the Incident Response Guide.

Each option in depth

For each option below: the threat it is built for, how it fails, the controls that make it work, when to choose it and a worked example.

MDR

Threat model. MDR providers detect and respond inside your estate, so they need privileged access, often through agents and remote tooling. Their threat model is your threat model plus the provider as a trusted relationship (T1199) and remote service path (T1133).

Failure modes. Response authority never agreed, so the provider watches but cannot contain; coverage limited to its own agent; and log data you cannot retrieve when you leave.

Controls. Follow the NCSC questions in Choosing a managed service provider (24 November 2025): least privilege, two-step verification on the provider's access, contractual log retention and access, severity-based notification times and clarity on subcontractors.

Decision criteria. Choose MDR when you need active threat hunting and containment beyond your staff's hours, and can grant and audit the access it requires.

Worked scenario. An MDR analyst sees credential dumping overnight and, under pre-agreed authority, isolates the host and disables the account, then hands the case to the internal team at 08:00 with a timeline.

MSSP

Threat model. An MSSP typically runs and monitors security devices and services. Its threat model centres on administrative access to many customers' devices, which makes it an attractive target.

Failure modes. Alert forwarding without investigation; shared administrative accounts across customers; and contracts silent on what happens if the MSSP itself has an incident.

Controls. Named administrative accounts per customer, logs you can access, documented incident steps, notification times in the contract, and an exit plan covering renewal, renegotiation and termination, as the NCSC guidance recommends.

Decision criteria. Choose an MSSP for device management and baseline monitoring when you have staff to investigate what it escalates.

Worked scenario. An MSSP escalates a firewall alert at 02:00. The internal on-call engineer investigates and finds a misrouted backup job. Because the MSSP held only device access, nothing was disrupted, and the contract defined the notification time that was met.

Where identity fits

Both models need standing access into your environment: agent management consoles, API credentials for EDR, identity and email platforms, VPN or remote access, and sometimes privileged directory roles. Attackers target providers for exactly this reach, which ATT&CK catalogues as T1199 Trusted Relationship and T1133 External Remote Services. CISA's guidance for MSP customers recommends least privilege for the shortest necessary time, keeping provider accounts out of administrator groups, disabling them when not in use, MFA, routing provider traffic through a dedicated VPN, and feeding provider activity into your own monitoring. Give each provider integration its own named service principal or API client, not a shared admin account, and review it quarterly. See the Third-Party Risk Management Guide.

When to use each

MDR suits: organisations without 24/7 analysts; those whose main risk is ransomware and account takeover; teams willing to delegate containment under an agreed policy.
MSSP suits: organisations that need security devices run and patched, compliance reporting, and log monitoring across a broad estate, with internal staff able to act on escalations.
Both, or MSSP plus retainer: larger organisations where device operations and detection response are separate competencies; see the Incident Response Retainer Buyer's Guide.
In-house or co-managed instead: organisations handling highly sensitive data or critical services, following the ASD recommendation, or those whose regulators restrict where data and staff may be located.

Small versus large organisations

Small organisations with no security staff usually gain most from MDR, because an alert that reaches an IT generalist at 3am is rarely actioned in time. Large organisations more often keep an internal SOC and buy MDR for specific gaps (out-of-hours cover, cloud, OT) or an MSSP for device operations, with clear boundaries so two parties are not both watching, or both assuming the other is.

Contract questions

The Canadian Centre for Cyber Security's Recommended Contract Clauses for SOC Procurement (ITSM.00.500, April 2025) and the NCSC's Choosing a managed service provider (November 2025) are the best public starting points. Ask every bidder, MDR or MSSP:

Actions: Which response actions will you take without asking, which need approval, and how fast is approval sought out of hours?
Coverage: Which log sources and assets are in scope, at what hours, and how will you tell us when a source goes silent?
Notification: Within what time will you notify us of a detected incident, and of incidents affecting your own systems or other clients that could reach us?
Service levels: What are the time to acknowledge, time to investigate and time to contain commitments by severity, and how are they measured and reported monthly?
Data: What data do you collect, where is it stored and processed, who can access it, and how is it segregated from other clients?
People and location: Where are analysts based, and do any staff or subcontractors work from other countries or a follow-the-sun model?
Subcontractors: Which subcontractors touch our data, and do you accept responsibility for their actions?
Access: What accounts and permissions do you need, how are they protected with MFA, and how quickly are they removed?
Assurance: What certifications, audit reports and testing evidence can you share, and do we have audit rights?
Liability: Who is liable when a missed detection or an incorrect action causes loss?
Exit: How do we get our data, detections, playbooks and case history back, in what format, at what cost, and how is our data deleted?

The Cyber Centre document separates mandatory requirements ("must", "shall") from rated ones ("should", "may"); use that wording discipline in your own tender. The MDR Service RFP Template and Managed Security Services RFP Template provide full question sets.

Costs that change the comparison

Data volume: where a service includes a SIEM, pricing often follows the volume of logs ingested; the ASD guidance warns that adding log sources over time can raise costs sharply unless ingestion is capped or managed.
Technology bundled or brought: MDR priced with the provider's own EDR licences may cost less up front but ties detection to that stack; bringing your own tools keeps portability and may add integration charges.
Incident hours: hands-on eradication, forensics and recovery are often outside the base fee and billed per incident or through a retainer.
Internal effort: an MSSP that escalates rather than acts still needs your staff to respond, which is a real cost often left out of comparisons.
Hidden caps: check for limits on the number of investigations, hunts or incident hours a month, and what happens to service levels when a cap is reached during a major incident.
Exit: data export, migration and the overlap period with a new provider cost money; agree them at signing, not at termination.

Onboarding and testing

Agree the responsibility matrix and action policy before any agent is deployed, including exclusions for critical servers and service accounts.
Provision provider access through named, least-privilege identities with MFA, logged to a platform you control.
Onboard sources in phases, confirming each one produces data the provider can see.
Run in notify-only mode for an initial period, then enable approved actions.
Test with a controlled exercise: simulate known techniques and measure whether the provider detects, notifies and acts within SLA.
Rehearse an incident jointly, including out-of-hours escalation and the hand-off to your responders.

Rollback: keep the ability to revoke all provider access in one step, and keep your own copy of security logs so a change of provider does not erase history.

Measuring the service

Time to notify and time to contain per severity, measured from your own records, not only the provider's report.
Detection rate in tests: share of simulated techniques the provider detected and reported.
Escalation quality: share of escalations that were actionable without follow-up questions.
Source health: count of in-scope sources silent beyond the agreed threshold.
Provider access hygiene: provider accounts active versus contracted, and time to remove access after staff changes.

Common failure patterns

Buying "monitoring" and assuming response. Alerts arrive by email at night and nobody acts.
No pre-approved action policy, so an MDR analyst waits hours for permission to isolate a host.
Telemetry gaps nobody owns. Cloud or identity logs are out of scope and both sides assume the other covers them.
Provider accounts with standing global admin, never reviewed, becoming the easiest route into the estate.
No exit plan, leaving data, detections and access behind when the contract ends.
Logs held only by the provider, so independent investigation is impossible after a dispute or provider incident.

Framework mapping

Framework	Reference	What it asks of an outsourced service
NIST CSF 2.0	GV.SC-05, GV.SC-06, GV.SC-07	Security requirements in contracts, due diligence before signing, and ongoing monitoring of the provider
NIST CSF 2.0	GV.SC-10	Provisions for activities after the agreement ends
NIST CSF 2.0	RS.MA-01, RS.CO-02	Coordinated incident execution and stakeholder notification
NIST SP 800-53 r5	SA-9 External System Services; SA-9(5) Processing, Storage, and Service Location	Security obligations and data location for the service
NIST SP 800-53 r5	PS-7 External Personnel Security; IR-4 Incident Handling	Provider staff requirements and incident handling roles
CIS Controls v8.1	Control 15 Service Provider Management; Control 17 Incident Response Management	Inventory, classification, contract terms, monitoring and decommissioning of providers
ISO/IEC 27001:2022	Annex A 5.19 to 5.22 (supplier relationships); 5.26 Response to information security incidents	Supplier agreements, monitoring and incident response

Decision checklist

Who will act on a critical alert at 3am on a Sunday?
Which actions are you willing to delegate, and for which assets and accounts?
Do you need devices operated, threats hunted, or both?
Which data and staff locations do your regulators and customers allow?
Can you keep your own copy of logs and revoke provider access in one step?
What does exit look like, and is it priced in the contract?

Practitioner checklist

Write a responsibility matrix naming every response action and its owner.
Agree a pre-approved action policy with exclusions for critical systems and service accounts.
Put notification times, SLAs by severity and monthly reporting into the contract.
Give the provider named, least-privilege, MFA-protected identities and log their use yourself.
Keep your own copy of security logs independent of the provider.
Test the service with simulated techniques at onboarding and at least annually.
Review provider access quarterly and remove unused accounts.
Document the exit process: data return, format, deletion and access revocation.

MDR vs MSSP: Service Models, Response Scope and Contract Questions