What is managed SIEM?

Managed SIEM is a service in which a security provider operates your security information and event management platform: onboarding log sources, writing and tuning detection rules, monitoring alerts 24/7, investigating incidents and producing compliance reports. The platform may be owned by you or by the provider; the provider is accountable for it producing usable detections.

What is the difference between managed SIEM and SIEM as a service?

SIEM as a service is a delivery model in which the provider also supplies the platform, usually cloud-native and subscription-based, so you own neither licenses nor infrastructure. Managed SIEM is the broader category: it includes SIEM as a service, co-managed arrangements, and providers operating a SIEM you already own.

What is co-managed SIEM?

Co-managed SIEM splits the work between your team and the provider. Typically you keep platform ownership and full console access, the provider covers off-hours monitoring and detection engineering, and both parties share a rule library under a common change process. It suits organizations with an existing security team that needs depth and coverage rather than replacement.

What is the difference between managed SIEM and MDR?

Managed SIEM centers on the log platform and the detections built on it across every source you connect. MDR (managed detection and response) centers on endpoint and identity telemetry with a stronger response mandate, often on the provider's own tooling. Many organizations run both, with the SIEM as the system of record and MDR as the first responder; our MSSP vs MDR vs SOC comparison covers the overlap.

Does PCI DSS require a SIEM?

PCI DSS v4.0.1 does not name SIEM, but Requirement 10 requires audit logging of all access to system components and cardholder data, daily log review (automated mechanisms allowed), twelve months of retention with three months immediately available, and detection of control failures. In practice a SIEM, managed or not, is how assessed entities meet those requirements.

What does managed SIEM cost?

Pricing is driven by ingested log volume or number of sources, retention period, hours of coverage, the depth of detection engineering and response mandate, and whether the platform is yours or the provider's. HackersHub does not publish prices and scopes every engagement individually; the SOC as a service cost drivers guide explains each variable.

2 November 2026 · 11 min read · By Michael van Mameren, Lead Penetration Tester (OSCP)

Managed SIEM: what the service includes, how the delivery models differ, and what to ask before you sign

A SIEM is the most expensive security tool most organizations under-use. Managed SIEM hands the platform, the detection content and the 24/7 watch to a provider, so the logs you already pay to collect start producing incidents instead of dashboards.

Talk to us about managed SIEM

What a SIEM is, and what managed SIEM adds

A SIEM (security information and event management platform) collects logs and telemetry from across your environment, normalizes them into a common format, correlates events against detection rules and behavioral baselines, and raises alerts for analysts to investigate. It is also the system of record that auditors ask for when they want to know who accessed what, and when. Microsoft Sentinel, Splunk, Elastic Security, Google Security Operations, IBM QRadar and Sumo Logic are the platforms most US buyers will encounter; they differ in licensing, query language and cloud model, but the operating problem is the same for all of them.

Managed SIEM is a service in which a provider runs that platform for you: onboarding and maintaining log sources, writing and tuning the detection content, watching the alert queue 24/7, investigating what fires, and producing the reports your compliance team needs. The platform may be yours or the provider's. The distinction that matters is who is accountable for the SIEM producing true positives at 3 a.m. on a Sunday, because that is the moment an unmanaged SIEM is a very expensive log archive.

A SIEM is a platform; a SOC is the function that operates it. If you are weighing a managed SIEM against buying the whole operations function as a service, our explainer on what SOC as a service is covers the people, process and platform side, and where the two offers overlap.

Why SIEMs fail when nobody manages them

Most SIEM projects do not fail at purchase. They fail eighteen months later, for one of these five reasons. A sixth, the compliance-only SIEM that is collected but never queried, passes the audit and fails the breach.

1. Tuning is never finished

Out-of-the-box rules fire on normal behavior in your environment: service accounts, backup jobs, vulnerability scanners, your own penetration testers. Every rule needs exceptions, thresholds and context, and every change to the environment breaks some of them. Without a named owner for detection content, the queue fills with noise and analysts stop reading it.

2. Log volume outruns the budget

Most platforms charge by ingested volume or by compute. Teams respond by switching off verbose sources, which are often the ones with the most forensic value (DNS, proxy, endpoint process telemetry). The SIEM then confirms what the firewall already said and misses what happened on the endpoint.

3. Parsing breaks silently

A vendor changes a log format, a connector is deprecated, a certificate expires, a forwarder is rebuilt without its configuration. The source goes dark or arrives unparsed, no alert fires because there is no rule for 'a source stopped talking', and the gap is discovered during an incident.

