NIS2 wird oft als Rechts- oder Compliance-Thema eingeordnet. In der Praxis ist es ebenso ein Führungs-, Betriebs- und Nachweis-Thema. Organisationen stehen nicht nur vor der Frage, welche Richtlinien sie haben sollten, sondern auch davor, was sie im Ernstfall tatsächlich belegen können. Genau hier werden Logging, Aufbewahrung und Nachvollziehbarkeit zu einem zentralen Bestandteil der operativen Resilienz.
Für viele mittelständische Organisationen ist das die eigentliche Herausforderung. Nicht, ob Cybersicherheit wichtig ist, sondern wie aus verstreuten Einzelmaßnahmen ein belastbares Mindestniveau wird. NIS2 erhöht den Druck, weil Governance, Risikomanagement, Meldepflichten und technische Nachweise enger zusammenrücken. Eine Richtlinie beschreibt das Soll. Logs helfen zu zeigen, was im Ist passiert ist.
Dieser Inhalt stellt keine Rechtsberatung dar. Er dient als praktische Orientierung für Geschäftsleitungen, IT-Verantwortliche, Infrastrukturteams, MSPs sowie Rollen aus Informationssicherheit, Risikomanagement und Compliance, die die operativen Folgen von NIS2 verstehen müssen.
Für wen diese Seite gedacht ist
Diese Seite richtet sich vor allem an:
- Geschäftsführungen, Inhaber und Vorstände,
- IT-Leitungen und Infrastrukturverantwortliche,
- externe Administratoren und MSPs,
- Teams aus Informationssicherheit, Risikomanagement und Compliance,
- Organisationen, die unsicher sind, ob sie direkt in den Anwendungsbereich fallen oder über regulierte Kunden betroffen sind.
Was Sie mitnehmen sollten
Nach dem Lesen sollten Sie klarer einschätzen können:
- was NIS2 praktisch verändert,
- welche Organisationen typischerweise betroffen sind,
- warum Dokumentation allein nicht ausreicht,
- warum Logs für Audit, Vorfälle und Nachvollziehbarkeit entscheidend sind,
- welche Log-Quellen zuerst Priorität haben,
- warum lokale Logs bei einer Kompromittierung ein Schwachpunkt sind,
- wann ein zentrales oder SaaS-basiertes Modell sinnvoll ist.
Was NIS2 in der Praxis verändert
NIS2 ist die EU-Richtlinie, mit der das gemeinsame Cybersicherheitsniveau in den Mitgliedstaaten angehoben werden soll. Sie erweitert den Kreis betroffener Sektoren, erhöht die Erwartungen an das Risikomanagement und macht die Verantwortung der Leitungsebene deutlich sichtbarer. Außerdem verschärft sie die Anforderungen an Meldungen signifikanter Sicherheitsvorfälle und an die Fähigkeit, Entscheidungen nachvollziehbar zu begründen.
Entscheidend ist dabei: NIS2 richtet sich nicht nur an einen kleinen Kreis klassischer Kritischer-Infrastrukturen-Betreiber. Betroffen sind deutlich mehr Organisationen, darunter viele mittlere Unternehmen und öffentliche Einrichtungen in relevanten Sektoren. Damit wird Cybersicherheit endgültig zu einem Thema, das nicht allein in der IT verbleiben kann.
Für die Geschäftsleitung ist NIS2 relevant, weil:
- Cyberrisiken aktiv überwacht und priorisiert werden müssen,
- Sicherheitsvorfälle Management-Entscheidungen unter Zeitdruck erzwingen,
- Aufsicht, Kunden und Partner belastbare Nachweise erwarten,
- Reputations- und Betriebsrisiken direkt auf die Unternehmensführung zurückfallen.
Für die IT ist NIS2 relevant, weil:
- Maßnahmen nicht nur definiert, sondern betrieben werden müssen,
- Auditierbarkeit und Nachvollziehbarkeit wichtiger werden,
- Incident-Timelines schnell rekonstruiert werden müssen,
- lokale, uneinheitliche Log-Landschaften unter Prüfung schwer zu verteidigen sind.
Mehr zur Führungsverantwortung finden Sie auf NIS2 für die Geschäftsleitung.
Welche Organisationen typischerweise betroffen sind
NIS2 betrifft Organisationen in Sektoren, die für Wirtschaft, Gesellschaft oder öffentliche Versorgung besonders wichtig sind. Dazu zählen typischerweise Energie, Verkehr, Gesundheitswesen, digitale Infrastruktur, bestimmte digitale Dienste, öffentliche Verwaltung, Wasser, Abwasser, Abfallwirtschaft sowie weitere benannte Bereiche.
In der Praxis entscheidet aber selten ein einzelner Faktor. Maßgeblich ist meist die Kombination aus:
- Art der erbrachten Dienstleistung,
- sektoraler Einordnung,
- Unternehmensgröße,
- Einbindung in eine Unternehmensgruppe,
- operativer Bedeutung innerhalb einer Liefer- oder Leistungskette.
Deshalb ist die Frage "Sind wir KRITIS?" für einen ersten Realitätscheck oft zu grob. Sinnvoller ist die Frage, ob Ihre Organisation eine regulierungsrelevante Leistung erbringt und ob Sektor, Größe und Rolle zusammengenommen auf eine direkte Betroffenheit hindeuten.
Für eine erste Einordnung lesen Sie Fällt Ihre Organisation unter NIS2?.
Unterschiedliche Pflichteniveaus sind kein Detail für Juristen
Nicht jede betroffene Organisation wird mit identischer Intensität beaufsichtigt. Je nach nationaler Umsetzung, Kategorie und Rolle unterscheiden sich Pflichteniveau, Aufsichtsdichte und Nachweiserwartungen. Für ein internationales Publikum ist es sinnvoller, von unterschiedlichen Pflichteniveaus oder Aufsichtsintensitäten zu sprechen als nationale Begriffe unreflektiert zu übernehmen.
Operativ ist das keine Fußnote. Es beeinflusst:
- wie formell Management-Reporting aufgebaut sein muss,
- wie belastbar Prozesse dokumentiert und gelebt werden müssen,
- wie tief die Nachweis- und Aufbewahrungspflichten reichen,
- wie gut sich technische und organisatorische Maßnahmen belegen lassen müssen.
Mehr dazu finden Sie auf Unterschiedliche NIS2-Pflichteniveaus.
Was NIS2 nicht automatisch bedeutet
Viele Organisationen lesen NIS2 entweder zu klein oder zu groß. Beides ist problematisch.
NIS2 bedeutet nicht automatisch:
- dass Sie sofort ein eigenes SOC aufbauen müssen,
- dass ohne großes SIEM kein sinnvoller Start möglich ist,
- dass ein Paket aus Richtlinien bereits ausreicht,
- dass lokale Event Logs und Geräte-Syslog eine ausreichende Beweisgrundlage darstellen,
- dass Verantwortung einfach auf MSPs oder Outsourcing-Partner verlagert werden kann.
Für viele Organisationen ist ein belastbares Minimum wertvoller als ein ambitioniertes Zielbild, das operativ nie stabil wird. Es geht nicht darum, alles zu sammeln oder jede Sicherheitsfunktion gleichzeitig einzuführen. Es geht darum, ein verteidigbares Minimum an Nachvollziehbarkeit, Vorfallsbereitschaft und Audit-Unterstützung zu schaffen.
Warum Dokumentation allein nicht ausreicht
Dokumentation ist notwendig. Rollen, Prozesse, Risikobewertungen und Incident-Abläufe müssen definiert sein. Aber sie beantworten nicht die Fragen, die in einer Prüfung oder nach einem Vorfall tatsächlich gestellt werden:
- Wer hatte Zugriff auf das betroffene System?
- Wann begann die auffällige Aktivität?
- Welche Änderungen gingen dem Vorfall voraus?
- Welche Accounts und Systeme waren beteiligt?
- Worauf stützt sich die Bewertung des Vorfalls?
- Was kann die Organisation rückwirkend belegen?
Ohne technische Nachweise wird aus Incident Response schnell eine Mischung aus Vermutungen, Screenshots und manueller Rekonstruktion. Das ist weder für die IT noch für die Geschäftsleitung eine belastbare Position.
Warum Logs für Audit, Vorfälle und Nachvollziehbarkeit entscheidend sind
Logs sind kein technisches Nebenprodukt. Sie sind Rohmaterial für Nachweise.
Für Audits
Auditoren und Aufsichtsstellen wollen nicht nur hören, dass Kontrollen existieren. Sie erwarten, dass relevante Aktivitäten nachvollzogen werden können:
- Anmeldeversuche,
- Rechteänderungen,
- administrative Eingriffe,
- Konfigurationsänderungen,
- sicherheitsrelevante Ereignisse über einen Zeitraum hinweg.
Ohne diese Nachweise existieren Maßnahmen nur auf dem Papier.
Für Incident Response
Wenn ein Vorfall erkannt wird, zählt Zeit. Teams müssen innerhalb kurzer Fristen verstehen:
- was passiert ist,
- wann es begonnen hat,
- welche Systeme betroffen sind,
- welche Identitäten beteiligt waren,
- ob der Vorfall noch andauert.
Wenn relevante Daten nur lokal auf den kompromittierten Systemen liegen, wird diese Rekonstruktion deutlich fragiler.
Für interne Untersuchungen
Nicht jeder relevante Fall ist sofort ein meldepflichtiger Sicherheitsvorfall. Häufig geht es um:
- ungewöhnliche Logins,
- nicht zuordenbare Konfigurationsänderungen,
- administrative Fehler,
- Hinweise auf missbrauchte Konten,
- Fragen an externe Dienstleister oder interne Teams.
Logs helfen, Vermutungen von belegbaren Fakten zu trennen.
Für regulatorische Verteidigbarkeit
NIS2 erhöht den Druck auf zeitnahe Bewertung und Meldung signifikanter Vorfälle. Eine Organisation braucht in kurzer Zeit kein perfektes Gesamtbild, aber sie braucht eine glaubwürdige Datenbasis für erste Entscheidungen. Zentral aufbewahrte Logs verbessern diese Position erheblich.
Welche Log-Quellen zuerst zählen
Ein brauchbares Logging-Minimum beginnt selten mit "alles sammeln". Es beginnt mit einigen evidenzstarken Quellen.
Identität und Zugriff
Active Directory, Entra ID und andere IAM-Systeme gehören fast immer zu den wichtigsten Quellen. Ohne Nachweise zu Authentifizierung, Rechteänderungen und administrativen Aktionen werden viele Ermittlungswege schwach.
Zentrale Windows-Server und ausgewählte Endpunkte
Nicht jeder Client muss sofort Teil der ersten Welle sein. Aber Domain Controller, Jump Hosts, Administrationsarbeitsplätze und kritische Server in der Regel schon.
Firewalls, VPN und Netzwerkkontrollen
Externe Zugriffe, Fernadministration und Netzwerkbewegungen sind für Audit und Incident Response meist zentral.
Hypervisor, Storage und Infrastruktur-Appliances
Virtualisierung und Storage werden in der Praxis oft zu spät berücksichtigt, obwohl genau dort hochrelevante Spuren liegen.
Cloud- und SaaS-Systeme
Viele kritische Prozesse laufen heute teilweise oder vollständig in Microsoft 365, Google Workspace, Cloud-Plattformen oder geschäftskritischen SaaS-Diensten. Wer diese Ebene ignoriert, baut eine blinde Stelle in die Nachweiskette ein.
Die Priorisierung ist ausführlich beschrieben in Welche Logs Sie für Audit und NIS2 brauchen.
Wie ein realistisches Minimum aussieht
Für viele kleine und mittlere Organisationen ist nicht das Maximalmodell entscheidend, sondern ein belastbares Minimum. Typischerweise umfasst es:
- zentrale Sammlung außerhalb der Quellsysteme,
- Abdeckung von Identität, Kernservern, Firewalls, VPN und ausgewählten Cloud-Diensten,
- Aufbewahrung passend zu Audit- und Incident-Anforderungen,
- regelmäßige Prüfung, ob die Log-Zufuhr tatsächlich funktioniert,
- die Fähigkeit, relevante Ereignisse im Ernstfall schnell zu finden.
Das ist kein Verzicht auf Reife. Es ist ein operativ tragfähiger Startpunkt. Erst darauf lohnt es sich, später mehr Quellen, Korrelationen, Alarmierung oder tiefere Analyse aufzubauen.
Warum lokale Logs ein Schwachpunkt sind
Das ist einer der wichtigsten Punkte im gesamten Thema. Logs, die ausschließlich lokal auf Servern, Appliances oder in Anwendungen liegen, sind im Kompromittierungsfall ein offensichtlicher Schwachpunkt.
Angreifer versuchen häufig:
- lokale Spuren zu verändern,
- Logs zu löschen,
- Historie durch normales Überschreiben verschwinden zu lassen,
- Logging zu reduzieren oder zu deaktivieren,
- betroffene Systeme unzugänglich zu machen.
Eine Beweisspur außerhalb des kompromittierten Systems senkt das Risiko erheblich, dass genau die wichtigsten Nachweise im entscheidenden Moment verloren gehen. Zentraler Log-Empfang und zentrale Aufbewahrung außerhalb der Quellsysteme sind daher keine Komfortfunktion, sondern ein praktischer Schutz für Audit, Untersuchung und regulatorische Verteidigung.
Mehr dazu lesen Sie auf Audit, Nachvollziehbarkeit und Nachweise.
Wann ein zentrales oder SaaS-Modell sinnvoll ist
Ein selbst betriebener Logging- oder Analytics-Stack kann sinnvoll sein, wenn Organisation und Team genug Kapazität dafür haben. Für viele mittelständische Unternehmen ist aber zunächst etwas anderes wichtiger:
- schnell eine belastbare Aufbewahrung aufbauen,
- Nachweise außerhalb der Quellsysteme sichern,
- internen Betriebsaufwand begrenzen,
- keine übergroße SIEM- oder SOC-Initiative starten, bevor das Minimum steht.
Ein zentrales oder SaaS-basiertes Modell ist dann sinnvoll, wenn die Organisation rasch ein defensibles Fundament für Audit, Vorfälle und Nachvollziehbarkeit braucht, ohne eine große Plattform selbst betreiben zu wollen. Das ist kein Produktversprechen, sondern eine pragmatische Beobachtung.
Gerade für mittelständische Organisationen ist dabei auch die Betriebsrealität entscheidend. Ein Logging-Konzept ist nur dann hilfreich, wenn es im Alltag nicht an Personal, Zeit oder Spezialwissen scheitert. Viele Teams brauchen keine möglichst komplexe Sicherheitsplattform, sondern eine Lösung, mit der sie drei Dinge verlässlich leisten können: wichtige Quellen anbinden, Evidenz außerhalb der Quellsysteme aufbewahren und im Ernstfall schnell verwertbare Informationen finden. Dieser pragmatische Blick schützt davor, das Zielbild mit dem ersten sinnvollen Schritt zu verwechseln.
Ein belastbares Minimum ist außerdem nicht nur eine Frage der Technik, sondern auch der Governance. Die Organisation sollte wissen, wer den Status der wichtigsten Quellen prüft, wer Lücken eskaliert und wie regelmäßig die Abrufbarkeit zentral gespeicherter Evidenz getestet wird. Genau diese operative Disziplin macht oft den Unterschied zwischen einem theoretisch vorhandenen Logging-Konzept und einer tatsächlich nutzbaren Nachweisbasis.
Offizielle Quellen und weitere Lektüre
Wenn Sie Pflichten und Reichweite bewerten, sollten Sie sich auf Primärquellen und offizielle Leitlinien stützen.
Sinnvolle Ausgangspunkte sind:
- der Richtlinientext von NIS2 auf EUR-Lex,
- offizielle Informationen und FAQ der Europäischen Kommission,
- nationale Leitlinien der zuständigen Aufsichts- oder Sicherheitsbehörden,
- länderspezifische Hilfsmittel zur Einordnung von Betroffenheit und Pflichten.
Innerhalb dieses Hubs helfen vor allem diese Seiten weiter:
- Fällt Ihre Organisation unter NIS2?
- Unterschiedliche NIS2-Pflichteniveaus
- NIS2 für die Geschäftsleitung
- Audit, Nachvollziehbarkeit und Nachweise
- Welche Logs Sie für Audit und NIS2 brauchen
FAQ
Müssen wir Logs aus jedem System sammeln?
Nein. Für die meisten Organisationen ist klare Priorisierung wertvoller als wahlloses Sammeln. Starten Sie mit Identitäten, kritischen Servern, Firewalls, VPN, ausgewählten Cloud-Diensten und weiteren evidenzstarken Quellen.
Bedeutet NIS2, dass wir sofort ein SIEM brauchen?
Nicht zwingend. Sie brauchen Nachweise, Nachvollziehbarkeit und nutzbare Aufbewahrung. Für manche Organisationen führt das später zu einem SIEM. Für viele ist zentrale Sammlung und Retention der richtige erste Schritt.
Reichen lokale Logs, wenn wir sie lange genug aufbewahren?
Nein. Lange Retention auf einem kompromittierten System löst das Grundproblem nicht. Die Daten bleiben anfällig für Manipulation, Löschung oder Nichtverfügbarkeit.
Ist das nur relevant, wenn wir sicher wissen, dass wir direkt betroffen sind?
Nein. Dieselben Prinzipien sind auch für Lieferanten regulierter Organisationen und für Unternehmen relevant, die gerade erst ihre erste interne Einschätzung vornehmen.
Gibt es unter NIS2 eine einheitliche Aufbewahrungsfrist für Logs?
Nein. Die passende Retention hängt von Audit-Anforderungen, Incident-Bedarf, Risikoprofil und operativer Realität ab. Entscheidend ist, dass die Frist begründbar ist und die Daten in diesem Zeitraum tatsächlich nutzbar bleiben.
Was ist für viele mittelständische Organisationen der häufigste Fehlstart?
Mit zu großem Ehrgeiz zu beginnen. Wenn zuerst ein komplexes Zielbild geplant wird, aber Verantwortlichkeiten, priorisierte Quellen und zentrale Aufbewahrung fehlen, entsteht schnell viel Aufwand mit wenig belastbarer Evidenz.
Nächster Schritt
Wenn Sie daraus einen konkreten Startpunkt machen wollen:
- Checkliste herunterladen für die erste interne Einordnung von NIS2-Relevanz und Logging-Reife.
- Erste Orientierungskonsultation anfragen zur Frage, wie ein realistisches Evidenz-Minimum in Ihrer Umgebung aussehen sollte.
- Für Early Access / Updates anmelden zum minimalen Logging-Standard für Audit, Incident Response und Nachvollziehbarkeit.