SOC 24/7 im Jahr 2026 - Funktionsweise, rechtliche Anforderungen und Bewertung der Wirksamkeit

Ein SOC beobachtet die Umgebung, qualifiziert Alarme, führt technische Untersuchungen durch, begrenzt die Auswirkungen von Sicherheitsvorfällen und eskaliert Fälle an Systemeigentümer, die Leitung oder die zuständigen Reaktionsteams. Es verbindet damit technische Analyse und Entscheidungsprozesse. Die Information, dass ein Konto eine ungewöhnliche Operation ausgeführt hat, ist lediglich der Ausgangspunkt. Der Analyst muss wissen, ob das Konto privilegiert ist, welches Asset betroffen ist, welcher Geschäftsprozess davon abhängt und welche Folgen eine Sperrung des Kontos oder eine Isolation des Geräts haben kann.

Die zur Beschreibung von Sicherheitsdiensten verwendeten Begriffe sind nicht austauschbar.

• SIEM, Security Information and Event Management, dient der Sammlung, Suche, Normalisierung und Korrelation von Ereignisdaten. Es ist ein Werkzeug zur Unterstützung des Betriebs und kein Reaktionsteam.
• SOAR, Security Orchestration, Automation and Response, integriert Sicherheitswerkzeuge und führt definierte Abläufe aus. Automatisiert werden können beispielsweise die Anreicherung eines Alarms, die Anlage eines Falls, das Abrufen zusätzlicher Telemetrie, die Isolation eines Geräts, das Ungültigmachen einer Sitzung oder die Sperrung eines Kontos. Automatisierung beseitigt jedoch nicht das Risiko einer falschen Entscheidung. Maßnahmen mit großer Auswirkung sollten klar definierte Bedingungen, begrenzte Berechtigungen, einen Audit-Trail und, soweit erforderlich, eine menschliche Freigabe besitzen ^[17].
• SOC ist die organisatorische Fähigkeit zur Erkennung, Analyse und Reaktion. Es kann intern, als externe Dienstleistung oder in einem gemeinsam betriebenen Modell organisiert werden.
• CSIRT ist ein Incident-Response-Team mit einem definierten Zuständigkeitsbereich und einem festgelegten Kreis betreuter Stellen. Die Bezeichnung CERT wird in einem ähnlichen Zusammenhang häufig verwendet, doch der Name eines Teams legt dessen Kompetenzen nicht fest. Das polnische KSC definiert unter anderem CSIRT MON, CSIRT NASK, CSIRT GOV und sektorale CSIRTs ^[8].
• MDR, Managed Detection and Response, bezeichnet die dienstleistungsbasierte Bereitstellung eines Teils oder der gesamten Erkennungs- und Reaktionsfähigkeit. Ein MDR-Angebot kann ausschließlich Endgeräte abdecken, ein anderes zusätzlich Identitäten, Netzwerk, E-Mail, Cloud und Anwendungen. Aus dem Namen der Dienstleistung folgt daher weder der Umfang der Telemetrie noch die Befugnis des Anbieters nach Erkennung einer Bedrohung.

Ein eigenes SOC gibt einer Organisation die unmittelbarste Kontrolle über Personal, Telemetrie und Reaktion. Es erfordert jedoch Fachkompetenz, Schicht- oder Bereitschaftsmodelle, den Betrieb der Plattform und die kontinuierliche Weiterentwicklung der Detektion. Ein ausgelagertes Modell ermöglicht die Nutzung eines spezialisierten Teams und der Infrastruktur des Dienstleisters. Dadurch gewinnen Vertrag, technische Integration, Aufsicht und Datenjurisdiktion an Bedeutung. In einem gemeinsam betriebenen Modell werden die Aufgaben geteilt. Beispielsweise kann der Dienstleister Monitoring und Erstanalyse übernehmen, während Entscheidungen über kritische Systeme beim Kunden verbleiben. Die Studie von Kokulu und Mitautoren auf Grundlage von 18 Interviews mit SOC-Analysten und -Managern verdeutlicht, wie wichtig die Anpassung der SOC-Organisation an die tatsächlichen Arbeitsbedingungen einschließlich der Beziehungen zwischen Personal, Management und Technologie ist ^[3].

