NIS2, DORA, NIST und der gemeinsame Kern der ISO-Managementsystemnormen koppeln ein Überprüfungsintervall jeweils an eine Liste von Ereignissen, und nur das Intervall passt in einen Kalender. Was jeder Text verlangt, wen er als Prüfer benennt und was die Überprüfung hinterlassen muss.
NIS2, DORA, NIST und der gemeinsame Kern der ISO-Managementsystemnormen koppeln ein Überprüfungsintervall jeweils an eine Liste von Ereignissen, und nur das Intervall passt in einen Kalender. Was jeder Text verlangt, wen er als Prüfer benennt und was die Überprüfung hinterlassen muss.
Nummer 1.1.2 des Anhangs der Durchführungsverordnung (EU) 2024/2690 der Kommission besteht aus einem Satz und einem kurzen zweiten:
„Das Konzept für die Sicherheit von Netz- und Informationssystemen wird von den Leitungsorganen mindestens jährlich sowie bei erheblichen Sicherheitsvorfällen oder wesentlichen Änderungen der Betriebsabläufe oder der Risiken überprüft und – soweit angemessen – aktualisiert. Das Ergebnis der Überprüfung wird dokumentiert."
Der Satz enthält vier getrennte Anforderungen. Es gibt eine Untergrenze für das Intervall: mindestens jährlich. Es gibt einen Ereignisauslöser: erhebliche Sicherheitsvorfälle oder wesentliche Änderungen der Betriebsabläufe oder der Risiken. Es gibt einen benannten Prüfer: die Leitungsorgane. Und es gibt einen Nachweis: Das Ergebnis wird dokumentiert. Nummer 1.1.1 Buchstabe k fügt ein fünftes Detail zum Konzept selbst hinzu. Es muss „das Datum der förmlichen Genehmigung durch die Leitungsorgane" enthalten.
Ein Überprüfungsdatum in einer Tabelle beantwortet die erste dieser Anforderungen. Die anderen drei brauchen etwas anderes.
Ein Wort zum Anwendungsbereich. Die Durchführungsverordnung gilt für eine bestimmte Liste von NIS2-Einrichtungen: DNS-Diensteanbieter, TLD-Namenregister, Anbieter von Cloud-Computing-Diensten und Rechenzentrumsdiensten, Betreiber von Inhaltszustellnetzen, Anbieter verwalteter Dienste und verwalteter Sicherheitsdienste, Anbieter von Online-Marktplätzen, Online-Suchmaschinen, Plattformen für Dienste sozialer Netzwerke sowie Vertrauensdiensteanbieter. Für alle anderen ist sie ein Referenztext, und ein nützlicher, weil sie Intervall, Ereignisse, Prüfer und Nachweis in einem Satz zusammenbringt.
Die meisten Texte überlassen Ihnen die Zahl. Die NIST- und ISO-Texte zitiere ich im englischen Original, jeweils mit einer sinngemässen deutschen Wiedergabe.
NIST SP 800-53 Rev. 5 eröffnet neunzehn ihrer Control-Familien mit einem Control zu Richtlinien und Verfahren. AC-1, für die Zugriffskontrolle, lautet unter Buchstabe (c):
"Review and update the current access control:1. Policy [Assignment: organization-defined frequency] and following [Assignment: organization-defined events]; and2. Procedures [Assignment: organization-defined frequency] and following [Assignment: organization-defined events]."
Sinngemäss: Die aktuelle Richtlinie und die aktuellen Verfahren zur Zugriffskontrolle werden jeweils in einer von der Organisation festgelegten Häufigkeit und nach von der Organisation festgelegten Ereignissen überprüft und aktualisiert.
Der Wortlaut zur Richtlinie ist in allen neunzehn identisch, von AC-1 bis SR-1. Die Häufigkeit legen Sie fest. Die Ereignisse ebenso. AC-1(b) verlangt ausserdem, dass Sie „an [Assignment: organization-defined official]" (sinngemäss: eine von der Organisation bestimmte verantwortliche Person) benennen, die die Richtlinie verwaltet. Der Katalog lässt Ihnen drei Lücken: ein Intervall, eine Liste von Ereignissen und eine Person.
Der gemeinsame Kern der ISO-Managementsystemnormen sagt zu Richtlinien noch weniger. ISO/IEC 27001 baut auf der Harmonisierten Struktur (Harmonized Structure) auf, dem gemeinsamen Text, den die Managementsystemnormen der ISO teilen. In ihrem normativen Text kommt „planned intervals" zweimal vor: für das interne Audit in 9.2.1 und für die Managementbewertung in 9.3.1:
"Top management shall review the organization's XXX management system, at planned intervals, to ensure its continuing suitability, adequacy and effectiveness."
Sinngemäss: Die oberste Leitung muss das XXX-Managementsystem der Organisation in geplanten Abständen bewerten, um seine fortdauernde Eignung, Angemessenheit und Wirksamkeit sicherzustellen.
ISO/IEC 27001 ergänzt diesen Kern um eigenen Text. Die Norm ist kostenpflichtig, und ich habe sie hier weder zitiert noch paraphrasiert. Der gemeinsame Text verlangt, dass Sie das Intervall planen, und nennt Ihnen keine Zahl.
Die EU-Texte setzen eine Untergrenze. Nummer 1.1.2 sagt „mindestens jährlich". DORA Art. 6(5) sagt, dass der IKT-Risikomanagementrahmen, der nach Art. 6(2) auch „Leit- und Richtlinien" umfasst, „mindestens einmal jährlich — bzw. im Falle von Kleinstunternehmen regelmäßig —" überprüft wird. Eine Untergrenze ist kein Intervall. Im Anhang der 2024/2690 kommt „planned intervals" (in der englischen Fassung) 30-mal vor und „at least annually" nur dreimal: für das Sicherheitskonzept, für die Risikobewertung und den Risikobehandlungsplan und für die Zuweisung von Personal zu Rollen. Überall sonst bleibt das Intervall der Einrichtung überlassen.
Kein Text lässt den Kalender allein stehen. Jeder nennt neben dem Intervall Ereignisse.
DORA Art. 6(5) hat die längste Liste:
„Der IKT-Risikomanagementrahmen wird mindestens einmal jährlich — bzw. im Falle von Kleinstunternehmen regelmäßig — sowie bei Auftreten schwerwiegender IKT-bezogener Vorfälle und nach aufsichtsrechtlichen Anweisungen oder Feststellungen, die sich aus einschlägigen Tests der digitalen operationalen Resilienz oder Auditverfahren ergeben, dokumentiert und überprüft."
Die Erläuterung (Discussion) zu NIST AC-1 nennt „assessment or audit findings, security incidents or breaches, or changes in laws, executive orders, directives, regulations, policies, standards, and guidelines" (sinngemäss: Feststellungen aus Bewertungen oder Audits, Sicherheitsvorfälle oder -verletzungen sowie Änderungen von Gesetzen, Executive Orders, Direktiven, Vorschriften, Richtlinien, Standards und Leitlinien). Die Harmonisierte Struktur legt die Ereignisse in die Managementbewertung selbst: 9.3.2 verlangt, dass die Bewertung „changes in external and internal issues that are relevant to the XXX management system" (sinngemäss: Veränderungen bei externen und internen Themen, die für das XXX-Managementsystem relevant sind) und „changes in needs and expectations of interested parties that are relevant to the XXX management system" (sinngemäss: Veränderungen bei den Erfordernissen und Erwartungen interessierter Parteien, die für das XXX-Managementsystem relevant sind) einbezieht.
| Text | Intervall | Ereignisse, die die Überprüfung vorziehen | Wer überprüft | Was bleibt |
|---|---|---|---|---|
| NIS2-DVO 2024/2690, 1.1.2 | Mindestens jährlich | Erhebliche Sicherheitsvorfälle; wesentliche Änderungen der Betriebsabläufe oder der Risiken | Leitungsorgane | „Das Ergebnis der Überprüfung wird dokumentiert." |
| DORA Art. 6(5); RTS 2024/1774 Art. 27 | Mindestens einmal jährlich (bei Kleinstunternehmen regelmässig) | Schwerwiegende IKT-bezogene Vorfälle; aufsichtsrechtliche Anweisungen; Feststellungen aus Tests oder Audits | Die im Bericht genannte Funktion | Ein Bericht über die Überprüfung, der Behörde auf Verlangen vorzulegen |
| NIST SP 800-53 AC-1 | Von der Organisation festgelegt | Von der Organisation festgelegt; die Erläuterung nennt Feststellungen, Vorfälle, Rechtsänderungen | Von der Organisation bestimmte verantwortliche Person | Aktualisierte Richtlinie und Verfahren |
| Harmonisierte Struktur der ISO, 9.3 | Geplante Abstände | Veränderungen bei internen und externen Themen und bei den Erfordernissen interessierter Parteien, als Input der Bewertung | Oberste Leitung | "Documented information … as evidence of the results" (dokumentierte Information als Nachweis der Ergebnisse) |
Die Intervallspalte ist die einfache. Setzen Sie ein Datum, und ein Tool kann Sie erinnern. Die Ereignisspalte ist schwieriger, weil das Ereignis nicht in der Richtlinie stattfindet. Es findet im Vorfallsregister statt, in einem Schreiben der Aufsicht, in einem Auditbericht, in einer Reorganisation, in einem neuen Vertrag. Auf der Seite der Richtlinie ändert sich nichts an dem Tag, an dem ein erheblicher Vorfall abgeschlossen wird. Jemand muss diese Tatsache zum Verantwortlichen der Richtlinie tragen und fragen, ob der Text noch stimmt.
Angenommen, ein erheblicher Vorfall im März zeigt, dass die Zugriffsrichtlinie nicht mehr dazu passt, wie Zugriff tatsächlich vergeben wird. Ist der Kalender der einzige Auslöser, wartet dieser Befund auf die jährliche Überprüfung im Januar. Das Intervall wurde eingehalten, der Ereignisauslöser nicht, und das Überprüfungsprotokoll zeigt keinen Fehler.
Schreiben Sie in der Praxis die Ereignisliste neben jede Richtlinie, so konkret wie möglich: „jeder als erheblich eingestufte Vorfall", „jeder Wechsel des Hosting-Anbieters", „jede neue Regulierung im Anwendungsbereich". Benennen Sie dann, wer dafür verantwortlich ist, das Ereignis zu bemerken und die Überprüfung anzustossen. Der Verantwortliche für das Vorfallsregister oder den Änderungsprozess ist für diese Aufgabe besser aufgestellt als der Verantwortliche der Richtlinie, der das Ereignis womöglich nie zu sehen bekommt.
Nummer 1.1.2 sagt „überprüft und – soweit angemessen – aktualisiert". Nummer 1.2.6 verwendet dasselbe Paar für Rollen, Verantwortlichkeiten und Weisungsbefugnisse. Das Paar trennt zwei Handlungen. Die Überprüfung ist ein Urteil darüber, ob der Text noch passt. Die Aktualisierung ist eine Änderung, und sie folgt nur, wenn das Urteil es verlangt.
Damit ist „keine Änderung nötig" ein legitimes Ergebnis einer Überprüfung, und auch dieses Ergebnis muss einen Nachweis hinterlassen. Nach 1.1.2 wird das Ergebnis dokumentiert, wie auch immer es ausfällt. Die Harmonisierte Struktur verlangt „review and approval for suitability and adequacy" (sinngemäss: Überprüfung und Genehmigung hinsichtlich Eignung und Angemessenheit), wenn dokumentierte Information erstellt und aktualisiert wird (7.5.2), und dokumentierte Information „as evidence of the results of management reviews" (sinngemäss: als Nachweis der Ergebnisse von Managementbewertungen) (9.3.3). Eine Richtlinie, deren letzte Version zwei Jahre alt ist und deren Akte seither keine Überprüfung zeigt, sagt einem Auditor eines von zwei Dingen, und keines hilft Ihnen: Niemand hat sie überprüft, oder jemand hat es getan und keine Spur hinterlassen.
Am weitesten gehen die technischen Standards zu DORA bei der Frage, was der Nachweis enthält. Art. 27(2) der Delegierten Verordnung (EU) 2024/1774 der Kommission legt den Inhalt des Berichts über die Überprüfung des Rahmens fest. Unter anderem enthält der Bericht:
„c) eine Beschreibung des Grunds für die Überprüfung des IKT-Risikomanagementrahmens nach Artikel 6 Absatz 5 der Verordnung (EU) 2022/2554;d) das Anfangs- und Enddatum des Überprüfungszeitraums;e) eine Angabe der für die Überprüfung verantwortlichen Funktion;"
Verlangt wird ausserdem „eine Liste aller bisherigen Überprüfungen". Wurde die Überprüfung nach IKT-bezogenen Vorfällen eingeleitet, „so muss der Bericht eine Liste aller IKT-bezogenen Vorfälle mit einer Analyse der Ursachen dieser Vorfälle enthalten". Nach Art. 2(2) derselben Verordnung müssen die IKT-Sicherheitsrichtlinien „das Datum der förmlichen Genehmigung der IKT-Sicherheitsrichtlinien durch das Leitungsorgan enthalten".
Der Grund ist das Feld, das eine Liste von Daten nicht fassen kann. Ein Protokoll mit einer Zeile pro Jahr zeigt, dass das Intervall eingehalten wurde. Es sagt nichts darüber, ob je eine Überprüfung durch ein Ereignis ausgelöst wurde. Steht in jeder Zeile „jährlich", kann ein Auditor mit gutem Grund fragen, was nach dem Vorfall geschah, den Sie im letzten Frühjahr gemeldet haben.
Ein brauchbarer Überprüfungsnachweis hat deshalb fünf Teile: das Datum, die Person oder Rolle, die geurteilt hat, den Auslöser (das Intervall oder ein benanntes Ereignis), das Ergebnis (keine Änderung oder eine neue Version) und eine kurze Begründung. Die Begründung kann ein Satz sein: „Nach der Hosting-Migration überprüft; Abschnitt zum Zugriff weiterhin zutreffend."
devguard hat mit App 2.2.0 regelmässige Überprüfungszyklen für Richtlinien, Aufzeichnungen, Nachweise und Zuweisungen eingeführt. Der Teil für Richtlinien folgt den oben beschriebenen Unterscheidungen, und er deckt nur die Kalenderhälfte ab.
Eine Richtlinie trägt einen Überprüfungszeitplan, ausgewählt aus den gemeinsamen Zeitplänen der Organisation. Das nächste Überprüfungsdatum wird aus diesem Zeitplan abgeleitet und auf der Richtlinie zusammen mit dem Datum der letzten Überprüfung angezeigt; ist das Datum verstrichen, wird die Richtlinie als überfällig markiert. Die Genehmigung einer neuen Version zählt als Überprüfung und setzt die Uhr zurück. Eine Überprüfung, die zu dem Schluss kommt, dass keine Änderung nötig ist, wird mit Als überprüft markieren festgehalten; das setzt das Datum, ohne eine Version zu veröffentlichen. Nur Mitglieder der Genehmigungsrolle der Richtlinie können sie als überprüft markieren. Dieselbe Rolle wird vor dem Datum erinnert und erneut, wenn die Überprüfung überfällig ist, und fällige Überprüfungen erscheinen auf der Seite Fristen. In der Rollenliste zählt eine Spalte Verantwortlich für pro Rolle die Richtlinien, die sie genehmigt. Diese Zahl ist die Überprüfungslast, die eine Person mit dem Beitritt zur Rolle übernimmt. Wird der Text einer veröffentlichten Richtlinie bearbeitet, geht sie zurück in den Entwurf, bis eine neue Version genehmigt ist.
[screenshot: die Karte „Regelmässige Überprüfung" im Richtlinien-Editor, mit Überprüfungszeitplan, „Nächste Prüfung", „Zuletzt überprüft" und der Schaltfläche „Als überprüft markieren"]
Aus der Bauweise folgen drei Grenzen.
Erstens erkennt devguard den Ereignisauslöser nicht. Der Abschluss eines erheblichen Vorfalls oder der Wechsel eines Anbieters verschiebt kein Überprüfungsdatum einer Richtlinie. Die einzige Änderung, die es bemerkt, ist eine Bearbeitung des Richtlinientexts selbst. Jemand muss die Richtlinie nach dem Ereignis öffnen und die Überprüfung festhalten.
Zweitens wird das nächste Datum ab der letzten Überprüfung gezählt. Bei einem einfachen jährlichen Zeitplan ist eine Richtlinie, die zwei Monate zu spät überprüft wurde, ein Jahr nach dieser verspäteten Überprüfung wieder fällig; eine verspätete Überprüfung verschiebt also jedes spätere Datum. Ein Zeitplan, der an ein Kalenderdatum gebunden ist, etwa jeden 15. Januar, vermeidet diese Drift, um den Preis eines kurzen Zyklus nach einer verspäteten Überprüfung.
Drittens hält Als überprüft markieren im Aktivitätsprotokoll fest, wer und wann, und sonst nichts. Eine Begründung nimmt es nicht auf. Der Auslöser und die Begründung in einem Satz aus dem vorigen Abschnitt gehören in den Kommentarverlauf der Richtlinie, und sie dort zu erfassen, ist ein eigener Schritt, den das Produkt nicht erzwingt.
Bevor die nächste jährliche Überprüfung ansteht, schreiben Sie neben jede Richtlinie zwei Spalten: das Intervall mit dem Grund, warum Sie es gewählt haben, und die Ereignisse, die die Überprüfung vorziehen würden, jeweils mit der Rolle, die sie anstossen muss.
devguard leitet das nächste Überprüfungsdatum jeder Richtlinie aus dem hinterlegten Zeitplan ab und erinnert die Genehmigungsrolle, wenn es fällig wird; Details stehen im Changelog.
Starten Sie kostenlos, bringen Sie Ihre Frameworks mit, und die Nachweise bleiben an der Arbeit, während sie ausgeliefert wird, ohne Setup-Reibung, ohne Feuerwehrübung in der Audit-Woche.
Starten Sie kostenlos, bringen Sie Ihre Frameworks mit, und die Nachweise bleiben an der Arbeit, während sie ausgeliefert wird, ohne Setup-Reibung, ohne Feuerwehrübung in der Audit-Woche.