Ein SOC steht in keinem Regulierungstext Compliance braucht Detection und Response, kein SOC

NIS2, DORA und CRA verlangen Detection und Response als Fähigkeit, aber kein Security Operations Center. Im Gesetzestext steht das nirgends, im An­ge­bot jedes MSSP schon. Daniel Thomas Heessel, CISO des Jahres 2026, zeigt was Regulatorik wirklich fordert und welches Betriebsmodell wirklich passt.

Seit NIS2, DORA und CRA gilt als ausgemacht: Jedes regulierte Unternehmen braucht ein Security Operations Center (SOC). Im Gesetzestext steht das nirgends. Im Angebot jedes Beraters, MSP und MSSP aber schon. Das ist kein Zufall, sondern ein Geschäftsmodell. Was die Gesetze und Normen wirklich verlangen, kostet einen Bruchteil – wenn man es vom Ziel her denkt und nicht vom Vertrieb.

Das Problem

SOC, KI-gestützte Detection, 24/7-Schutz, Cyberresilienz: Der LinkedIn-Feed kennt seit Monaten kaum andere Themen. Die meisten Posts stammen von Sales-Managern, die ein Produkt verkaufen müssen. Die wenigsten von Menschen, die je ein SOC von innen gesehen haben. Noch seltener von solchen, die eines aufgebaut oder geleitet haben.

Seit zehn Jahren arbeite ich an Security Operations. Ich habe selbst ein SOC aufgebaut und geleitet, Masterarbeiten zu SOC mit Open-Source-Tools betreut und den SANS MGT/LDR551 „Building and Leading Security Operations Centers“ absolviert. Das heißt nicht, dass ich alles richtig mache. Es heißt: was hier folgt, kommt aus der Praxis – nicht aus dem Pitch-Deck.

Aber eins nach dem andern.

Cyberabwehr rund um die Uhr

Fünf Fragen helfen IT-Leitern beim Wechsel ins Managed SOC

Was Gesetze, Normen und Standards wirklich fordern

Kaum ein SOC-Post auf LinkedIn kommt ohne Verweis auf NIS2, DORA oder CRA aus. Die Implikation ist stets dieselbe: Wer reguliert ist, kommt an einem SOC nicht vorbei. Ein Blick in die tatsächlichen Texte lohnt sich.

Ich habe die relevanten Passagen der aktuellen Regulatorik und der gängigen Normen nebeneinandergestellt - Richtlinien, Verordnungen und die Standards, nach denen in DACH überwiegend zertifiziert und geprüft wird:

Das wiederkehrende Muster: Die Texte sprechen von Fähigkeiten: Detektion, Reaktion, Wirksamkeitsnachweis, Meldefristen. Wie ein Unternehmen diese Fähigkeiten organisatorisch abbilden, ist nicht festgelegt. Ein SOC kann diese Fähigkeiten abbilden. Ein gut orchestriertes Zusammenspiel aus EDR, MDR und dokumentiertem Incident-Response-Prozess aber auch.

Auch hybride Modelle sind möglich. Die Wahl gehört ins Unternehmen – nicht ins Standardangebot eines Dienstleisters. Dieser Unterschied geht im Vertrieb systematisch verloren. Denn ein SOC verkauft sich besser als „angemessene Detection-und-Response-Fähigkeit".

Damit zur eigentlichen Frage: Was ist ein SOC – und was nicht?

Ist das klassische SOC am Ende?

Lang lebe das SOC!

Was ist ein SOC – und was nicht

Wenn die Normen kein SOC verlangen, aber Detection und Response, was ist dann überhaupt ein SOC? Die beiden substanziellsten Quellen dazu kommen nicht von Herstellern, sondern von MITRE und SANS Institute.

MITRE beschreibt in „11 Strategies of a World-Class Cybersecurity Operations Center" (2. Auflage, 2022) Security Operations als Zusammenspiel aus Monitoring, Detection, Analyse, Response und Recovery. Ein SOC bündelt diese Aktivitäten in definierten Funktionsbereichen – unter anderem Incident Triage, Threat Intelligence und Hunting, Vulnerability Management sowie SOC-Engineering.

SANS ergänzt in seinen jährlichen SOC-Surveys (zuletzt 2024, Chris Crowley) eine wichtige Differenzierung:

Ein SOC ist ein Betriebsmodell, nicht eine Technologie. Ein SIEM ist kein SOC. Ein EDR ist kein SOC. Auch ein MDR-Dienst ist strenggenommen kein SOC, sondern ausgelagerte Detection-und-Response-Kapazität.