Ein 24/7-Modell ist sinnvoll, wenn eine kritische Dienstleistung ohne Unterbrechung läuft, die Folgen einer verzögerten Reaktion schnell zunehmen oder Verfahren und Rechtsvorschriften kurze Eskalationsfristen vorsehen. Es bedeutet nicht, dass jede Spezialistenrolle rund um die Uhr an einem Arbeitsplatz besetzt sein muss. Ein Modell kann eine ständig besetzte erste Linie mit Rufbereitschaft von Spezialisten und Entscheidungsträgern verbinden. Wichtiger als die Erklärung "24/7" ist, wer einen Alarm um 03:00 Uhr tatsächlich entgegennimmt, welche Befugnisse diese Person besitzt, wie schnell eskaliert werden kann und ob auf Kundenseite eine Person erreichbar ist, die eine Maßnahme mit Auswirkungen auf den Dienst freigeben kann.

Eine SOAR-Plattform kann Zugriff auf Logs, Identitätsdaten, Sicherheitskonfigurationen, API-Token, Informationen über Schwachstellen und Beweismaterial aus Sicherheitsvorfällen erhalten. Sie ist damit in der Praxis ein Infrastrukturbaustein mit hohem Vertrauensniveau. Im von 4crypto entwickelten Modell wird das SOAR-System so konzipiert, dass grundlegende Automatisierungs- und Ereignisbehandlungsprozesse in einer kontrollierten Umgebung betrieben werden können, ohne dass operative Kundendaten an externe Automatisierungs- oder generative KI-Dienste außerhalb der vorgesehenen Architektur übermittelt werden müssen. Dies beschreibt ein Entwurfsziel und stellt für sich allein keinen Sicherheitsnachweis dar.

Der Standort eines Servers in Polen oder im EWR genügt nicht, um die Souveränität eines Dienstes zu belegen. Zu prüfen sind Eigentümer der Infrastruktur, Jurisdiktion der an der Leistungserbringung beteiligten Stellen, Unterauftragnehmer, administrativer Fernzugriff, Produkttelemetrie, Backups, Schlüsselmanagement, Aktualisierungsprozesse und ausgehende Verbindungen. Enthalten Logs personenbezogene Daten, unterliegt eine Übermittlung in ein Drittland Kapitel V der DSGVO ^[14]. Für vom KSC erfasste Stellen gehört die Sicherheit der Lieferkette zum Management von Cybersicherheitsrisiken ^[8]. Die Behauptung eines Anbieters über lokale Verarbeitung sollte deshalb anhand der Architektur, der Verträge, der Liste der Auftragsverarbeiter und des tatsächlich beobachteten Netzwerkverkehrs geprüft werden.

SOC-Arbeit bildet einen Zyklus, in dem die Qualität jeder Stufe die folgende Stufe begrenzt. Automatisierung kann fehlende Telemetrie nicht kompensieren, und ein leistungsfähiges SIEM hilft wenig, wenn die kritischen Werte nicht bekannt sind.

Umfang und Prioritäten. Zunächst sind Dienste, Systeme, Identitäten und Datenflüsse zu bestimmen, bei denen ein Verlust von Vertraulichkeit, Integrität oder Verfügbarkeit erhebliche Folgen hätte. Daraus ergeben sich Bedrohungsszenarien, erforderliche Datenquellen und Reaktionsprioritäten. Eine reine Geräteliste beschreibt keine geschäftlichen Abhängigkeiten.

Zustand der Telemetrie. Ein SOC sollte nicht nur wissen, welche Logs gesammelt werden, sondern auch, ob die Quellen ordnungsgemäß funktionieren. Zu überwachen sind Vollständigkeit, Verzögerung, Zeitsynchronisation, Feldqualität, Integrität, Aufbewahrung und die Möglichkeit eines sicheren Exports. Fehlende Ereignisse von einem kritischen Domänencontroller oder VPN-Gateway sollten als Sensorproblem sichtbar werden und nicht als Zeichen einer ruhigen Nacht gelten.

Kontext. Ein Ereignis wird erst durch die Verknüpfung mit dem Asset-Verantwortlichen, der Kritikalität des Assets, der Benutzerrolle, bekannten Schwachstellen, administrativen Änderungen und früheren Aktivitäten aussagekräftig. IP-Geolokalisierung oder ein einzelner Reputationsindikator sind Indizien. Sie sind kein eigenständiger Nachweis einer Kompromittierung.

