Firewalls sind konfiguriert, Mehrfaktor-Authentifizierung ist aktiviert, Backups laufen, Server werden überwacht und Mitarbeitende regelmäßig geschult.

Damit ist doch alles erledigt – oder?

Nicht ganz.

Spätestens bei einer internen Prüfung, einem externen Audit oder einer behördlichen Überprüfung stellt sich eine weitere entscheidende Frage:

Können wir nachweisen, dass wir das alles tatsächlich und systematisch tun?

Genau an diesem Punkt kommt die Dokumentation ins Spiel.

NIS-2-Sicherheit besteht nicht nur daraus, technische und organisatorische Maßnahmen einzuführen. Sicherheitsmaßnahmen müssen in ein nachvollziehbares Risikomanagement eingebettet, Verantwortlichkeiten festgelegt und Prozesse so organisiert werden, dass ihre Umsetzung und Wirksamkeit nachvollzogen werden können.

Eine gute Dokumentation beantwortet deshalb nicht nur die Frage:

„Was haben wir eingerichtet?“

Sie beantwortet auch:

„Warum haben wir es eingerichtet, wer ist dafür verantwortlich, wie wird es betrieben, wann wurde es überprüft und wo befindet sich der Nachweis?“

In diesem Teil unserer NIS-2-Serie schauen wir uns an, wie eine auditfähige Dokumentationsstruktur aufgebaut werden kann.

Warum Dokumentation so wichtig ist

Informationssicherheit findet auf mehreren Ebenen statt.

Eine Organisation könnte beispielsweise technisch hervorragend abgesichert sein:

Firewall
MFA
EDR
SIEM
Backups
Netzwerksegmentierung
Schwachstellenscanner
Patchmanagement

Wenn aber niemand dokumentiert hat, wie diese Maßnahmen organisiert und kontrolliert werden, entsteht spätestens bei einer Prüfung ein Problem.

Ein Auditor könnte beispielsweise fragen:

• Welche Systeme werden durch MFA geschützt?
• Wer überprüft die Firewall-Regeln?
• Wie häufig werden Schwachstellenscans durchgeführt?
• Wer bewertet gefundene Schwachstellen?
• Welche Fristen gelten für kritische Sicherheitsupdates?
• Wann wurde der letzte Restore-Test durchgeführt?
• Wer darf administrative Konten anlegen?
• Wann wurde der Notfallplan zuletzt getestet?
• Wie werden Sicherheitsvorfälle eskaliert?
• Wann wurden Mitarbeitende zuletzt geschult?

Darauf sollte eine Organisation nicht mit

„Das müsste eigentlich der Kollege aus der IT wissen.“

antworten müssen.

Stattdessen sollte es definierte Dokumente und Nachweise geben.

Die Dokumentationspyramide

Eine praktische Sicherheitsdokumentation lässt sich in mehrere Ebenen aufteilen.

Beispielsweise:

                Sicherheitskonzept
                       │
                       ▼
                  Richtlinien
                       │
                       ▼
                   Prozesse
                       │
                       ▼
              Betriebsdokumentation
                       │
                       ▼
                   Nachweise

Diese Ebenen erfüllen unterschiedliche Aufgaben.

Das Sicherheitskonzept beschreibt den grundsätzlichen Rahmen.

Richtlinien definieren verbindliche Regeln.

Prozesse beschreiben wiederkehrende Abläufe.

Die Betriebsdokumentation beschreibt die konkrete technische Umsetzung.

Nachweise belegen schließlich, dass diese Vorgaben tatsächlich umgesetzt werden.

Schauen wir uns diese Ebenen genauer an.

1. Das Sicherheitskonzept

Das Sicherheitskonzept bildet einen zentralen Rahmen der Sicherheitsdokumentation.

Es sollte die Sicherheitsarchitektur einer Organisation verständlich beschreiben und unter anderem Antworten auf folgende Fragen liefern:

