Skip to content
nexalign

Decision guide · Security

SIEM platform and SOC build: a structured decision guide

SIEM and SOC decisions are too often run as a tool purchase and too rarely as a strategic architecture decision. The right structure separates three questions: which logs must be captured (scope)? Which analytics platform aggregates and alerts (SIEM)? Who responds 24/7 (SOC)? Each question has its own dealbreakers and stakeholders. Bundling them buys too much licence and too little response capability.

TL;DR

SIEM, SOC operations and log scope are three decisions, not one.

Who owns this decision

CISO as decision owner, SOC lead, IT operations, network lead, Data Protection Officer and CFO as co-decision-makers.

Key criteria to weight

  • Log scope and ingest volume

    Identity, endpoint, perimeter, cloud, application. The realistic daily volume (GB/day) drives 40%+ of TCO.

  • Detection-engineering depth

    Custom use cases vs. out-of-the-box rules. Anyone who does not build detections in-house pays for MSSP capability or lives with gaps.

  • Operating model: in-house, MSSP, MDR, hybrid

    Cost structure, control, response time and liability differ fundamentally. The decision is not reversible without migration pain.

  • Integration depth with EDR and IAM

    SIEM without deep EDR and identity integration is log aggregation, not threat detection. Check interfaces before licence.

  • Compliance evidence (NIS2, DORA, ISO 27001)

    Log retention, access logging, incident-reporting data. Regulatory expectations drive the minimum architecture.

  • 3-year TCO including staff

    Licence is a fraction. Ingest/storage costs, 6 to 8 FTE for an internal SOC, tuning and use-case engineering dominate.

Step-by-step decision flow

  1. 1

    Define log scope

    Which sources are mandatory (NIS2 Art. 21, ISO 27001 A.8.15)? Which do we want (MDR/hunting)? Scope is a dealbreaker for platform choice.

  2. 2

    Decide the operating model

    Internal SOC, MSSP, MDR bundle or hybrid. Decide before platform, because it determines architecture and license type.

  3. 3

    Plan the use-case library

    MITRE ATT&CK based. Which tactics matter for your threat profile? Use cases are the value of the SOC, not the platform.

  4. 4

    SIEM shortlist and PoC

    Test 3 to 4 platforms with real logs, measure ingest costs realistically, validate dashboards against real use cases.

  5. 5

    Check integration and exit

    EDR feed, IAM, ITSM, SOAR, cloud audit. Plus: data export, API breadth, migration to another platform. DORA Art. 28 expects an exit path.

  6. 6

    Score, document, decide

    Weighted scoring, evidence per cell, residual risks from log gaps documented. Decision memo becomes the entry document for NIS2 evidence.

Vendor market structure

Strukturvergleich der relevanten SIEM-Plattformen für DACH-Mid-Market und Enterprise.

VendorCloud-nativeEU-HostingIngest-ModellSOAR enthaltenMSSP-DACHLizenzmodell
Splunk Enterprise Security ↗Splunk Cloud Platform plus On-PremEU-Region verfügbarVolumen (GB/Tag) oder WorkloadSplunk SOAR (separat)Breite MSSP-AbdeckungSubscription, Workload-basiert
Microsoft Sentinel ↗Azure-natives SIEMEU-Region (Frankfurt, Niederlande)Pay-per-GB plus ReservationNative Playbooks (Logic Apps)Breite MSSP-AbdeckungAzure-Abrechnung, kein Min-Commit
Elastic Security ↗Elastic Cloud, Self-Managed möglichEU-Region verfügbarResource-basiert (RAM/Storage)Eingebaute Playbooks, begrenztWachsende MSSP-AbdeckungSubscription, Resource-basiert
IBM QRadar / QRadar Suite ↗QRadar SaaS plus On-PremEU-Region verfügbarEPS-basiertQRadar SOAR (Resilient)Mature MSSP-Abdeckung in DACHSubscription, EPS-Tier
Sumo Logic Cloud SIEM ↗Cloud-nativeEU-Region verfügbarDaily-GB-Modell mit TiersCloud SOAR ModulBegrenzte DACH-AbdeckungSubscription
Wazuh ↗Self-managed oder Wazuh CloudSelf-Managed in EUOpen-Source, kein Volumen-Lock-inKeine native SOARWachsende DACH-PartnerOpen-Source, Support optional
LogPoint ↗SaaS und On-PremEU-only HostingNode-basiertNative SOAR-ModulStark in DACH und SkandinavienSubscription, Node-Modell