Detektion. Eine Regel sollte einer konkreten Hypothese entsprechen: Welches Verhalten soll erkannt werden, welche Telemetrie wird benötigt und welche legitimen Aktivitäten können ähnlich aussehen? MITRE ATT&CK strukturiert Wissen über Taktiken und Techniken von Angreifern und hilft, dieses Wissen mit der Detektion zu verbinden. Zum 29. August 2026 sind ATT&CK-v19.2-Daten verfügbar, darunter separate Datensätze für Detection Strategies und Analytics ^[19]. Eine ATT&CK-Zuordnung ist jedoch kein Testergebnis. Die Kennzeichnung einer Technik als "covered" beweist nicht, dass eine konkrete Regel mit der tatsächlich verfügbaren Telemetrie funktioniert.

Bewertung und Untersuchung. Der Analyst sollte feststellen, ob ein Alarm reale Aktivität beschreibt, welchen Umfang und welche Auswirkungen sie hat und was noch unbekannt ist. Eine gute Untersuchung ist reproduzierbar: Sie enthält Zeitachse, Datenquellen, Beweise, Hypothesen und den Grad der Gewissheit. Tatsachen und Schlussfolgerungen des Analysten sollten klar voneinander getrennt werden.

Reaktion. Die Isolation eines Geräts, das Ungültigmachen einer Sitzung oder die Sperrung eines Kontos oder einer Adresse kann Schäden begrenzen, aber ebenso einen legitimen Prozess unterbrechen. Automatisierte Reaktionen sollten einem vorab genehmigten Szenario folgen und auf Fälle begrenzt sein, in denen die Kosten einer falschen Reaktion akzeptabel sind. NIST SP 800-61 Rev. 3 behandelt Incident Response als Teil eines umfassenderen Cybersicherheits-Risikomanagements und verbindet Vorbereitung, Erkennung, Reaktion und Wiederherstellung mit den Funktionen des NIST CSF 2.0 ^[17][20].

Lernen. Nach einem Sicherheitsvorfall sollten Regeln, Datenquellen, Konfiguration, Architektur, Verfahren und Schulungen verbessert werden. War beispielsweise eine schwache E-Mail-Konfiguration eine wesentliche Voraussetzung für erfolgreiches Phishing, löst das bloße Schließen des Vorfalls die Ursache nicht. Dann können eine Prüfung von SPF, DKIM und DMARC, die Analyse des Authentisierungsprozesses und Security Awareness relevant sein. Erfolgte der Einstieg über einen verwundbaren Edge-Dienst, können Schwachstellenscans, Hardening oder ein Penetrationstest erforderlich sein. Diese Maßnahmen ergänzen das SOC, ersetzen es aber nicht.

Ein SOC sieht nicht alles. Verschlüsselung begrenzt die Inhaltsanalyse. Manche SaaS-Dienste liefern nur eingeschränkte Telemetrie oder setzen eine höhere Lizenzstufe für administrative Ereignisprotokolle voraus. Ein Edge-Gerät kann kompromittiert werden, bevor es einen Alarm sendet, ein EDR-Agent kann deaktiviert und ein lokales Log gelöscht werden. Zur Detektionsarchitektur gehören deshalb die Überwachung des Zustands von Datenquellen, die Verteilung von Beweisdaten und, für besonders wichtige Ereignisse, die Möglichkeit einer Bestätigung durch mehr als eine Quelle.

Das Ausbleiben eines Alarms ist kein Beweis dafür, dass kein Angriff stattgefunden hat. Es bedeutet lediglich, dass mit den verfügbaren Daten und der vorhandenen Detektionslogik kein Alarm ausgelöst wurde.

Die Berichte von Mandiant, Verizon, ENISA und CERT Polska beschreiben unterschiedliche Populationen, verwenden unterschiedliche Definitionen und beruhen auf verschiedenen Datenquellen. Ihre Prozentwerte dürfen nicht so miteinander verglichen werden, als würden sie denselben Markt messen. Sie helfen, Problemarten in bestimmten Datensätzen zu erkennen, erlauben aber keine Wirksamkeitsgarantie für ein konkretes SOC.

Mandiant M-Trends 2026 basiert auf mehr als 500.000 Stunden von Mandiant im Jahr 2025 durchgeführten Incident-Untersuchungen. Die globale Median-Dwell-Time, also die Zeit von der Kompromittierung bis zur Erkennung, betrug 14 Tage gegenüber 11 Tagen im Vorjahr. Für die untersuchten Fälle von Cyberspionage und Vorfälle im Zusammenhang mit nordkoreanischen IT-Arbeitskräften betrug der Median 122 Tage. Exploits machten 32% der von Mandiant beobachteten initialen Infektionsvektoren aus ^[4]. Dies sind Daten aus Mandiant-Untersuchungen und keine universelle Statistik für alle Organisationen.