• Welche Infrastruktur wird betrieben?
• Welche wesentlichen Geschäfts- oder Verwaltungsprozesse existieren?
• Welche kritischen Systeme werden eingesetzt?
• Welche Schutzbedarfe bestehen?
• Welche wesentlichen Risiken wurden identifiziert?
• Welche Sicherheitsmaßnahmen wurden daraus abgeleitet?
• Welche organisatorischen Verantwortlichkeiten bestehen?
• Wie werden Sicherheitsvorfälle behandelt?
• Wie wird die Aufrechterhaltung des Betriebs sichergestellt?

Ein mögliches Inhaltsverzeichnis könnte folgendermaßen aussehen:

1. Zweck und Zielsetzung

2. Geltungsbereich

3. Organisation
   3.1 Verantwortlichkeiten
   3.2 Informationssicherheitsorganisation
   3.3 Rollen

4. Infrastruktur
   4.1 Standorte
   4.2 Netzwerke
   4.3 Server
   4.4 Clients
   4.5 Cloud-Dienste

5. Schutzbedarfsfeststellung

6. Risikoanalyse

7. Sicherheitsmaßnahmen
   7.1 Identitätsmanagement
   7.2 Netzwerksicherheit
   7.3 Endpoint Security
   7.4 Backup
   7.5 Monitoring
   7.6 Schwachstellenmanagement

8. Incident Response

9. Business Continuity

10. Überprüfung und Verbesserung

Das Sicherheitskonzept sollte dabei nicht zu einem statischen Dokument werden, das einmal erstellt und anschließend jahrelang nicht mehr angefasst wird.

Die IT verändert sich permanent.

Neue Server kommen hinzu, Anwendungen werden ersetzt, Cloud-Dienste eingeführt und Netzwerkstrukturen verändert.

Das Sicherheitskonzept muss deshalb regelmäßig überprüft und aktualisiert werden.

2. Richtlinien

Während das Sicherheitskonzept den Rahmen beschreibt, legen Richtlinien verbindliche Regeln fest.

Eine Richtlinie könnte beispielsweise bestimmen:

Administrative Zugänge müssen mit Mehrfaktor-Authentifizierung geschützt werden.

Eine andere Richtlinie könnte vorgeben:

Kritische Sicherheitsupdates sind nach Bewertung innerhalb einer festgelegten Frist einzuspielen.

Typische Sicherheitsrichtlinien können beispielsweise sein:

• Informationssicherheitsrichtlinie
• Passwortrichtlinie
• Berechtigungsrichtlinie
• Patchmanagement-Richtlinie
• Backup-Richtlinie
• Mobile-Device-Richtlinie
• Homeoffice-Richtlinie
• Logging-Richtlinie
• Incident-Response-Richtlinie
• Richtlinie für externe Dienstleister
• Cloud-Richtlinie
• Verschlüsselungsrichtlinie
• Richtlinie zur Softwareinstallation
• Acceptable-Use-Richtlinie

Dabei gilt:

Eine Richtlinie sollte tatsächlich verbindlich sein.

Eine Sammlung unverbindlicher Empfehlungen erfüllt einen anderen Zweck.

Was gehört in eine Richtlinie?

Eine einheitliche Struktur erleichtert die Verwaltung erheblich.

Beispielsweise:

Dokument:
Patchmanagement-Richtlinie

Dokument-ID:
IS-RL-004

Version:
2.1

Verantwortlich:
Informationssicherheitsbeauftragter

Freigabe:
Geschäftsleitung

Gültig ab:
01.09.2026

Nächste Überprüfung:
01.09.2027

Geltungsbereich:
gesamte Organisation

Danach folgt der eigentliche Inhalt:

1. Ziel
2. Geltungsbereich
3. Begriffe
4. Verantwortlichkeiten
5. Vorgaben
6. Ausnahmen
7. Kontrollen
8. Dokumentation
9. Inkrafttreten

