NIS2 im Betrieb: vom Geltungsbereich über Controls zum Nachweis

Marcel Rieger

Managing Director, Cyber Risk

Viele NIS2-Vorhaben im Mittelstand haben ein Startproblem und ein Dauerproblem. Das Startproblem ist ein unklarer Geltungsbereich. Das Dauerproblem sind Nachweise, die zum Projektende vollständig sind und zwölf Monate später veraltet. Dieser Artikel richtet sich an IT-Leitung und Informationssicherheitsbeauftragte und beschreibt eine Arbeitskette, die beides adressiert: Scope festlegen, Controls ableiten, Nachweise definieren, Betrieb organisieren.

Wie Sie das Umsetzungsprojekt selbst planen, mit Phasen, Workstreams und Ressourcen, steht im Beitrag NIS2-Umsetzung als Programm planen.

Zwei Ebenen von Scope

Der Begriff Scope wird in NIS2-Projekten für zwei verschiedene Dinge benutzt. Wer sie verwechselt, verliert Zeit.

Die erste Ebene ist die rechtliche Betroffenheit. Sie wird für die Einrichtung als Ganzes festgestellt, nach Sektor und Größe gemäß § 28 BSIG, im Konzern unter Einbeziehung verbundener Unternehmen. Das Ergebnis ist eine Einstufung als besonders wichtige oder wichtige Einrichtung, keine Systemliste.

Die zweite Ebene ist der technische Geltungsbereich. § 30 Absatz 1 BSIG bezieht die Maßnahmen auf die informationstechnischen Systeme, Komponenten und Prozesse, die die Einrichtung für die Erbringung ihrer Dienste nutzt. In einem Industrieunternehmen ist das in der Regel fast die gesamte zentrale IT: Identitäten und Verzeichnisdienst, E-Mail und Zusammenarbeit, ERP, Fertigungssteuerung, Netzwerk, Fernzugänge, Datensicherung. Eine Abgrenzung nach dem Muster "nur das Rechenzentrum" oder "nur die Produktlinie X", wie sie bei ISO-27001-Zertifikaten vorkommt, lässt sich bei NIS2 nach unserer Einschätzung selten begründen. Das BSI sieht das ähnlich: Das Gesetz verlangt die Maßnahmen nach seiner Auffassung für den gesamten relevanten Einrichtungsbetrieb. Zentrale Dienste wie Identitäten und E-Mail tragen fast jeden Geschäftsprozess.

Praktisch heißt das: Wenn Sie ein ISO-Zertifikat mit engem Geltungsbereich haben, prüfen Sie, welche Systeme außerhalb liegen und trotzdem unter § 30 fallen. Diese Liste ist Ihr erster Arbeitsauftrag.

Das Inventar als Grundlage

Ohne Inventar kein Scope. Sie brauchen keine perfekte Konfigurationsdatenbank, aber eine Liste, die vier Fragen beantwortet. Welche Geschäftsdienste erbringen wir? Welche Anwendungen und Systeme tragen sie? Wo laufen diese, im eigenen Netz, beim Dienstleister oder in der Cloud? Und wer ist fachlich und technisch verantwortlich?

Fangen Sie bei den Diensten an, nicht bei der Hardware. Ein Inventar mit 2.000 Endgeräten, aber ohne Zuordnung zu Prozessen, hilft bei der Risikoanalyse nicht weiter.

Controls aus § 30 ableiten

Die zehn Mindestmaßnahmen in § 30 Absatz 2 BSIG sind Themen, keine prüfbaren Anforderungen. Ihre Aufgabe ist, daraus ein Kontrollset zu machen, in dem jede Anforderung mit Ja oder Nein geprüft werden kann. Aus "Multi-Faktor-Authentifizierung" wird zum Beispiel: Alle Fernzugänge und alle administrativen Konten verlangen einen zweiten Faktor, Ausnahmen sind dokumentiert und befristet.

Erfinden Sie das Set nicht neu. Wenn Sie ISO 27001 oder den IT-Grundschutz nutzen, ordnen Sie die zehn Maßnahmen den vorhandenen Controls zu und ergänzen nur, was fehlt. Typische Ergänzungen sind die Meldewege nach § 32 BSIG und die Registrierung. Eine gute Quelle für Formulierungen und Nachweisbeispiele ist die Technical Implementation Guidance der ENISA vom Juni 2025. Sie ist formal für die Einrichtungsarten geschrieben, die unter die Durchführungsverordnung (EU) 2024/2690 fallen, etwa Cloud- und Rechenzentrumsanbieter oder Managed Service Provider. Für diese Einrichtungen hat die Verordnung nach § 30 Absatz 3 BSIG Vorrang. Als Steinbruch für Nachweisbeispiele taugt sie auch für andere Einrichtungen.

