Pflicht oder Verkaufsargument?: Der Mythos vom Security Operations Center

Was die Regulatorik an Fähigkeiten und Prozessen tatsächlich verlangt, kostet einen Bruchteil eines SOCs – sofern man vom Ziel her denkt und nicht vom Vertrieb.

Die Diskussion um SOCs, KI-gestützte Detection und 24/7-Schutz prägt seit Monaten die einschlägigen LinkedIn-Feeds. Die meisten Beiträge 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.

Der Autor dieses Beitrags arbeitet seit zehn Jahren in Security Operations. Er hat selbst ein SOC aufgebaut und geleitet, Masterarbeiten im SOC-Umfeld betreut und den SANS MGT551 „Building and Leading Security Operations Centers“ absolviert. Das heißt nicht, dass damit alles richtig gemacht wird. Es heißt: Was hier folgt, kommt aus der Praxis und nicht aus dem Pitch-Deck.

Was Gesetze, Normen und Standards wirklich fordern

Die Aussage von Beratern ist stets dieselbe: Wer reguliert ist, kommt an einem SOC nicht vorbei. Ein Blick in die tatsächlichen Gesetzestexte lohnt sich jedoch:

• Die NIS-2-Richtlinie (EU 2022/2555) verlangt in Artikel 21 Absatz 2 die Bewältigung von Sicherheitsvorfällen sowie Verfahren zur Bewertung der Wirksamkeit von Sicherheitsmaßnahmen – ohne SOC-Vorgabe. Der seit Oktober 2024 anwendbare NIS-2-Durchführungsrechtsakt (EU 2024/2690) konkretisiert technische Anforderungen für DNS, Cloud und Rechenzentren. Das seit 6. Dezember 2025 in Kraft befindliche neue BSI-Gesetz (BSIG) regelt in den Paragrafen 30, 32 und 38 ein Risikomanagement in zehn Bereichen, Meldefristen von 24 Stunden, 72 Stunden und einem Monat sowie die persönliche Haftung der Geschäftsleitung.
• DORA (EU 2022/2554), seit Januar 2025 anwendbar, verlangt in Artikel 10 Mechanismen zur zeitnahen Erkennung anomaler Aktivitäten, mehrere Kontrollebenen und automatische Warnungen. Die Artikel 17 bis 19 in Verbindung mit dem technischen Regulierungsstandard (RTS) 2024/1772 schreiben ein IKT-Vorfallmanagement mit Klassifizierung und Meldefristen vor. Die Umsetzung kann intern, extern oder hybrid erfolgen.
• Der Cyber Resilience Act (EU 2024/2847) verpflichtet Hersteller ab dem 11. September 2026 zur Meldung aktiv ausgenutzter Schwachstellen innerhalb von 24 Stunden, 72 Stunden und 14 Tagen. Ab Dezember 2027 gelten die vollen Anforderungen an Security-by-Design und Vulnerability Handling. Das deutsche KRITIS-Dachgesetz, seit 16. März 2026 in Kraft, fordert physische und organisatorische Resilienz kritischer Anlagen.
• Auch ISO/IEC 27001:2022 (Annex A 8.16 sowie 5.24 bis 5.28) und das NIST CSF 2.0 sprechen von Monitoring-Aktivitäten, Incident-Management-Lifecycle und den Funktionen Detect und Respond – ohne ein SOC zu fordern.

Tabelle 1 (hier als pdf-Datei verfügbar) stellt die relevanten Passagen der aktuellen Regulatorik und der gängigen Normen noch einmal nebeneinander:

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

Ob ein Unternehmen seine Detection- und Response-Fähigkeit über ein internes SOC, ein ausgelagertes Modell oder eine hybride Lösung abbildet, ist eine unternehmerische Entscheidung – keine Frage des Standardangebots eines Dienstleisters. Im Vertrieb geht diese Wahlfreiheit systematisch verloren. Denn ein SOC verkauft sich besser als „angemessene Detection-und-Response-Fähigkeit.“

Was ein SOC ist – und was nicht