Damit erhält jedes Dokument eine nachvollziehbare Struktur.

3. Prozesse

Eine Richtlinie sagt, was getan werden muss.

Ein Prozess beschreibt, wie es getan wird.

Beispiel:

Die Patchmanagement-Richtlinie fordert:

Kritische Sicherheitsupdates müssen zeitnah bewertet und installiert werden.

Der dazugehörige Prozess beschreibt anschließend:

Hersteller veröffentlicht Update
        │
        ▼
Schwachstelle bewerten
        │
        ▼
Priorität festlegen
        │
        ▼
Update testen
        │
        ▼
Freigabe
        │
        ▼
Installation
        │
        ▼
Funktionskontrolle
        │
        ▼
Dokumentation

Damit wird aus einer abstrakten Vorgabe ein reproduzierbarer Arbeitsablauf.

Prozesse brauchen Verantwortlichkeiten

Ein häufiger Fehler besteht darin, Prozesse zwar zu beschreiben, aber niemandem eindeutig zuzuordnen.

Deshalb sollte für jeden wichtigen Prozess geklärt sein:

Wer startet den Prozess?

Wer führt ihn durch?

Wer entscheidet?

Wer muss informiert werden?

Wer kontrolliert das Ergebnis?

Wer dokumentiert den Abschluss?

Hilfreich kann dabei beispielsweise ein RACI-Modell sein.

Die Rollen werden typischerweise unterschieden in:

R = Responsible
A = Accountable
C = Consulted
I = Informed

Damit lässt sich insbesondere bei organisationsübergreifenden Prozessen verhindern, dass Verantwortlichkeiten zwischen IT, Informationssicherheit, Fachbereichen, Datenschutz und externen Dienstleistern verloren gehen.

4. Betriebsdokumentation

Nun kommen wir zur technischen Ebene.

Die Betriebsdokumentation beschreibt, wie Systeme tatsächlich betrieben werden.

Für einen Server könnten beispielsweise dokumentiert werden:

Hostname
IP-Adresse
Betriebssystem
Standort
Virtualisierung
Verantwortlicher
Anwendung
Schutzbedarf
Backup
Monitoring
Patchverfahren
Administrationszugang
Abhängigkeiten
Wiederherstellungsverfahren

Auch Konfigurationen gehören zur Betriebsdokumentation.

Beispielsweise:

Firewall-Regeln
VLAN-Strukturen
VPN-Konfigurationen
Backup-Jobs
Monitoring-Regeln
SIEM-Anbindungen
Administrationswege
Authentifizierungsverfahren

Wichtig ist allerdings eine vernünftige Balance.

Eine Betriebsdokumentation muss nicht jeden einzelnen Mausklick erklären.

Sie sollte aber ausreichend Informationen enthalten, damit qualifizierte Personen das System nachvollziehen, betreiben und im Notfall wiederherstellen können.

Wissen darf nicht nur in Köpfen existieren

Ein klassisches IT-Risiko lautet:

„Das weiß nur Peter.“

Problematisch wird es spätestens, wenn Peter:

• Urlaub hat,
• krank ist,
• das Unternehmen verlässt,
• nicht erreichbar ist.

Kritisches Betriebswissen sollte deshalb dokumentiert werden.

Besonders wichtig sind beispielsweise:

Administrationszugänge
Wiederherstellungsverfahren
Backup-Systeme
Netzwerkarchitektur
Notfallzugänge
Abhängigkeiten
Dienstleisterkontakte
Eskalationswege

Natürlich gehören Passwörter nicht im Klartext in die Betriebsdokumentation.

Stattdessen kann dort beispielsweise stehen:

Administrativer Zugang:

Zugangsdaten befinden sich im zentralen Passwortmanager.

Tresor:
IT-Infrastruktur

Collection:
Firewall

