Guide

SOC as a Service & MDR: The Complete Guide

What a security operations centre actually does, how SOC, MSSP, MDR and SIEM differ, build vs buy, the metrics that matter, and how to evaluate a provider.

15 min read · Updated 25 Aug 2026 · By TechBiz Security

In short

A Security Operations Centre (SOC) is the function that continuously monitors an organisation's systems for signs of attack, investigates what the tooling flags, and drives the response when something is real. SOC-as-a-service means that function is delivered by an external provider rather than staffed in-house — the analysts, the detection engineering, and the 24/7 coverage come as a service. It differs from a penetration test in timing: testing tells you what could happen, a SOC tells you what is happening right now.

What is a Security Operations Centre?

A SOC is not a room full of screens — it is a capability. It combines people, defined processes, and tooling to answer one question continuously: is something bad happening in our environment right now, and what are we doing about it?

That capability has four parts. Collection — getting logs and telemetry out of your systems into one place. Detection — turning that telemetry into meaningful alerts. Triage and investigation — humans deciding which alerts are real and what they mean. Response — containing and remediating what turns out to be genuine. A tool can do the first two. The last two are why a SOC needs analysts.

The distinction that matters commercially: buying a SIEM gives you collection and some detection. Buying a SOC gives you the humans who make the other half work.

SOC vs MSSP vs MDR vs SIEM — what actually differs

These four terms are used almost interchangeably in sales conversations, and they are not the same thing. Buying the wrong one is how organisations end up paying for alert forwarding and believing they bought detection.

	SIEM	MSSP	MDR	SOC-as-a-Service
What it is	A platform	A managed service	A managed outcome	A managed function
Primary job	Collect, correlate, store logs	Manage security devices	Detect and respond on your behalf	Run the whole detection & response function
Humans included?	No	Usually device admins	Yes — analysts	Yes — analysts + detection engineering
Who investigates alerts?	You	Usually you	The provider	The provider
Typical scope	Whatever you feed it	Firewalls, EDR, proxies	Endpoint-led, often expanding	Broad: endpoint, network, cloud, identity
Common failure mode	Expensive log storage nobody reads	Alerts forwarded, not investigated	Narrow telemetry coverage	Weak integration with your own IT team

A blunt test for any provider: ask what happens at 3am when a detection fires. If the answer is "we send you an alert", that is alert forwarding, whatever the contract calls it. If the answer is "an analyst investigates, and here is the containment action we are authorised to take", that is detection and response.

In-house SOC vs SOC-as-a-service

The honest constraint on an in-house SOC is not tooling cost — it is staffing 24/7. Genuine round-the-clock coverage needs roughly 8–12 analysts once you account for three shifts, weekends, holidays, leave and attrition. Below that headcount you have business-hours monitoring with an on-call rota, which is a legitimate choice but should be called what it is.

Build in-house when — you have deep environment-specific context that would take an outsider a long time to learn, regulatory constraints on who may view your data, or you are already large enough to sustain the rota.
Buy as a service when — you need 24/7 coverage sooner than you can hire it, your alert volume does not justify a full team, or you want mature detection engineering without building that discipline from scratch.
Hybrid — your team owns business-hours triage and environment context; the provider covers nights, weekends and surge. Common, and often the most realistic path for mid-market organisations.

Whichever you choose, the deciding factor is rarely the technology. It is whether someone competent is actually looking, at the hour an attacker chooses to move.

What a SOC actually does day to day

Log and telemetry collection — Endpoint, network, identity, cloud control-plane and application logs are centralised. Coverage gaps here become blind spots everywhere downstream.
Detection engineering — Writing, tuning and retiring the rules that turn telemetry into alerts. This is ongoing work, not a one-time setup — an untuned detection stack drowns analysts in false positives within weeks.
Alert triage — Analysts assess each detection: is it real, what is the scope, does it need escalation. Most alerts are not incidents, and deciding that quickly is the core skill.
Investigation — For alerts that survive triage — establishing what actually happened, which assets and accounts are involved, and how far it reached.
Threat hunting — Proactively searching for adversary activity that no rule fired on, usually driven by a hypothesis or fresh threat intelligence.
Incident response — Containment, eradication and recovery when something is confirmed — plus the evidence preservation that matters if the incident becomes a legal or regulatory matter.
Reporting and feedback — What was seen, what was done, and what should change. Findings should loop back into detection rules and into hardening work.

The detection stack, by category

Tooling categories matter more than vendor names, because the categories define what you can and cannot see.

EDR / XDR — endpoint (and increasingly cross-domain) detection and response. The single highest-value telemetry source for most organisations, because endpoints are where attackers execute.
SIEM — central collection, correlation and retention. Its value depends entirely on what you feed it and how well the rules are tuned.
NDR — network detection and response. Valuable where endpoint agents cannot go: OT, IoT, unmanaged devices.
Identity monitoring — increasingly the decisive signal. Modern intrusions frequently involve valid credentials rather than malware, which makes authentication and privilege telemetry critical.
Cloud control-plane logs — AWS CloudTrail, Azure Activity/Entra logs, GCP Audit Logs. Cloud compromise usually shows up here first, and these are commonly not collected at all.
SOAR / automation — automating repetitive triage and containment steps. Useful once your process is stable; premature automation just automates a bad process.
Threat intelligence — context on adversary infrastructure and behaviour, used to prioritise and to drive hunts.