Wenn die Normen kein SOC verlangen, sondern Detection und Response, stellt sich die Frage, was ein SOC überhaupt ausmacht. Die beiden substanziellsten Quellen dazu stammen nicht von Herstellern, sondern von der gemeinnützigen Forschungsorganisation MITRE und dem 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 – darunter Incident Triage, Threat Intelligence, Threat Hunting, Vulnerability Management und SOC-Engineering.

Das SANS Institute ergänzt in seinen jährlichen SOC Surveys – zuletzt 2025 unter der Leitung von Chris Crowley – eine wichtige Differenzierung: Ein SOC ist ein Betriebsmodell, keine Technologie. Ein Security Information and Event Management (SIEM). Ein EDR ist kein SOC. Auch ein MDR-Dienst ist streng genommen kein SOC, sondern ausgelagerte Detection- und Response-Kapazität. KI-gestützte Detection wiederum ist ein Analyseverfahren innerhalb der Detection-Funktion – sie ersetzt kein Betriebsmodell, sondern setzt eines voraus.

Ein ausgereiftes SOC im MITRE-Sinn setzt fünf Elemente voraus:

• Detection Use Cases und Logging-Plan: definierte Use Cases, abgeleitet aus einem Bedrohungsmodell (idealerweise MITRE ATT&CK), und ein Logging-Plan, der diese Use Cases datentechnisch trägt
• Response-Playbooks: dokumentiert pro Incident-Typ
• Definierte Rollen: L1-, L2- und L3-Analysten, Detection Engineering, Threat Intelligence sowie SOC-Lead
• Metriken: Mean Time to Detect (MTTD), Mean Time to Respond (MTTR), Alert-to-Incident-Ratio und Dwell Time
• Use-Case-Lifecycle: Entwicklung, Test, Produktivnahme, Tuning und Außerbetriebnahme

Fehlt eines dieser Elemente, fehlt das Betriebsmodell. Übrig bleiben Dashboards.

Vier realistische Betriebsmodelle für den Mittelstand

Wie ein SOC organisatorisch aufgestellt sein kann, behandelt MITRE in Kapitel 3 desselben Buchs unter dem Titel „Build a SOC Structure to Match Your Organizational Needs“. Dort werden neun gleichberechtigte Organisationsmodelle beschrieben:

Ad Hoc Security Response (keine stehende Incident-Response-Kapazität), Security as Additional Duty (SOC-Aufgaben als Teil anderer Rollen), Distributed SOC, Centralized SOC, Federated SOC, Coordinating SOC, Hierarchical SOC, National SOC sowie Managed Security/SOC Service Provider.

MITRE bevorzugt keines der Modelle. Welches passt, entscheidet die Organisation nach Größe, Reifegrad und Kontext. Für die DACH-Mittelstandspraxis bleiben vier realistisch wählbare Varianten.

1. Internes SOC

Eigene Analysten, eigene Technologie, eigener 24/7-Betrieb – realistisch erst ab einer gewissen Unternehmensgröße und höherem Reifegrad und im DACH-Raum typischerweise bei Konzernen, Betreibern kritischer Infrastrukturen (KRITIS) und Banken anzutreffen. Dem Vorteil voller Kontrolle, tiefen Domänenwissens und direkter Reaktionsfähigkeit stehen ein angespannter Personalmarkt, Schichtbetrieb, eine lange Aufbauphase und fehlende Skaleneffekte gegenüber.

Die Kosten liegen je nach Zahl der Vollzeitstellen (FTE) und Technologie-Stack typischerweise zwischen einer und fünf Millionen Euro pro Jahr. In der MITRE-Systematik entspricht das Modell einem Centralized, Distributed, Federated oder Hierarchical SOC.

2. Vollausgelagertes SOC (MSSP/MDR)

Ein Dienstleister übernimmt Monitoring, Detection und häufig auch Response – in der MITRE-Systematik der Managed Security/SOC Service Provider.

