Both of them say they will watch your security around the clock. Only one of them has agreed, in writing, to do something about what it sees.
That sentence is the whole of the MDR vs MSSP question, and it survives every variation in how the two are marketed. One sells the management of your security estate. The other sells an outcome: that threats get found and contained. This article sets out the five differences that actually change what you get, the one question that separates the two in thirty seconds, and the contract clauses worth arguing about.
- An MSSP manages security technology. Availability, configuration, tuning, tickets.
- MDR sells detection and response as an outcome, usually with its own tooling and its own analysts.
- The dividing line is who acts when something is found at three in the morning.
- Many providers sell both, and the labels have blurred. Read the service description, not the name.
- Neither one makes your incident response plan somebody else’s problem.
What an MSSP actually sells
A managed security service provider operates security technology on your behalf. The firewall, the email gateway, the endpoint platform, often the SIEM. They keep it running, apply policy, handle changes, and raise tickets when it reports something.
That is a real and valuable service, and in the MDR vs MSSP comparison it is often the right one. It is also, crucially, a service whose commitments are about the technology. The SLA says the platform will be available, changes will be made within a window, and alerts will be escalated. It does not usually say that an intrusion will be found.
What MDR actually sells
Managed detection and response starts from the other end. The commitment is about threats: that suspicious activity is identified, investigated by analysts, and either dismissed or contained, within a stated time.
In practice an MDR provider usually brings its own detection stack rather than operating yours, because the outcome is easier to guarantee on technology the provider knows. It staffs analysts around the clock, and the good ones will take containment actions directly, under authority you granted in advance.
An MSSP tells you the alarm went off. An MDR provider has already been to the building, checked whether anybody is inside, and locked the door behind them.
MDR vs MSSP: the five differences that matter
- 1 What is being sold. Management of technology, or a detection and response outcome.
- 2 Whose tooling. An MSSP typically runs yours. An MDR provider typically brings its own, which has consequences when the contract ends.
- 3 Who responds. An MSSP escalates to you. An MDR provider may isolate a host or disable an account itself, if you authorized it.
- 4 The shape of the SLA. Platform availability and ticket response, against time to detect and time to respond.
- 5 Coverage. Both claim 24/7. Ask what is staffed by analysts at 3am and what is an on-call rota reached through a queue.
The question that settles it in thirty seconds
Ask the provider this, and listen to the whole answer. At three in the morning, your analyst sees a domain administrator account log in from an unfamiliar country and start to enumerate the network. What happens next?
An MSSP will describe an escalation: a ticket, a call tree, your on-call engineer. An MDR provider will describe an action: the account is disabled, the host is isolated, and you are told what was done. Both answers are legitimate. They are not the same purchase, and only one of them works if nobody on your side answers the phone.
If the answer involves your team taking the action, make sure your team knows that. The most expensive failure mode in this market is an organization that believed it had bought response and had actually bought notification.
Where the line has blurred
The MDR vs MSSP distinction was cleaner five years ago than it is now. Most MSSPs now offer an MDR tier, and most MDR providers will co-manage a SIEM you already own.
Which means the label on the proposal tells you very little. The service description tells you everything. Read it for three things. What the provider commits to detect, what it is authorized to do without asking, and what happens to the data and the detections when you leave.
What to pin down in the contract
- 1 Response authority, in writing. Which actions the provider may take unilaterally, on which systems, and the exceptions.
- 2 How the response clock is defined. From the event, from the alert, or from the analyst opening the case. These are very different numbers.
- 3 Who owns the telemetry. If the provider’s platform holds your logs, what you get back on exit, in what format, covering what period.
- 4 Retention. Your compliance obligations do not transfer with the service. If a standard requires twelve months, the contract has to deliver twelve months.
- 5 Escalation to you. Named people, named channels, and what happens when none of them answers.
Which one fits, in the MDR vs MSSP choice
An MSSP fits when you have a security team that can act and the gap is operational capacity. Devices to keep running, policies to maintain, out-of-hours coverage of the platform itself.
MDR fits when the gap is the people. No night shift, no analysts, and a real need for somebody to contain an incident before anyone on your side wakes up. Many organizations end up with both, and that is fine as long as the boundary between them is written down rather than assumed.
Where we fit
Our managed service runs on Google Cloud SecOps with threat intelligence attached, which is the MSSP side of this, and the analysts behind it are the SOC. If what you need is breadth and retention rather than depth on a few sources, that is managed SIEM. And the difference between SIEM, SOAR and XDR is worth settling before you pick a service model on top of them.
When the detection fires and something did happen, the work moves to DFIR, and the thing that decides how that goes is whether somebody wrote the plan down first. The template for that plan is here. Talk to the team.
Sources
- NIST, SP 800-61, Computer Security Incident Handling Guide: the response phases that any of these services plugs into.
- NIST, SP 800-92, Guide to Computer Security Log Management: retention and log handling, which stays your obligation whoever operates the platform.