Ein SIEM ist ein Werkzeug. Ein SOC ist eine mögliche Organisationsform, dieses Werkzeug wirksam einzusetzen. Eine von mehreren.

Ein ausgereiftes SOC im MITRE-Sinn setzt voraus:

• definierte Detection Use Cases, abgeleitet aus einem Bedrohungsmodell (idealerweise MITRE ATT&CK)

• einen Logging-Plan, der diese Use Cases datentechnisch überhaupt erst ermöglicht

• Playbook-Sets für Response

• definierte Rollen: L1-/L2-/L3-Analysten, Detection Engineering, Threat Intelligence

• Metriken: MTTD, MTTR, Alert-to-Incident-Ratio, Dwell Time

• einen Use-Case-Lifecycle (Entwicklung, Test, Produktivnahme, Tuning, Außerbetriebnahme)

Wer das nicht hat, hat kein echtes SOC. Er hat nur Dashboards.

SOC-Automatisierung

Disruptive Technologien für das SOC

Betriebsmodelle und Organisation

MITRE listet in Strategy 3 neun gleichberechtigte SOC-Organisationsmodelle: von „Ad Hoc Security Response" (keine stehende IR-Kapazität) über „Security as Additional Duty" (SOC-Aufgaben als Teil anderer Rollen), „Centralized SOC", „Federated SOC", „Coordinating SOC", „Hierarchical SOC" und „National SOC" bis zum „Managed Security/SOC Service Provider".

Keines davon wird als Default markiert. Welches passt, entscheidet die Organisation nach Größe, Reifegrad und Kontext. In der DACH-Mittelstandspraxis reduziert sich diese Spannweite auf vier realistisch wählbare Varianten:

1. Internes SOC: Eigene Analysten, eigene Technologie, eigener 24/7-Betrieb. Realistisch erst ab einer kritischen Unternehmensgröße und höherem Reifegrad – in DACH typischerweise Konzerne, KRITIS, Banken. MITRE-Entsprechung: Centralized, Distributed, Federated oder Hierarchical SOC.

• Vorteil: volle Kontrolle, tiefes Domänenwissen, direkte Reaktionsfähigkeit.

• Nachteil: angespannter Personalmarkt, Schichtbetrieb, lange Aufbauphase, fehlende Skaleneffekte.

• Kosten: mittlere bis hohe einstellige Millionen pro Jahr.

2. Vollausgelagertes SOC (MSSP/MDR): Dienstleister übernimmt Monitoring, Detection, oft auch Response. MITRE-Entsprechung: Managed Security/SOC Service Provider.

• Vorteil: schnelle Verfügbarkeit, keine Personalbeschaffung, planbare Kosten.

• Nachteil: der Dienstleister kennt Ihre Umgebung nicht so gut wie Sie selbst. Die Detection-Qualität hängt maßgeblich davon ab, was Sie an Logdaten und Kontext liefern. Dazu Vertragsbindung, Lock-in und SLAs, die meist Reaktionszeit messen, nicht inhaltliche Qualität.

• Kosten: sechsstelliger Jahresbetrag typisch, je nach Umfang und SLA.

3. Hybrid / Co-Managed: Tooling intern, Betrieb teilweise extern. Typische Aufteilung: Tagesbetrieb intern, Nacht und Wochenende extern. Oder: Detection Engineering intern, L1-Triage extern. MITRE-Entsprechung: Kombination aus internem SOC und Managed Service Provider.

• Vorteil: Kontrolle über kritische Entscheidungen bleibt intern, externe Ressourcen decken Skalierungslücken. In der Mittelstandspraxis oft das realistischste Modell.

• Nachteil: klare Schnittstellendefinition zwingend, sonst entstehen Verantwortungslücken. Höherer Steuerungsaufwand als Vollauslagerung.

• Kosten: mittlerer sechsstelliger bis niedriger siebenstelliger Jahresbetrag, je nach Verteilung.

4. Security as Additional Duty mit EDR + MDR + IR-Prozess: Kein dediziertes SOC. Ein modernes EDR mit angeschlossenem MDR-Service deckt den Großteil der relevanten Detection-Use-Cases ab. Incident-Response-Kapazität wird über Retainer eingekauft. Security-Aufgaben sind Teil anderer Rollen (IT-Leitung, Administration, IT-Security). MITRE-Entsprechung: Security as Additional Duty, ein anerkanntes Organisationsmodell, kein Kompromiss.