4. Alert fatigue replaces detection

When a SIEM raises hundreds of alerts a day and a two-person team can investigate twenty, the team triages by gut. Real intrusions in 2026 generate a handful of low-severity events spread over days: a new MFA device, an impossible-travel sign-in, a mailbox rule, an unusual OAuth consent.

5. Nobody is watching outside office hours

Ransomware operators deploy on Friday evenings and public holidays for a reason. A SIEM that is reviewed every morning gives an attacker a twelve-hour head start, and most domain-wide ransomware deployments complete in less than that.

What a managed SIEM service includes

Six workstreams. If a proposal is silent on any of them, the gap becomes your problem on day one.

Log-source onboarding and health

Connecting identity, endpoint, cloud, network and SaaS sources; building parsers for applications the platform does not know; monitoring every source for silence or volume anomalies; owning the fix when a connector breaks.

Detection engineering

Writing, mapping and version-controlling detection rules against MITRE ATT&CK, tuning them to your environment, retiring rules that no longer earn their keep, and adding content for new techniques and for findings from your own penetration tests.

24/7 monitoring and triage

Analysts reading every alert around the clock, enriching it with asset and identity context, deciding true or false positive, and escalating confirmed incidents to your team through an agreed path with agreed severities.

Investigation and response support

Scoping an incident across the data the SIEM holds, building the timeline, identifying affected accounts and hosts, and recommending or executing containment steps depending on the mandate in the contract.

Reporting for leadership and auditors

Monthly service reports (coverage, alert volumes, incidents, tuning changes) and compliance evidence packs mapped to PCI DSS, HIPAA, SOC 2, NIS2 or DORA, so the same data answers both the CISO and the auditor.

Retention, archive and search

Hot retention for investigation, cold or archive storage for the retention periods your regulators require, and a tested path to bring archived data back when a breach investigation reaches back twelve months.

Four delivery models for managed SIEM

The same six workstreams can be split between you and the provider in four common ways. The right one depends on how much platform control and in-house analyst capacity you want to keep.

Aspect	Fully managed	Co-managed SIEM	SIEM as a service (cloud-native)	Bring your own SIEM
Who owns the platform and license	Provider	You, or shared	Provider, multi-tenant or dedicated tenant	You
Who writes detection content	Provider	Both, with a shared rule library and change process	Provider, with your custom rules on request	Provider on your platform
Who watches 24/7	Provider	Provider off-hours, your team in-hours (or any split)	Provider	Provider
Your team's console access	Read-only or dashboards	Full	Usually full within your tenant	Full
Data residency and ownership	Negotiated; check export rights	Yours	Provider's cloud; confirm region and export	Yours
Exit	Hardest: data and content live with the provider	Straightforward: you keep platform and rules	Medium: export logs, rebuild rules elsewhere	Easiest: switch operator, keep everything
Best for	No in-house SOC capacity, wants one accountable party	Existing team that needs coverage and depth, not replacement	Cloud-first organizations without legacy on-prem log sources	Already licensed a SIEM and cannot staff it

Which log sources to onboard first

Volume is not value. Onboard in the order that catches the attack chains we actually see in red team engagements, then expand.

Identity: directory and identity-provider sign-in and audit logs (Active Directory, Entra ID, Okta), including MFA registration, conditional access and privileged role changes
Endpoint detection and response telemetry: process, network and file events from your EDR platform, which is where most initial access and lateral movement is visible
Email security: delivery, phishing verdicts, mailbox rule creation and forwarding changes
Cloud control plane: AWS CloudTrail, Azure Activity Log, Google Cloud Audit Logs, plus storage access logs for your sensitive buckets
Perimeter and remote access: firewall, VPN, zero-trust access broker and web proxy logs, with egress as well as ingress
SaaS administrative audit logs: Microsoft 365, Google Workspace, Salesforce, your HR and finance platforms
Privileged access and secrets: PAM session logs, vault access, service-account key usage
Servers and workloads: Windows Security and PowerShell logs, Linux authentication and sudo, container orchestration audit logs
DNS and DHCP, which turn an IP address in every other log into a named host and catch command-and-control patterns
Last, not first: network flow data and OT telemetry, high volume and valuable only once the sources above are clean

Metrics that tell you whether the service works

Ask for these on the monthly report. They are concepts every mature provider measures; the targets are yours to negotiate.

Log-source coverage against your asset inventory

