A SIEM is a product. A SOC is a team. Almost every confusion between the two comes from that one distinction, and it matters commercially, because you can buy a SIEM and still have nobody watching it at three in the morning.
Vendors blur the line on purpose. A platform gets sold as though it were a service, and a service gets sold as though the platform were the hard part. It is not. The hard part is the rota of people reading what the platform produces.
This guide sets out what each one does, where they overlap, how MDR and XDR relate to both, which to buy first, and what to check in either contract.
A SIEM tells you something happened. A SOC decides what it means and does something about it. Buying the first and assuming you have the second is the most expensive mistake in this category.
What a Managed SIEM Actually Does
Security Information and Event Management is the data layer. It collects logs from across your estate, normalises them into a common format, stores them, and correlates events to surface patterns a human should look at. NIST defines it as the application that collects and analyses that data.
A managed SIEM means somebody else runs that platform for you: deployment, tuning, rule maintenance and upgrades. What it covers:
- Log collection from firewalls, servers, applications, identity providers and network devices
- Normalisation, so a Windows event and a firewall log can be compared
- Event correlation against rules, signatures and behavioural baselines
- Retention, which is often what the compliance requirement actually demands
- Reporting and dashboards
Getting the logging itself right is the foundation, and the NCSC has guidance on logging for security purposes that is worth reading before you buy anything. A SIEM fed badly produces confident nonsense.
What a managed SIEM does not include, unless you contract for it separately, is anybody deciding what to do when a rule fires.
What a Managed SOC Actually Does
A Security Operations Centre is the human layer that sits on top. Analysts in shifts, investigating what the platform surfaces, deciding what is real, and acting on it.
- Continuous monitoring, with alerts validated by a person before they reach your team
- Investigation, which means separating the genuine detections from the noise
- Incident response and containment, under documented runbooks
- Threat hunting, looking for what the rules did not catch
- Compliance evidence produced on a schedule
Good runbooks are mapped to a known adversary framework rather than invented in-house. Transputec’s run against MITRE ATT&CK, which gives you a way to ask a provider what they can actually detect. Our guide to how a managed SOC works goes through the monitoring in more depth.
Not sure whether you are missing the platform or the people?
Our SOC team will look at your current log coverage and monitoring, show you where the gaps are, and explain what would change if analysts were watching around the clock.
Book a SOC briefingManaged SOC vs Managed SIEM: The Core Difference
Set side by side, the split is clean.
| Aspect | Managed SIEM | Managed SOC |
|---|---|---|
| What you are buying | A platform, run for you | A team, with a platform underneath |
| Scope | Log management, correlation, retention, reporting | Monitoring, investigation, response, threat hunting |
| When an alert fires | You are told | Someone investigates, then contains it |
| People included | Platform engineers; analysts usually not | Analysts in shifts, around the clock |
| Out of hours | The platform keeps collecting | Someone is awake and on shift |
| Compliance value | Retention and audit trail | Evidence plus demonstrable response |
| Fails when | Nobody reads the output | The log coverage underneath is incomplete |
The last row is the one buyers miss. These are layers, not rivals. A SOC with poor log coverage is blind in the places you did not instrument, and a SIEM with nobody reading it is an expensive archive.
Do You Need Both, or Just One?
You always need both functions. The question is who supplies each, and whether you are paying for them twice.
Three arrangements are common:
- You own the SIEM, a provider runs the SOC inside it. Your licence, your data retention, their analysts. Common where a Microsoft estate already includes Sentinel.
- The provider supplies both. Simpler commercially, one contract, but check what happens to your historical data if you leave.
- You own both and staff it yourself. Workable above a certain size, and the arithmetic is unforgiving below it.
Transputec works either of the first two ways. We operate inside an existing SIEM, whether that is Microsoft Sentinel, Splunk, IBM QRadar, Elastic, Chronicle or Sumo Logic, or deploy one where there is nothing in place. There is no rip-and-replace and no lock-in, because the detection content travels rather than the platform.
If the third option is what you are weighing, the staffing maths is in our guide to choosing a managed SOC provider, which covers what in-house cover genuinely costs.
Where MDR and XDR Fit
Two more acronyms sit between the platform and the team, and both get sold as substitutes for a SOC.
MDR, managed detection and response, is a narrower service: detection and response, usually centred on the endpoint, often on the provider’s own tooling. It is faster to deploy than a full SOC and covers less of the estate. For a smaller organisation it is frequently the right first step.
XDR, extended detection and response, is a product category rather than a service. It correlates across endpoint, identity, email and cloud in one vendor’s stack. It can replace a SIEM for some estates, and it still needs somebody watching it. We compare the tooling in EDR vs XDR.
The useful test cuts through all four terms. Ask who investigates an alert at 3am, and who has the authority to isolate a machine. If the answer is nobody, the acronym does not matter.
Which One to Buy First
Start from what is missing, not from the product category.
- No log collection worth the name? Fix the SIEM layer first. A SOC cannot investigate data you never captured.
- Logs flowing but nobody watching? Buy the SOC. This is the most common position, and the most dangerous, because the dashboard creates a feeling of coverage that is not there.
- A compliance deadline driving it? Retention and evidence come from the SIEM layer, but demonstrating response needs the SOC. Most frameworks want both.
- A breach you are still recovering from? Response capability first, then fix the instrumentation it exposed.
Cost shapes the order too. Managed SIEM licensing usually scales with data volume, while the service scales with estate size, so the two move on different axes as you grow. Our managed SOC cost guide sets out the pricing models.
What You Keep and What the Provider Holds
This is the clause worth reading twice, because it decides how easily you can leave.
Transputec’s split is that we hold the analyst rota, the SIEM contract and the playbook library, and you keep the strategy and the data. Whoever you buy from, establish four things in writing:
- Who owns the log data, and in what format you get it back
- Where it is stored. Our SOC telemetry, storage and analysts stay in the UK, which matters for UK GDPR evidence
- Who owns the detection rules written during your contract
- What happens at exit, including how much history transfers
Detection content tuned to your environment is the quiet asset in any SOC contract. If it stays with the provider, switching costs you the tuning as well as the service.
How to Judge a Managed SOC or Managed SIEM Contract
Ask for numbers, and ask where they came from.
| Ask for | Why it matters |
|---|---|
| Median time to detect, triage and contain | Separately, by severity. An average across all alerts hides the ones that count |
| The source of those figures | Their own telemetry or a vendor benchmark. These are not the same claim |
| False positive rate after tuning | And how long tuning takes before the number applies |
| Which frameworks the reporting covers | ICO, FCA, ISO 27001, Cyber Essentials Plus and PCI DSS are the usual UK set |
| Whether an analyst sees every alert | Human validation before escalation is the difference between a SOC and a dashboard |
For reference, our medians are under 60 seconds to detect known techniques, four minutes to triage a P1 and eleven minutes to contain a confirmed intrusion. Those come from rolling 90-day telemetry across our UK client estate rather than a vendor datasheet, which is exactly the distinction to press any provider on.
On response specifically, the NCSC’s incident management guidance is a reasonable yardstick for what a mature process looks like.
Conclusion
The managed SOC vs managed SIEM question is really one about people. The platform is necessary and it is the easier half to buy. What decides whether you find out about an intrusion on Tuesday night or the following Monday is whether anyone is on shift, what they are allowed to do, and how well the thing feeding them has been tuned.
If you are working out which layer you are missing, talk to our team about the security work behind Transputec’s managed SOC services, including how we run inside a SIEM you already own.
Frequently Asked Questions
Can a managed SOC and a managed SIEM be combined?
They are normally combined, because they do different jobs. The SIEM collects and correlates, the SOC investigates and responds. Buying them from one provider is simpler commercially, and buying them separately is common where you already hold a platform licence. What you should not do is buy the platform alone and assume the monitoring came with it.
Is a managed SIEM cheaper than a managed SOC?
Usually, and for a reason that matters: you are paying for software and engineering rather than a 24-hour rota of analysts. SIEM pricing tends to track data volume, while SOC pricing tracks estate size, so the gap narrows as your log ingestion grows. Compare them on what each one removes from your own team rather than on the headline fee. Our cost guide covers the pricing models.
Do we still need a SIEM if we buy a managed SOC?
You need the function, though not necessarily your own licence. A SOC has to read telemetry from somewhere, so either you supply the platform or the provider does. Transputec is tooling-agnostic: we operate inside Microsoft Sentinel, Splunk, IBM QRadar, Elastic, Chronicle or Sumo Logic, or deploy a platform where there is none. The question to settle is who holds the licence and who keeps the data.
How is a managed SOC different from an in-house SOC?
The capability is the same; the staffing risk is not. An in-house team means you carry the rota, the recruitment and the tooling decisions, and one resignation can remove overnight cover. A provider carries that, and their analysts see patterns across many estates rather than one. The arithmetic and the trade-offs are in our guide to choosing a managed SOC provider.
Which compliance frameworks does SOC and SIEM reporting cover?
For UK organisations the usual set is ICO incident notification, FCA operational resilience, ISO 27001 Annex A controls, Cyber Essentials Plus and PCI DSS. The SIEM layer supplies retention and the audit trail; the SOC supplies evidence that something was done about what the logs showed. Most frameworks want both halves, so ask to see a sample evidence pack rather than a list of logos.
This article was drafted with AI assistance and reviewed by the Transputec team. Featured image: AI-generated.