Damit bleibt dokumentiert, wo die Zugangsdaten kontrolliert verfügbar sind, ohne sie in verschiedenen Dokumenten zu vervielfältigen.

5. Nachweise – aus Behauptungen werden Belege

Nun kommen wir zu einem der wichtigsten Bereiche für Audits.

Ein Dokument sagt:

„Wir führen regelmäßig Restore-Tests durch.“

Ein Auditor könnte daraufhin fragen:

„Wann wurde der letzte Restore-Test durchgeführt?“

Jetzt wird ein Nachweis benötigt.

Ein Restore-Test-Protokoll könnte beispielsweise enthalten:

Test:
Restore Fileserver

Datum:
12.08.2026

Backup:
11.08.2026 – 23:00 Uhr

Verantwortlich:
IT-Betrieb

Wiederhergestellt:
Testverzeichnis / Test-VM

Ergebnis:
erfolgreich

Dauer:
47 Minuten

Abweichungen:
keine

Freigabe:
13.08.2026

Damit wird aus einer Aussage ein überprüfbarer Vorgang.

Typische Nachweise

Im NIS-2-Umfeld können zahlreiche Nachweise relevant sein.

Beispiele:

• Schulungsnachweise
• Patchberichte
• Schwachstellenscans
• Restore-Testprotokolle
• Backup-Berichte
• Firewall-Reviews
• Berechtigungsprüfungen
• MFA-Auswertungen
• Incident-Protokolle
• Penetrationstest-Berichte
• Notfallübungen
• Protokolle von Risikoanalysen
• Managementbewertungen
• Dienstleisterbewertungen
• Asset-Prüfungen
• Änderungsprotokolle

Dabei sollte nicht wahllos alles gespeichert werden.

Entscheidend ist eine strukturierte Zuordnung.

Von der Anforderung zum Nachweis

Eine besonders leistungsfähige Dokumentationsstruktur entsteht, wenn Anforderungen, Maßnahmen und Nachweise miteinander verknüpft werden.

Beispielsweise:

Risiko
│
▼
Unbefugter administrativer Zugriff
│
▼
Maßnahme
MFA für Administrationskonten
│
▼
Richtlinie
Berechtigungsrichtlinie
│
▼
Prozess
Benutzer- und Berechtigungsmanagement
│
▼
Technische Umsetzung
MFA am zentralen Administrationszugang
│
▼
Nachweis
regelmäßige Berechtigungsprüfung

Damit entsteht eine nachvollziehbare Kette:

Risiko → Maßnahme → Vorgabe → Umsetzung → Kontrolle → Nachweis

Genau diese Nachvollziehbarkeit ist für ein funktionierendes Informationssicherheitsmanagement besonders wertvoll.

6. Der Auditordner

Ein Audit sollte nicht damit beginnen, dass fünf Mitarbeitende hektisch Dokumente aus verschiedenen Netzlaufwerken zusammensuchen.

Deshalb empfiehlt sich eine vorbereitete Auditstruktur.

Das kann ein geschütztes Verzeichnis, ein Dokumentenmanagementsystem oder eine andere kontrollierte Plattform sein.

Eine mögliche Struktur:

NIS2-Audit/
│
├── 01_Organisation/
│
├── 02_Risikoanalyse/
│
├── 03_Sicherheitskonzept/
│
├── 04_Richtlinien/
│
├── 05_Asset-Management/
│
├── 06_Berechtigungen/
│
├── 07_Patchmanagement/
│
├── 08_Schwachstellen/
│
├── 09_Backup/
│
├── 10_Logging_Monitoring/
│
├── 11_Incident_Response/
│
├── 12_Business_Continuity/
│
├── 13_Lieferanten/
│
├── 14_Schulungen/
│
├── 15_Prüfungen/
│
└── 16_Nachweise/

Innerhalb der Bereiche können weitere Unterordner entstehen.

Zum Beispiel:

09_Backup/
│
├── Richtlinie/
├── Konzept/
├── Restore-Tests/
├── Monatsberichte/
└── Abweichungen/

Dadurch lassen sich benötigte Informationen wesentlich schneller finden.

Der Auditordner ist keine Müllhalde

Ein verbreitetes Problem entsteht, wenn einfach sämtliche vorhandenen Dateien in einen Auditordner kopiert werden.

Dann findet man irgendwann:

Backup-Konzept.docx
Backup-Konzept-neu.docx
Backup-Konzept-neu2.docx
Backup-Konzept-final.docx
Backup-Konzept-final-neu.docx
Backup-Konzept-final-neu-WIRKLICH.docx

Spätestens dann stellt sich eine unangenehme Frage:

Welche Version gilt eigentlich?

Damit kommen wir zum nächsten wichtigen Thema.

7. Versionsverwaltung

Sicherheitsdokumente verändern sich.

Deshalb muss nachvollziehbar sein:

• Welche Version ist aktuell?
• Wer hat sie erstellt?
• Wer hat sie geändert?
• Was wurde geändert?
• Wer hat sie freigegeben?
• Wann trat sie in Kraft?
• Welche Version galt zu einem bestimmten Zeitpunkt?

Ein Dokument könnte beispielsweise folgende Historie enthalten:

Version 1.0
01.02.2026
Erstfassung

Version 1.1
15.03.2026
MFA-Anforderungen ergänzt

Version 2.0
01.07.2026
Rollenmodell überarbeitet

Zusätzlich sollte eindeutig erkennbar sein:

Status:
Freigegeben

Version:
2.0

Gültig seit:
01.07.2026

Alte Versionen nicht einfach löschen

Alte Versionen können für die Nachvollziehbarkeit wichtig sein.

Bei einem Sicherheitsvorfall könnte beispielsweise gefragt werden:

Welche Richtlinie galt zum Zeitpunkt des Vorfalls?

Deshalb sollte die Dokumentenverwaltung zwischen

Aktuell

und

Archiv

unterscheiden.

Beispielsweise:

Richtlinien/
│
├── Aktuell/
│   └── Patchmanagement-Richtlinie_v2.0.pdf
│
└── Archiv/
    ├── Patchmanagement-Richtlinie_v1.0.pdf
    └── Patchmanagement-Richtlinie_v1.1.pdf

Dabei sollten natürlich auch die jeweiligen Aufbewahrungsanforderungen berücksichtigt werden.

Dokumente regelmäßig überprüfen

Ein Sicherheitsdokument sollte nicht unbegrenzt gültig bleiben.

Deshalb empfiehlt sich für wichtige Dokumente ein Review-Datum.

Beispielsweise:

Dokument:
Backup-Richtlinie

Version:
3.0

Freigegeben:
01.06.2026

Nächster Review:
01.06.2027

Noch besser ist ein dokumentierter Review-Prozess.

Dabei wird regelmäßig geprüft:

Ist das Dokument noch aktuell?

Haben sich Systeme geändert?

Haben sich Verantwortlichkeiten geändert?

Gab es Sicherheitsvorfälle?

Gab es neue Risiken?

Haben sich gesetzliche Anforderungen geändert?

Müssen technische Maßnahmen angepasst werden?

Selbst wenn keine Änderung notwendig ist, sollte die Überprüfung nachvollziehbar dokumentiert werden.

Dokumentation automatisieren

Nicht jeder Nachweis muss manuell als PDF erstellt werden.

Viele Systeme erzeugen bereits wertvolle Nachweise.

Beispiele:

Wazuh
→ Sicherheitsereignisse

OpenVAS
→ Schwachstellenberichte

NetBox
→ Asset-Dokumentation

Graylog
→ Logdaten

Grafana
→ Monitoring-Auswertungen

Backup-System
→ Jobberichte

Ticketsystem
→ Bearbeitung von Sicherheitsmaßnahmen