The percentage of in-scope systems and identities actually sending logs, and a list of what is missing. A SIEM cannot detect what it does not see, and this number is the one most providers would rather not show.

Detection coverage mapped to MITRE ATT&CK

Which techniques have active, tested detections and which do not, so the gaps are a conscious decision rather than an accident. Detections validated by a purple team exercise or your last penetration test count more than rules that have never fired.

Alert-to-incident ratio and false-positive rate

How many alerts the analysts handled, how many became incidents, and how the tuning backlog moved. A falling ratio with stable coverage means the content is getting better, not that attacks stopped.

Time to detect, acknowledge and contain

Mean or median time from first malicious event to detection, from alert to analyst acknowledgment, and from confirmation to containment. Measure them per severity and read the trend, not a single month.

Ingest health and parser failures

Sources that went silent, sources arriving unparsed, and how long each took to notice and fix.

Retention compliance

Evidence that each source is retained for the period your frameworks require and that archived data can be restored and searched within a defined time, tested at least annually.

Compliance hooks: what the frameworks actually require from logging

For US buyers the clearest requirements sit in PCI DSS v4.0.1 Requirement 10, which requires audit logs for all access to system components and cardholder data, daily review of logs (automated mechanisms are permitted under 10.4.1.1), twelve months of retention with three months immediately available (10.5.1), and prompt detection of failures in critical security controls (10.7). Requirement 11.5 adds intrusion detection and change detection. A managed SIEM is the natural evidence source for all of them. HIPAA's Security Rule requires audit controls (45 CFR 164.312(b)) and regular information system activity review (164.308(a)(1)(ii)(D)); SOC 2 maps to CC7.2, monitoring system components for anomalies indicative of malicious acts; the GLBA Safeguards Rule requires monitoring and logging of authorized user activity; and 23 NYCRR 500.6 requires audit trails that can reconstruct transactions and detect cybersecurity events. CMMC 2.0 Level 2 inherits the NIST SP 800-171 audit and accountability family, and NIST CSF 2.0 frames all of this under Detect: Continuous Monitoring and Adverse Event Analysis.

In the EU, NIS2 Article 21(2) requires incident handling and basic cyber hygiene measures that supervisors read as centralized logging and detection capability, and DORA Article 10 requires mechanisms to promptly detect anomalous activities while Article 17 requires an incident management process with early warning indicators. ISO 27001:2022 controls A.8.15 (logging) and A.8.16 (monitoring activities) are the certification equivalents. A managed SIEM report that cites these per control saves your compliance team a quarter of evidence gathering.

Questions to ask a managed SIEM provider

Put these to every shortlisted provider in writing.

Who owns the detection content, and do we keep it (and its history) if we leave?
What happens to our log data at exit: format, timeline, cost, and proof of deletion afterwards?
Which of our sources need custom parsers, who builds them, and how is a broken parser detected?
How is ingestion priced, what filtering do you apply to control volume, and who decides what gets dropped?
How do you prove 24/7 coverage: staffing model, follow-the-sun or single site, and what we see in the ticket trail?
What is the escalation path by severity, who on your side can take containment action, and under what written mandate?
How does the service integrate with our EDR, our MDR provider if separate, and our incident response retainer?
Where is our data stored and processed, in which region, and who at the provider can access it?
Which compliance reports are standard, and how do you validate detections: purple team exercises, breach simulation, or findings from our penetration tests?

How HackersHub runs managed SIEM

HackersHub is an Amsterdam-based offensive-security firm that also runs managed security for enterprise clients in the EU and the US, delivered remotely with on-site work where an engagement needs it. Our managed SIEM service covers log-source onboarding, SIEM and EDR management, 24/7 monitoring, incident response support and reporting that maps to the compliance frameworks above. We work co-managed or fully managed, on your platform or ours.

What distinguishes the detection content is where it comes from. Our testers hold at least OSCP, with OSWE and CREST-certified testers on the team, and they spend their days getting into environments like yours. Every technique that works in a penetration test or red team engagement becomes a detection hypothesis for the SIEM, and every detection is tested against the attack that inspired it. If you want the contract side right before you talk to anyone, start with our MSSP contract checklist; if budget is the first question, the SOC as a service cost drivers guide explains what moves the number without quoting one.

Frequently asked questions

Related guides on managed security

Is your SIEM producing incidents or dashboards?

We onboard the sources that matter, write detections from the attacks we run ourselves, and watch the queue around the clock. Talk to an expert about a co-managed or fully managed SIEM.

Explore managed security services Schedule a call