Herkunft, Version, Freigabe und Änderungen so dokumentieren, dass der Nachweis später ohne Rekonstruktion erklärt werden kann.
Ein Dokument wird nicht dadurch belastbar, dass es auf einer Blockchain liegt, auf einem WORM-Datenträger gespeichert oder per Hashwert geschützt ist. Entscheidend ist, ob die Informationen im Nachweis rückführbar sind: wofür er gilt, woher er stammt, wer ihn geprüft und freigegeben hat und welche Version zum maßgeblichen Zeitpunkt galt.
Mindestangaben eines belastbaren Nachweises prüfen
Zuerst muss der Nachweis erklärbar sein. Danach entscheidet das Risiko, wie stark seine Integrität technisch abgesichert werden muss.
Direkte Antwort
Was macht einen NIS2-Nachweis belastbar?
Ein belastbarer NIS2-Nachweis lässt erkennen, welche Anforderung und welchen Geltungsbereich er betrifft, aus welcher Quelle er stammt, welche Version gültig ist, wer ihn geprüft und freigegeben hat und ob spätere Änderungen nachvollziehbar sind. Je nach Risiko kommen Zugriffsschutz, Änderungsprotokoll, Hashwert, elektronische Signatur, Zeitstempel oder unveränderbare Ablage hinzu.
Ausgangslage
Woran man einen schwachen Nachweis erkennt
→Eine Richtlinie wurde nach einem Vorfall überschrieben.
→Ein Screenshot besitzt weder Datum noch Systembezug.
→Eine Kundenantwort verweist auf ein Zertifikat mit anderem Scope.
→Ein Maßnahmenstatus wurde geändert, ohne die vorherige Version aufzubewahren.
→Eine Geschäftsführungsentscheidung liegt nur in einer E-Mail.
→Ein Restore-Test wird behauptet, aber Ergebnis und Beteiligte fehlen.
→Eine Vorfallchronologie wurde nachträglich aus Erinnerungen rekonstruiert.
Das Problem liegt häufig nicht im fehlenden Dokument. Es fehlt die Verbindung zwischen Aussage, Quelle, Zeitpunkt, Freigabe und tatsächlicher Umsetzung.
Rechtlicher Rahmen
Was NIS2 und das BSIG verlangen
Das BSIG verlangt geeignete, wirksame und verhältnismäßige Maßnahmen. Betroffene Unternehmen müssen in der Lage sein, die Umsetzung und Überwachung ihrer Maßnahmen im Rahmen von Aufsicht, Prüfung oder konkreten Auskunftsverlangen nachvollziehbar zu belegen.
Das BSI kann Dokumentationen, Berichte, Prüfungen, Audits und Zertifizierungen als Nachweise berücksichtigen.
Es besteht keine allgemeine Vorgabe, dass jedes Dokument qualifiziert signiert, auf einer Blockchain gespeichert oder als WORM-Datensatz archiviert wird.
Für sicherheitskritische Aufzeichnungen wie Logs gelten je nach Einrichtung und Rechtsgrundlage konkretere Anforderungen an Schutz, Aufbewahrung und Änderbarkeit.
Der erforderliche Schutz folgt aus Risiko, Nachweisart, Empfänger und möglicher Streitwirkung.
„Revisionssicher" ist kein einheitlich definierter NIS2-Status. Auf dieser Seite bezeichnet der Begriff eine Dokumentation, deren Herkunft, Version, Freigabe und Änderungen nachvollziehbar bleiben und die vor unbefugter Veränderung geschützt ist.
Reihenfolge
Zuerst rückführbar, dann technisch absichern
Ein belastbarer Nachweis entsteht in zwei Schritten — nicht in umgekehrter Reihenfolge. Wer mit Blockchain, WORM oder Signatur beginnt, sichert eine Fassung ab, deren Aussage noch gar nicht erklärbar ist.
Schritt 1
Nachweis vollständig und rückführbar aufbauen
Der Nachweis zeigt valide, vollständig und nachvollziehbar, welcher Anlass vorlag, welche Daten verwendet wurden, was bewertet und entschieden wurde, wer geprüft und freigegeben hat und welche Fassung zum maßgeblichen Zeitpunkt galt.
Schritt 2
Schutzbedarf risikobasiert festlegen
Erst auf der vollständigen, freigegebenen Fassung stellt sich die Frage nach dem technischen Schutz. Sie wird anlassbezogen mit dem jeweiligen Stakeholder — Kunde, BSI, Prüfer — abgestimmt, nicht pauschal vorab entschieden.
Priorität 1 — Rückführbarkeit
Nachweis
Quelle
Vorgang
Entscheidung
damalige betriebliche Realität
Oft genügt sorgfältige Dokumentenlenkung. Definierte Ablage, Versionierung, Freigabe, Änderungshistorie und Review sind klassische Bestandteile eines Qualitätsmanagements nach DIN EN ISO 9001. Für viele Nachweise reicht genau das — zusätzliche Hochsicherheitstechnik wird erst bei erhöhtem Risiko relevant.
Schutzbedarf
Drei Stufen der Nachweisintegrität
Nicht jeder Nachweis braucht dieselbe technische Absicherung. Die folgende Einordnung beginnt mit der betrieblichen Mindestanforderung und erhöht den Schutz dort, wo Entscheidung, Vorfall oder externe Verwendung größere Folgen haben.
Stufe 1
Erklärbar und zugeordnet
Geeignet für
Richtlinien
Prozessbeschreibungen
Rollenübersichten
Maßnahmenlisten
regelmäßige Statusberichte
Mindestangaben und Mindestmaßnahmen
Mindestangaben
Nachweis-ID, Titel
betroffene Anforderung, Scope
Quelle, Owner
Version, Datum
Reviewtermin
Technische Mindestmaßnahmen
definierte Ablage
eingeschränkte Schreibrechte
Versionierung und Backup
gültige Version klar markiert
Das Unternehmen kann erklären, wofür der Nachweis gilt und welche Version maßgeblich ist.
Stufe 2
Freigegeben und änderungsnachvollziehbar
Geeignet für
Geschäftsführungsentscheidungen
Risikoakzeptanzen
MFA- oder Patch-Ausnahmen
Lieferantenbewertungen
Wiederanlaufpläne, Meldebewertungen
Test- und Wirksamkeitsprotokolle
Zusätzliche Angaben und Maßnahmen
Zusätzliche Angaben
geprüft durch, freigegeben durch
Freigabedatum
Entscheidungsgrundlage
Änderungsgrund, vorherige Version
Gültigkeitsdauer
Zusätzliche Maßnahmen
getrennte Bearbeitungs- und Freigaberollen
geschützte Änderungshistorie
vorherige Versionen erhalten
Abschlussversion exportieren
Zugriffe protokollieren
Das Unternehmen kann zeigen, wer auf welcher Grundlage entschieden hat und welche Fassung zum Entscheidungszeitpunkt galt.
Stufe 3
Manipulation erkennbar oder extern verifizierbar
Geeignet für
behördlich vorgelegte Unterlagen mit besonderer Bedeutung von Herkunft, Zeitpunkt oder unveränderter Abschlussfassung
wesentliche Kunden- oder Vertragszusagen
Konfliktsituationen mit strittiger Aussage
Incident-Timelines
externe Auditberichte
Nachweise mit hoher Haftungs- oder Schadenswirkung
Mögliche zusätzliche Maßnahmen
Mögliche zusätzliche Maßnahmen
Hashwert der Abschlussversion
append-only- oder WORM-Ablage
geschützte Audit Logs
elektronisches Siegel oder Signatur
qualifizierter Zeitstempel
unabhängige Prüfung oder Zertifizierung
Eine spätere Veränderung wird erkennbar oder Herkunft und Zeitpunkt können durch einen unabhängigen Mechanismus überprüft werden.
Stufe 3 ist kein allgemeines NIS2-Mindestniveau. Sie wird dort relevant, wo Streitpotenzial, Schadenswirkung, zeitliche Bedeutung, Manipulationsrisiko oder eine vertragliche beziehungsweise regulatorische Anforderung den zusätzlichen Schutz rechtfertigen. Nicht der Empfänger allein bestimmt die Stufe.
Praxischeck
Ist dieser Nachweis belastbar?
Zehn Fragen ordnen einen einzelnen Nachweis ein. Die Antworten bleiben in Ihrem Browser, werden nicht gespeichert und nicht übertragen.
Beantworten Sie jede Frage mit Ja oder Nein. Das Ergebnis erscheint unten.
Ist die betroffene Anforderung eindeutig benannt?
Ist klar, für welches System, Unternehmen, Produkt oder Verfahren der Nachweis gilt?
Ist die Quelle des Nachweises dokumentiert?
Sind Ersteller und verantwortliche Rolle erkennbar?
Besitzt der Nachweis eine Version und ein Erstellungsdatum?
Ist die gültige Fassung eindeutig gekennzeichnet?
Ist dokumentiert, wer geprüft und freigegeben hat?
Bleiben frühere Versionen und Änderungen nachvollziehbar?
Ist der Nachweis vor unbefugter Änderung geschützt?
Gibt es einen Reviewtermin oder eine Gültigkeitsdauer?
Beantworten Sie die Fragen, um eine Einordnung zu erhalten.
Kopiervorlage
Diese Angaben gehören in eine belastbare NIS2-Dokumentation
Das Manifest fasst die Mindestangaben eines Nachweises zusammen. Jede Zeile nennt Zweck und ein Beispiel. Kopieren Sie die Vorlage und ersetzen Sie die Beispiele durch Ihre eigenen Werte.
# Feld : Wert # Zweck — BeispielNACHWEIS-ID:# eindeutige Referenz — EVID-2026-014TITEL:# verständliche Bezeichnung — Restore-Test ERPBETROFFENE ANFORDERUNG:# Bezug zur Pflicht — §30 Abs. 2 BSIGGELTUNGSBEREICH:# Scope — ERP-ProduktivsystemQUELLE:# Ursprung der Information — Restore-ProtokollVERSION:# maßgebliche Fassung — 1.2ERSTELLT AM:# Entstehungszeitpunkt — 17.06.2026ERSTELLT DURCH:# verantwortliche Rolle — IT-BetriebGEPRÜFT DURCH:# fachliche Prüfung — InformationssicherheitFREIGEGEBEN DURCH:# Entscheidung — IT-LeitungFREIGEGEBEN AM:# Gültigkeitsbeginn — 19.06.2026GÜLTIG BIS / REVIEW:# Reviewtermin — 19.06.2027STATUS:# Einordnung — freigegebenVORHERIGE VERSION:# frühere Fassung — 1.1 abgelöstÄNDERUNGSGRUND:# Grund der letzten ÄnderungABLAGE / REFERENZ:# Fundort der maßgeblichen FassungINTEGRITÄTSMERKMAL:# optionale Absicherung — SHA-256-Hash
Nicht jedes Feld muss in der Datei selbst stehen. Entscheidend ist, dass Datei, Metadaten und Freigabe eindeutig miteinander verbunden bleiben. Ein Hash oder eine Signatur bestätigt nicht die inhaltliche Richtigkeit — das Integritätsmerkmal zeigt nur, ob die freigegebene Fassung später verändert wurde beziehungsweise wer sie bestätigt hat.
Konkretes Beispiel
Beispiel: Restore-Test als belastbarer Nachweis
Ausgangslage: Das Unternehmen erklärt gegenüber einem Kunden, dass Wiederherstellungstests regelmäßig durchgeführt werden.
Schwacher Nachweis
Screenshot eines erfolgreichen Jobs ohne Datum, Systembezug, Freigabe oder Ergebnisbewertung.
Belastbarer Nachweis
Test-ID, getestetes System
Datum, Beteiligte
Backup-Stand
erwartetes und tatsächliches Ergebnis
gemessene Wiederanlaufzeit
Abweichungen, offene Maßnahmen
geprüfte Abschlussversion, Reviewtermin
Für diesen Fall ist Stufe 2 die angemessene Grundeinordnung.
Empfängerperspektive
Der Empfänger bestimmt mit, wie stark der Nachweis abgesichert werden muss
Internes Management
Entscheidungsgrundlage
Freigabe
Maßnahmen
Wiedervorlage
Kunde oder Auftraggeber
Scope
freigegebene Aussage
Aktualität
externe Verwendbarkeit
Einschränkungen
Behörde oder Prüfer
Anforderungsbezug
Umsetzungsnachweis
Verantwortliche
Version
Änderungshistorie
Vorfall- oder Streitfall
belastbare Zeitlinie
damaliger Informationsstand
Entscheidungszeitpunkt
unveränderte Abschlussfassung
nachvollziehbare Änderungen
Der gleiche Inhalt kann intern mit Stufe 1 ausreichen und bei einer wesentlichen externen Zusage Stufe 2 oder 3 benötigen.
Technische Absicherung
Technik kommt zuletzt — und nach Schutzbedarf
Steht ein vollständiger, freigegebener und rückführbarer Nachweis, ist der wichtigste Teil getan. Häufig trägt bereits eine sorgfältige Dokumentenlenkung nach DIN EN ISO 9001 — Ablage, Versionierung, Freigabe, Änderungshistorie, Review. Zusätzliche Technik wird erst dort relevant, wo eine spätere Veränderung erkennbar oder extern überprüfbar sein muss. Welche Eigenschaft welches Mittel absichert, fasst die folgende Übersicht zusammen.
Hash, Signatur, Siegel, Zeitstempel und WORM im Überblick
Hashwert
Zeigt
ob eine Datei nach Erstellung des Hashwertes verändert wurde.
Zeigt nicht
wer die Datei erstellt hat, ob der Inhalt richtig ist, wann sie tatsächlich entstand.
Elektronische Signatur
Kann zeigen
wer eine Datei signiert hat und ob sie nach der Signatur verändert wurde.
Zeigt nicht automatisch
ob die Aussage fachlich richtig ist oder ob der Signierende zuständig war.
Elektronisches Siegel
Geeignet für
Herkunft aus einer Organisation, automatisierte Dokumentausgabe, Integritätsprüfung.
Zeitstempel
Kann zeigen
dass bestimmte Daten zu einem bestimmten Zeitpunkt vorlagen.
WORM oder append-only
Geeignet für
Aufzeichnungen, die nach Abschluss nicht überschrieben werden sollen: Logs, kritische Freigaben, langfristige Archivierung.
Die Technik sichert eine Eigenschaft des Nachweises. Sie ersetzt weder fachliche Prüfung noch eindeutigen Geltungsbereich — und sie wird mit dem Stakeholder anlassbezogen vereinbart, nicht pauschal vorausgesetzt.
Im Tagesgeschäft
Wo Nachweisintegrität im Tagesgeschäft relevant wird
Der Compliance Arbeitsplatz verbindet die konkrete Anforderung mit Quelle, Scope, Prüfung, Freigabe, offenen Punkten und Review. Operative Daten bleiben in den vorhandenen Fachsystemen und Ablagen.
Der Arbeitsplatz bestätigt nicht automatisch, dass ein Inhalt wahr ist. Er hält fest, welche Grundlage verwendet wurde, wer geprüft und entschieden hat und welche Fassung freigegeben wurde.
Für besonders schutzbedürftige Nachweise können später zusätzliche Integritätsmerkmale wie Hashwert, elektronisches Siegel oder geschützte Archivierung ergänzt werden.
Häufige Fragen
Revisionssichere NIS2-Nachweise
NIS2 schreibt nicht pauschal eine bestimmte Archivierungs-, Signatur- oder Speichertechnologie für alle Nachweise vor. Unternehmen müssen jedoch die Umsetzung ihrer Maßnahmen nachvollziehbar dokumentieren und geeignete Nachweise vorlegen können.
Eine allgemeine Pflicht zu technisch fälschungssicheren Dokumenten besteht nicht. Für wesentliche Nachweise sollte jedoch erkennbar bleiben, welche Fassung freigegeben wurde, wer sie bestätigt hat und ob sie später verändert wurde. Der erforderliche technische Schutz richtet sich nach Risiko, Empfänger und möglicher Streitwirkung.
Der Begriff bezeichnet hier eine Dokumentation, deren Herkunft, Geltungsbereich, Version, Freigabe und Änderungen nachvollziehbar bleiben und die vor unbefugter Veränderung geschützt ist.
Das hängt von Konfiguration und Prozess ab. Entscheidend sind Rollen, Versionierung, Freigabe, Aufbewahrung, Änderungshistorie und die Möglichkeit, frühere Fassungen wiederherzustellen.
Nein. Ein Hashwert ist sinnvoll, wenn eine bestimmte Abschlussversion später eindeutig überprüft werden soll. Für normale interne Prozessdokumente können Versionierung, Freigabe und Zugriffsschutz ausreichen.
Sie kann die Identität des Signierenden und die Unverändertheit der signierten Fassung bestätigen. Sie beweist nicht automatisch, dass der Inhalt fachlich korrekt oder vollständig ist.
Es gibt keine einheitliche Aufbewahrungsfrist für sämtliche NIS2-Nachweise. Die Dauer richtet sich nach Nachweisart, Risiko, Meldepflicht, Vertrag, Haftung und weiteren gesetzlichen oder branchenspezifischen Vorgaben.
Quellen und weiterführende Seiten
Grundlage und nächste Schritte
Diese Seite stützt sich auf offizielle Quellen:
BSIG — Gesetz über das Bundesamt für Sicherheit in der Informationstechnik
BSI — Bundesamt für Sicherheit in der Informationstechnik