Handbuch zur NIS2-Projektorganisation im Betrieb

Wenn ein NIS2-Vorhaben erst bei einer Sicherheitsprüfung sichtbar wird, ist die Projektorganisation bereits zu spät aufgesetzt. Ein Handbuch zur NIS2-Projektorganisation schafft den Rahmen, um Anforderungen in Verantwortlichkeiten, Maßnahmen, Nachweise und einen steuerbaren Betrieb zu überführen. Entscheidend ist dabei nicht die Anzahl der Arbeitspakete, sondern ob IT, Informationssicherheit, Fachbereiche, Einkauf und Management an denselben Risiken und Entscheidungswegen arbeiten.

NIS2 ist kein isoliertes Security-Projekt. In vielen Unternehmen berührt die Umsetzung gewachsene SAP-Landschaften, Identity- und Berechtigungskonzepte, Schnittstellen zu Lieferanten, Cloud-Dienste, OT-nahe Systeme sowie Notfall- und Meldeprozesse. Eine wirksame Projektorganisation muss diese Abhängigkeiten sichtbar machen, ohne den Betrieb durch zusätzliche Gremien zu blockieren.

Warum die NIS2-Projektorganisation häufig scheitert

Der typische Fehler liegt in einer zu engen Zuordnung: Die Informationssicherheit soll NIS2 umsetzen, während Fachbereiche, Plattformteams und Prozessverantwortliche nur punktuell beteiligt werden. Dadurch entstehen Risikoanalysen, die kritische Datenflüsse oder Betriebsabhängigkeiten nicht ausreichend abbilden. Maßnahmen bleiben dann auf Richtlinienebene, obwohl ihre Umsetzung etwa Änderungen an Rollenmodellen, Backup-Konzepten, Monitoring oder Lieferantensteuerung verlangt.

Auch ein reines Compliance-Projekt greift zu kurz. Regulatorische Anforderungen müssen rechtlich eingeordnet werden, ihre tatsächliche Wirksamkeit entsteht jedoch im technischen und organisatorischen Betrieb. Wer etwa einen Meldeprozess definiert, muss klären, welche Betriebsdaten verfügbar sind, wer einen Vorfall bewertet, wer Entscheidungen freigibt und wie die Kommunikation revisionssicher dokumentiert wird.

Die Projektorganisation sollte deshalb nicht als dauerhaftes Parallelkonstrukt geplant werden. Ihr Ziel ist ein belastbarer Übergang in bestehende Steuerungs- und Betriebsmodelle. Was im Projekt geklärt wird, muss später durch Linienverantwortliche, Service Owner und Kontrollinstanzen fortgeführt werden können.

Handbuch zur NIS2-Projektorganisation: Der richtige Zuschnitt

Am Anfang steht keine Maßnahmenliste, sondern die Abgrenzung des Vorhabens. Unternehmen sollten feststellen, welche Gesellschaften, Dienste, Standorte, Systeme und ausgelagerten Leistungen betroffen sein könnten. Diese Einordnung ist zugleich rechtlich und technisch anspruchsvoll. Insbesondere bei Unternehmensgruppen, hybriden Betriebsmodellen und geteilten IT-Services reichen Organigramme allein nicht aus.

Für die rechtliche Bewertung von Anwendungsbereich, Pflichten und konkreten Meldeanforderungen sollte die rechtlich eigenständige Quteco Rechtsanwaltsgesellschaft mbH eingebunden werden. Die Projektorganisation benötigt dieses Ergebnis als belastbare Entscheidungsgrundlage. Sie ersetzt keine rechtliche Bewertung durch technische Annahmen.

Auf dieser Basis empfiehlt sich ein Kernteam mit klaren Entscheidungsrechten. Die Projektleitung steuert Terminplan, Abhängigkeiten und Eskalationen. Die Informationssicherheit verantwortet Sicherheitsanforderungen und Risikobewertungen. IT- und Service-Verantwortliche bewerten Machbarkeit, Betriebsfolgen und technische Nachweise. Fachbereiche liefern die Perspektive auf kritische Prozesse, während Einkauf und Lieferantenmanagement Verträge, Dienstleister und externe Abhängigkeiten einbringen.

Die Geschäftsleitung oder ein beauftragtes Steuerungsgremium braucht mehr als Statusberichte. Es entscheidet über Risikobereitschaft, Prioritäten, Budgets und Ausnahmen. Gerade bei Maßnahmen mit Betriebsrisiko - etwa Härtungen produktiver Schnittstellen oder Anpassungen privilegierter Berechtigungen - müssen Entscheidungen nachvollziehbar dokumentiert sein.

Rollen nicht nur benennen, sondern verbindlich machen

Eine RACI-Matrix kann hilfreich sein, wenn sie konkrete Ergebnisse regelt. Für jede Maßnahme sollte feststehen, wer sie ausführt, wer fachlich verantwortlich ist, wer eine Freigabe erteilt und wer informiert wird. Allgemeine Einträge wie „IT“ oder „Security“ sind dafür zu ungenau. Sinnvoller sind Rollen wie SAP Basis Lead, Identity Owner, Service Owner für einen kritischen Dienst oder Verantwortliche für Lieferantenrisiken.

Besonders relevant ist die Trennung von Umsetzung und Kontrolle. Wer ein Logging-Konzept betreibt, sollte nicht allein dessen Wirksamkeit bewerten. Gleiches gilt für Tests von Notfallmaßnahmen. Unabhängige Prüf- oder Kontrollhandlungen schaffen belastbarere Nachweise und machen Schwachstellen früher sichtbar.

Vom Risiko zur umsetzbaren Maßnahmensteuerung