Frameworks worth anchoring to

MITRE ATT&CK — a knowledge base of real adversary tactics and techniques. Its practical use in a SOC is coverage mapping: which techniques can we actually detect, and where are the gaps?
NIST SP 800-61 — the Computer Security Incident Handling Guide; the standard reference for structuring the incident-response lifecycle.
Sigma — a vendor-neutral format for writing detection rules, which lets detection logic move between platforms instead of being locked to one SIEM.
The Pyramid of Pain — David Bianco's model explaining why detecting adversary behaviour hurts an attacker far more than blocking their file hashes or IPs, which they can change trivially.
MITRE D3FEND — a counterpart to ATT&CK that catalogues defensive countermeasures.

The metrics that actually mean something

SOC reporting is easy to game. Alert volume and "threats blocked" look impressive and say almost nothing. These are the numbers worth tracking:

MTTD (mean time to detect) — how long between compromise and detection. The number attackers care about most.
MTTR (mean time to respond/contain) — how long between detection and containment.
False-positive rate — rising false positives predict analyst burnout and missed real alerts. A tuning problem, not an analyst problem.
Detection coverage — what proportion of relevant ATT&CK techniques you can actually detect, honestly assessed.
Telemetry coverage — what percentage of assets are actually reporting. Usually lower than anyone assumes, and the most common root cause of a miss.
Escalation accuracy — of alerts escalated to you, how many warranted it. Measures whether triage is doing its job.

Beware "threats blocked" as a headline metric. A firewall dropping internet background noise generates enormous numbers and reflects no security outcome whatsoever.

How to evaluate a SOC or MDR provider

At 3am, when a detection fires, what exactly happens — and who does it?
Which containment actions are you authorised to take without waiting for me, and which need my approval?
What telemetry do you require, and what are the blind spots if I cannot provide some of it?
Who writes and tunes the detection rules, and how often are they reviewed?
How do you measure detection coverage, and will you show me your ATT&CK coverage map?
What are your actual response times, and are they contractual or aspirational?
How is my data stored, where, for how long, and who can access it?
What does onboarding look like, and how long until detections are genuinely tuned to my environment?

The last question matters more than most buyers expect. A SOC is rarely effective on day one — the first weeks are spent learning what normal looks like in your environment. A provider who claims otherwise is overselling.

Frequently asked questions

What is SOC as a service?

SOC as a service means an external provider runs your security monitoring, detection and response function — the analysts, the detection engineering and the 24/7 coverage are delivered as a service rather than staffed in-house. You keep ownership of decisions and of your environment; the provider supplies the capability.

What is the difference between MDR and SOC as a service?

MDR (managed detection and response) is typically endpoint-led and focused on delivering a detection-and-response outcome. SOC as a service is broader in scope — covering endpoint, network, cloud and identity telemetry, plus the surrounding detection engineering, hunting and reporting. In practice the terms overlap, so judge the actual scope and telemetry rather than the label.

Do we still need penetration testing if we have a SOC?

Yes — they answer different questions. Penetration testing tells you what an attacker could do; a SOC tells you what is happening now. Testing also validates that your SOC detects the activity it should, which is why purple-team exercises pair the two deliberately.

How long does it take to onboard a SOC service?

Log sources can usually be connected in days to a few weeks depending on how many systems are in scope. Genuinely tuned detections take longer, because the provider first has to learn what normal traffic and behaviour look like in your environment. Expect meaningful tuning over the first month or two.

Will a SOC stop every attack?

No, and any provider promising that is selling something. A SOC reduces how long an attacker stays undetected and how far they get. The realistic goals are faster detection, faster containment, and a documented response — not the elimination of risk.

What logs do we need to send?

At minimum: endpoint (EDR) telemetry, authentication and identity logs, and cloud control-plane logs if you use cloud. Network, email security and application logs add substantial value. Any system not sending telemetry is a blind spot, so gaps should be agreed and documented rather than discovered during an incident.

Is SOC monitoring required for compliance?

Frameworks rarely say "buy a SOC" by name, but PCI DSS, SOC 2, ISO 27001 and the NIST Cybersecurity Framework all expect continuous monitoring, log review and a functioning incident-response capability. A SOC is the usual way organisations satisfy those expectations in practice.

Related services

SOC Services Managed Security Services Threat Hunting Threat Intelligence Incident Response Digital Forensics Purple Team Exercises Malware Analysis

Keep reading

Need 24/7 monitoring?

Tell us what you need covered and we will scope it — analyst-reviewed detection, agreed escalation paths, and reporting your auditors can use.

Book a security consultation SOC services