Der Verizon DBIR 2026 analysiert mehr als 31.000 Sicherheitsvorfälle, darunter mehr als 22.000 bestätigte Datenschutzverletzungen bei Organisationen in 145 Staaten ^[5]. In der öffentlichen Zusammenfassung gibt Verizon an, dass 31% der Verletzungen mit der Ausnutzung von Software-Schwachstellen begannen und Ransomware bei 48% der Verletzungen vorkam ^[5]. Der DBIR weist selbst darauf hin, dass er Ereignisse beschreibt, die in den Datensatz aufgenommen wurden und die Kriterien des Berichts erfüllten. Die Prozentwerte sind daher keine Wahrscheinlichkeit dafür, dass eine beliebige Organisation eine bestimmte Art von Verletzung erleidet.

Der ENISA Threat Landscape 2025 umfasst 4.875 Vorfälle im Zeitraum vom 1. Juli 2024 bis zum 30. Juni 2025. DDoS machte 77% der gemeldeten Vorfälle aus und war zu einem großen Teil mit Hacktivismus verbunden. Ransomware wurde von ENISA dagegen als die Bedrohung mit den größten Auswirkungen in der EU bewertet ^[6]. Hier zeigt sich eine wichtige Unterscheidung: Häufigkeit und Schwere der Auswirkungen sind verschiedene Messgrößen.

CERT Polska berichtet für 2025 über 658.320 Meldungen und 260.783 registrierte eindeutige Sicherheitsvorfälle. Computerbetrug machte 253.238 Vorfälle und damit 97,1% aller registrierten Vorfälle aus ^[7]. Der Bericht führt den Anstieg der Meldungen und registrierten Vorfälle unter anderem auf ein gestiegenes Bewusstsein und die Rolle des Teams beim Monitoring und bei der Analyse zurück. Aus diesen Zahlen lässt sich daher nicht unmittelbar ableiten, dass die Zahl erfolgreicher Cyberangriffe im gleichen Verhältnis gestiegen ist.

Die gemeinsame operative Schlussfolgerung aus diesen Quellen ist breiter als die bloße Einführung von EDR. Ein Detektionsprogramm sollte Endgeräte, Identitäten, internetexponierte Dienste, Edge-Infrastruktur, Cloud-Dienste, E-Mail und Abhängigkeiten von Dritten berücksichtigen, weil wesentliche Angriffspfade nicht an einer Workstation enden.

Die Untersuchung von Alahmadi, Axon und Martinovic umfasste eine Online-Befragung von 20 in SOCs tätigen Praktikern und anschließend eine qualitative Untersuchung mit 21 Praktikern ^[2]. Die Autoren stellten fest, dass ein Teil der von Praktikern als False Positives bezeichneten Alarme tatsächlich korrekte Erkennungen legitimer Aktivität waren. Die Unterscheidung ist wesentlich: Ein Werkzeug kann Verhalten, das einer Regel entspricht, richtig erkennen, obwohl der daraus entstehende Alarm keine Incident-Response-Maßnahme erfordert.

Der Titel "99% False Positives" bedeutet nicht, dass 99% der Alarme in einem typischen SOC falsch sind. Die Studie legt keinen solchen universellen Wert fest. Sie untersucht vielmehr Qualität und Interpretierbarkeit von Alarmen sowie den Bedarf an Kontext, der eine schnelle Validierung ermöglicht ^[2].

Gutes Detection Tuning besteht daher nicht allein darin, die Zahl der Alarme zu senken. Zu aggressives Filtern kann False Positives reduzieren und gleichzeitig übersehene Ereignisse erhöhen. Qualität der Alarme, Szenarioabdeckung, Testergebnisse und über andere Wege entdeckte Ereignisse müssen gemeinsam betrachtet werden.

Eine Organisation kann Millionen von Ereignissen täglich verarbeiten und gleichzeitig Änderungen der Cloud-Konfiguration, Administratoraktivitäten, Ereignisse auf VPN-Gateways, die Nutzung von Applikationstoken oder Änderungen von Zugriffsrichtlinien nicht protokollieren. Ein großes Datenvolumen bedeutet keine umfassende Sichtbarkeit.

