SOC as a service,
explained properly.
What SOC as a service actually covers, how it differs from an MSSP, an MDR product and building your own, and the questions that separate providers who investigate from providers who notify.
SOC as a service is a subscription to a Security Operations Center instead of building one. The provider supplies analysts, detection content and platform, and monitors your environment around the clock. You keep the estate and the risk decisions. What varies between providers is scope and mandate: which surfaces are watched, and what the provider may do when something fires.
Where each one breaks.
Every model works for somebody. The useful question is which failure mode you can live with.
Total control, deep context on your own systems, no third party in the loop.
Three shifts of analysts, retention in a tight market, and detection engineering as a permanent function rather than a project.
Device management and alerting at predictable cost, often bundled with existing infrastructure contracts.
Output is frequently a queue. If nobody investigates to a conclusion, the work has moved rather than disappeared.
Analysts, detection content and coverage as a subscription, scaling with the estate rather than with headcount.
Quality varies enormously behind similar words. The scope and the response mandate matter far more than the label.
Your team keeps daytime ownership and context; the provider covers nights, weekends and surge.
Handover discipline. Two teams sharing one queue works only when escalation paths are written down and rehearsed.
Six questions worth asking.
- 01Show me a redacted incident timeline from last quarter: detection, first analyst action, containment.
- 02Which surfaces are in scope, and specifically is identity telemetry included or extra?
- 03What are you contractually permitted to do without calling me first?
- 04Who is awake at 3am on a Sunday, and are they the same people I meet during onboarding?
- 05How long is data retained, and can I query it myself?
- 06When a detection is wrong, what is the process for tuning it, and how long does that take?
Two shapes, one SOC.
Your tools. Our SOC.
Vendor-agnostic managed XDR, operating over the EDR you already own. The option when replacing the estate is not on the table.
Our stack. Our SOC.
Platform and operations together, when standardizing is preferable to maintaining competence across several vendors.
Reselling rather than buying? The MSP version of this page covers the white-label delivery model.
Usually in, usually extra.
Generalized across the market rather than specific to any one provider. Use it as a checklist against whatever you are quoted, because the second column is where proposals diverge.
- +Endpoint detection monitoring and triage
- +Continuous coverage across nights and weekends
- +Alert investigation to a conclusion by an analyst
- +Escalation to a named contact with context attached
- +Periodic reporting on what was seen and done
- +Detection tuning as the environment changes
- ?Identity telemetry, despite being where intrusions progress
- ?Cloud control plane and SaaS audit logs
- ?Active containment rather than notification
- ?Log retention beyond a short default window
- ?Incident response past the point of containment
- ?Onboarding and tuning effort at the start
- ?Threat hunting as distinct from alert triage
The right column is not a list of things providers hide. It is a list of things that genuinely cost more to supply, which is why they are scoped separately. The problem is only when a proposal is silent about them and the assumption surfaces during an incident.
Common questions.
What is SOC as a service?
SOC as a service is a subscription to a Security Operations Center rather than the construction of one. A provider supplies the analysts, the detection content and the platform, and monitors your environment around the clock. You keep ownership of the estate and the decisions; the provider supplies the watching and, depending on the tier, the response.
How is SOC as a service different from an MSSP?
The historical distinction is that an MSSP manages security devices and forwards what they generate, while SOC as a service is oriented around detection and investigation. In practice the labels have blurred, so the useful test is behavioral: ask whether anyone investigates each alert to a conclusion, and whether the provider takes action or hands you a queue.
Is SOC as a service the same as MDR?
They overlap heavily and vendors use both terms for similar offers. MDR usually implies the provider supplies the detection technology as well as the operations. SOC as a service is the broader term and often covers operating what the customer already owns. Rather than argue definitions, compare scope: which surfaces are watched, and what the provider is contracted to do when something fires.
Do I still need a SIEM?
Usually something plays that role, because investigation needs searchable history. Whether you own it, the provider owns it, or it is bundled changes the commercial shape rather than the requirement. What matters is retention long enough to answer the questions an incident raises, and whether anyone is querying it outside business hours.
What should be in scope?
Endpoints are the common starting point and the least sufficient on their own. Identity is where most intrusions now actually progress, so identity telemetry belongs in scope early. Cloud control planes, email and network sources follow depending on the estate. A provider watching only endpoints is watching one of several doors.
How do I compare providers fairly?
Ask each for a redacted incident timeline from the last quarter showing detection time, first analyst action, and containment. That single artefact separates providers who investigate from providers who notify, and it is harder to dress up than a capability matrix. Then ask what they are contractually permitted to do without calling you first.
What does the provider need access to?
Telemetry from the systems in scope, and a defined boundary for response actions. A well-scoped engagement does not require open-ended administrative control of your environment. Agree in writing which actions may be taken without a call, which require one, and who is called, before the first incident rather than during it.
Does buying a SOC mean losing internal capability?
It usually means redirecting it. Internal teams stop staffing overnight triage and spend the time on the things only they can do: knowing which systems matter, owning remediation, and making risk decisions. The failure mode is treating the provider as a black box and never reading the incident reports.
How quickly can it be running?
Connecting sources is quick; making the detections meaningful is not. Tuning to an environment takes time, and a provider promising full value on day one is describing an untuned queue. Expect a period where volume is deliberately reduced before coverage is widened.
What happens if it is not working?
Look for evidence rather than reassurance. Falling alert volume with no investigation record is a warning, not a success. Ask for the same incident timeline you asked for during evaluation, quarterly, and compare it against what you were shown when you signed.
See if you qualify.
No sales call.
Answer a few questions about your environment and see where you land, without booking anything.