NIS2 listet zehn Massnahmenbereiche auf und lässt die Leitungsorgane das Ergebnis billigen; die Durchführungsverordnung (EU) 2024/2690 erwartet für jede Risikobehandlungsmassnahme eine benannte Verantwortung und einen Termin. Die Aufgabenliste zwischen der Übernahme des Frameworks und dem bestandenen Audit müssen Sie selbst ableiten. Drei Eigenschaften lassen sie einen Audittermin überstehen.
NIS2 listet zehn Massnahmenbereiche auf und lässt die Leitungsorgane das Ergebnis billigen; die Durchführungsverordnung (EU) 2024/2690 erwartet für jede Risikobehandlungsmassnahme eine benannte Verantwortung und einen Termin. Die Aufgabenliste zwischen der Übernahme des Frameworks und dem bestandenen Audit müssen Sie selbst ableiten. Drei Eigenschaften lassen sie einen Audittermin überstehen.
Das Framework ist übernommen, das Kickoff vorbei, und in irgendjemandes Kalender steht ein Audittermin. Der nächste Morgen bringt eine sehr konkrete Frage: Was genau wird jetzt getan, und wer übernimmt welches Stück? Der Text, für den Sie das Framework übernommen haben, wird sie nicht beantworten. NIS2 Art. 21(1) verlangt von Einrichtungen, «geeignete und verhältnismäßige technische, operative und organisatorische Maßnahmen» zu ergreifen, «um die Risiken für die Sicherheit der Netz- und Informationssysteme […] zu beherrschen». Das ist ein einziger Satz, der Monate an Arbeit erzeugt und nichts davon auflistet. Zwischen «wir haben das Framework übernommen» und «wir haben das Audit bestanden» liegt eine Aufgabenliste, die jemand schreiben muss, und es gibt drei wiederkehrende Arten, auf die das schiefgeht. Alle drei sind im Regulierungstext selbst sichtbar, also möchte ich dort anfangen.
Ein Hinweis zur deutschen Fassung dieses Beitrags: Zitate aus NIS2 und der Durchführungsverordnung (EU) 2024/2690 folgen der amtlichen deutschen Fassung auf EUR-Lex; die ENISA-Guidance liegt nur auf Englisch vor und wird im Original zitiert.
Lesen wir, was Art. 21(2) tatsächlich aufzählt. Er rahmt die Massnahmen als «gefahrenübergreifenden Ansatz», der «zumindest Folgendes umfassen» muss, und gibt dann zehn Punkte. Zwei davon vollständig. Buchstabe b: «Bewältigung von Sicherheitsvorfällen;». Buchstabe d: «Sicherheit der Lieferkette einschließlich sicherheitsbezogener Aspekte der Beziehungen zwischen den einzelnen Einrichtungen und ihren unmittelbaren Anbietern oder Diensteanbietern;». Die übrigen acht haben dieselbe Form: Konzepte für Risikoanalyse, Aufrechterhaltung des Betriebs und Krisenmanagement, Sicherheit bei Erwerb und Entwicklung einschliesslich Umgang mit Schwachstellen, Wirksamkeitsbewertung, Cyberhygiene und Schulungen, Kryptografie, Personalsicherheit samt Zugriffskontrolle und Anlagenmanagement, Multi-Faktor-Authentifizierung und gesicherte Kommunikation. Jeder Punkt ist eine Überschrift über Arbeit, die die Richtlinie nicht aufzählt. Und «zumindest» macht die Liste zu einer Untergrenze; selbst die volle Abdeckung der zehn Überschriften ist also nicht automatisch die ganze Aufgabe.
Art. 20(1) macht jemanden für die Lücke zwischen Überschrift und Arbeit verantwortlich: «Die Mitgliedstaaten stellen sicher, dass die Leitungsorgane wesentlicher und wichtiger Einrichtungen die von diesen Einrichtungen zur Einhaltung von Artikel 21 ergriffenen Risikomanagementmaßnahmen im Bereich der Cybersicherheit billigen, ihre Umsetzung überwachen und für Verstöße gegen diesen Artikel durch die betreffenden Einrichtungen verantwortlich gemacht werden können.» Billigung und Überwachung brauchen ein Objekt. Ein Leitungsorgan kann «Bewältigung von Sicherheitsvorfällen» nicht sinnvoll billigen; billigen kann es einen konkreten Satz von Massnahmen mit Verantwortlichen und Terminen.
Eine Ebene konkreter wurde die Kommission in der Durchführungsverordnung (EU) 2024/2690. Seien wir ehrlich beim Geltungsbereich, bevor wir uns darauf stützen: Nach ihrem Art. 1 bindet sie einen bestimmten Kreis von Einrichtungsarten (DNS-Diensteanbieter, TLD-Namenregister, Cloud-Computing- und Rechenzentrumsanbieter, Betreiber von Inhaltszustellnetzen, Anbieter verwalteter Dienste und verwalteter Sicherheitsdienste, Online-Marktplätze, Online-Suchmaschinen, Plattformen für Dienste sozialer Netzwerke und Vertrauensdiensteanbieter). Für alle anderen funktioniert sie als Konkretisierung der Kommission, was Art. 21(2) in der Praxis bedeutet, und was sie erwartet, ist Planungsvokabular. Anhang Nummer 2.1.2 Buchstabe i lässt Einrichtungen «ermitteln, wer für die Umsetzung der Maßnahmen für die Behandlung von Risiken verantwortlich ist und wann diese erfolgen sollte». Nach Nummer 2.1.4 bewerten sie «die Ergebnisse der Risikobewertung und den Risikobehandlungsplan in geplanten Zeitabständen und mindestens jährlich» und aktualisieren sie, «soweit angemessen». Die Formulierung «in geplanten Zeitabständen» kehrt im ganzen Anhang wieder, von den Rollen (1.2.6) über die Risikobehandlung (2.1.4) bis zur Sicherheitsprüfung (6.5.3). Wer, wann, überprüft nach Zeitplan: Das ist eine Aufgabenliste, beschrieben in Verordnungsprosa. Ein Vorbehalt, da NIS2 eine Richtlinie ist: Die Pflichten erreichen Einrichtungen über die nationale Umsetzung, die die Mitgliedstaaten bis zum 17. Oktober 2024 zu erlassen hatten (Art. 41(1)).
Der verlockende Weg zur Liste ist ein Workshop. Leute, die die Organisation kennen, schreiben auf, was zu tun ist, und das Ergebnis sieht vernünftig aus. Mein Problem damit: Seine Vollständigkeit ist Glück, weil nichts die Liste mit den Pflichten verbindet. Ein Massnahmenbereich, an den im Raum niemand gedacht hat, erzeugt null Aufgaben, und niemand bemerkt es, weil Abwesenheit auf einer Liste unsichtbar ist. Das Audit ist der Ort, an dem die Lücke auftaucht, und die Richtlinie benennt bereits, was dann folgt: Eine Einrichtung, die feststellt, dass sie den Massnahmen nach Art. 21(2) nicht nachkommt, ergreift «unverzüglich alle erforderlichen, angemessenen und verhältnismäßigen Korrekturmaßnahmen» (Art. 21(4)). Aufzählungslücken beim Audit zu entdecken ist die teure Form der Aufzählung.
Die Alternative ist Ableitung: das übernommene Framework Anforderung für Anforderung durchgehen und fragen, welche Arbeit jede einzelne für Ihre Organisation impliziert. Das ist mechanisch genug, dass eine Regulierungsbehörde es öffentlich vorgemacht hat. ENISAs Technical Implementation Guidance (Juni 2025) geht die 2024/2690 Punkt für Punkt durch; die eigene Strukturnotiz: "Each requirement is followed by three elements: guidance, examples of evidence and tips". Für Anhang Nummer 1.2.1, die Zuweisung von Sicherheitsverantwortlichkeiten, enthält die Guidance unter anderem "Assign security roles and responsibilities to personnel and include these roles in the organisational chart", und zu den Evidenzbeispielen gehören "Job descriptions" und eine "List of security roles, who occupies them and contact information". ENISA stellt ausdrücklich fest, die Guidance sei "not legally binding" und "non-exhaustive"; behandeln Sie sie also als Beleg dafür, dass die Abbildung von Anforderung auf Aufgabe ableitbar ist, nicht als Liste zum Kopieren. Die Eigenschaft, die es zu behalten gilt: Jede Aufgabe auf Ihrer Liste sollte auf die Anforderung zurückführen, der sie dient. Nachverfolgbarkeit macht aus «wir haben viel gearbeitet» ein «wir haben das Framework abgedeckt», und sie ist der Unterschied, den ein Auditor tatsächlich prüfen kann.
Der zweite Fehler ist langsamer. Die Liste ist vollständig, und jede Zeile hat einen Namen in der Spalte für Verantwortliche. Bis das Audit kommt, haben einige dieser Personen das Team gewechselt oder sind gegangen. Aufgaben, die jemandem zugewiesen sind, der weg ist, sind Waisen; das Organigramm hat sich geändert und die Liste nicht. Nichts Dramatisches markiert den Moment, in dem das passiert, und deshalb bleibt es unbemerkt.
Das eigene Vokabular der Verordnung zeigt auf die Lösung. Nach Anhang Nummer 1.2.1 der 2024/2690 legen Einrichtungen «Verantwortlichkeiten und Weisungsbefugnisse für die Sicherheit von Netz- und Informationssystemen» fest und «ordnen sie den Rollen zu». Das Substantiv, das die Verordnung wählt, ist «Rollen». Eine Rolle überlebt eine Kündigung, und die Überprüfung, die Nummer 1.2.6 erwartet — Rollen werden «von den Leitungsorganen in geplanten Zeitabständen sowie bei erheblichen Sicherheitsvorfällen oder wesentlichen Änderungen der Betriebsabläufe oder der Risiken überprüft und – soweit angemessen – aktualisiert» — hat ein stabiles Objekt zu überprüfen. Verantwortung per Rolle heisst: «Auf wessen Tisch liegt das?» hat eine aktuelle Antwort, nämlich wer die Rolle heute innehat, ohne jede Archäologie. Die Zuweisung an eine benannte Einzelperson hat weiterhin ihren Platz: echte Einmalaufgaben, bei denen die Arbeit einer Person gehört statt einer Funktion. Was zählt, ist der Standard, und ich würde ihn jedes Mal auf Rollen setzen. Ist der Standard Personen, zerfällt die Liste mit der Geschwindigkeit Ihrer Fluktuation. Ist der Standard Rollen, zerfällt sie nur, wenn sich das Design der Organisation ändert — und die Überprüfung nach 1.2.6 ist genau der Moment, das aufzufangen.
Mit einer abgeleiteten Liste in Rollenverantwortung schafft der Audittermin die dritte Versuchung: einen Plan bauen — eine Zeitplan-Tabelle, eine Folie mit Phasen, ein Gantt-Diagramm. Ich bin inzwischen überzeugt, dass der zweite Plan der leiseste der drei Fehlermodi ist, weil er nach Sorgfalt aussieht, während er passiert. In dem Moment, in dem der Plan ein zweites Artefakt ist, beginnt er zu driften: Die Arbeit ändert sich täglich, und der Plan wird im Takt von Meetings aktualisiert. Aufgaben schliessen verspätet, neue Aufgaben entstehen aus einer Risikobewertung, und der Plan beschreibt nun ein Projekt, das es nicht mehr gibt. Überprüfungen «in geplanten Zeitabständen» richten sich dann auf das Artefakt statt auf die Arbeit, und sie werden bestanden.
Der Plan, der nicht driften kann, ist eine Sicht: dieselbe Aufgabenliste, nach Zeit gefiltert und gruppiert. Vom Audittermin rückwärts zu planen heisst dann genau eines: Fristen auf den echten Aufgaben setzen, sodass sich die offene Arbeit über das Fenster zwischen jetzt und dem Termin verteilt. Zwei Eigenschaften folgen ohne Mehrkosten. Überfällig wird berechenbar und erscheint dort, wo die Arbeit lebt, weil die Frist auf der Aufgabe sitzt statt in einem Paralleldokument. Und Fortschritt braucht keinen separaten Statusbericht; Sie zählen die Aufgaben.
Damit ist die werkzeugneutrale Fassung komplett. Eine Aufgabenliste übersteht den Kontakt mit einem Audittermin, wenn sie drei Eigenschaften hat:
Jeder Issue-Tracker kann das halten. Eine Tabelle auch, wenn Fristen und Verantwortliche in den Aufgabenzeilen leben und nirgendwo sonst.
Diese drei Eigenschaften waren der Entwurfsauftrag für devguards Module Tasks und Roadmap. So haben wir sie gebaut, plus ein Verhalten, das Sie kennen sollten, bevor Sie sich darauf verlassen.
Ableitung ist Seeding: Die Übernahme eines Frameworks legt die Aufgaben an, die dessen Vorlagen beschreiben, pro Organisation. Eine Aufgabe, die einem Control dient, ist von ihrer Anlage an mit diesem Control verknüpft; Nachverfolgbarkeit ist damit eingebaut und nicht einer Namenskonvention überlassen. Wer dasselbe Framework zweimal übernimmt, bekommt nie doppelte Aufgaben; Arbeit, die bereits existiert, bleibt unangetastet. Jede Aufgabe durchläuft dieselben einfachen Status — offen, in Arbeit, in Prüfung, erledigt oder abgebrochen.
Die Verantwortung folgt dem Rollen-zuerst-Argument: Verantwortlich für eine Aufgabe ist entweder eine Person oder eine Business-Rolle, nie beides. Diesen Standard haben wir bewusst so gewählt — Personen besitzen keine Einträge; Rollen tun es. Eine Aufgabe bezieht sich auf höchstens einen Eintrag: eine Policy, ein Evidenz-Item, ein Risiko, ein Asset, einen Lieferanten oder ein Audit.
Die Roadmap ist die Sicht im strengen Sinn: Sie speichert nichts Eigenes ausser dem Zieldatum, das Sie für die Übernahme wählen; alles, was sie zeigt, wird live aus den Aufgaben gelesen. Darum besitzt die Roadmap nichts: Eine Sicht kann nicht von der Arbeit wegdriften. Planen heisst, ein Zieldatum mindestens zwei Wochen in der Zukunft zu wählen; näher liegende Termine werden abgelehnt. Die offenen Aufgaben werden dann von einer Woche nach der Planung bis zum Zieldatum verteilt, wobei jede Frist auf dem Freitag ihrer Woche landet, sodass sich die Roadmap als wöchentliche Arbeitspakete liest. Fortschritt wird als Zählung berichtet, erledigt gegen offen und offene Aufgaben über der Frist, bewusst ohne ein «on track»-Label.
Das Verhalten, das Sie kennen sollten, ist das Re-Planning. Ein Re-Plan terminiert nur die offenen geseedeten Aufgaben neu. Erledigte und abgebrochene Aufgaben behalten ihre Termine, und von Hand angelegte Aufgaben werden nie angefasst. Aber die Grenze schneidet auch in die andere Richtung: Eine von Hand gesetzte Frist auf einer offenen geseedeten Aufgabe ist nicht geschützt. Ein Re-Plan gibt jeder offenen geseedeten Aufgabe eine frische geplante Frist, von Hand gesetzte Termine eingeschlossen. Das ist der Tausch, den wir gewählt haben: Die Roadmap bleibt eine reine Funktion aus Zieldatum plus offener Arbeit, um den Preis, dass sie manuelle Terminänderungen in ihrem Inneren nicht respektiert.
Eine Grenze ist Absicht: Tasks sind menschliche Arbeit. Die geplante Erstellung von Tickets in externen Systemen lebt in einem separaten Actions-Modul.
Alles andere ist eine Sicht auf sie oder ein Input in sie: Die Risikobewertung erweitert sie (das Wer-und-Wann aus 2.1.2 Buchstabe i wird zu Zeilen), die Roadmap fragt sie ab, der Statusbericht zählt sie. Bekommen Sie die drei Eigenschaften richtig hin, wird der Audittermin zu einem Satz Fristen auf Arbeit, die Sie bereits sehen können. Was nach dem Bestehen passiert, ist ein anderes Problem — den Zustand halten statt ihn erreichen — und das hat seinen eigenen Beitrag: Audit-ready is a state you keep.
Die oben beschriebene Seeding-, Zuweisungs- und Roadmap-Mechanik ist devguards Tasks-Modul, Teil von devguard.ch/platform.
Start free, bring your frameworks, and keep the evidence attached as the work ships — no setup friction, no audit-week fire drill.
Start free, bring your frameworks, and keep the evidence attached as the work ships — no setup friction, no audit-week fire drill.