Abdeckung lässt sich besser als Paar beschreiben: Bedrohungsszenario - erforderliche Telemetrie. Anschließend ist zu prüfen, ob die Daten tatsächlich eintreffen, ob die Detektionslogik das Verhalten erkennen kann und ob die Reaktion funktioniert. NIST CSF 2.0 kann helfen, erwartete Ergebnisse des Sicherheitsprogramms zu strukturieren ^[20], während ATT&CK als Modell gegnerischen Verhaltens dienen kann ^[19]. Keines dieser Dokumente ersetzt einen kontrollierten Test in der eigenen Umgebung.

Der Test kann sehr unterschiedlich ausfallen: vom Nachstellen eines einzelnen administrativen Ereignisses über Purple Teaming bis zu einem vollständigen Penetrationstest mit vereinbartem Ziel. Entscheidend ist, ob die Organisation ein konkretes Szenario beobachten und korrekt behandeln kann.

SOAR verkürzt die Ausführungszeit wiederkehrender Tätigkeiten und unterstützt einen konsistenten Reaktionsablauf. Derselbe Mechanismus kann aber die Folgen eines Fehlers beschleunigen und vergrößern. Die automatische Isolation einer gewöhnlichen Workstation und das automatische Trennen eines Domänencontrollers, Cluster-Knotens oder OT-Elements haben völlig unterschiedliche Betriebsrisiken.

Maßnahmen sollten deshalb nach ihrer Auswirkung klassifiziert werden. Einige können automatisch erfolgen, etwa die Anreicherung eines Alarms oder das Abrufen zusätzlicher Daten. Andere können eine hohe Konfidenzschwelle und die Freigabe eines Analysten erfordern. Maßnahmen, die eine Dienstleistung unterbrechen können, sollten einen vereinbarten Autorisierungspfad, soweit technisch möglich eine Rücknahmemöglichkeit und eine vollständige Ausführungsprotokollierung besitzen ^[17].

Es gibt keine einzelne Kennzahl, die ein SOC angemessen beschreibt. Zeitmetriken lassen sich besonders leicht missverstehen.

MTTD kann die Zeit vom Beginn eines Vorfalls bis zu seiner Erkennung bedeuten. In einem anderen Bericht kann der Wert jedoch vom Erzeugen eines Alarms bis zu dessen Bestätigung durch einen Analysten gemessen werden. MTTR kann Reaktionszeit, Reparaturzeit oder die Zeit bis zur vollständigen Wiederherstellung eines Dienstes bedeuten. Ohne eindeutig definierten Anfangs- und Endpunkt ist die Zahl nicht zuverlässig vergleichbar.

Auch die Dwell Time aus dem Mandiant-Bericht entspricht nicht der internen Bearbeitungszeit eines Alarms. Sie umfasst die Zeit, in der ein Angreifer vor seiner Erkennung in der Umgebung präsent war ^[4].

Ein besserer Satz von Kennzahlen verbindet mehrere Perspektiven:

• Abdeckung kritischer Dienste, Assets und Bedrohungsszenarien mit überprüfter Telemetrie und getesteten Detektionen;
• Zustand der Datenquellen einschließlich Vollständigkeit, Latenz, Parserfehlern und Unterbrechungen der Telemetrie;
• Qualität der Alarme einschließlich bestätigter Alarme, benign true positives sowie der Ursachen falscher und übersehener Detektionen;
• Zeiten mit eindeutig festgelegten Messpunkten: Eingang des Alarms, Bestätigung, Eskalation, Eindämmung und Wiederherstellung;
• Ereignisse, die über andere Wege entdeckt wurden, obwohl das SOC sie hätte erkennen sollen;
• Zeit für das Schließen von Telemetrie- und Detektionslücken sowie Umsetzung von Maßnahmen nach Sicherheitsvorfällen;
• Fallrückstand, Belastung der Bereitschaft und Qualität der Übergaben zwischen Schichten.

Ziel ist nicht eine möglichst große Zahl von Metriken. Eine Kennzahl ist dann sinnvoll, wenn sie eine Entscheidung auslöst: Änderung einer Regel, Verbesserung der Sichtbarkeit, Anpassung eines Verfahrens, zusätzliche Schulung oder Investition in eine konkrete Fähigkeit.

Am 29. August 2026 gilt das KSC in der Fassung nach der Novelle, die am 3. April 2026 in Kraft trat. Der von der Kanzlei des Sejm zum Stand vom 18. August 2026 konsolidierte Text berücksichtigt Dz.U. 2026 Pos. 20, 252, 815 und 1003 ^[8][9]. NIS2 bleibt eine EU-Richtlinie; für polnische Einrichtungen ergeben sich die konkreten nationalen Pflichten in erster Linie aus dem KSC, das diese Richtlinie umsetzt ^[10].

