MDR vs MSSP vs SOC-as-a-Service: What's Actually Different
These three terms get used almost interchangeably in vendor pitches, but they describe genuinely different levels of service. Here's what each one actually does, and the questions that reveal which one you're being sold.
The short answer
All three sell you help watching your environment for threats. The real difference is what happens after something fires: an MSSP typically forwards alerts and manages your tools, leaving investigation and the decision to act with your team. SOC-as-a-service adds staffed, 24/7 eyes on the alerts, but often stops at notification rather than taking action. MDR is the only one of the three that implies the provider investigates every alert and takes contained action on your behalf, within authority you pre-approve, not just tells you about it.
None of this is standardised. Vendors use all three terms loosely, and some products marketed as MDR are closer to SOC-as-a-service in practice. The only reliable way to know what you're buying is to ask what happens between an alert firing and a threat being contained, and who does that work.
What an MSSP actually does
A managed security service provider (MSSP) grew out of managing the tools themselves: firewalls, VPNs, early intrusion detection systems. That heritage still shows in how most MSSP contracts work today. The provider deploys, tunes and keeps your security tools running, forwards the alerts those tools generate, and produces the compliance reporting you need. What it usually does not do is decide, on your behalf, that a specific alert is a real incident and then act to contain it.
That's not a criticism of the model. An MSSP can be exactly right for a team that already has the people to triage alerts and just wants the tooling managed, or that needs a managed firewall and email gateway rather than a response function. The problem is when "managed security" gets sold as if it covers the investigation and response work it doesn't include, leaving a team that thought they were covered discovering, mid-incident, that the alert was sitting in a queue.
What "SOC-as-a-service" usually means
SOC-as-a-service sits between the two. It typically adds what a basic MSSP contract lacks: named analysts actually watching a console around the clock, rather than alerts simply routing into a ticketing system. That's a meaningful step up, and for a lot of organisations it's genuinely sufficient.
Where it tends to fall short of MDR is in authority and depth. A SOC-as-a-service analyst will often confirm that an alert looks real and escalate it to you, rather than being pre-authorised to isolate the affected host or kill the malicious process themselves. The notification arrives faster than with a pure MSSP, but your team still does the actual containment, usually outside normal hours, under pressure. This is also the term with the most overlap with MDR in how vendors use it; some SOC-as-a-service offerings are, in substance, MDR, and some MDR products are, in substance, SOC-as-a-service with a different label. The name alone won't tell you.
What MDR adds on top
Managed detection and response is defined by the second word as much as the first. A genuine MDR provider doesn't just detect and tell you; it investigates the alert to confirm what actually happened, then takes contained action, isolating a host, killing a process, disabling a compromised account, within scope and authority your team pre-approves at onboarding. The alert doesn't wait for your team to wake up and decide; the decision was already made in advance, for that class of action.
A few things tend to go with that model in practice, though they're not universal: threat intelligence tuned to the specific operating systems and software you actually run, rather than generic feeds; a shared workspace where you can see the investigation as it happens instead of waiting for a summary; and written service levels for how fast an alert gets acknowledged and a critical incident gets contained, not just how fast it gets noticed.
MDR doesn't require replacing the tools you already run. A provider worth considering should connect to the EDR, SIEM, identity and network tools you already own rather than asking you to buy theirs first.
Side by side
| Question | MSSP | SOC-as-a-service | MDR |
|---|---|---|---|
| What happens to an alert? | Forwarded or ticketed to your team | Reviewed by an analyst, then escalated | Investigated and acted on directly |
| Who takes containment action? | Your team | Usually your team, on the provider's advice | The provider, within pre-approved scope |
| Whose tools are used? | Usually deployed and managed by the provider | Varies; often the provider's own stack | Typically the tools you already own |
| Is coverage 24/7? | Often business hours, or on-call after | Yes, that's the core offer | Yes, including the response, not just the watching |
| Best fit for | Teams with their own analysts who need tooling managed | Teams that need 24/7 eyes but can still respond in hours | Teams with no night shift and no SOC of their own |
Five questions that cut through the marketing
Whatever a vendor calls their service, these questions reveal what you're actually buying faster than the label does.
- When an alert fires at 3am, who decides whether to act, and how fast? If the answer is "we call you," you're paying for notification, not response.
- What specific actions are you authorised to take without calling me first? A real answer names actions (isolate a host, disable an account) agreed in advance, not a vague "we'll contain the threat."
- What's the written SLA for acknowledgement and for containment of a critical incident? "Fast" is not a number. Ask for both figures separately.
- Do I need to buy your tools, or do you work with what I already run? A requirement to replace your stack is a sign the "service" is partly a hardware or licence sale.
- Can I see the investigation while it happens, not just a summary afterwards? A shared workspace is a good proxy for whether real investigative work is happening at all.
Where Pulse fits
Touchpoint's Pulse is built to the MDR end of this spectrum: named analysts investigate every alert from the tools you already run, and act within containment authority you set at onboarding, around the clock. Signal, Pulse's threat intelligence layer, is matched to the specific operating systems, hardware and software in your environment rather than a generic feed. See how it works and what's included on the Pulse MDR page, or compare the published pricing on Packages.
Frequently asked questions
Is MDR more expensive than an MSSP?+
Often, yes, per device or endpoint, because the price covers investigation and containment work, not just alert forwarding. The comparison that matters is cost per contained incident, not cost per month: an MSSP that forwards everything to your team shifts the labour cost onto you instead of removing it.
Can MDR replace my SOC entirely?+
For most small and mid-sized teams, yes, that is the point: MDR exists so you do not have to staff a 24/7 SOC yourself. Larger organisations sometimes keep a small internal team for tier-1 triage or compliance ownership and use MDR for the always-on coverage and deep investigation work.
Do I need to buy new tools to use an MDR service?+
A good MDR provider should work with the EDR, SIEM and network tools you already run rather than requiring you to rip and replace them. If a vendor's MDR pitch depends on you first buying their own stack, confirm whether that is a genuine requirement or a bundling tactic.
Is SOC-as-a-service the same thing as MDR?+
They overlap, and some vendors use the terms interchangeably, but SOC-as-a-service more often describes staffed monitoring and alerting, while MDR specifically implies the provider also investigates and takes contained action within authority you pre-approve. Always ask what happens after an alert fires, not just who is watching for it.
Not sure which one you actually need?
Tell us what you have in place today and we'll give you a straight answer, not a sales pitch.