NIS2 SIEM: Sicherheitsmonitoring für den Mittelstand
Letzte Aktualisierung: 23. März 2026
NIS2 verlangt für betroffene Unternehmen gemäß Art. 21 Abs. 2 Buchst. b der Richtlinie (EU) 2022/2555 wirksames Incident Handling; zusammen mit Art. 21 Abs. 2 Buchst. d und j entsteht daraus ein klarer Bedarf an zentralem Sicherheitsmonitoring. Für viele mittelständische Unternehmen ist ein SIEM deshalb nicht Luxus, sondern der praktikabelste Weg, Logs, Alarme und Reaktionsprozesse belastbar zusammenzuführen.
Die entscheidende juristische Einordnung lautet dabei: NIS2 schreibt kein bestimmtes Produkt mit dem Namen SIEM vor. NIS2 schreibt aber vor, dass Sie Sicherheitsereignisse erkennen, bewerten, eskalieren und dokumentieren können. Genau deshalb reicht ein Flickenteppich aus Firewall-Konsole, M365-Portal, Einzellogs und ungepflegten E-Mail-Warnungen für viele betroffene KMU nicht mehr aus. Wenn Sie zuerst Begriffe, Betroffenheit und organisatorische Verantwortlichkeit sortieren möchten, sind das Glossar zu SIEM, die NIS2 Online-Schulung und unser Vergleich zu Compliance-Software im Mittelstand sinnvolle Ausgangspunkte.
Warum NIS2 ein SIEM-System verlangt (§ 30 BSIG-E)
NIS2 verlangt in der Praxis ein SIEM, weil die Richtlinie funktionierende Erkennung und Reaktion fordert, nicht bloß abstrakte Richtlinien auf Papier. Art. 21 Abs. 2 Buchst. b verlangt Maßnahmen zur Behandlung von Sicherheitsvorfällen. Art. 21 Abs. 2 Buchst. d fordert Business-Continuity-nahe Vorkehrungen einschließlich Backup, Disaster Recovery und Krisenmanagement. Art. 21 Abs. 2 Buchst. j nennt den Einsatz von Multi-Faktor-Authentisierung, gesicherter Kommunikation und ähnlichen Schutzmechanismen. Diese Maßnahmen sind nur dann steuerbar, wenn sicherheitsrelevante Ereignisse zentral sichtbar werden.
Der Verweis auf § 30 BSIG-E stammt aus dem deutschen Entwurfsstadium. Für die Praxis im Jahr 2026 ist wichtiger, dass nach BSI-Angaben mit Inkrafttreten des NIS-2-Umsetzungsgesetzes am 6. Dezember 2025 die dort geregelten Registrierungs- und Meldepflichten über das BSI-Portal operativ gelten. Wenn interne Projektunterlagen noch mit „BSIG-E“ arbeiten, ist das deshalb ein Datumsproblem und kein inhaltlicher Freibrief. Für Sicherheitsmonitoring zählt die heute geltende Nachweis- und Reaktionsfähigkeit, nicht die alte Entwurfsbezeichnung.
Für mittelständische Unternehmen ist die Kernfrage deshalb nicht: „Steht das Wort SIEM wörtlich im Gesetz?“ Die Kernfrage lautet: „Kann unser Unternehmen nachweisen, dass sicherheitsrelevante Ereignisse aus kritischen Systemen erkannt, korreliert, bewertet und fristgerecht an Incident Response, Geschäftsführung und gegebenenfalls BSI weitergegeben werden?“ Wenn die Antwort darauf nein oder nur teilweise lautet, fehlt kein Produktmarketing, sondern eine Compliance- und Sicherheitsfunktion.
BSI-seitig passt diese Lesart zum Grundgedanken der NIS2-Umsetzung. Der IT-Grundschutz-Baustein DER.1 Detektion von sicherheitsrelevanten Ereignissen und der Baustein DER.2.1 Behandlung von Sicherheitsvorfällen beschreiben genau die operative Linie, die auch unter NIS2 tragfähig sein muss: Ereignisse erkennen, priorisieren, behandeln und dokumentieren. Ein SIEM ist dafür nicht die einzig denkbare Technik, aber im Mittelstand sehr häufig die organisatorisch sauberste.
Besonders relevant wird das bei drei typischen Konstellationen:
- Mehrere Log-Quellen: Microsoft 365, Firewall, VPN, Endpoints, Server und Cloud-Workloads erzeugen Warnungen in getrennten Oberflächen.
- Externe IT-Dienstleister: Managed Service Provider betreiben Teile der Infrastruktur, aber niemand hat ein zentrales Lagebild.
- Meldepflichtige Vorfälle: Art. 23 NIS2 verlangt bei erheblichen Vorfällen schnelle Meldungen. Ohne saubere Detection und Eskalation wird die 24-Stunden-Logik schnell unrealistisch.
Genau an dieser Stelle trifft NIS2 den Mittelstand operativ. Nicht jede Organisation braucht ein großes Security Operations Center. Aber jede betroffene Organisation braucht einen belastbaren Weg von der ersten Auffälligkeit zum nachweisbaren Incident Handling. Ein SIEM bildet diesen Weg oft wesentlich besser ab als manuelle Excel-Listen oder Einzelportale.
Was ist ein SIEM? (Funktionsweise erklärt)
Ein SIEM ist eine zentrale Plattform für Security Information and Event Management. Das System sammelt Log-Daten aus verschiedenen Quellen, normalisiert sie, korreliert Ereignisse, bewertet Risiken und erzeugt Alarme für die weitere Bearbeitung. Technisch ist ein SIEM damit die Schnittstelle zwischen reiner Datensammlung und operativer Sicherheitsreaktion.
Für ein KMU lässt sich die Funktionsweise in fünf Bausteine zerlegen:
- Datenaufnahme: Das SIEM übernimmt Logs aus Firewalls, Microsoft 365, Active Directory, Servern, Endpoints, VPN, E-Mail-Security, Cloud-Diensten oder Produktionssystemen.
- Normalisierung: Unterschiedliche Log-Formate werden in ein gemeinsames Schema überführt, damit Ereignisse vergleichbar werden.
- Korrelation: Einzelne unauffällige Signale werden zusammengeführt, etwa fehlgeschlagene Anmeldungen, anschließende erfolgreiche Logins und auffällige Datenabflüsse.
- Alarmierung: Das System erzeugt priorisierte Warnungen, idealerweise mit Kontext, Schweregrad und Eskalationsweg.
- Auswertung und Nachweis: Sicherheitsverantwortliche können Vorfälle nachvollziehen, Trends erkennen, Reports erzeugen und Maßnahmen dokumentieren.
Für den Mittelstand ist besonders wichtig, was ein SIEM nicht ist. Ein SIEM ist weder automatisch ein vollständiges SOC noch automatisch gute Incident Response. Es ersetzt keine Rollen, keine Reaktionspläne und kein Risikomanagement. Es macht aber sichtbar, was ohne zentrale Logik oft unsichtbar bleibt.
Ein einfaches Beispiel zeigt den Unterschied. Ohne SIEM sieht Ihre Firewall verdächtigen Traffic, Microsoft 365 erkennt verdächtige Anmeldungen und Ihr Endpoint-Tool blockiert ein Script. Jedes System meldet für sich. Mit SIEM werden diese drei Signale als zusammenhängender Angriffspfad sichtbar: kompromittiertes Konto, auffällige Anmeldung, laterale Bewegung, möglicher Datenabfluss. Genau diese Korrelation ist unter NIS2 für belastbares Incident Handling entscheidend.
Aus BSI-Perspektive lässt sich ein SIEM gut an bestehende Bausteine des IT-Grundschutzes anschließen. Die operative Idee ist dieselbe: Schutzbedarf verstehen, Ereignisse überwachen, Vorfälle strukturiert bearbeiten und Nachweise revisionsfähig dokumentieren. Wer diesen Zusammenhang vertiefen möchte, findet im Beitrag zum BSI IT-Grundschutz die passende Governance-Ebene, in unserem Leitfaden zur NIS2-Vorfallmeldung die Meldeperspektive und im Beitrag zu NIS2-Maßnahmen für Cyberhygiene-Schulungen die organisatorische Ergänzung.
SIEM-Lösungen für KMU im Vergleich
SIEM-Lösungen für KMU unterscheiden sich weniger nach Marketing-Versprechen als nach Betriebsmodell, Integrationsreife und Personalbedarf. Für mittelständische Unternehmen ist deshalb nicht die Funktionsliste entscheidend, sondern die Frage, wie schnell sich kritische Datenquellen anbinden, Alarme sinnvoll priorisieren und Berichte für Management oder Prüfung erstellen lassen.
Die folgende Vergleichstabelle ist bewusst pragmatisch. Sie ordnet keine Produkte als „beste Lösung“ ein, sondern zeigt, welche Lösungsklasse für welchen Mittelstandstyp typischerweise passt.
| Lösungsklasse | Typische Beispiele | Stärke | Schwäche | Geeignet für |
|---|---|---|---|---|
| Cloud-nahes SIEM im Microsoft-Umfeld | Microsoft Sentinel und angrenzende Security-Stacks | Gute Integration in M365, Azure, Defender, schnelle Einführung | Kann bei heterogener IT und Log-Volumen teuer oder komplex werden | KMU mit starkem Microsoft-Fokus |
| Plattform-SIEM mit breitem Ökosystem | Splunk, IBM QRadar, LogRhythm, Elastic Security | Sehr tiefe Auswertung, viele Konnektoren, hohe Flexibilität | Tuning, Betrieb und Kostenaufwand oft hoch | Reifere Mittelständler mit eigenem Security-Team |
| MSSP- oder Managed-SIEM-Angebot | Dienstleisterbetrieb auf Basis etablierter Plattformen | Weniger Eigenaufwand, 24/7-Monitoring optional, schneller Start | Abhängigkeit vom Dienstleister, Qualität schwankt | KMU ohne eigenes SOC |
| Leichtgewichtiges Log- und Monitoring-Setup | Syslog plus EDR plus einzelne Alarmregeln | Niedriger Einstieg, geringe Anfangskosten | Schwache Korrelation, geringer Nachweiswert, hohe Blind Spots | Kleine Umgebungen als Übergangslösung |
Für die Auswahl sind meist vier Fragen wichtiger als der Markenname:
- Welche Systeme sind wirklich kritisch? ERP, Identitäten, E-Mail, VPN, Server, OT, Backup und Cloud-Anwendungen gehören fast immer dazu.
- Wer betreibt das System? Interne IT, externer MSSP oder Mischmodell.
- Wie viel Log-Volumen fällt an? Das beeinflusst Kosten, Datenhaltung und Alarmqualität massiv.
- Welche Reaktionszeit brauchen Sie? Bürozeiten-Monitoring reicht für manche KMU, für andere nicht.
Ein häufiger Beschaffungsfehler ist die Verwechslung von „viele Daten ingestieren“ mit „besser überwachen“. Ein Mittelständler mit 80 Mitarbeitenden braucht nicht automatisch dieselbe SIEM-Tiefe wie ein Konzern. Er braucht aber Use Cases, die seine realen Risiken abdecken: Administrator-Login außerhalb des Profils, MFA-Bypass, auffälliger Datenexport, Ransomware-Indikatoren, verdächtige VPN-Anmeldung, Abschalten von Backup-Jobs oder Manipulation von E-Mail-Regeln.
Wenn Sie diese Werkzeugfrage mit Governance verbinden möchten, ist auch der Blick auf Compliance-Software im Mittelstand sinnvoll. Ein SIEM ersetzt keine Dokumentations- oder Schulungslogik. Umgekehrt ersetzt ein Governance-Tool kein operatives Sicherheitsmonitoring. Für die begriffliche Abgrenzung zwischen Plattform, Team und Dienstleister hilft zusätzlich unser Glossar zu SIEM.
Managed SIEM vs. On-Premise: Kosten und Aufwand
Managed SIEM ist für viele KMU wirtschaftlich sinnvoller als ein vollständig selbst betriebenes On-Premise- oder Self-Managed-SIEM. Der Grund ist nicht nur die Lizenz, sondern der laufende Personalbedarf. Ein SIEM liefert nur dann Nutzen, wenn Use Cases gepflegt, False Positives reduziert, neue Log-Quellen angebunden und Alarme tatsächlich bearbeitet werden.
Die wirtschaftliche Realität sieht im Mittelstand häufig so aus:
| Modell | Direkte Kosten | Interner Aufwand | Typisches Risiko |
|---|---|---|---|
| Managed SIEM | planbare monatliche Betriebskosten plus Setup | mittel | Abhängigkeit von Servicequalität und SLA |
| Self-Managed Cloud-SIEM | variable Lizenz- und Ingest-Kosten | hoch | Kostenexplosion durch Datenmenge und fehlendes Tuning |
| On-Premise SIEM | hohe Start- und Betriebskosten | sehr hoch | fehlende Skalierung, hoher Pflegeaufwand |
Managed SIEM passt besonders dann, wenn Ihr Unternehmen keine eigene Security-Analysten-Rolle aufbauen will oder kann. Der Dienstleister übernimmt typischerweise Plattformbetrieb, Rule-Tuning, Alarmqualifizierung und gegebenenfalls 24/7-Erstreaktion. Das entlastet die interne IT, verlangt aber klare Verantwortlichkeiten: Wer nimmt Eskalationen an? Wer entscheidet über Isolierung, externe Kommunikation und BSI-Meldung? Ohne diese Governance bleibt auch ein guter MSSP nur halbfertig.
On-Premise oder Self-Managed kann sinnvoll sein, wenn besondere Datenhaltungsanforderungen, OT-Nähe, hohe Integrationsfreiheit oder bestehende Security-Kompetenz im Haus vorhanden sind. Für viele klassische KMU ist dieses Modell aber zu personalintensiv. Die versteckten Kosten liegen nicht im Server, sondern in den Menschen: Security Engineering, Plattformpflege, Use-Case-Entwicklung, Alarmtriage, Nachweisdokumentation.
Eine grobe Kostenlogik hilft bei der Vorentscheidung:
- Kleines KMU mit fokussiertem Scope: eher Managed SIEM oder stark cloud-nahes Modell.
- Mittelständler mit hybrider Infrastruktur und Auditanforderungen: häufig Managed SIEM mit klarer Berichtslinie.
- Security-reifer Mittelstand mit eigenem Team: gegebenenfalls Self-Managed oder Plattform-SIEM.
Wer nur den Lizenzpreis vergleicht, unterschätzt die Gesamtkosten fast immer. Ein günstiges Tool mit schlechter Alarmqualität bindet mehr interne Zeit als ein teurerer, sauber betriebener Dienst. Für die Management-Perspektive auf Budget, Haftung und Mindestschutz lohnt ergänzend der Beitrag zu Cybersecurity-Kosten für KMU sowie die Einordnung zur Geschäftsführer-Haftung bei Cyberangriffen.
Implementierung: Von der Planung zum Go-Live
SIEM-Implementierung für NIS2 beginnt mit Scope und Verantwortlichkeit, nicht mit dem Kauf einer Plattform. Ein Mittelständler sollte das Projekt als Sicherheits- und Compliance-Vorhaben führen: Welche kritischen Dienste müssen überwacht werden, welche Vorfälle sollen erkannt werden, wer reagiert, welche Nachweise werden benötigt und wie wird die Wirksamkeit getestet?
Ein belastbarer NIS2-SIEM-Rollout lässt sich in sieben Schritte gliedern:
-
Betroffenheit und Zielbild klären
Prüfen Sie zuerst, ob Ihr Unternehmen als wichtige oder besonders wichtige Einrichtung betroffen ist und welche Dienste unter NIS2 kritisch sind. Ohne Scope produzieren Sie später entweder Blind Spots oder unnötige Log-Kosten. -
Assets und Log-Quellen inventarisieren
Erfassen Sie Identitäten, Server, Cloud-Konten, Firewalls, E-Mail, VPN, Endpoints, Backup-Systeme, Admin-Zugänge und gegebenenfalls OT-Komponenten. NIS2-Compliance scheitert oft nicht an fehlender Technik, sondern an fehlender Vollständigkeit. -
Use Cases definieren
Legen Sie fest, welche Ereignisse zwingend erkannt werden sollen: privilegierte Logins, MFA-Fehler, Massenverschlüsselung, Datenexfiltration, verdächtige PowerShell-Nutzung, Deaktivierung von Schutzmechanismen, Backup-Manipulation oder auffällige Administratoraktivität. -
Betriebsmodell festlegen
Entscheiden Sie früh, ob Sie Managed SIEM, Self-Managed oder Mischbetrieb wollen. Davon hängen SLA, Eskalationswege, Personalbedarf und Budget ab. -
Alarmierung und Eskalation dokumentieren
Definieren Sie Schweregrade, Reaktionszeiten, Kontaktwege und Entscheidungsrollen. Nur dann wird aus Monitoring ein belastbarer Incident-Handling-Prozess im Sinne von Art. 21 Abs. 2 Buchst. b. -
Pilotieren und tunen
Starten Sie mit den kritischsten Datenquellen statt mit Vollabdeckung. Ein kleiner sauberer Scope ist wertvoller als ein großes unbrauchbares Alarmrauschen. -
Go-Live testen und nachweisen
Führen Sie Tabletop-Tests oder simulierte Vorfälle durch. Prüfen Sie, ob Alarme ankommen, ob Eskalationen funktionieren und ob Ihr Team daraus eine belastbare Vorfallsdokumentation erzeugen kann.
Für BSI-nahe Nachweisfähigkeit ist außerdem wichtig, dass das SIEM nicht isoliert bleibt. Es muss mit Risikomanagement, Incident Response, Backup-Strategie, Berechtigungskonzept und Geschäftsleitungskommunikation verzahnt sein. Wer nur Logs sammelt, aber keine Entscheidungen auslöst, hat ein Datenprojekt gebaut, kein Sicherheitsmonitoring.
Drei Umsetzungsprinzipien sind für KMU besonders hilfreich:
- Kritische Systeme zuerst: Identitäten, E-Mail, Firewall, VPN und Backup sind meist wichtiger als exotische Vollabdeckung.
- Detection vor Perfektion: Lieber zehn hochwertige Regeln live als hundert ungetestete Use Cases.
- Dokumentation ab Tag eins: Quellen, Regeln, Eskalationspfade und Testergebnisse sollten sofort nachvollziehbar abgelegt werden.
Wenn Ihr Unternehmen parallel Schulung, Rollenklärung und Management-Sensibilisierung aufbauen muss, sollte das nicht getrennt vom Technikprojekt laufen. Für genau diese organisatorische Seite ist die NIS2 Online-Schulung der passende Anschluss, weil Technik allein die Leitungspflichten und Awareness-Anforderungen nicht erfüllt.
FAQ
Ist SIEM Pflicht unter NIS2?
Ein SIEM ist unter NIS2 nicht als Produktbegriff ausdrücklich vorgeschrieben. Pflichtig ist aber die Fähigkeit zu Sicherheitsmonitoring, Incident Handling und nachvollziehbarer Reaktion gemäß Art. 21 Abs. 2 Richtlinie (EU) 2022/2555. Für viele betroffene KMU ist ein SIEM deshalb die praktisch naheliegende Pflichtumsetzung.
Wie implementiere ich SIEM für NIS2-Compliance?
Sie implementieren SIEM für NIS2-Compliance, indem Sie zuerst Scope und kritische Systeme festlegen, danach relevante Log-Quellen anbinden, konkrete Detection-Use-Cases definieren, Alarm- und Eskalationswege dokumentieren und die Wirksamkeit gegen reale Vorfallabläufe testen. Die Plattform allein erfüllt NIS2 nicht.
Reicht ein Managed Detection and Response Dienst statt SIEM?
Ein MDR-Dienst kann ausreichen, wenn er Ihre kritischen Log-Quellen tatsächlich integriert, Ereignisse korreliert, Alarme qualifiziert und in Ihre Incident-Response-Prozesse eingebunden ist. Reine „Alert-Weiterleitung“ ohne zentrale Nachweis- und Auswertungslogik reicht für NIS2 meist nicht.
Welche Logs sollten KMU zuerst anbinden?
KMU sollten zuerst Identitäts- und Authentifizierungsdaten, Microsoft-365- oder E-Mail-Logs, Firewall- und VPN-Ereignisse, Endpoint-Signale, Admin-Aktivitäten und Backup-relevante Logs anbinden. Diese Quellen liefern meist den höchsten Sicherheits- und Nachweiswert.
Ist ein SIEM auch für kleinere betroffene Unternehmen verhältnismäßig?
Ja, wenn das Betriebsmodell zum Risiko und zur Unternehmensgröße passt. Verhältnismäßigkeit bedeutet unter NIS2 nicht Minimalismus um jeden Preis, sondern angemessene Wirksamkeit. Für kleinere betroffene Unternehmen ist deshalb oft ein fokussiertes Managed SIEM verhältnismäßiger als gar kein zentrales Monitoring.
Was ist der häufigste Fehler bei SIEM-Projekten im Mittelstand?
Der häufigste Fehler ist die Beschaffung einer Plattform ohne klares Betriebsmodell. Wenn unklar bleibt, wer Regeln pflegt, Alarme bewertet, Eskalationen annimmt und Berichte erzeugt, entsteht kein Sicherheitsmonitoring, sondern nur eine neue Datenquelle.
Fazit: NIS2 verlangt belastbares Monitoring, nicht bloß Tool-Einkauf
NIS2 verlangt für den Mittelstand kein magisches Produkt, sondern belastbares Sicherheitsmonitoring mit nachweisbarer Reaktionsfähigkeit. Genau deshalb ist ein SIEM für viele betroffene Unternehmen die richtige Antwort: Es verbindet Logs, Alarme, Korrelation und Dokumentation zu einer Struktur, die Art. 21 und Art. 23 praktisch erfüllbar macht.
Wenn Sie NIS2-Sicherheitsmonitoring nicht nur technisch, sondern organisatorisch sauber aufsetzen wollen, starten Sie mit unserer NIS2 Online-Schulung und ordnen Sie parallel Ihre Prozesse für Monitoring, Vorfallmeldung und Verantwortlichkeit. Ergänzend helfen Ihnen der Leitfaden zu NIS2-Vorfallmeldungen, der Einstieg in den BSI IT-Grundschutz, unser Glossar zu SIEM und der Vergleich zu Compliance-Software im Mittelstand.