Art. 8 verpflichtet eine wesentliche oder wichtige Einrichtung zur Einführung eines Informationssicherheitsmanagementsystems in dem Informationssystem, das in Prozessen mit Einfluss auf die Erbringung ihrer Dienstleistung verwendet wird. Zu den Anforderungen gehören die kontinuierliche Überwachung dieses Systems sowie das Management von Sicherheitsvorfällen, Schwachstellen, Zugriffen, Assets, Business Continuity und Lieferkettenrisiken ^[8]. Das Gesetz verlangt damit bestimmte Fähigkeiten. Es schreibt nicht vor, dass diese als Produkt mit der Bezeichnung SOC eingekauft werden müssen.

Art. 11 sieht für einen schwerwiegenden Vorfall mehrere Stufen vor. Die Einrichtung übermittelt eine Frühwarnung unverzüglich, spätestens innerhalb von 24 Stunden nach der Erkennung, und eine Meldung des schwerwiegenden Vorfalls unverzüglich, spätestens innerhalb von 72 Stunden nach der Erkennung. Der Abschlussbericht ist spätestens einen Monat nach der 72-Stunden-Meldung zu übermitteln ^[8]. Für Vertrauensdiensteanbieter enthält das Gesetz eine gesonderte 24-Stunden-Regel zur Meldung eines schwerwiegenden Vorfalls ^[8].

Auch die Übergangsfristen erfordern eine genaue Einordnung. Einrichtungen, die am 3. April 2026 die Kriterien einer wesentlichen oder wichtigen Einrichtung erfüllten, haben grundsätzlich zwölf Monate für die Pflichten aus Kapitel 3, also bis zum 3. April 2027 ^[9]. Dies ist keine universelle Frist für jede Einrichtung, die künftig unter das KSC fällt. Werden die Kriterien später erfüllt, gilt der im KSC vorgesehene Mechanismus ab dem Tag, an dem die Voraussetzungen erfüllt sind ^[8].

Die Meldefristen von KSC und DORA sollten für ein Ereignis nicht automatisch addiert werden. Art. 8i KSC enthält eine besondere Regelung für wesentliche oder wichtige Einrichtungen aus den Sektoren Bankwesen und Finanzmarktinfrastrukturen. Grundsätzlich finden auf sie die KSC-Vorschriften zum Informationssicherheitsmanagementsystem oder zur Meldung schwerwiegender Vorfälle keine Anwendung, vorbehaltlich der im Gesetz ausdrücklich aufgeführten Ausnahmen ^[8]. Im Umfang dieser Ausnahme hat DORA grundlegende Bedeutung.

Diese Unterscheidung hat unmittelbare Folgen für den SOC-Betrieb. Ein Melde-Runbook sollte nicht einen universellen Pfad "NIS2/KSC/DORA/DSGVO" enthalten. Zunächst sind Status der Einrichtung, Art des Vorfalls und das anwendbare Rechtsregime zu bestimmen.

DORA, die Verordnung (EU) 2022/2554, gilt seit dem 17. Januar 2025 für die in der Verordnung genannten Finanzunternehmen ^[11]. Sie verlangt unter anderem Mechanismen zur Erkennung anomaler Aktivitäten und einen Prozess für das Management IKT-bezogener Vorfälle.

Die Delegierte Verordnung (EU) 2024/1774 konkretisiert die technischen Anforderungen. Art. 23 verlangt unter anderem die Sammlung, Überwachung und Analyse bestimmter Informationsquellen, die Identifikation anomaler Aktivitäten und den Einsatz alarmgenerierender Werkzeuge zumindest für IKT- und Informationsassets, die kritische oder wichtige Funktionen unterstützen. Alarme sind so zu priorisieren, dass erkannte IKT-bezogene Vorfälle sowohl während als auch außerhalb der Geschäftszeiten innerhalb der erwarteten Lösungszeit behandelt werden können ^[12].

Für einen schwerwiegenden IKT-bezogenen Vorfall verlangt die Delegierte Verordnung (EU) 2025/301 eine Erstmeldung so früh wie möglich, jedenfalls innerhalb von vier Stunden nach Einstufung als schwerwiegend und spätestens 24 Stunden, nachdem das Finanzunternehmen von dem Vorfall Kenntnis erlangt hat. Der Zwischenbericht ist spätestens 72 Stunden nach der Erstmeldung einzureichen. Der Abschlussbericht folgt grundsätzlich innerhalb eines Monats nach dem Zwischenbericht oder dessen letzter Aktualisierung ^[13].