Solche Informationen können Teil einer Nachweisstrategie werden.

Automatisch erzeugte Daten haben einen weiteren Vorteil:

Sie reduzieren manuellen Dokumentationsaufwand.

Statt jeden Monat ein Dokument mit dem Titel

Server wurden geprüft.

zu erstellen, können vorhandene technische Daten als Beleg genutzt werden.

Ticketsysteme als Nachweisquelle

Auch ein Ticketsystem kann für Audits sehr wertvoll sein.

Beispielsweise:

OpenVAS
   │
   ▼
kritische Schwachstelle
   │
   ▼
Ticket #SEC-2026-0142
   │
   ├── Bewertung
   ├── Verantwortlicher
   ├── Priorität
   ├── Maßnahmen
   ├── Frist
   └── Abschluss

Damit lässt sich später nachvollziehen:

• wann eine Schwachstelle erkannt wurde,
• wann sie bewertet wurde,
• wer verantwortlich war,
• welche Maßnahme durchgeführt wurde,
• wann die Schwachstelle geschlossen wurde.

Das ist wesentlich aussagekräftiger als ein Schwachstellenscan, der irgendwo als PDF abgelegt wurde.

Ausnahmen dokumentieren

Nicht jede Sicherheitsanforderung lässt sich sofort umsetzen.

Vielleicht unterstützt ein wichtiges Altsystem keine MFA.

Vielleicht kann eine kritische Anwendung kurzfristig nicht aktualisiert werden.

Die schlechteste Lösung wäre:

Das Problem einfach zu ignorieren.

Besser ist ein dokumentierter Ausnahmeprozess.

Beispielsweise:

Abweichung:
Legacy-System unterstützt keine MFA

Risiko:
erhöhtes Risiko unbefugter Zugriffe

Begründung:
Hersteller unterstützt MFA nicht

Kompensierende Maßnahmen:
Zugriff nur über Management-Netz
Firewall-Beschränkung
individuelle Administrationskonten
verstärktes Logging

Verantwortlich:
IT-Leitung

Freigabe:
Geschäftsleitung

Gültig bis:
31.12.2026

Maßnahme:
Migration auf neues System

Damit verschwindet das Risiko nicht.

Aber die Organisation zeigt, dass es erkannt, bewertet und behandelt wurde.

Dokumentation schützen

Die NIS-2-Dokumentation selbst enthält hochsensible Informationen.

Ein Sicherheitskonzept kann beispielsweise verraten:

• welche Server existieren,
• welche Netzwerksegmente vorhanden sind,
• welche Systeme kritisch sind,
• welche Sicherheitsprodukte eingesetzt werden,
• wie Backups funktionieren,
• welche Dienstleister Zugriff besitzen,
• wo Schwachstellen bestehen.

Für einen Angreifer wäre eine vollständige Sicherheitsdokumentation deshalb äußerst interessant.

Daher benötigt auch die Dokumentationsplattform:

• Zugriffsschutz
• Rollen und Berechtigungen
• MFA
• Backup
• Verschlüsselung
• Protokollierung
• Versionsverwaltung
• Wiederherstellungsmöglichkeiten

Ein Auditordner sollte keinesfalls als allgemein zugängliches Netzlaufwerk betrieben werden.

Dokumentation muss zur Realität passen

Der vielleicht wichtigste Grundsatz lautet:

Dokumentiert werden sollte nicht die gewünschte Welt, sondern die tatsächliche Welt.

Eine Richtlinie, die behauptet:

„Alle administrativen Zugriffe sind mit MFA geschützt.“

ist problematisch, wenn tatsächlich 30 Prozent der Systeme keine MFA verwenden.

Besser wäre eine ehrliche Dokumentation:

Ziel:
100 % MFA

Aktueller Stand:
87 %

Ausnahmen:
6 Legacy-Systeme

Kompensierende Maßnahmen:
vorhanden