Stand: 2026-04. Basierend auf öffentlich zugänglichen Vendor-Angaben. Stand April 2026. Eigene Validierung über DecisionOS-Profil empfohlen.

Example memo, fictional case

Klinikgruppe, 1500 Mitarbeiter, NIS2 in scope, mehrere Standorte

Readiness score

77

Trigger
BSI-Prüfung nach §75c SGB V plus NIS2 Art. 21 Logging-Pflichten. Die bestehende SIEM-Lizenz läuft in einer Variante, die das Haus nicht verlängern will.
Top criteria (weights)
  • Cloud-natives Hosting in EU20%
  • Ingest-Kosten bei realistischem Volumen20%
  • MSSP-Coverage in DACH 24/715%
  • Detection-Engineering-Tiefe15%
  • EDR-Integration in den vorhandenen Endpoint-Stack15%
  • Compliance-Mapping NIS2/§75c15%
Shortlist
  • Cloud-natives SIEM des vorhandenen Plattform-Anbieters plus DACH-MSSP
  • SIEM eines europäischen Anbieters als SaaS plus eigener SOC-L1
  • Migration des Bestands-SIEM in dessen Cloud-Variante plus dessen SOAR
Decision
Das SIEM des vorhandenen Plattform-Anbieters plus DACH-MSSP-Vertrag, Detection-Engineering inhouse aufgebaut, SOAR über die nativen Automatisierungsdienste.
Rationale
Die Migration des Bestands-SIEM war wirtschaftlich nicht darstellbar: bei dem Volumen, das die Logging-Pflichten hier erzeugen, liegen die Ingest-Kosten über der Schwelle, die das Budget hergibt. Die SaaS-Option scheiterte nicht am Produkt, sondern am Betriebsmodell: sie setzt einen eigenen SOC-L1 voraus, und diese Gruppe kann über ihre Standorte hinweg keine 24/7-Schicht besetzen. Die gewählte Option sitzt auf dem Identity- und Endpoint-Stack, den das Haus ohnehin betreibt, die operative Tiefe liefert der MSSP.
Residual risks
  • Die Konzentration auf den vorhandenen Plattform-Anbieter erhöht sich substanziell
  • Eigenes Detection-Engineering muss in 9 Monaten Mindest-Reife erreichen
Run your own memo →

Compliance note

Under NIS2 Art. 21, logging is among the mandatory risk-management measures. The BSI recommends 12 months of retention for security-relevant logs. Under DORA Art. 11, financial entities face stricter requirements including incident reporting to the supervisor. ISO 27001:2022 controls A.8.15 (Logging), A.8.16 (Monitoring) and A.5.7 (Threat Intelligence) form the technical frame.

Common pitfalls

  • Choosing the platform before the operating model, which leads to license mismatch.
  • Underestimating ingest costs: cloud audit logs and EDR telemetry explode quickly.
  • Engaging an MSSP without clear SLAs and escalation paths: liability stays with the operator (NIS2 Art. 21).
  • Not building detection engineering in-house, which creates dependency on MSSP quality.
  • Building use cases only after go-live: the SOC runs 6 months without real value.

FAQ

Internal SOC, MSSP or MDR: which structure fits?

An internal SOC pays off above roughly 2,000 employees or for critical infrastructure with 24/7 regulatory pressure. MSSP for mid-market with stable runbooks. MDR when tooling and response should be bundled together. The decision is not a cost question. It is a control and liability question under NIS2 Art. 21.

Which SIEM architecture for NIS2-compliant logging?

NIS2 Art. 21 requires logging of security-relevant events with appropriate retention (BSI recommends 12 months). The SIEM must at minimum cover: identity logs (AD/Entra), endpoint telemetry (EDR feed), perimeter (FW/proxy) and cloud audit logs. Sovereign hosting and EU data residency are common dealbreakers.

What does a SOC really cost?

License is the smallest cost block. Realistic 3-year TCO: SIEM license 20%, ingest/storage 15%, 24/7 staff (6 to 8 FTE for a real internal SOC) 50%, tuning and use-case engineering 10%, integration 5%. The FTE question dominates, which is why many teams outsource to MSSP.

Run this decision in DecisionOS →What is DecisionOS?