DORA verlangt nicht den Kauf eines bestimmten SOC. In der Praxis entstehen jedoch Anforderungen, die bei vielen Organisationen eine Erkennungs- und Eskalationsfähigkeit außerhalb regulärer Arbeitszeiten notwendig machen.

Die DSGVO begründet keine allgemeine Pflicht zum Betrieb eines SOC. Art. 32 verlangt Sicherheitsmaßnahmen, die dem Risiko angemessen sind ^[14]. Art. 33 betrifft eine Verletzung des Schutzes personenbezogener Daten und nicht jeden Cybersicherheitsvorfall.

Bei einer Verletzung des Schutzes personenbezogener Daten meldet der Verantwortliche diese unverzüglich und möglichst binnen 72 Stunden, nachdem ihm die Verletzung bekannt wurde, an die zuständige Aufsichtsbehörde, es sei denn, dass die Verletzung voraussichtlich nicht zu einem Risiko für die Rechte und Freiheiten natürlicher Personen führt. Ein Auftragsverarbeiter informiert den Verantwortlichen unverzüglich, nachdem ihm die Verletzung bekannt wurde ^[14].

Ein SOC sollte deshalb die Informationen für die rechtliche Bewertung eines Vorfalls schnell bereitstellen können. Die Qualifikation als Verletzung des Schutzes personenbezogener Daten ist jedoch ein gesonderter rechtlicher Prozess. Die DSGVO-Frist beginnt nicht automatisch mit einem beliebigen SIEM-Alarm. Ausführlicher zu den Pflichten des Verantwortlichen im Beitrag zum DSGVO-Audit.

Am 29. August 2026 gilt die Verordnung des Ministerrats vom 21. Mai 2024 über den Nationalen Interoperabilitätsrahmen, KRI ^[15]. § 19 enthält für Stellen, die öffentliche Aufgaben wahrnehmen, Anforderungen an das Informationssicherheitsmanagementsystem und verlangt mindestens einmal jährlich ein periodisches internes Audit der Informationssicherheit. § 19 Abs. 3 enthält einen Mechanismus, nach dem die Anforderungen der Abs. 1 und 2 als erfüllt gelten, wenn das ISMS auf Grundlage von PN-ISO/IEC 27001 entwickelt wurde und die Festlegung von Sicherheitsmaßnahmen, das Risikomanagement und die Auditierung auf den einschlägigen Polnischen Normen im Zusammenhang mit PN-ISO/IEC 27001 beruhen, darunter PN-ISO/IEC 27002 und PN-ISO/IEC 27005 ^[15].

Für ein SOC ist § 20 besonders praktisch relevant. Er verlangt die Nachvollziehbarkeit von Aktivitäten in Informationssystemen und innerhalb seines Anwendungsbereichs unter anderem die Protokollierung administrativer Zugriffe und von Änderungen der Sicherheitskonfiguration. Soweit andere Vorschriften keinen anderen Zeitraum bestimmen, werden die Protokollinformationen zwei Jahre aufbewahrt ^[15]. KRI verpflichtet jedoch weder zum Kauf eines SOC noch zur ISO/IEC-27001-Zertifizierung.

Auch der Zeithorizont 2027 muss berücksichtigt werden. ELI nennt den 23. Februar 2027 als Datum des Außerkrafttretens der aktuellen KRI-Verordnung ^[15]. Der Entwurf einer Nachfolgeregelung RD313 wurde 2026 veröffentlicht und ist am 29. August 2026 weiterhin ein Entwurf und kein geltendes Recht ^[16]. Seine Begründung geht unter anderem von einer Verlagerung bestimmter Sicherheitsregelungen im Zusammenhang mit dem neuen KSC aus. Die heutige Fassung der §§ 19 und 20 darf daher nicht ohne erneute Rechtsprüfung auf die Zeit nach dem 23. Februar 2027 übertragen werden.

ISO/IEC 27001:2022 mit Amendment 1:2024 legt Anforderungen an ein Informationssicherheitsmanagementsystem fest ^[21]. ISO/IEC 27035-1:2023 beschreibt Grundsätze und den Prozess des Managements von Informationssicherheitsvorfällen ^[18]. NIST CSF 2.0 ist ein freiwilliges Framework zum Management von Cybersicherheitsrisiken. NIST SP 800-61 Rev. 3 enthält Empfehlungen zur Reaktion auf Sicherheitsvorfälle in Verbindung mit CSF 2.0 ^[17][20].