• Vorteil: erfüllt NIS2, DORA (sofern anwendbar) und ISO 27001 vollumfänglich. Geringster Overhead, schnellste Einführung. Für viele mittelständische Unternehmen das angemessene Modell.

• Nachteil: keine 24/7-Eigenkapazität, längere Erkennungszeiten in Nebenzeiten. Abhängigkeit vom MDR-Anbieter bei Detection-Qualität. In der Anbieterlandschaft selten aktiv angeboten, da geringere Marge.

• Kosten: typischerweise 50.000 bis 200.000 € pro Jahr, je nach Unternehmensgröße und Retainer-Umfang.

SOC-Analysten – die Lotsen im Cyber-Verkehr

Einsichten in ein Security Operations Center (SOC)

Die Reihenfolge entscheidet

Ein SOC ist nicht sinnvoll, wenn die Grundlagen fehlen:

• kein belastbarer Logging-Plan,

• kein Bedrohungsmodell,

• kein dokumentierter IR-Prozess,

• keine Asset-Inventur,

• kein verantwortlicher Security-Lead.

In diesen Fällen produziert es Alerts, die niemand bearbeitet, und Kosten, die niemand rechtfertigen kann. Das ist der Standardfall im Mittelstand.

Sinnvoll ist ein SOC, wenn Bedrohungslage, Schutzbedarf oder Regulatorik ein 24/7-Erkennungsniveau verlangen, die organisatorischen Grundlagen stehen und eine klare Eskalationskette bis zur Geschäftsführung existiert.

Die Reihenfolge in der Praxis ist immer gleich:

Schutzbedarf → Bedrohungsmodell → Logging-Plan → Detection Engineering → IR-Prozess → Betriebsmodell.

SOC ist Schritt sechs. Nicht Schritt eins.

Und: Strategie und Umsetzung gehören getrennt. Wer beim Hausbau den Elektriker den Grundriss zeichnen lässt, bekommt ein Haus für den Elektriker – nicht für sich. Im Security-Kontext heißt das: Der Architekt (intern der CISO, extern ein unabhängiger Berater ohne Produktinteresse) klärt Schutzbedarf, Bedrohungen, Detection-Tiefe und passendes Betriebsmodell. Der Umsetzer – MSSP, Systemhaus, Produktanbieter – liefert gegen diese Spezifikation. Wer beide Rollen in eine Hand gibt, hat genau einen Gewinner. Und der sitzt nicht auf Ihrer Seite des Tisches.

NIS-2-Umsetzung hinkt 2026 der Bedrohungslage hinterher

Warum die meisten Unternehmen 2026 bei NIS-2 scheitern werden

Fazit

Die aktuelle SOC-Diskussion ist in weiten Teilen Marketing und Sales-Pitch. Was als Fachdebatte auftritt, ist Vertriebsarbeit – und sie funktioniert, weil sie Compliance als Zwang inszeniert, wo Fähigkeit gemeint ist.

Wahr ist: Jede regulierte Einrichtung braucht Detection und Response als Fähigkeit. Das kann ein SOC sein. Es kann EDR + MDR + dokumentierter IR-Prozess sein. Es kann ein hybrides Modell sein. Was es ist, entscheidet das Unternehmen, nicht der Anbieter.

Drei Kernsätze für alle, die gerade vor dieser Entscheidung stehen:

• 1. Lesen Sie den Gesetzestext. Nicht die Broschüre des Anbieters.

• 2. Bauen Sie erst die Grundlagen, dann das Betriebsmodell. Schutzbedarf, Bedrohungsmodell, Logging-Plan, IR-Prozess – in dieser Reihenfolge.

• 3. Trennen Sie Architekten und Umsetzer. Wer berät, darf kein Produkt verkaufen!

Wer diese drei Regeln beachtet, bekommt Wirksamkeit. Wer sie ignoriert, bekommt ein teures Theater – und am Ende die Erkenntnis: "a fool with a new tool is still a fool."

Über den Autor: Daniel Thomas Heessel ist Gründer und Geschäftsführer der Threat-Informed Cybersecurity Solutions GmbH sowie Gründer von certmap.de. Er beschäftigt sich mit bedrohungsorientierter Informationssicherheit und der wirksamen Verbindung von Cybersecurity und Compliance. 2026 wurde er als CISO des Jahres ausgezeichnet.

(ID:50858736)