Die Risikobewertung ist das verbindende Element zwischen Regulierung und Projektarbeit. Sie sollte nicht als einmaliges Dokument entstehen, sondern als priorisierte Sicht auf geschäftskritische Leistungen, Bedrohungen, Schutzmaßnahmen und Restrisiken. In ERP- und SAP-Umgebungen betrifft das beispielsweise die Verfügbarkeit zentraler Geschäftsprozesse, die Integrität von Stamm- und Bewegungsdaten, Schnittstellen zu Logistik oder Produktion sowie die Absicherung privilegierter Zugriffe.

Aus Risiken werden Maßnahmenpakete, die jeweils einen verantwortlichen Owner, einen Zieltermin, Abhängigkeiten und einen prüfbaren Abschlussnachweis erhalten. Ein Beispiel: Die Maßnahme „Notfallwiederherstellung verbessern“ ist zu unbestimmt. Aussagekräftiger ist ein Paket, das Wiederanlaufziele für priorisierte Anwendungen festlegt, Wiederherstellungstests plant, Ergebnisse dokumentiert und Abweichungen einer Entscheidung zuführt.

Nicht jede Lücke muss sofort geschlossen werden. Es kann sachgerecht sein, eine Maßnahme nach Geschäftskritikalität, technischem Risiko und Umsetzungsaufwand zu staffeln. Voraussetzung ist, dass Übergangsrisiken transparent sind, kompensierende Kontrollen benannt werden und das zuständige Gremium die Entscheidung trägt. Aufgeschobene Maßnahmen ohne Eigentümer und Termin sind dagegen kein Risikomanagement, sondern ein Dokumentationsdefizit.

Steuerung über wenige belastbare Artefakte

Ein praxistaugliches Projekt braucht keine umfangreiche Parallelablage. Es braucht Unterlagen, die Entscheidungen und Nachweise verbinden: einen abgestimmten Geltungsbereich, ein Risiko- und Maßnahmenregister, eine Verantwortungsmatrix, eine Liste kritischer Dienstleister, einen Test- und Nachweisplan sowie ein Eskalations- und Reportingformat. Je nach Ausgangslage können ergänzend Architekturübersichten, Datenflussanalysen und Berechtigungskonzepte erforderlich sein.

Diese Artefakte sollten an bestehende Prozesse anschließen. Wenn Changes über ein etabliertes Change-Management laufen, müssen NIS2-relevante Änderungen dort sichtbar werden. Wenn Audit-Feststellungen bereits zentral verwaltet werden, sollte kein zweites Maßnahmenregister entstehen. Der Nutzen liegt in einer konsistenten Steuerung, nicht in zusätzlichen Dokumenten.

Nachweise entstehen im Betrieb, nicht im Abschlussbericht

Ein häufiges Risiko liegt in der Übergabe nach Projektende. Richtlinien, Konzepte und Testprotokolle sind nur dann belastbar, wenn sie durch wiederkehrende Betriebsprozesse aktualisiert werden. Dazu gehören regelmäßige Risikoüberprüfungen, Übungen für Sicherheitsvorfälle, technische Kontrollen, Lieferantenbewertungen und die Nachverfolgung von Maßnahmen.

Für SAP- und Integrationslandschaften sollte die Betriebsübergabe auch konkrete Kontrollfragen beantworten: Werden kritische Berechtigungen regelmäßig geprüft? Sind Schnittstellen und Datenflüsse in der aktuellen Architektur dokumentiert? Lassen sich Sicherheitsereignisse aus zentralen Systemen auswerten? Wurden Wiederanlauf- und Wiederherstellungstests unter realistischen Bedingungen durchgeführt? Die Antworten müssen nicht perfekt sein, aber sie müssen fachlich belastbar und nachvollziehbar sein.

Ein Management-Reporting sollte deshalb nicht nur den Anteil erledigter Maßnahmen zeigen. Aussagekräftiger sind überfällige Maßnahmen mit Geschäftsrisiko, offene Entscheidungen, kritische Abhängigkeiten zu Dienstleistern, Ergebnisse aus Tests und die Entwicklung wesentlicher Restrisiken. So wird NIS2 von einer isolierten Pflicht zu einem Bestandteil der IT- und Betriebssteuerung.

Ein sinnvoller Einstieg unter Zeitdruck

Unternehmen müssen nicht zunächst ein vollständiges Zielbild entwerfen. Ein strukturierter Quick Check kann Geltungsbereich, wesentliche Lücken, kritische Daten- und Systemabhängigkeiten sowie den notwendigen Projektzuschnitt in kurzer Zeit klären. Anschließend lässt sich ein umsetzungsfähiger Fahrplan aufbauen, der Maßnahmen nach Risiko priorisiert und an laufende Transformationsvorhaben anbindet.

Besonders bei S/4HANA-Migrationen, Carve-outs oder größeren Integrationsprojekten sollte NIS2 früh in Test-, Cutover- und Betriebsübergabeplanung einfließen. Nachträgliche Anforderungen an Logging, Berechtigungen oder Wiederanlauftests verursachen häufig mehr Aufwand, weil Architekturentscheidungen, Dienstleistervereinbarungen und produktive Abläufe dann bereits festgelegt sind.

NIS2-Projektorganisation konkret aufsetzen

Quteco unterstützt mit Quick Checks, Workshops und operativer Projektbegleitung dabei, NIS2-Anforderungen in steuerbare Arbeitsstrukturen für IT-, SAP-, Daten- und Betriebsprozesse zu überführen. Bei rechtlichen Fragestellungen zur Einordnung und zu Pflichten kann ergänzend die rechtlich eigenständige Quteco Rechtsanwaltsgesellschaft mbH eingebunden werden. Der erste belastbare Schritt ist eine gemeinsame Sicht auf Geltungsbereich, Risiken, Verantwortlichkeiten und die Nachweise, die im laufenden Betrieb tatsächlich geführt werden können.