Diese Dokumente können nützliche Referenzpunkte sein und unter Umständen zu Vertragsanforderungen werden. Sie sind jedoch nicht mit einem polnischen Gesetz oder einer unmittelbar geltenden EU-Verordnung gleichzusetzen. Bei einem KSC- und NIS2-Audit, KRI-Audit oder IT-Sicherheitsaudit sollten die Bewertungskriterien ausdrücklich benannt werden. Die Konformität mit einem Dokument darf nicht als automatische Erfüllung aller anderen Anforderungen dargestellt werden.

Sprachmodelle können bei der Zusammenfassung von Fällen, dem Aufbau von Zeitachsen, der Formulierung von SIEM-Abfragen, der Strukturierung von Daten und dem Entwurf von Detektionslogik helfen. Ihre Ausgabe ist kein unabhängiges Beweismittel. Eine vom Modell erzeugte Aussage muss anhand der Rohtelemetrie oder einer anderen zuverlässigen Quelle bestätigt werden.

Die Risiken sind konkret. Kundenlogs, personenbezogene Daten, technische Geheimnisse oder Architekturinformationen können an ein externes Modell gelangen. Ein Modell kann einen falschen Schluss mit hoher sprachlicher Sicherheit präsentieren. Der Inhalt eines analysierten Tickets, einer Nachricht, einer Webseite oder einer Datei kann Anweisungen enthalten, die das Verhalten eines LLM-gestützten Systems verändern. OWASP beschreibt dieses Problem als Prompt Injection, einschließlich der indirekten Variante, bei der Anweisungen aus verarbeiteten externen Webseiten oder Dateien stammen ^[22]. Das größte Risiko entsteht, wenn ungeprüfte Modellausgaben unmittelbar mit der Befugnis verbunden werden, Änderungen an der Infrastruktur auszuführen.

Eine angemessene Architektur begrenzt Daten und Berechtigungen, trennt Kundenumgebungen, protokolliert Modellaufrufe, testet erzeugte Abfragen und Skripte vor dem produktiven Einsatz und verlangt Freigaben für Maßnahmen mit großer Auswirkung. Ein hoher Automatisierungsgrad ist dort sinnvoll, wo die Folgen einer Fehlentscheidung verstanden und kontrolliert werden.

MITRE veröffentlichte im August 2026 die Aktualisierung v19.2. Die offiziellen Datensätze umfassen für die jeweiligen ATT&CK-Domänen unter anderem Techniken, Detection Strategies und Analytics ^[19]. Dadurch lässt sich gegnerisches Verhalten präziser mit benötigter Telemetrie und Detektionslogik verbinden.

Ein SOC sollte dennoch nicht allein anhand des Prozentsatzes von ATT&CK-Techniken bewertet werden, die ein Produkt angeblich "abdeckt". Eine Technik kann viele Varianten besitzen. Eine Regel kann eine Datenquelle voraussetzen, die die Organisation nicht sammelt. Eine Detektion kann unter Windows funktionieren, aber nicht unter Linux oder in einer Cloud-Umgebung. Abdeckung erhält erst dann Aussagekraft, wenn das Szenario in der betreffenden Umgebung getestet wurde.

Ein reifes SOC wird nicht durch die Zahl der Bildschirme, die Zahl der Detektionsregeln oder den Namen einer eingekauften Dienstleistung definiert. Sein Wert lässt sich erst nachweisen, wenn die Organisation weiß, was sie schützen will, verlässliche Telemetrie besitzt, ein relevantes Bedrohungsszenario erkennen kann, den analytischen Entscheidungsweg reproduzieren kann, eine angemessene Reaktion durchführt und die Sicherheitsmaßnahmen nach einem Vorfall verbessert.

Ein 24/7-Modell ist dort begründet, wo Bedrohungen und Auswirkungen nicht in Geschäftszeiten passen. Rechtsvorschriften können zusätzlich kontinuierliches Monitoring oder sehr kurze Meldefristen verlangen. Die grundlegende Regel bleibt gleich: Ein Werkzeug, eine Rufbereitschaft und formale Compliance sind nur Teile einer operativen Fähigkeit. Die Wirksamkeit zeigt sich daran, ob der gesamte Prozess funktioniert, wenn er tatsächlich benötigt wird.