¶ NIS2-Nachweisregister
Leeres Musterregister: Diese öffentliche Beispielseite enthält keine realen Nachweise, Sicherheitskonfigurationen, Schwachstelleninformationen, personenbezogenen Daten, Verträge oder Behördenunterlagen. Originale werden in einer geschützten, zugriffsgeregelten und für den jeweiligen Zweck freigegebenen Ablage geführt.
Keine Statusbehauptung: Farben, Kennzahlen und Musterzeilen erläutern ausschließlich die vorgesehene Registerlogik. Sie bestätigen weder die Umsetzung noch die Angemessenheit oder Wirksamkeit von Maßnahmen in einem Unternehmen.
¶ Dokumenteninformationen
| Feld | Wert |
|---|---|
| Dokumenten-ID | NIS2-REG-02-07 |
| Dokumentenart | Metadatenregister und Arbeitsanweisung für NIS2-Nachweise |
| Wiki.js-Pfad | /NIS2/02-Risikomanagement-und-Nachweise/Nachweisregister |
| Verantwortlich | NIS2-Nachweiskoordination; Evidence Owner je Registereintrag |
| Status | Entwurf – keine realen Nachweise erfasst, geprüft oder freigegeben |
| Version / Stand | 0.3 / 09.08.2026 |
| Schutzklasse | Wiki enthält nur Muster und Metadaten; Originale gemäß Informationsklassifizierung |
| Freigabe | Ausstehend; unternehmensbezogene Rollen, Statuswerte und Aufbewahrungsregeln festzulegen |
Nachweise eindeutig zuordnen, geschützt referenzieren, fachlich prüfen und aktuell halten. Eigene redaktionelle SVG-Grafik. Zum Vergrößern öffnen.
¶ 1. Register-Cockpit – Muster ohne Echtdaten
Das Cockpit verdichtet den Registerbestand für die Steuerung. Ein Gedankenstrich bedeutet: Auf dieser Musterseite liegt kein realer Messwert vor. Fehlende Werte dürfen nicht als Null oder als Erfüllung interpretiert werden.
—
keine Echtdaten im Muster-Wiki
—
keine Echtdaten im Muster-Wiki
—
keine Echtdaten im Muster-Wiki
—
keine Echtdaten im Muster-Wiki
Ein reales Cockpit nennt Stichtag, Geltungsbereich, Datenquelle, Filter und Aussagegrenze. Die bloße Anzahl vorhandener Dateien ist keine Qualitätskennzahl.
¶ 2. Zweck und Arbeitsergebnisse
Das Nachweisregister beantwortet nicht nur die Frage, ob irgendein Dokument existiert, sondern ob ein geeigneter und aktueller Nachweis die gewünschte Aussage für den richtigen Dienst, Zeitraum und Scope trägt. Es soll insbesondere sicherstellen, dass
- jede wesentliche NIS2-Anforderung mit relevanten Diensten, Risiken und Maßnahmen verbunden werden kann,
- Verantwortliche erkennen, welcher Beleg fehlt, abläuft oder fachlich nicht ausreicht,
- sensible Originale nicht unkontrolliert im Wiki oder per E-Mail verteilt werden,
- Aussagen über Umsetzung und Wirksamkeit auf prüfbaren Kriterien beruhen,
- Audit-, Leitungs- oder Behördenanfragen kontrolliert und nachvollziehbar bedient werden,
- Abweichungen, Ersatznachweise und Folgemaßnahmen sichtbar bleiben.
Das Register ist damit ein Steuerungsinstrument. Es ist weder ein frei zugängliches Dokumentenarchiv noch ein Ersatz für Risiko-, Maßnahmen-, Incident- oder Auditregister.
¶ 3. Was als Nachweis gilt – und was nicht
Ein Nachweisobjekt ist eine kontrollierte Information, die eine konkrete Aussage unterstützt. Dazu können freigegebene Richtlinien, Protokolle, Tickets, Systemauszüge, Testberichte, Schulungsaufzeichnungen, Verträge, Auditfeststellungen oder Managemententscheidungen gehören.
Nicht jede Datei ist automatisch ein geeigneter Nachweis. Ein Dokument kann
- nur eine Absicht beschreiben, aber keine Umsetzung belegen,
- einen anderen Standort, Dienst oder Zeitraum betreffen,
- veraltet, unvollständig oder nicht freigegeben sein,
- aus einer nicht vertrauenswürdigen Quelle stammen,
- durch unklare Filter oder nachträgliche Bearbeitung seine Aussagekraft verlieren,
- mehr vertrauliche oder personenbezogene Informationen enthalten als erforderlich.
Die Eignung wird deshalb immer gegen einen definierten Nachweisbedarf geprüft.
¶ 4. Vier Ebenen sauber trennen
| Ebene | Leitfrage | Typisches Arbeitsergebnis |
|---|---|---|
| Nachweisbedarf | Was muss für welche Anforderung und welchen Scope belegt werden? | Soll-Eintrag oder Prüfkriterium |
| Nachweisobjekt | Welche kontrollierte Information trägt die Aussage? | Original mit eindeutiger Referenz |
| Nachweisprüfung | Ist der Beleg aktuell, vollständig, authentisch und geeignet? | dokumentiertes Prüfergebnis |
| Nachweispaket | Welche freigegebene Auswahl wird einem bestimmten Empfänger bereitgestellt? | Index, Kopien/Links, Freigabe und Übergabeprotokoll |
Diese Trennung verhindert, dass „Datei vorhanden“ fälschlich mit „Pflicht erfüllt“ oder „Maßnahme wirksam“ gleichgesetzt wird.
¶ 5. Rechtliche Einordnung ohne Überdehnung
§ 30 BSIG verlangt für besonders wichtige und wichtige Einrichtungen angemessene, verhältnismäßige und wirksame technische und organisatorische Risikomanagementmaßnahmen. Die Maßnahmen sind zu dokumentieren. Diese Dokumentation muss intern so gesteuert werden, dass Umsetzung, Überwachung und Nachvollziehbarkeit möglich sind.
Die besondere, turnusmäßige Nachweispflicht nach § 39 BSIG gilt hingegen für Betreiber kritischer Anlagen. Sie umfasst Nachweise durch Sicherheitsaudits, Prüfungen oder Zertifizierungen sowie gegebenenfalls Angaben zu Sicherheitsmängeln, Mängelbeseitigungsplänen und deren Umsetzung. Ein öffentliches Musterregister darf diese besondere Pflicht nicht pauschal auf jede NIS2-Einrichtung übertragen.
Daneben können Aufsichts-, Auskunfts-, Vertrags- oder sektorspezifische Pflichten bestehen. Deshalb erhält jeder Registereintrag ein Feld „Rechts-/Anforderungsbezug“, ohne daraus automatisch eine Rechtsbewertung abzuleiten. Betroffenheit, Fristen und zuständige Stellen sind organisationsbezogen zu prüfen.
¶ 6. Durchgängige Beweiskette
Eine belastbare Referenzkette lautet:
Anforderung → relevanter Dienst → Risiko → Maßnahme/Kontrolle → Nachweisbedarf → Originalnachweis → Prüfung → Feststellung/Entscheidung → Folgemaßnahme
Jeder Sprung muss nachvollziehbar sein. Ein technischer Prüfbericht ohne Zuordnung zum relevanten Dienst bleibt ebenso unvollständig wie eine Richtlinie ohne Umsetzungs- oder Wirksamkeitsbeleg. Änderungen an Dienst, Risiko oder Maßnahme lösen eine Prüfung aus, ob bestehende Nachweise noch passen.
¶ 7. Identifikation, Versionierung und Referenzen
Jeder Eintrag erhält eine dauerhafte ID, zum Beispiel NIS2-NW-2026-001. Eine mögliche Systematik besteht aus Regelwerk, Objekttyp, Jahr und laufender Nummer. Die ID bleibt beim Nachweisobjekt; neue Versionen werden nicht als unabhängige, unverbundene Dateien geführt.
Ergänzend werden erfasst:
- Nachweistitel und Kurzbeschreibung,
- freigegebene Version sowie Erstellungs- und Freigabedatum,
- führende Systemreferenz statt unsicherer Freitextpfade,
- Vorgänger, Nachfolger und Ersetzungsgrund,
- Quelle, Ersteller und Nachweis-Owner,
- optional Hash, Signatur oder revisionsfähige Systemhistorie.
Direkte Dateilinks werden nur verwendet, wenn Berechtigungen, Beständigkeit und Zweckbindung gewährleistet sind.
¶ 8. Mindestfelder des Registers
| Feldgruppe | Verbindliche Metadaten |
|---|---|
| Identität | Nachweis-ID, Titel, Typ, Version, Datum, Sprache und Quelle |
| Aussage | Nachweisbedarf, Prüffrage, behauptete Aussage und Aussagegrenze |
| Scope | Einrichtung, relevanter Dienst, Prozess, Standort, System, Anbieter und Zeitraum |
| Zuordnung | Anforderung, Risiko-ID, Maßnahmen-ID, Kontrollziel und gegebenenfalls Vorfall/Audit |
| Verantwortung | Evidence Owner, Ersteller, Prüfer, Freigeber und fachlicher Ansprechpartner |
| Original | führende Ablage, Systemreferenz, Dateiformat, Integritätsmerkmal und Zugriffsklasse |
| Lebenszyklus | Erstellungs-, Prüf-, Freigabe-, Ablauf-, Wiedervorlage- und Archivdatum |
| Bewertung | Vollständigkeit, Aktualität, Authentizität, Eignung, Ergebnis und Einschränkung |
| Status | Bedarf, Erhebung, Prüfung, Freigabe, gültig, abgelaufen, ersetzt oder gesperrt |
| Abweichung | Feststellung, Risiko, Ersatznachweis, Folgemaßnahme, Owner und Termin |
| Offenlegung | Empfänger, Zweck, Freigabe, Übermittlungsweg, Paketversion und Lösch-/Rückgaberegel |
| Aufbewahrung | Frist, Fristbeginn, Rechts-/Vertragsbezug, Löschklasse und mögliche Sperre |
Pflichtfelder, Wertelisten und Validierungsregeln werden vor produktiver Nutzung organisationsbezogen freigegeben.
¶ 9. Aussageebenen eines Nachweises
Ein Registereintrag kennzeichnet, welche Ebene tatsächlich belegt wird:
- Vorgabe: Eine Regel, Verantwortung oder Zielsetzung wurde beschlossen.
- Umsetzung: Eine Maßnahme wurde eingerichtet oder eine Aufgabe durchgeführt.
- Betrieb: Die Maßnahme arbeitet über einen definierten Zeitraum.
- Test: Eine kontrollierte Prüfung wurde mit festgelegtem Ergebnis durchgeführt.
- Wirksamkeit: Das definierte Sicherheitsziel wurde anhand geeigneter Kriterien erreicht.
- Entscheidung: Eine Abweichung, Akzeptanz oder Folgemaßnahme wurde befugt entschieden.
Eine freigegebene Richtlinie belegt regelmäßig eine Vorgabe, aber nicht automatisch deren technische Umsetzung oder Wirksamkeit.
¶ 10. Lebenszyklusstatus
„Freigegeben“ bedeutet, dass die definierte Prüfung abgeschlossen wurde. Der Status bestätigt nur die zugeordnete Aussageebene und den geprüften Scope – nicht pauschal die NIS2-Konformität.
¶ 11. Qualitätsampel
Scope, Zeitraum, Quelle, Integrität und Prüfkriterium sind nachvollziehbar.
Der Nachweis ist nutzbar, besitzt aber dokumentierte Grenzen oder offene Ergänzungen.
Der Nachweis fehlt, ist abgelaufen, nicht authentisch oder trägt die geforderte Aussage nicht.
Eine Bewertung ist noch nicht erfolgt oder mangels Informationen nicht möglich.
Die Bewertung enthält immer Begründung, Prüfer, Datum, Prüfmethode und nächste Aktion. Farbe ohne Textbegründung ist nicht ausreichend.
¶ 12. Abdeckung und Lückensteuerung
Abdeckung wird nicht nur als Prozentwert geführt. Für jeden Nachweisbedarf gilt einer der Zustände:
- vollständig abgedeckt: geeigneter, gültiger Nachweis für den gesamten Scope,
- teilweise abgedeckt: Einschränkung nach Standort, System, Anbieter oder Zeitraum,
- ersatzweise abgedeckt: temporärer Alternativbeleg mit genehmigter Befristung,
- nicht abgedeckt: kein geeigneter Nachweis vorhanden,
- nicht anwendbar: fachlich begründet, geprüft und befugt entschieden.
„Nicht anwendbar“ ist keine Ausweichoption. Die Begründung nennt Anforderung, Scope, Tatsachenbasis, Entscheider und nächsten Review.
¶ 13. Gültigkeit und Fälligkeitsampel
Fristen entstehen aus Gültigkeitsende, Reviewintervall, Vertragslaufzeit, Auditplan oder anlassbezogenen Änderungen. Vorwarnzeiten werden nach Beschaffungs- und Prüfaufwand gewählt. Ein abgelaufener Nachweis wird nicht durch bloßes Ändern des Datums verlängert; erforderlich ist eine dokumentierte Neubewertung oder ein Nachfolger.
¶ 14. Quellen- und Vertrauensbewertung
Die Quelle beeinflusst die Aussagekraft. Mögliche Kategorien sind:
- intern systemerzeugt und revisionsfähig,
- intern manuell erstellt und fachlich freigegeben,
- externer unabhängiger Prüfbericht oder Zertifikat,
- Lieferantenselbstauskunft,
- öffentlich zugängliche Information,
- forensisch oder im Vorfall gesicherte Information.
Für externe Zertifikate werden mindestens Aussteller, Standard und Version, geprüfte Organisationseinheit, Standort/Scope, Gültigkeit und Einschränkungen geprüft. Ein Zertifikat des Anbieters ersetzt nicht automatisch die Prüfung der tatsächlich bezogenen Dienstleistung.
¶ 15. Integrität, Authentizität und Nachvollziehbarkeit
Die Organisation legt abhängig vom Schutz- und Beweisbedarf fest, wie Originalität und Unverändertheit belegt werden. Geeignete Mittel können sein:
- revisionsfähige Systemhistorie und unveränderbare Ereignisprotokolle,
- digitale Signatur oder dokumentierte Freigabe,
- Hashwert mit gesicherter Erfassungszeit,
- kontrollierter Export aus einem Quellsystem,
- Ersteller-, Prüf- und Änderungshistorie,
- gesicherte Beweiskette bei Vorfall- und Forensikdaten.
Ein Hash allein belegt nicht, dass der Inhalt ursprünglich richtig oder vollständig war. Er unterstützt lediglich den Vergleich eines eindeutig festgelegten Datenstands.
¶ 16. Schutzklassen und Datenminimierung
Das Register enthält nur die für Steuerung und Auffindbarkeit erforderlichen Metadaten. Das Original erhält eine Schutzklasse, beispielsweise öffentlich, intern, vertraulich oder streng vertraulich. Besonders schutzbedürftig sind unter anderem:
- Netzwerkpläne, Administrations- und Sicherheitskonfigurationen,
- Schwachstellen-, Penetrationstest- und Forensikberichte,
- personenbezogene Schulungs-, Berechtigungs- oder Vorfalldaten,
- Vertragskonditionen und Geschäftsgeheimnisse,
- Behördenkommunikation und nicht veröffentlichte Feststellungen.
Vorschauen, Dateinamen und Freitextfelder dürfen keine sensiblen Inhalte unnötig offenlegen.
¶ 17. Rollen und RACI-Grundmodell
| Aufgabe | Evidence Owner | Fachprüfer | Registerkoordination | Risiko-/Maßnahmen-Owner | Datenschutz/Legal | Geschäftsleitung |
|---|---|---|---|---|---|---|
| Nachweisbedarf definieren | M | M | K | V | K | I |
| Original erzeugen/beschaffen | V | K | M | M | K | I |
| Eignung und Scope prüfen | M | V | K | M | K | I |
| Metadaten und Fristen pflegen | M | K | V | I | I | I |
| Lücke und Folgemaßnahme behandeln | M | K | K | V | K | I |
| externe Offenlegung freigeben | M | K | K | I | V/M | I |
| wesentliche Lücke eskalieren | M | K | V | V | K | I/E |
V = verantwortlich, M = mitwirkend, K = konsultiert, I = informiert, E = entscheidend. Das Modell ist vor Nutzung an Organisation, Sektor und Vollmachten anzupassen.
¶ 18. Zugriffs- und Berechtigungsmodell
Zugriff folgt Erforderlichkeit, Schutzklasse und Funktionstrennung. Mindestens zu unterscheiden sind Lesen, Hochladen, Metadatenpflege, fachliche Prüfung, Freigabe, Export und Löschung. Kritische Änderungen und externe Pakete können ein Vier-Augen-Prinzip erfordern.
Berechtigungen werden regelmäßig überprüft. Gruppen, Funktionskonten, Vertreter und befristete externe Zugriffe sind sichtbar zu führen. Ein Wiki-Link darf keinen Zugriff auf ein Original eröffnen, der im führenden System nicht ausdrücklich gewährt wurde.
¶ 19. Standardablauf für einen neuen Nachweis
- Nachweisbedarf und Prüffrage festlegen.
- Dienst, Risiko, Maßnahme, Scope und Zeitraum zuordnen.
- Evidence Owner und fachlichen Prüfer bestimmen.
- Original kontrolliert erzeugen, exportieren oder anfordern.
- Schutzklasse, Integrität und führende Ablage festlegen.
- Vollständigkeit, Aktualität, Authentizität und Eignung prüfen.
- Einschränkungen, Abweichungen und Ersatzmaßnahmen erfassen.
- Status, Gültigkeit, Wiedervorlage und Aufbewahrung freigeben.
- Bei Bedarf kontrolliertes Nachweispaket erstellen.
- Änderungen, Ablauf, Ersatz, Archivierung oder Löschung überwachen.
Der Prozess endet nicht mit dem Hochladen einer Datei, sondern mit einer nachvollziehbaren Entscheidung über ihre Aussagekraft.
¶ 20. Anlassbezogene Neubewertung
Ein Nachweis wird vor dem regulären Termin erneut geprüft, wenn sich beispielsweise
- relevanter Dienst, Systemarchitektur oder Standort,
- Bedrohungs- oder Risikolage,
- Maßnahme, Prüfkriterium oder Verantwortlichkeit,
- Anbieter, Vertrag, Unterauftragnehmer oder Zertifikats-Scope,
- Rechts-, Aufsichts- oder Kundenanforderung,
- Vorfall, Schwachstelle, Auditfeststellung oder Ausnahme
wesentlich ändert. Das Register dokumentiert Auslöser, betroffene Nachweise, Entscheidung und Folgemaßnahmen.
¶ 21. Nachweise für technische Maßnahmen
Technische Nachweise benötigen reproduzierbare Angaben. Ein Screenshot ohne Zeit, System, Scope, Filter und Quelle ist häufig nicht ausreichend. Geeignete Metadaten sind beispielsweise:
- System/Instanz, Umgebung und verantwortlicher Betrieb,
- Erfassungszeitraum und Zeitzone,
- Abfrage, Filter oder Testschritte,
- Tool- und Regelversion,
- vollständig, anonymisiert oder stichprobenartig erhobener Umfang,
- Rohdatenreferenz und Exportformat,
- bekannte Blindstellen, Fehler und ausgeschlossene Systeme,
- Prüfergebnis und fachliche Interpretation.
Automatisierte Berichte werden auf Vollständigkeit der Datenquelle und Funktionsfähigkeit der Auswertung geprüft.
¶ 22. Lieferanten- und Dienstleisternachweise
Bei ausgelagerten Leistungen wird erfasst, welche Aussage ein Lieferantennachweis tatsächlich abdeckt. Relevant sind Leistungs-Scope, Standorte, Plattform, Unterauftragnehmer, Laufzeit und vertragliche Verpflichtungen. Mögliche Nachweise sind Zertifikate, Prüfberichte, Leistungskennzahlen, Testprotokolle, Meldungen, Vertragsanlagen und Nachweise zur Mängelbeseitigung.
Eine Selbstauskunft besitzt eine andere Beweiskraft als ein unabhängiger Prüfbericht. Kritische Lücken werden nicht durch eine allgemeine Marketingaussage des Anbieters geschlossen.
¶ 23. Personenbezogene Daten und Datenschutz
Schulungslisten, Berechtigungsprüfungen, Protokolle, Vorfälle und Untersuchungen können personenbezogene Daten enthalten. Vor Speicherung oder Offenlegung werden Zweck, Erforderlichkeit, Zugriff, Aufbewahrung und Löschung abgestimmt. Wo möglich, enthält das Register statt Namen Rollen, pseudonymisierte Kennungen oder aggregierte Ergebnisse.
Datenschutzrechtliche Prüfungen bleiben im Datenschutzmanagement. Das NIS2-Register referenziert nur die notwendige Entscheidung oder kontrollierte Ablage.
¶ 24. Abweichungen, Ersatznachweise und Folgemaßnahmen
Ist ein Nachweis unvollständig oder ungeeignet, erhält die Lücke eine Feststellungs-ID. Dokumentiert werden:
- betroffene Anforderung, Maßnahme, Risiko und Dienst,
- Art, Ursache und Auswirkung der Nachweislücke,
- vorläufiger Ersatznachweis und dessen Grenzen,
- Risikoentscheidung oder Eskalationsbedarf,
- Korrekturmaßnahme, Owner und Termin,
- Nachprüfung und Abschlusskriterium.
Eine offene Nachweislücke wird nicht durch Umbenennen des Status verborgen. Wesentliche oder wiederkehrende Lücken fließen in Risiko- und Verbesserungssteuerung ein.
¶ 25. Nachweispakete für Audit, Leitung und Behörde
Ein Nachweispaket ist eine zweckgebundene Auswahl, keine unkontrollierte Kopie des Archivs. Es enthält mindestens:
- Paket-ID, Empfänger, Zweck und Rechts-/Vertragsbezug,
- freigegebenen Index mit Nachweis-IDs und Versionen,
- Geltungsbereich, relevante Dienste und Berichtszeitraum,
- Prüfkriterien und bekannte Einschränkungen,
- freigegebene Kopien oder zeitlich begrenzte Zugriffsmöglichkeiten,
- Ansprechpartner und Rückfragenweg,
- Übergabe-, Empfangs- und gegebenenfalls Löschbestätigung.
Vor Weitergabe werden Geheimhaltungsbedarf, Personenbezug, Schwachstellendetails, Geschäftsgeheimnisse und sichere Übermittlung geprüft.
¶ 26. Besondere Nachweise für Betreiber kritischer Anlagen
Soweit § 39 BSIG anwendbar ist, muss das Register die periodischen Prüf- oder Zertifizierungsnachweise und die zugehörige Dokumentation kontrolliert abbilden können. Dazu gehören insbesondere:
- festgelegter Nachweistermin und betroffene kritische Anlage,
- Art und Umfang des Sicherheitsaudits, der Prüfung oder Zertifizierung,
- prüfende Stelle und deren Eignung,
- Ergebnis, festgestellte Sicherheitsmängel und Einschränkungen,
- Mängelbeseitigungsplan, Verantwortliche und Termine,
- Nachweis der erfolgten Mängelbeseitigung,
- an das BSI übermittelte Paketversion und Übermittlungsbestätigung.
Konkrete Fristen, BSI-Festlegungen und Übergangsvorschriften werden für den Einzelfall aktuell geprüft.
¶ 27. Kontrollierte Offenlegung und Übertragungsprotokoll
Jede externe Ausgabe erhält ein Protokoll mit Paketversion, Empfänger, Freigeber, Zweck, Zeitpunkt, Übermittlungsweg und Schutzmaßnahmen. Zeitlich begrenzte Portalfreigaben sind unkontrollierten E-Mail-Anhängen vorzuziehen. Änderungen nach der Übergabe erzeugen eine neue Paketversion.
Soweit eine Rückgabe oder Löschung vereinbart wurde, wird deren Erfüllung nachgehalten. Ein externes Paket wird nicht automatisch zur führenden Ablage.
¶ 28. Auditstichprobe und Reproduzierbarkeit
Eine Stichprobe wird so dokumentiert, dass Auswahl und Ergebnis nachvollzogen werden können:
- Grundgesamtheit und Datenstand,
- Auswahlmethode und Stichprobengröße,
- einbezogene und ausgeschlossene Objekte,
- Prüfschritte, Kriterien und Toleranzen,
- Abweichungen und Hochrechnungsgrenzen,
- Prüfer, Datum und verwendete Werkzeuge.
Die Stichprobe darf nicht stillschweigend als Aussage über nicht geprüfte Bereiche dargestellt werden.
¶ 29. Dubletten, Mehrfachnutzung und Vererbung
Ein Nachweis kann mehrere Anforderungen unterstützen. Statt Kopien werden kontrollierte Referenzen verwendet. Das Register zeigt, welche Aussagen und Scopes jeweils gedeckt sind. Wird das Original ersetzt, erhalten alle abhängigen Zuordnungen eine Neubewertung.
Dubletten werden über ID, Hash, Dateiname, Titel, Quelle und Zeitraum erkannt. Vor Zusammenführung ist zu klären, ob die Dateien wirklich identisch oder nur ähnlich benannt sind.
¶ 30. Änderungs- und Prüfprotokoll
Mindestens folgende Ereignisse werden protokolliert:
- Anlage und Änderung eines Registereintrags,
- Austausch, Sperrung oder Archivierung eines Originals,
- Änderung von Status, Qualität, Scope oder Gültigkeit,
- fachliche Prüfung, Freigabe und Widerruf,
- Zugriffserteilung und kritischer Export,
- Bildung und Übermittlung eines Nachweispakets,
- Abweichung, Eskalation und Abschluss.
Das Protokoll nennt Zeit, handelnde Rolle, alten und neuen Wert sowie Begründung.
¶ 31. Kennzahlen für Steuerung und Management
Sinnvolle Kennzahlen werden nach Dienst, Anforderung, Owner und Schutzklasse filterbar gemacht. Beispiele:
- offene Nachweisbedarfe und Abdeckungsstatus,
- ungeprüfte, ungeeignete und eingeschränkt geeignete Nachweise,
- fällige und überfällige Prüfungen,
- Einträge ohne Owner, Scope, Gültigkeit oder führende Referenz,
- Nachweislücken mit hohem oder kritischem Risikobezug,
- durchschnittliche Zeit von Anforderung bis Freigabe,
- wiederkehrende Lücken und überfällige Folgemaßnahmen,
- Nachweispakete mit offenen Rückgabe- oder Löschbestätigungen.
Die Kennzahl enthält Definition, Quelle, Stichtag, Verantwortlichen und Ziel-/Eskalationswert.
¶ 32. Filter- und Arbeitsansichten
Für die tägliche Arbeit sind insbesondere folgende Sichten nützlich:
- „meine fälligen Nachweise“ nach Owner,
- Lücken zu kritischen oder hoch bewerteten Risiken,
- Nachweise je relevantem Dienst und Standort,
- auslaufende Lieferantenzertifikate,
- ungeprüfte technische Exporte,
- offene Abweichungen und Ersatznachweise,
- Nachweise für das nächste Audit- oder Behördenpaket,
- personenbezogene oder streng vertrauliche Nachweise,
- Einträge ohne vollständige Referenzkette.
Filter verändern nur die Ansicht, nicht den Status. Exportierte Listen erhalten Filterkriterien und Stichtag.
¶ 33. Fiktive Musterzeilen
Die folgenden Einträge sind reine Demonstrationsdaten. Sie belegen keine tatsächliche Maßnahme oder Prüfung.
| ID | fiktiver Nachweisbedarf | fiktiver Scope | Aussageebene | Lebenszyklus | Qualität | Fälligkeit |
|---|---|---|---|---|---|---|
| DEMO-NW-001 | Wiederanlauftest für Beispieldienst A | Muster-Rechenzentrum / Q2 | Test | ▲ IN PRÜFUNG | ! GELB | ! BALD FÄLLIG |
| DEMO-NW-002 | Prüfung privilegierter Musterkonten | Beispielplattform / Monat 07 | Betrieb | ◇ EINGEGANGEN | ○ GRAU | ✓ IM PLAN |
| DEMO-NW-003 | Lieferantennachweis für Beispieldienst B | fiktiver Anbieter / Vertragsjahr | Umsetzung | × ABGELAUFEN | × ROT | × ÜBERFÄLLIG |
¶ 34. Import, Export und Datenqualität
Importe aus GRC-, Ticket-, Dokumenten- oder Prüfsystemen werden vor Übernahme validiert. Geprüft werden IDs, Pflichtfelder, Datumsformate, Wertelisten, Dubletten, Referenzen und Zeichencodierung. Fehlerhafte Datensätze gelangen in eine Klärungsliste statt unbemerkt in den Produktivbestand.
Exporte enthalten Zweck, Datenstand, Filter, Schutzklasse und verantwortliche Stelle. Sensible Spalten werden abhängig vom Empfänger entfernt oder pseudonymisiert. Tabellenexporte sind Arbeitskopien und ersetzen das führende Register nicht.
¶ 35. Archivierung, Löschung und Sperren
Aufbewahrungsregeln unterscheiden Original, Registermetadaten, Prüfprotokoll und externes Nachweispaket. Frist und Fristbeginn werden nachvollziehbar festgelegt. Bei Vorfall, Rechtsstreit, Behördenverfahren oder Audit kann eine Löschsperre erforderlich sein.
Nach Fristablauf wird kontrolliert archiviert oder gelöscht. Das Register hält gegebenenfalls einen minimalen Nachweis über Löschung, Sperre oder archivierte Vorgängerversion vor, ohne das entfernte Original wiederzugeben.
¶ 36. Qualitätsgate vor Freigabe
- Ist der Nachweisbedarf eindeutig und einer Anforderung zugeordnet?
- Sind relevanter Dienst, Scope, Zeitraum und Aussagegrenze erkennbar?
- Stimmen Original, Version, Quelle und Registerreferenz überein?
- Sind Authentizität, Integrität und Vollständigkeit angemessen geprüft?
- Belegt das Objekt Vorgabe, Umsetzung, Betrieb, Test oder Wirksamkeit korrekt?
- Sind Einschränkungen und ausgeschlossene Bereiche sichtbar?
- Sind Owner, Prüfer, Gültigkeit, Wiedervorlage und Aufbewahrung festgelegt?
- Ist der Schutz sensibler und personenbezogener Inhalte gewährleistet?
- Sind Lücken, Ersatznachweise und Folgemaßnahmen mit Risiko verknüpft?
- Ist eine mögliche externe Offenlegung ausdrücklich freigegeben?
Erst nach bestandenem Qualitätsgate erhält der Eintrag den dafür vorgesehenen Freigabestatus.
¶ 37. Häufige Fehler und Gegenmaßnahmen
| Fehler | Risiko/Folge | Gegenmaßnahme |
|---|---|---|
| Dateiablage wird als Register verwendet | keine Zuordnung, Frist oder Eignungsprüfung | strukturierte Metadaten und dauerhafte IDs |
| Richtlinie gilt als Wirksamkeitsnachweis | Aussage wird überdehnt | Aussageebene und Prüfkriterium erfassen |
| Screenshots ohne Kontext | nicht reproduzierbar | System, Zeit, Filter, Quelle und Scope dokumentieren |
| Zertifikat ohne Scopeprüfung | Dienst möglicherweise nicht abgedeckt | Einheit, Standort, Leistung und Ausschlüsse prüfen |
| sensible Originale im Wiki | unzulässige Offenlegung | nur Metadaten und geschützte Referenz veröffentlichen |
| Ablaufdatum wird verlängert | veraltete Aussage bleibt verborgen | dokumentierte Neubewertung oder Nachfolger |
| Nachweislücke wird als „nicht anwendbar“ markiert | fehlende Umsetzung wird verschleiert | Begründung, Prüfer und befugte Entscheidung verlangen |
| Versand per ungeschützter E-Mail | Kontrollverlust | freigegebenes Portal und Übertragungsprotokoll |
¶ 38. Offene Entscheidungen vor produktiver Nutzung
- führendes Register- und Dokumentensystem bestimmen,
- Nachweis-IDs, Pflichtfelder, Wertelisten und Statusmodell freigeben,
- Schutzklassen, Rollen und Berechtigungen festlegen,
- Integritäts- und Authentizitätsanforderungen je Nachweisart bestimmen,
- Gültigkeits-, Vorwarn-, Aufbewahrungs- und Löschregeln abstimmen,
- Qualitätsgate und fachliche Prüfer je Kontrollbereich benennen,
- Verfahren für Nachweispakete und sichere externe Übermittlung genehmigen,
- Anwendbarkeit und Ausgestaltung besonderer Nachweise nach § 39 BSIG prüfen,
- bestehende Nachweise stichprobenartig auf Scope und Aussagekraft bewerten.
Bis zur Entscheidung bleiben Status und Beispielwerte ausdrücklich als Entwurf gekennzeichnet.
¶ 39. Verknüpfte Seiten
- NIS2-Risikoregister
- NIS2-Risikomethodik
- Maßnahmenkatalog nach BSIG
- Wirksamkeitsprüfung
- ISMS-Nachweisregister
- Dokumentenlenkung
- Informationsklassifizierung
- Lieferantenbewertungen
¶ 40. Offizielle Grundlagen und Arbeitshilfen
- § 30 BSIG – Risikomanagementmaßnahmen besonders wichtiger und wichtiger Einrichtungen
- § 39 BSIG – Nachweispflichten für Betreiber kritischer Anlagen
- § 61 BSIG – Aufsichts- und Durchsetzungsmaßnahmen für besonders wichtige Einrichtungen
- § 62 BSIG – Aufsichts- und Durchsetzungsmaßnahmen für wichtige Einrichtungen
- EUR-Lex – Richtlinie (EU) 2022/2555
- BSI – Informationen für NIS2-regulierte Unternehmen
Rechtslage, behördliche Festlegungen und branchenspezifische Anforderungen werden vor einer realen Umsetzung aktuell geprüft. Die Links öffnen in einem neuen Tab.
¶ 41. Weiterführende Unterstützung durch SMCT MANAGEMENT
Unterstützung beim Aufbau prüffähiger NIS2-Nachweisstrukturen, bei der Zuordnung zu Risiken und Maßnahmen sowie bei geschützten Audit- und Behördenpaketen.
Informationen zur NIS2-Beratung öffnen
¶ 42. Änderungshistorie
| Version | Datum | Änderung | Freigabe |
|---|---|---|---|
| 0.3 | 09.08.2026 | Beweiskette, Pflichtabgrenzung, Ampeln, Mindestfelder, Aussageebenen, Integrität, Schutz, Rollen, technische und externe Nachweise, Nachweispakete, Kennzahlen und Qualitätsgate umfassend ergänzt | Ausstehend |
| 0.2 | 08.08.2026 | Rollen, Lebenszyklus, Qualitätsbewertung, Gültigkeit, Integrität, Auditpakete und Freigabekriterien vertieft | Ausstehend |
| 0.1 | 08.08.2026 | Leere Musterstruktur für kontrollierte NIS2-Nachweismetadaten erstellt | Ausstehend |