Vorteile sind schnelle Verfügbarkeit, der Wegfall der Personalbeschaffung und planbare Kosten. Demgegenüber kennt der Dienstleister die Umgebung des Kunden naturgemäß weniger gut als ein internes Team; die Detection-Qualität hängt maßgeblich davon ab, welche Logdaten und welchen Kontext das Unternehmen liefert. Hinzu kommen Vertragsbindung, Lock-in und Service Level Agreements (SLAs), die meist Reaktionszeit messen statt inhaltliche Qualität.

Die Kosten bewegen sich typischerweise im sechsstelligen Jahresbereich, je nach Umfang und SLA.

3. Hybrid beziehungsweise Co-Managed

Tooling intern, Betrieb teilweise extern – etwa Tagesbetrieb intern und Nacht- bzw. Wochenendbetrieb extern, oder Detection Engineering intern und L1-Triage extern. MITRE ordnet dies als Kombination aus internem SOC und Managed Service Provider ein.

Das Modell deckt häufig den Bedarf größerer Mittelständler ab: Die Kontrolle über kritische Entscheidungen bleibt intern, externe Ressourcen schließen Skalierungslücken. Voraussetzung ist eine klare Schnittstellendefinition, sonst entstehen Verantwortungslücken; der Steuerungsaufwand liegt höher als bei Vollauslagerung. Kostenrahmen: mittlerer sechsstelliger bis niedriger siebenstelliger Jahresbetrag, je nach Verteilung.

4. Security as Additional Duty mit EDR, MDR und 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 führt dieses Modell als Security as Additional Duty; es ist ein anerkanntes Organisationsmodell, kein Kompromiss. Es kann die Anforderungen von NIS-2 und ISO 27001 für viele mittelständische Einrichtungen abdecken – nicht jedoch DORA-Anforderungen an Finanzinstitute oder KRITIS-Pflichten.

Vorteile sind der geringste Overhead und die schnellste Einführung; Nachteile die fehlende 24/7-Eigenkapazität, längere Erkennungszeiten in Nebenzeiten sowie die Abhängigkeit vom MDR-Anbieter bei der Detection-Qualität. In der Anbieterlandschaft wird dieses Modell selten aktiv angeboten, da die Marge geringer ist. Kosten: typischerweise 50.000 bis 200.000 Euro pro Jahr, je nach Unternehmensgröße und Retainer-Umfang.

Warum die Reihenfolge entscheidet

Ein SOC ist der letzte Baustein einer Sicherheitsarchitektur, nicht der erste. Es arbeitet mit Logdaten, Bedrohungsannahmen und definierten Incident-Abläufen – Dinge, die im Unternehmen bereits vorhanden sein müssen, bevor das Betriebsmodell sie nutzen kann. Fehlt diese Vorarbeit, erkennt es entweder nichts oder alles. Beides ist wertlos.

Konkret nicht sinnvoll ist ein SOC, solange ein belastbarer Logging-Plan, ein Bedrohungsmodell, ein dokumentierter Incident-Response-Prozess, eine Asset-Inventur oder ein verantwortlicher Security-Lead fehlen. In diesen Fällen produziert es Alerts, die niemand bearbeitet, und Kosten, die niemand rechtfertigen kann – der Standardfall im Mittelstand. Umgekehrt ist ein SOC dann sinnvoll, 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. Das SOC ist Schritt sechs, nicht Schritt eins.

Hinzu kommt: Strategie und Umsetzung gehören getrennt. Wer sich beim Hausbau vom Bauträger den Grundriss zeichnen lässt, bekommt das Haus, das der Bauträger am liebsten baut – zu dem Preis, den er am liebsten nimmt. Nicht das Haus, in dem der Bauherr leben will.

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, ob MSSP, Systemhaus oder Produktanbieter, liefert gegen diese Spezifikation. Wer beide Rollen in eine Hand gibt, schafft genau einen Gewinner – und das ist nicht der Kunde.

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 tatsächlich Fähigkeit gefordert ist.

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

Drei Empfehlungen für alle, die gerade vor dieser Entscheidung stehen.

Erstens: Lesen Sie den Gesetzestext, nicht die Broschüre des Anbieters.

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

Drittens: 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. Oder, frei nach einem alten IT-Sprichwort: „A fool with a new tool is still a fool.“