¶ NIS2-Wirksamkeitsprüfung
Leeres Musterverfahren: Diese öffentliche Beispielseite enthält keine realen Testergebnisse, Sicherheitslücken, Kontrollbewertungen, Systemdaten, Lieferantennachweise oder Managementfreigaben. Farben und Musterzeilen erläutern ausschließlich das vorgesehene Prüfverfahren.
Wirksamkeit muss belegt werden: Eine Richtlinie, ein installiertes Werkzeug, eine Konfiguration oder ein einmal durchgeführter Test bestätigt noch keine nachhaltige Wirksamkeit. Maßgeblich sind vorher festgelegte Kriterien, geeignete Daten, ein nachvollziehbarer Scope und eine befugte Bewertung.
¶ Dokumenteninformationen
| Feld | Wert |
|---|---|
| Dokumenten-ID | NIS2-MA-02-06 |
| Dokumentenart | Prüfverfahren und Registerstruktur für die Wirksamkeit von NIS2-Risikomanagementmaßnahmen |
| Wiki.js-Pfad | /NIS2/02-Risikomanagement-und-Nachweise/Wirksamkeitspruefung |
| Verantwortlich | Control Owner; Prüfkoordination; unabhängige prüfende Rolle je Kontrollart |
| Status | Entwurf – keine realen Kontrollen geprüft oder als wirksam bestätigt |
| Version / Stand | 0.3 / 09.08.2026 |
| Schutzklasse | Wiki enthält Methodik und Muster; Test-, Schwachstellen- und Betriebsdaten geschützt |
| Rechtsbezug | insbesondere § 30 Absatz 2 Nummer 6 BSIG; abhängig von der Einrichtungsart EU-Vorgaben |
| Freigabe | Ausstehend; Kontrolluniversum, Kriterien, Frequenzen und Prüferrollen festzulegen |
Kontrollwirkung mit belastbaren Kriterien, Daten, unabhängiger Bewertung und nachvollziehbarer Aussagegrenze bestätigen. Eigene redaktionelle SVG-Grafik. Zum Vergrößern öffnen.
¶ 1. Prüf-Cockpit – Muster ohne Echtdaten
Das Cockpit zeigt die vorgesehene Steuerungsansicht. Ein Gedankenstrich bedeutet: Auf dieser Musterseite liegt kein realer Messwert vor. Fehlende Werte dürfen nicht als Null, bestandene Prüfung oder wirksame Kontrolle 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, Kontrolluniversum, Risikosicht, Datenquelle, Prüfabdeckung und Aussagegrenze. Die Zahl durchgeführter Tests sagt allein nichts über die Wirksamkeit aus.
¶ 2. Zweck und Arbeitsergebnisse
Die Wirksamkeitsprüfung beantwortet für eine konkrete Kontrolle und einen definierten Scope:
- Ist die Kontrolle geeignet entworfen?
- Ist sie vollständig und korrekt umgesetzt?
- Funktioniert sie im tatsächlichen Betrieb über den erforderlichen Zeitraum?
- Reduziert sie das zugeordnete Risiko wie erwartet?
- Welche Restlücken, Unsicherheiten und Restrisiken verbleiben?
- Welche Nachbesserung, Nachprüfung oder Leitungsentscheidung ist erforderlich?
Arbeitsergebnisse sind Prüfauftrag, Prüfplan, kontrollierte Nachweise, Ergebnisbewertung, Feststellungen, Folgemaßnahmen, Nachprüfung und aktualisierte Restrisikobewertung.
¶ 3. Rechtlicher Rahmen
§ 30 Absatz 1 BSIG verlangt geeignete, verhältnismäßige und wirksame technische und organisatorische Maßnahmen. § 30 Absatz 2 Nummer 6 nennt ausdrücklich Konzepte und Verfahren zur Bewertung der Wirksamkeit von Risikomanagementmaßnahmen im Bereich der Sicherheit in der Informationstechnik.
Für die in § 30 Absatz 3 genannten digitalen Einrichtungsarten hat die Durchführungsverordnung (EU) 2024/2690 Vorrang. Sie konkretisiert unter anderem regelmäßige Sicherheitstests, die Nutzung der Testergebnisse für die Wirksamkeitsbewertung und unabhängige Überprüfungen. Vor Übernahme konkreter Anforderungen wird geprüft, ob die Organisation und der Dienst in ihren Anwendungsbereich fallen.
Das Musterverfahren ist keine Rechtsberatung und kein positiver NIS2-Nachweis.
¶ 4. Vier Ebenen der Aussage
| Ebene | Leitfrage | Typischer Nachweis |
|---|---|---|
| Vorgabe | Ist Ziel, Verantwortung und Verfahren genehmigt beschrieben? | Richtlinie, Verfahren, Rollenentscheidung |
| Umsetzung | Wurde die Kontrolle im vorgesehenen Scope eingerichtet? | Konfiguration, Ticket, Abnahme, Schulung |
| Funktion | Arbeitet die Kontrolle bei einem definierten Test wie vorgesehen? | Funktions-, Wiederherstellungs- oder Sicherheitstest |
| Wirksamkeit | Reduziert die Kontrolle das reale Risiko nachhaltig innerhalb der festgelegten Toleranz? | Betriebsdaten, Trend, Stichprobe, Übung und unabhängige Bewertung |
Eine Aussage auf niedrigerer Ebene darf nicht als höhere Ebene berichtet werden. Eine freigegebene Richtlinie belegt keine technische Umsetzung; ein erfolgreicher Einzeltest belegt nicht automatisch nachhaltige Betriebswirksamkeit.
¶ 5. Design- und Betriebswirksamkeit
Designwirksamkeit bewertet, ob die Kontrolle bei korrekter Umsetzung grundsätzlich geeignet ist, das definierte Risiko im vorgesehenen Scope zu reduzieren. Dazu gehören Architektur, Prozess, Rollen, Frequenz, Abdeckung und Reaktionsweg.
Betriebswirksamkeit bewertet, ob die Kontrolle tatsächlich, vollständig, rechtzeitig und über einen angemessenen Zeitraum funktioniert. Beide Bewertungen werden getrennt dokumentiert. Eine gut entworfene, aber unzureichend betriebene Kontrolle ist nicht wirksam.
¶ 6. Kontrolluniversum
Das Kontrolluniversum ist die vollständige, versionierte Liste der zu prüfenden Kontrollen. Jede Kontrolle erhält:
- Kontroll-ID und verständlichen Titel,
- Kontrollziel und zugeordnetes Risiko,
- relevante Dienste, Systeme, Standorte und Anbieter,
- Control Owner und ausführende Rollen,
- Kontrollart: präventiv, detektiv, korrektiv oder wiederherstellend,
- Ausführung: manuell, technisch automatisiert oder kombiniert,
- Frequenz und erwartete Abdeckung,
- geplante Prüfart und Prüfturnus,
- Nachweis- und Datenquellen,
- letzte Bewertung und nächste Fälligkeit.
Das Kontrolluniversum wird mit Risiko-, Maßnahmen- und Nachweisregister verknüpft.
¶ 7. Prüfidentität und Versionierung
Jede Prüfung erhält eine dauerhafte ID, beispielsweise NIS2-WP-2026-001. Wiederholungs- und Nachprüfungen werden als verbundene Prüfungen geführt, nicht als unkontrollierte Überschreibung.
Erfasst werden Version des Prüfauftrags, Stichtag, tatsächlicher Prüfzeitraum, Prüfer, verwendete Kriterien, Datenstand, Abweichungen vom Plan und Freigabestatus. Änderungen nach Berichtserstellung erzeugen eine neue Version oder ein dokumentiertes Addendum.
¶ 8. Wirksamkeitshypothese
Vor der Prüfung wird formuliert, warum die Kontrolle das Risiko reduzieren soll:
Wenn [Kontrolle] im [Scope] mit [Frequenz/Abdeckung] betrieben wird, dann sinkt [Wahrscheinlichkeit/Auswirkung/Erkennungs- oder Wiederherstellungszeit], weil [Wirkmechanismus]. Dies wird anhand von [Daten/Methode] gegen [Kriterium/Toleranz] im Zeitraum [Zeitraum] geprüft.
Die Hypothese verhindert, dass beliebige leicht verfügbare Kennzahlen nachträglich als Wirksamkeitsbeleg verwendet werden.
¶ 9. Kontrollziel und Prüffrage
Das Kontrollziel beschreibt den erwarteten Sicherheitszustand. Die Prüffrage ist konkret und beantwortbar. Beispielhafte Musterfragen sind:
- Werden privilegierte Zugriffe vollständig genehmigt, protokolliert und regelmäßig überprüft?
- Kann ein definierter Musterdienst innerhalb genehmigter Ziele wiederhergestellt werden?
- Werden kritische Musterereignisse innerhalb der festgelegten Zeit erkannt und bearbeitet?
- Werden Lieferantenabweichungen für relevante Beispieldienste termingerecht eskaliert?
Die tatsächlichen Zielwerte werden aus Risiko, Dienstanforderung und genehmigter Toleranz abgeleitet.
¶ 10. Kriterien und Toleranzen
Ein Prüfkriterium enthält:
- Mess- oder Beobachtungsgröße,
- Sollwert beziehungsweise erwarteten Zustand,
- zulässige Toleranz und Bestehensregel,
- Scope und Zeitraum,
- Datenquelle und Berechnung,
- Umgang mit Ausnahmen und fehlenden Daten,
- Eskalationsschwelle.
Kriterien werden vor Beginn der Prüfung genehmigt. Nachträgliche Anpassungen werden transparent als Planabweichung dokumentiert.
¶ 11. Ergebnisampel
Kriterien im geprüften Scope erfüllt; Aussagegrenzen und Review bleiben dokumentiert.
Wirkung vorhanden, aber relevante Lücken, Ausnahmen oder Scopegrenzen bestehen.
Wesentliches Kriterium nicht erfüllt oder Kontrollwirkung nicht ausreichend.
Daten, Scope, Prüfbarkeit oder Unabhängigkeit reichen für eine Aussage nicht aus.
„Nicht bewertbar“ ist kein positives Ergebnis. Es erzeugt eine Folgeaktion zur Herstellung der Prüfbarkeit oder eine Risikoentscheidung.
¶ 12. Prüfstatus
„Abgeschlossen“ bezeichnet den Prüfprozess, nicht automatisch ein wirksames Ergebnis.
¶ 13. Prüfarten
Je nach Kontrollziel kommen einzeln oder kombiniert in Betracht:
- Dokumenten- und Designprüfung,
- Konfigurations- und Berechtigungsprüfung,
- Beobachtung eines realen Arbeitsablaufs,
- Stichprobe von Fällen, Konten, Assets oder Lieferanten,
- automatisierter oder manueller Sicherheitstest,
- Schwachstellenscan oder Penetrationstest,
- Wiederherstellungs- und Wiederanlauftest,
- Notfall-, Krisen- oder Kommunikationsübung,
- Auswertung von Betriebsereignissen, Kennzahlen und Trends,
- unabhängiges Audit oder qualifizierte externe Prüfung.
Methode und Kombination richten sich nach Risiko, Kontrollart, Scope und verfügbarer Evidenz.
¶ 14. Risikobasierte Prüfplanung
Der Prüfplan priorisiert:
- Kontrollen für kritische oder wichtige Dienste,
- hohe und kritische Risiken,
- neue oder wesentlich veränderte Kontrollen,
- Kontrollen mit geringer Nachweissicherheit,
- frühere Feststellungen und nicht bestandene Prüfungen,
- häufige Ausnahmen oder manuelle Umgehungsmöglichkeiten,
- wesentliche Lieferanten- und Konzentrationsabhängigkeiten,
- Anforderungen mit verbindlichen Prüf- oder Berichtsterminen.
Kontrollen mit geringerer Priorität bleiben im Kontrolluniversum und erhalten einen begründeten Turnus.
¶ 15. Prüffrequenz und Auslöser
Der Turnus berücksichtigt Risiko, Dienstwirkung, Kontrollfrequenz, Änderungsrate, Vorfälle, Datenqualität und externe Anforderungen. Neben planmäßigen Prüfungen lösen insbesondere folgende Ereignisse eine anlassbezogene Prüfung aus:
- wesentliche Änderung an Architektur, Prozess oder Anbieter,
- erheblicher Sicherheitsvorfall oder Beinaheereignis,
- neue kritische Schwachstelle oder Bedrohung,
- fehlgeschlagener Test oder wiederkehrende Ausnahme,
- deutliche Verschlechterung einer Kennzahl,
- Ablauf einer Zwischenmaßnahme oder Risikoakzeptanz,
- neue Rechts-, Aufsichts- oder Vertragsanforderung.
¶ 16. Prüfauftrag – Mindestfelder
| Feldgruppe | Mindestinhalt |
|---|---|
| Identität | Prüf-ID, Titel, Version, Anlass und Stichtag |
| Ziel | Kontrolle, Risiko, Dienst und erwartete Wirkung |
| Scope | Systeme, Prozesse, Standorte, Anbieter, Zeitraum und Ausschlüsse |
| Kriterien | Sollzustand, Toleranz, Bestehensregel und Eskalationsschwelle |
| Methode | Prüfschritte, Stichprobe, Werkzeuge, Datenquellen und Sicherheitsvorkehrungen |
| Rollen | Auftraggeber, Control Owner, Prüfer, Freigeber und Berichtsempfänger |
| Unabhängigkeit | Interessenkonflikte, Kompensationen und Einschränkungen |
| Nachweise | benötigte Originale, Datenstände und Integritätsmerkmale |
| Ergebnis | Feststellungen, Bewertung, Aussagegrenze und Restrisiko |
| Folge | Korrekturmaßnahme, Owner, Termin, Nachprüfung und Eskalation |
¶ 17. Unabhängigkeit
Wer eine Kontrolle plant oder betreibt, liefert Fachwissen und Nachweise, sollte ihre Wirksamkeit bei wesentlichen Risiken aber nicht allein bestätigen. Abhängig vom Risiko können eingesetzt werden:
- Vier-Augen-Prüfung durch eine andere qualifizierte Rolle,
- getrennte fachliche und technische Bewertung,
- interne Revision oder unabhängige Prüffunktion,
- externe Prüfung,
- Rotation der Prüfer.
Interessenkonflikte und organisatorische Einschränkungen werden offen dokumentiert.
¶ 18. Kompetenz der Prüfenden
Prüfer benötigen Kenntnisse der Kontrolltechnologie, des Geschäfts- und Dienstkontexts, der Prüfmethode und des sicheren Umgangs mit Ergebnissen. Für technische Tests können besondere Qualifikation, Freigabe und Haftungsregel erforderlich sein.
Kompetenz wird über Rolle, Erfahrung, Schulung, Zertifizierung oder beaufsichtigte Praxis nachvollziehbar gemacht. Ein Zertifikat allein ersetzt nicht die Eignung für den konkreten Prüfauftrag.
¶ 19. Grundgesamtheit und Stichprobe
Vor der Auswahl werden Grundgesamtheit, Zeitraum und Vollständigkeit bestimmt. Die Stichprobe berücksichtigt Risiko, Häufigkeit, Standorte, Rollen, Systeme, Anbieter, Ausnahmefälle und frühere Fehler. Auswahlmethode und Zufalls- oder Ermessenselemente werden dokumentiert.
Bequeme oder ausschließlich erfolgreiche Fälle sind nicht repräsentativ. Die Aussage wird auf den tatsächlich geprüften Umfang begrenzt.
¶ 20. Stichprobengröße und Aussagegrenze
Die Stichprobengröße wird nicht pauschal aus einer Mustertabelle übernommen. Sie richtet sich nach Grundgesamtheit, erwarteter Fehlerquote, Kontrollfrequenz, Risiko, Homogenität und gewünschter Aussage. Bei kleinen oder kritischen Grundgesamtheiten kann Vollprüfung angemessen sein.
Abweichungen in der Stichprobe werden daraufhin bewertet, ob Ausweitung, Ursachenanalyse oder sofortige Eskalation erforderlich ist.
¶ 21. Datenqualität
Prüfdaten werden bewertet hinsichtlich:
- Vollständigkeit und Abdeckung,
- Richtigkeit und Konsistenz,
- Zeitbezug, Zeitzone und Aktualität,
- Herkunft und verantwortlichem System,
- Integrität und Veränderungsschutz,
- Filter, Ausschlüssen und Aggregation,
- bekannten Blindstellen und Ausfällen,
- Personenbezug und Schutzbedarf.
Fehlende Daten führen nicht automatisch zu einem positiven Ergebnis. Sie können die Bewertung einschränken oder unmöglich machen.
¶ 22. Automatisierte Kennzahlen
Dashboards und Reports werden auf Datenquelle, Berechnung, Filter, Aktualisierung und Manipulationsschutz geprüft. Ein grünes Dashboard kann falsch sein, wenn Quellen unvollständig, Zeiträume ungeeignet oder Ausnahmen herausgefiltert sind.
Für jede Kennzahl werden Definition, Owner, Ziel, Toleranz, Eskalation und Datenqualitätskontrolle geführt.
¶ 23. Sichere technische Tests
Technische Tests benötigen genehmigten Scope, Zeitfenster, Ansprechpartner, Abbruchkriterien, Backup, Rückfallplan und Kommunikationsweg. Produktive Auswirkungen, Datenschutz, Lieferantenbedingungen und mögliche Meldepflichten werden vorab berücksichtigt.
Rohdaten, Zugangsinformationen und Schwachstellendetails bleiben geschützt. Ungeplante kritische Erkenntnisse werden über einen festgelegten Sofortweg eskaliert.
¶ 24. Konfigurations- und Berechtigungsprüfungen
Konfigurationsprüfungen dokumentieren System, Version, Baseline, Erfassungszeitpunkt, Abfrage, Ausnahmen und tatsächlichen Scope. Berechtigungsprüfungen betrachten Genehmigung, Funktionstrennung, privilegierte Rechte, verwaiste Konten, Rezertifizierung und technische Durchsetzung.
Eine Sollkonfiguration ohne Vergleich zum produktiven Ist-Zustand belegt keine Betriebswirksamkeit.
¶ 25. Wiederherstellungs- und Wiederanlauftests
Die Prüfung umfasst nicht nur erfolgreiche Datensicherung, sondern je nach Scope:
- Verfügbarkeit und Integrität der Sicherung,
- Wiederherstellung unter realistischen Bedingungen,
- Erreichen genehmigter Wiederanlauf- und Datenverlustziele,
- Abhängigkeiten, Schlüssel, Zugänge und Dokumentation,
- Entscheidung und Kommunikation im Notbetrieb,
- Übergang zurück in den Regelbetrieb.
Ein Teiltest wird nicht als vollständiger Dienst-Wiederanlauftest ausgewiesen.
¶ 26. Notfall- und Krisenübungen
Übungen prüfen Rollen, Entscheidungen, Erreichbarkeit, Informationsfluss, technische und organisatorische Maßnahmen sowie Rückkehr zum Normalbetrieb. Szenario, Lernziele, Beobachter, Einspielungen, Abbruchregeln und Auswertung werden vorab festgelegt.
Die Leistung einzelner Personen wird nicht öffentlich dargestellt. Im Vordergrund stehen System-, Prozess- und Schnittstellenlernen.
¶ 27. Lieferantenkontrollen
Bei ausgelagerten Kontrollen wird geprüft, welche Leistung der Anbieter tatsächlich erbringt und welche Verantwortung bei der Einrichtung verbleibt. Zertifikate und Prüfberichte werden auf Scope, Standort, Dienst, Zeitraum, Ausschlüsse und relevante Feststellungen bewertet.
Eigene Konfiguration, Schnittstellen, Berechtigungen, Notfallverfahren und Ausstiegsfähigkeit bleiben häufig separat zu prüfen.
¶ 28. Dreiecksprüfung der Evidenz
Eine belastbare Bewertung kombiniert nach Möglichkeit mehrere Perspektiven:
- Vorgabe und Design: Was soll geschehen und warum?
- Umsetzung und Konfiguration: Was ist tatsächlich eingerichtet?
- Betrieb und Ergebnis: Was geschieht über Zeit und mit welcher Wirkung?
Widersprechen sich Quellen, wird die Ursache geklärt. Eine Selbstauskunft wird nicht ohne weitere Evidenz als alleiniger Wirksamkeitsbeleg verwendet.
¶ 29. Durchführung und Abweichungen vom Prüfplan
Die Durchführung dokumentiert tatsächlichen Scope, Prüfschritte, Datenstände, Beobachtungen, verwendete Werkzeuge und Abweichungen vom Plan. Ausgelassene Systeme, verkürzte Zeiträume oder geänderte Stichproben werden mit Ursache und Auswirkung auf die Aussage festgehalten.
Wird der Test unsicher oder unzulässig, wird er kontrolliert abgebrochen. Abbruch ist ein Prüfstatus, kein negatives Wirksamkeitsurteil ohne weitere Bewertung.
¶ 30. Feststellungen
Jede Feststellung enthält:
- Feststellungs-ID und Bezug zu Kontrolle, Risiko und Dienst,
- Sollkriterium und beobachteten Sachverhalt,
- geprüften Scope und belastbare Nachweise,
- Auswirkung und Priorität,
- unmittelbare Sicherungsmaßnahme,
- Ursachenanalyse und nachhaltige Korrektur,
- Owner, Termin und Nachprüfung,
- Restrisiko und Eskalationsbedarf.
Beobachtung, Ursache und Bewertung werden sprachlich getrennt.
¶ 31. Ursachenanalyse
Die Ursachenanalyse betrachtet nicht nur den sichtbaren Fehler, sondern mögliche Beiträge aus Prozess, Technik, Kompetenz, Rollen, Ressourcen, Lieferanten, Anreizen und Überwachung. Methoden können beispielsweise 5-Why, Ursachenbaum oder Barrieranalyse sein.
„Menschlicher Fehler“ ist ohne Untersuchung von Rahmenbedingungen und Kontrollen selten eine ausreichende Ursache.
¶ 32. Sofortmaßnahme und nachhaltige Korrektur
Sofortmaßnahmen begrenzen akute Auswirkungen. Nachhaltige Korrekturen beseitigen Ursachen oder verstärken Barrieren. Beide erhalten getrennte Owner, Termine und Nachweise.
Eine kurzfristige manuelle Kontrolle wird befristet, überwacht und mit der dauerhaften Lösung verknüpft.
¶ 33. Nachprüfung
Nach Umsetzung einer Korrektur wird geprüft, ob
- die Maßnahme vollständig umgesetzt wurde,
- die ursprüngliche Feststellung behoben ist,
- keine wesentlichen Nebenwirkungen entstanden sind,
- die Kontrolle im Betrieb wirksam funktioniert,
- das Restrisiko neu bewertet werden kann.
Die Nachprüfung verwendet ein geeignetes Kriterium und ist nicht auf die Sichtprüfung eines geschlossenen Tickets beschränkt.
¶ 34. Restrisiko und Entscheidung
Das Restrisiko wird auf Basis der tatsächlich nachgewiesenen Wirkung aktualisiert. Berücksichtigt werden verbleibende Lücken, Unsicherheiten, Scopegrenzen, neue Risiken und Frühwarnindikatoren. Das Ergebnis wird mit der genehmigten Risikotoleranz verglichen.
Ein Restrisiko oberhalb der Toleranz führt zu weiterer Behandlung, befugter befristeter Akzeptanz oder Eskalation. Die Wirksamkeitsprüfung selbst erteilt keine Risikoakzeptanz.
¶ 35. Prüfbericht
Der Bericht enthält mindestens:
- Auftrag, Ziel, Scope und Zeitraum,
- Kontrolle, Risiko und Dienstbezug,
- Kriterien, Methode und Stichprobe,
- Prüfer, Kompetenz und Unabhängigkeit,
- Datenquellen und Datenqualität,
- Beobachtungen, Feststellungen und Bewertung,
- Aussagegrenzen und nicht geprüfte Bereiche,
- Restrisiko, Maßnahmen und Nachprüfung,
- Empfänger, Schutzklasse und Freigabe.
Eine Managementzusammenfassung ersetzt nicht den geschützten Detailbericht.
¶ 36. Managementbericht
Die Geschäftsleitung erhält eine verdichtete, aber entscheidungsfähige Sicht:
- Abdeckung kritischer Kontrollen und Dienste,
- nicht wirksame und nicht bewertbare Kontrollen,
- wesentliche Feststellungen und Restrisiken,
- überfällige Korrekturen und Nachprüfungen,
- Datenqualitäts- und Ressourcenprobleme,
- wiederkehrende oder systemische Ursachen,
- benötigte Entscheidungen, Budgets und Eskalationen.
Prüfabdeckung und Prüfergebnis werden getrennt ausgewiesen.
¶ 37. Kennzahlen
| Kennzahl | Steuerungszweck und Grenze |
|---|---|
| kritische Kontrollen ohne aktuelle Prüfung | zeigt Prüflücken, nicht automatisch Unwirksamkeit |
| nicht wirksam/teilweise wirksam nach Risikostufe | priorisiert Nachsteuerung |
| nicht bewertbare Kontrollen | macht Prüfbarkeits- und Datenprobleme sichtbar |
| überfällige Korrekturen/Nachprüfungen | unterstützt Eskalation |
| wiederkehrende Feststellungen | weist auf systemische Ursachen hin |
| technisch umgesetzt, aber ohne Betriebsnachweis | zeigt offene Wirksamkeitslücke |
| Zeit bis nachhaltiger Abschluss | zeigt Bearbeitungsgeschwindigkeit, nicht allein Qualität |
| Prüfungen mit Scope- oder Datenbeschränkung | macht Aussagegrenzen transparent |
¶ 38. Trend- und Gesamtbewertung
Einzelprüfungen werden über Zeit und Kontrollen hinweg ausgewertet. Wiederkehrende Abweichungen, sinkende Datenqualität, zunehmende Ausnahmen, häufige Testabbrüche oder lange Korrekturzeiten können systemische Probleme anzeigen.
Trends berücksichtigen Änderungen von Scope, Methode und Datenquelle. Sonst sind Zeitreihen möglicherweise nicht vergleichbar.
¶ 39. Falsch positive und falsch negative Ergebnisse
Prüfverfahren können Fehler produzieren. Falsch positiv bedeutet, eine Kontrolle erscheint unwirksam, obwohl das Ergebnis durch Test- oder Datenfehler entstand. Falsch negativ bedeutet, eine Kontrolle erscheint wirksam, obwohl Lücken nicht erkannt wurden.
Kalibrierung, unabhängige Gegenprüfung, geeignete Testdaten und triangulierte Evidenz reduzieren dieses Risiko. Unsicherheit wird berichtet statt verborgen.
¶ 40. Fiktive Musterprüfungen
Die folgenden Zeilen sind reine Demonstrationsdaten. Sie enthalten keine realen Tests oder Wirksamkeitsaussagen.
| ID | fiktive Kontrolle | fiktiver Scope | Prüfstatus | Ergebnis | Folge |
|---|---|---|---|---|---|
| DEMO-WP-001 | Wiederherstellung eines Beispieldienstes | Muster-Rechenzentrum | ◇ IN DURCHFÜHRUNG | ○ NICHT BEWERTBAR | Datenprüfung offen |
| DEMO-WP-002 | Review privilegierter Musterkonten | Beispielplattform | ▲ BEWERTUNG OFFEN | ! TEILWEISE WIRKSAM | fiktive Nachprüfung geplant |
| DEMO-WP-003 | Lieferanteneskalation für Beispieldienst B | fiktiver Anbieter | ○ GEPLANT | × KEIN ERGEBNIS | keine reale Prüfung |
¶ 41. Filter- und Arbeitsansichten
Nützliche Ansichten sind:
- Prüfungen je relevantem Dienst, Risiko und Control Owner,
- kritische Kontrollen ohne aktuellen Wirksamkeitsnachweis,
- geplante und fällige Prüfungen,
- nicht wirksame oder teilweise wirksame Kontrollen,
- nicht bewertbare Ergebnisse nach Ursache,
- überfällige Feststellungen und Nachprüfungen,
- Prüfungen mit eingeschränkter Datenqualität,
- Lieferantenkontrollen und externe Nachweise,
- wiederkehrende Feststellungen und systemische Trends.
Filter ändern nicht den Status. Exporte tragen Stichtag und Filterkriterien.
¶ 42. Schutz und Aufbewahrung
Prüfberichte, Rohdaten, Schwachstellen, Konfigurationen, Zugangsinformationen und personenbezogene Daten werden entsprechend Schutzbedarf gespeichert. Das Wiki führt nur Methodik, Status und kontrollierte Referenzen.
Aufbewahrung, Löschung, Sperren und externe Offenlegung werden mit Recht, Datenschutz, Vertrag und Nachweisbedarf abgestimmt. Unkontrollierte lokale Kopien werden vermieden.
¶ 43. Qualitätsgate vor Berichtfreigabe
- Sind Kontrollziel, Risiko, Dienst, Scope und Zeitraum eindeutig?
- Wurden Hypothese, Kriterien und Toleranz vorab festgelegt?
- Sind Methode, Stichprobe und Datenquellen geeignet?
- Sind Datenqualität, Prüferkompetenz und Unabhängigkeit bewertet?
- Wurden tatsächliche Planabweichungen und Ausschlüsse dokumentiert?
- Trennen Bericht und Ampel Umsetzung, Funktion und Wirksamkeit?
- Sind Feststellungen mit Ursache, Maßnahme, Owner und Termin verbunden?
- Sind Nachprüfung, Restrisiko und Eskalation festgelegt?
- Sind Aussagegrenzen und nicht bewertbare Bereiche sichtbar?
- Sind sensible Originale und personenbezogene Daten geschützt?
Erst nach bestandenem Qualitätsgate wird der Bericht freigegeben.
¶ 44. Häufige Fehler und Gegenmaßnahmen
| Fehler | Folge | Gegenmaßnahme |
|---|---|---|
| Richtlinie gilt als Wirksamkeitsbeleg | Vorgabe wird mit Wirkung verwechselt | vier Aussageebenen getrennt bewerten |
| Kriterien werden nach dem Test angepasst | Ergebnis wird geschönt | Kriterien und Toleranzen vorab genehmigen |
| bequeme Stichprobe | Aussage nicht repräsentativ | Grundgesamtheit und Auswahlmethode dokumentieren |
| grünes Dashboard ohne Datenprüfung | Scheinsicherheit | Quelle, Filter und Vollständigkeit validieren |
| Betreiber bestätigt sich selbst | Interessenkonflikt | unabhängige Gegenprüfung nach Risiko |
| Teiltest wird als Gesamtprüfung berichtet | Scope wird überdehnt | Aussagegrenze sichtbar angeben |
| geschlossenes Ticket = behobene Ursache | Wiederholung wahrscheinlich | nachhaltige Korrektur und Nachprüfung verlangen |
| „nicht bewertbar“ wird als bestanden behandelt | Prüflücke verborgen | Folgeaktion und Risikoentscheidung auslösen |
¶ 45. Offene Entscheidungen vor produktiver Nutzung
- Kontrolluniversum und Kontroll-IDs freigeben,
- Wirksamkeitshypothesen und Kriterien je Kontrollgruppe festlegen,
- risikobasierten Prüfplan und Frequenzen genehmigen,
- Stichproben- und Datenqualitätsregeln bestimmen,
- Prüferkompetenz, Unabhängigkeit und Eskalation festlegen,
- sichere technische Test- und Abbruchverfahren genehmigen,
- Bericht-, Feststellungs- und Nachprüfungsvorlagen freigeben,
- geschützte Nachweis- und Rohdatenablage einrichten,
- Managementkennzahlen und Berichtstakt beschließen,
- technische, organisatorische und Resilienzkontrollen pilotieren.
Bis zur Entscheidung bleiben sämtliche Musterstatus ausdrücklich Entwurf.
¶ 46. Verknüpfte Seiten
- Maßnahmenkatalog nach BSIG
- NIS2-Risikoregister
- Risikobehandlungsplan
- NIS2-Nachweisregister
- Verhältnismäßigkeit und Stand der Technik
- ISMS Wirksamkeitsmessungen
- Interne Audits
- Managementbewertung
- Abweichungen und Korrekturmaßnahmen
¶ 47. Offizielle Grundlagen
- § 30 BSIG – Risikomanagementmaßnahmen, insbesondere Absatz 2 Nummer 6
- EUR-Lex – Durchführungsverordnung (EU) 2024/2690 für bestimmte digitale Einrichtungsarten
- EUR-Lex – Richtlinie (EU) 2022/2555, insbesondere Artikel 21
- BSI – IT-Grundschutz als mögliche fachliche Orientierung
Anwendbarkeit, Rechtsstand, Prüfkriterien und Geltungsbereich der Quellen werden vor realen Prüfungen aktuell bewertet. Die Links öffnen in einem neuen Tab.
¶ 48. Weiterführende Unterstützung durch SMCT MANAGEMENT
Unterstützung bei risikobasierten Prüfplänen, Wirksamkeitshypothesen, Stichproben, sicheren Tests, Feststellungen, Nachprüfungen und Managementberichten.
Informationen zur NIS2-Beratung öffnen
¶ 49. Änderungshistorie
| Version | Datum | Änderung | Freigabe |
|---|---|---|---|
| 0.3 | 09.08.2026 | Aussageebenen, Design- und Betriebswirksamkeit, Kontrolluniversum, Hypothesen, Kriterien, Ergebnis- und Statusampeln, Prüfarten, Stichproben, Datenqualität, technische Tests, Nachprüfung, Restrisiko, Kennzahlen und Qualitätsgate umfassend ergänzt | Ausstehend |
| 0.2 | 08.08.2026 | Kontrollziele, Prüfplanung, Stichproben, Unabhängigkeit, Ergebnissicherung, Folgemaßnahmen und Trendbewertung vertieft | Ausstehend |
| 0.1 | 08.08.2026 | Musterverfahren für Kriterien, Prüfungen und Folgemaßnahmen erstellt | Ausstehend |