SIEM as a service, MDR or SOC as a Service: which to choose

"SIEM as a service", "MDR" and "SOC as a Service" show up side by side in vendor proposals. They are not the same thing. The most useful difference is not the technology but the answer to a simple question: when an alert fires at three in the morning, who triages it, who investigates and who acts?

Three models, three divisions of labor

SIEM as a service

The provider hosts and maintains the SIEM platform: collection, storage, correlation, updates and, in some contracts, a package of detection rules.

What the provider delivers. Infrastructure, connectors for log sources, retention and platform availability.
What stays with the company. Usually almost the entire operation: watching alerts, triaging, investigating, deciding and responding. Rule tuning can sit on either side, and it needs to be in writing.

Without someone watching alerts around the clock, the platform becomes a repository of events nobody reads in time, as we discussed in Traditional vs. modern SOC.

MDR (Managed Detection and Response)

MDR is a service focused on detecting, investigating and containing real threats. The provider does not stop at the notification: it validates the alert's severity, maps the observed behavior to MITRE ATT&CK techniques and carries out containment actions, such as isolating an endpoint or disabling an account, within rules agreed with the client.

What the provider delivers. 24×7 monitoring, triage, human investigation, threat hunting and remote containment.
What stays with the company. Authorizing the scope of response, carrying out root remediation (fixing the flaw, rebuilding the server) and making business decisions during an incident.

SOC as a Service

SOC as a Service is the complete security operation delivered by a third party: continuous monitoring, incident management, threat intelligence, metrics, technical and executive reports, and continuous improvement of detections. MDR is one of the capabilities a modern SOC delivers; the SOC also covers governance and a consolidated view of the security posture.

What the provider delivers. The entire detection and response operation, with platform, people, processes, SLA and metrics such as MTTD and MTTR.
What stays with the company. Business context (what is critical, who approves what), the highest-impact decisions and ultimate accountability for the risk.

What about MSS? MSS (Managed Security Services) is a different service: operating and monitoring security devices such as firewalls and antivirus. It is complementary, not a substitute. XDR, in turn, is technology, not a service: the platform that unifies telemetry from multiple layers. See Network Secure's MSS and SOC and MDR.

Who does what when the alert fires

NIST SP 800-61 Rev. 3, which aligns incident response with NIST CSF 2.0, calls for roles and responsibilities to be defined before an incident, including those of third parties. Across the three models, the map usually looks like this:

Triage. SIEM as a service: the company. MDR and SOC as a Service: the provider.
Investigation. SIEM as a service: the company. MDR: the provider, focused on the threat. SOC as a Service: the provider, with a view of the whole environment.
Containment. SIEM as a service: the company. MDR and SOC as a Service: the provider, within the limits authorized in the contract.
Remediation and business decisions. In all three models, the company, with support from the provider.

If the proposal does not say on which of these lines the provider stops, start there.

Total cost and required team

Comparing only the monthly fee is misleading: each model leaves a different share of the cost in-house.

People in shifts. A week has 168 hours, and the standard working week in Brazil is up to 44 hours. Keeping a single analyst seat staffed 24×7 takes four people before counting vacations, days off and absences. With SIEM as a service, that cost stays with the company.
Detection engineering. Rules have to be written, tested and adjusted every time the environment changes. The 2025 joint guidance from CISA and ASD's ACSC on implementing SIEM and SOAR treats the platform as something that requires ongoing configuration and tuning, not a product you install and forget.
Data volume. In many SIEM contracts, cost grows with the volume of ingested logs. What to collect is both a security decision and a budget decision.
Time to operate. An in-house SOC takes months to hire, train and integrate tools. A managed service starts from an operation that is already running, but sources still need to be integrated.

Decision criteria

There is no single answer; three factors weigh the most.

Size and team. If the company does not have, and does not plan to have, enough analysts for 24×7 shifts, SIEM as a service alone leaves the main gap open. MDR or SOC as a Service solve coverage.
Maturity. Models such as SOC-CMM assess the operation across business, people, process, technology and services domains. Companies with mature processes and teams may want only the platform; those still without a response process gain more from the full service.
Regulation and accountability. Outsourcing execution does not outsource accountability. In Brazil's financial sector, for example, CMN Resolution 4,893 keeps the institution responsible for the services it contracts. Regulated sectors need contracts and reports that hold up in an audit.

Rule of thumb: an in-house team and a desire for full control point to SIEM as a service; a small team and the need for fast containment, to MDR; the need for the whole operation, with metrics and governance, to SOC as a Service.

Questions to ask the provider

Where does the service end? Ask, in writing, who handles triage, investigation, containment and remediation.
Which actions do you take without asking for authorization? And which require approval, from whom and through which channel.
Which sources will be integrated, and which are left out? Endpoints, network, cloud, identity, applications.
How are detections mapped to MITRE ATT&CK? Is there documented, reviewed coverage?
Which metrics will I receive? MTTD, MTTR, SLA compliance and incident trends, not just event counts.
What does an incident notification look like? Ask for an example: does it say what happened, what has already been contained and what my team needs to do?
Who owns the data and the rules? Retention, access, log export and what happens when the contract ends.
What governance evidence do you have? Certifications, audits and access controls over client data.

Hybrid models

Many companies combine models; the UK NCSC guidance on building a SOC covers in-house, outsourced and hybrid options. Common combinations:

In-house team during business hours, service outside them. The internal team covers the working day and the provider takes nights, weekends and holidays.
Provider at first level, company on decisions. The SOC filters and investigates; the internal team approves the highest-impact actions.
SOC as a Service with agreed incident response. The provider runs the continuous operation, and the incident response plan defines how a crisis is handled jointly.

At Network Secure. Network Secure's SOC is ISO/IEC 27001:2022 certified, audited by Bureau Veritas, covering monitoring, detection, analysis and incident response. In the FitBank case, the model was N1 management: the SOC team filters events and sends what matters to the client's IT team, which audits and takes action.

Frequently asked questions

Is SIEM as a service already a SOC?

No. It is the collection and correlation platform delivered as a service. Without analysts watching alerts 24×7, tuned rules and a response process, the operation that turns events into action is missing.

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

MDR concentrates on detecting, investigating and containing threats. SOC as a Service is the complete operation, which includes MDR and adds incident management, metrics, executive reporting and governance.

Does hiring MDR or SOC as a Service remove the company's accountability?

No. The company outsources execution, not accountability for the risk. It still decides what is critical and answers to customers and regulators.

Sources consulted: NIST SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management (2025); NIST Cybersecurity Framework 2.0; CISA and ASD's ACSC, Implementing SIEM and SOAR Platforms (executive and practitioner guidance, 2025); NCSC (United Kingdom), Building a Security Operations Centre; SOC-CMM; MITRE ATT&CK; Brazilian Federal Constitution, art. 7, XIII (44-hour working week). This article is educational; models vary between providers and the suggested questions do not replace a technical and contractual assessment.