Migration:
bis Q4/2026 geplant

Damit wird ein bestehendes Defizit transparent behandelt.

Auditfähigkeit als kontinuierlicher Prozess

Dokumentation sollte nicht erst zwei Wochen vor einem Audit beginnen.

Besser ist ein kontinuierlicher Kreislauf:

Risiko erkennen
      │
      ▼
Maßnahme definieren
      │
      ▼
Maßnahme umsetzen
      │
      ▼
Umsetzung dokumentieren
      │
      ▼
Wirksamkeit prüfen
      │
      ▼
Nachweis erzeugen
      │
      ▼
Verbesserung
      │
      └──────────────► Risiko neu bewerten

Damit wird Dokumentation Bestandteil des Sicherheitsmanagements und nicht zu einer hektischen Zusatzaufgabe vor einer Prüfung.

Eine praktische NIS-2-Dokumentationsstruktur

Wer bei null beginnt, muss nicht sofort hunderte Dokumente erstellen.

Eine sinnvolle Grundstruktur könnte beispielsweise aus folgenden Elementen bestehen:

01 – Informationssicherheitsleitlinie

02 – Sicherheitsorganisation

03 – Asset-Inventar

04 – Schutzbedarfsfeststellung

05 – Risikoanalyse

06 – Sicherheitskonzept

07 – Sicherheitsrichtlinien

08 – Betriebsdokumentation

09 – Incident-Response-Plan

10 – Business-Continuity-Plan

11 – Backup- und Recovery-Konzept

12 – Lieferantenmanagement

13 – Schulungskonzept

14 – Prüf- und Kontrollplan

15 – Nachweise

16 – Abweichungen und Maßnahmen

17 – Dokumenten- und Versionsverwaltung

Diese Struktur kann anschließend schrittweise erweitert werden.

Der schnelle Audit-Check

Vor einer Prüfung sollte für jede wesentliche Sicherheitsmaßnahme mindestens beantwortet werden können:

WARUM?
Welches Risiko wird behandelt?

WAS?
Welche Maßnahme wurde festgelegt?

WER?
Wer ist verantwortlich?

WIE?
Wie wird die Maßnahme umgesetzt?

WANN?
Wie häufig wird sie durchgeführt?

WO?
Wo ist sie dokumentiert?

NACHWEIS?
Wie belegen wir die Umsetzung?

KONTROLLE?
Wie prüfen wir die Wirksamkeit?

Wer diese Fragen zuverlässig beantworten kann, verfügt bereits über eine sehr gute Grundlage für eine nachvollziehbare Sicherheitsorganisation.

Bei NIS-2 reicht es nicht, Sicherheitsprodukte zu installieren und darauf zu vertrauen, dass damit alles erledigt ist.

Eine belastbare Sicherheitsorganisation benötigt eine nachvollziehbare Verbindung zwischen:

Risiken, Vorgaben, Prozessen, technischen Maßnahmen, Verantwortlichkeiten, Kontrollen und Nachweisen.

Das Sicherheitskonzept beschreibt den Rahmen.

Richtlinien definieren verbindliche Vorgaben.

Prozesse erklären die konkrete Durchführung.

Die Betriebsdokumentation beschreibt die technische Realität.

Nachweise zeigen, dass die vorgesehenen Maßnahmen tatsächlich durchgeführt werden.

Ein strukturierter Auditordner macht diese Informationen schnell verfügbar.

Und eine saubere Versionsverwaltung stellt sicher, dass jederzeit nachvollzogen werden kann, welches Dokument wann gültig war.

Das Ziel sollte deshalb nicht lauten:

„Wir müssen Dokumente für das Audit erstellen.“

Sondern:

„Unsere Sicherheitsorganisation dokumentiert sich während des laufenden Betriebs nachvollziehbar.“

Dann verliert auch das nächste Audit einen erheblichen Teil seines Schreckens.