Schreiben Sie lieber weniger Anforderungen, die sich prüfen lassen, als viele, die niemand erfüllen will.

Für jedes Control einen Nachweis

Hier entscheidet sich, ob das Programm im Betrieb funktioniert. Legen Sie pro Control fünf Dinge fest:

• was als Nachweis gilt, zum Beispiel ein Bericht, ein Protokoll, ein Ticket oder ein Konfigurationsexport
• aus welchem System oder Prozess er stammt
• wer ihn erzeugt und wer ihn prüft
• wie oft er erneuert wird
• wo er abgelegt wird

Drei Beispiele zeigen, wie unterschiedlich das aussehen kann. Für die Datensicherung ist der Nachweis das Protokoll eines Wiederherstellungstests eines kritischen Systems, halbjährlich, erstellt vom Betrieb und abgezeichnet vom ISB. Für Berechtigungen ist es die quartalsweise Rezertifizierung privilegierter Konten durch die Fachverantwortlichen, mit dokumentierten Entzügen. Für die Lieferkette ist es die jährliche Bewertung der kritischen Dienstleister mit Ergebnis und Folgemaßnahmen.

Vermeiden Sie Nachweise, die nur für ein Audit entstehen. Gute Nachweise fallen im Betrieb ohnehin an und müssen nur gesammelt werden. Wo das nicht so ist, lohnt sich die Frage, ob der Prozess überhaupt läuft.

Das ist mehr als Ordnungsliebe. § 30 Absatz 1 BSIG verlangt ausdrücklich, dass die Einrichtung die Einhaltung dokumentiert, und eine fehlende Dokumentation ist nach § 65 BSIG ein eigener Bußgeldtatbestand. Bei besonders wichtigen Einrichtungen kann das BSI nach § 61 BSIG zudem Audits, Prüfungen oder Zertifizierungen durch unabhängige Stellen anordnen. Bei wichtigen Einrichtungen geht das nach § 62 BSIG, wenn Tatsachen die Annahme rechtfertigen, dass Pflichten nicht erfüllt werden.

Kontrollkalender und Wirksamkeit

Aus der Nachweistabelle entsteht ein Kontrollkalender: Was ist monatlich fällig, was quartalsweise, was jährlich? Bewährt hat sich, die Fälligkeiten als wiederkehrende Tickets im vorhandenen Ticketsystem anzulegen statt in einer separaten Tabelle. Dann sehen Sie Überfälligkeiten dort, wo die IT ohnehin arbeitet, und der Nachweis hängt direkt am Ticket.

§ 30 Absatz 2 Nummer 6 BSIG verlangt außerdem Konzepte und Verfahren, um die Wirksamkeit der Maßnahmen zu bewerten. Für den Anfang reichen wenige Kennzahlen, die sich ohne Handarbeit erheben lassen:

• Anteil der Konten mit zweitem Faktor, getrennt nach Benutzer- und Administrationskonten
• Alter der offenen kritischen Schwachstellen
• Anteil erfolgreicher Wiederherstellungstests
• Anteil überfälliger Kontrollen im Kalender

Wichtiger als die Zahl der Kennzahlen ist, dass jemand sie liest. Gehen Sie mit ihnen quartalsweise in die Geschäftsführung. Sie muss nach § 38 BSIG die Umsetzung überwachen und braucht dafür eine Grundlage. Wie ein solches Berichtswesen aufgebaut ist, beschreibt NIS2 Governance mit Reporting und KPIs.

Typische Fehler

Der Scope wird aus dem ISO-Zertifikat übernommen, ohne zu prüfen, ob er für NIS2 reicht. Controls werden aus einer Vorlage kopiert und enthalten Anforderungen, die niemand erfüllen will, die im Audit aber als Abweichung zählen. Nachweise liegen in persönlichen Postfächern und verschwinden mit dem nächsten Personalwechsel. Und die Wirksamkeitsmessung besteht aus einer Ampel, die seit Monaten auf Grün steht, weil niemand festgelegt hat, wann sie Gelb zeigt.

Wo Sie anfangen

Spielen Sie die Kette einmal für ein einzelnes Thema vollständig durch, etwa Datensicherung oder privilegierte Zugänge. Dabei sehen Sie schnell, wo Ihr Aufbau hakt, bevor Sie ihn auf alle zehn Maßnahmen ausrollen. Wir unterstützen IT-Leitungen dabei, Kontrollset und Nachweislogik aufzusetzen und in den Betrieb zu überführen. Die rechtliche Einordnung Ihres Unternehmens liefert vorab der NIS2-Check.