NIS2 intern umsetzen oder mit externer Beratung? Kosten, Zeit und Risiken im Vergleich

Die Entscheidung, NIS2 intern oder mit externer Unterstützung umzusetzen, ist mehr als ein Vergleich zwischen Beratungshonorar und den Personalkosten des eigenen Teams. Über den Projekterfolg entscheiden der konkrete Pflichtenumfang, die Verfügbarkeit entscheidungsbefugter Personen, die Qualität der Prozess- und Asset-Daten sowie die Fähigkeit der Organisation, die eingeführten Lösungen dauerhaft wirksam zu betreiben. Die vermeintlich günstigste Variante kann sich als die teuerste erweisen, wenn sie zu einer fehlerhaften Einordnung, wiederholten Analysen oder einer Dokumentation führt, die nicht mit der betrieblichen Praxis übereinstimmt. Deshalb sollten zunächst Anwendungsbereich und Lücken geklärt, anschließend die Gesamtkosten, der Zeitbedarf und die Risiken von drei Umsetzungsmodellen verglichen und erst danach Anbieter und Vorgehensweise ausgewählt werden.

Den Umsetzungspartner erst nach Klärung der Pflichten auswählen

Ein belastbarer Vergleich zwischen interner Umsetzung und externer Unterstützung ist erst möglich, wenn geklärt wurde, ob die Organisation den Anforderungen aus NIS2 und den einschlägigen nationalen Umsetzungsvorschriften unterliegt. Ist dies der Fall, muss festgelegt werden, welche Dienste, Organisationseinheiten, Standorte und Ressourcen in die Bewertung einzubeziehen sind. Ohne diese Einordnung lassen sich Arbeitsumfang, Projektdauer und Kosten nicht seriös bestimmen. Die Geschäftsleitung sollte außerdem einen Projektverantwortlichen benennen, der befugt ist, Entscheidungen zwischen operativem Geschäft, Rechtsfunktion und IT abzustimmen.

Ausgangspunkt ist weder der Kauf eines Dokumentenpakets noch die Einführung eines IT-Tools, sondern ein belastbares Bild des Geschäftsmodells. Zu erfassen sind die erbrachten Dienste, die unterstützenden Prozesse, Systeme und Daten sowie Lieferanten und Abhängigkeiten, die für die Betriebsfortführung maßgeblich sind. Erst diese Übersicht zeigt, ob die gesamte Gesellschaft oder nur bestimmte Dienste und Standorte in den Anwendungsbereich fallen. Das Ergebnis der ersten Phase sollte eine dokumentierte Einordnung der Organisation, eine eindeutige Abgrenzung des Untersuchungsbereichs sowie eine Liste der zu bewertenden und zu behandelnden Handlungsfelder sein.

Eine formale gesetzliche Betroffenheit ist von der geschäftlichen Notwendigkeit zu unterscheiden, die eigene Resilienz zu erhöhen. Eine Organisation kann außerhalb des gesetzlichen Anwendungsbereichs liegen und dennoch Anforderungen von Kunden, Konzernstrukturen, Versicherern oder anderen Beteiligten der Lieferkette erfüllen müssen. Ein solches Vorhaben sollte nicht als Erfüllung gesetzlicher Pflichten dargestellt werden, sondern als Reaktion auf konkrete vertragliche Anforderungen und operative Risiken.

Ein Beispiel ist ein Produktionsunternehmen, das über Firewalls, Datensicherungen und Endgeräteschutz verfügt, aber keinen Verantwortlichen für den Incident-Response-Prozess benennen kann. Gleichzeitig ist nicht geklärt, wie sich ein Ausfall des Produktionsplanungssystems auf Auftragsplanung, Materialverfügbarkeit und Liefertreue auswirkt. Das Problem liegt dann nicht allein im technischen Schutzniveau, sondern ebenso in fehlenden Verantwortlichkeiten und einer unzureichenden Analyse der Abhängigkeiten zwischen IT-System und Leistungserbringung.

Nach der Beschreibung der Geschäftstätigkeit ist eine rechtliche Bewertung anhand der zum Veröffentlichungszeitpunkt geltenden sektoralen, organisationsbezogenen und größenabhängigen Kriterien vorzunehmen. Die formale Position sollte durch das zuständige Organ oder eine vertretungsberechtigte Person bestätigt werden. Rechtsfunktion sowie Service- und Prozessverantwortliche sollten daran beteiligt sein. Die IT liefert die erforderlichen Systeminformationen, sollte die rechtliche Einordnung jedoch nicht allein entscheiden. Vertiefende Informationen enthält der Beitrag „NIS2-Richtlinie – für wen gilt sie und welche Unternehmen müssen die neuen Anforderungen erfüllen?“.

Die Umsetzungskosten enden nicht mit der Beraterrechnung

Eine interne Umsetzung ist nicht kostenlos. Ebenso bildet das Honorar eines Umsetzungspartners nicht die vollständigen Kosten externer Unterstützung ab. In die Kalkulation gehören die Aufwände der Geschäftsleitung, der Prozessverantwortlichen, der IT, des Einkaufs, des Personalbereichs, der Rechtsfunktion und der für das Managementsystem zuständigen Person. Diese Zeiten sollten auf Basis interner Kostensätze und realistischer Arbeitsstunden bewertet werden. Dabei sind auch operative Aufgaben zu berücksichtigen, die während des Projekts nicht oder nur verzögert erledigt werden können. Der Aufwand hängt vor allem von der Anzahl der einbezogenen Standorte, Prozesse, Systeme, Lieferanten und Gesellschaften ab.

Besonders häufig unterschätzt werden die Datenerhebung, die Abstimmung von Verantwortlichkeiten, die Inventarisierung von Assets und Lieferanten, die Aufbereitung von Nachweisen, die Durchführung von Tests und Schulungen sowie die Bereinigung widersprüchlicher Regelungen. Ein externer Partner verkürzt diese Arbeiten nur dann, wenn er die Anforderungen auf bestehende Prozesse, Rollen und Werkzeuge übertragen kann. Standardrichtlinien ohne Verständnis des Geschäftsmodells beseitigen keine Kosten. Sie verlagern sie lediglich in die Abstimmung, operative Einführung und spätere Pflege.

Eine Incident-Response-Dokumentation lässt sich schnell erstellen. Sie bleibt jedoch wirkungslos, wenn Bereitschaftsdienste, Eskalationswege, Beweissicherung und Vertretungsregelungen nicht abgestimmt sind. Die tatsächlichen Kosten zeigen sich erst bei einer Übung oder einem realen Ereignis, wenn das Verfahren grundlegend überarbeitet werden muss. Das Budget sollte daher einmalige und laufende Kosten getrennt ausweisen. Einzubeziehen sind Beratungshonorare, technische Investitionen, projektbedingte Ausfall- und Verzögerungszeiten, Nacharbeiten sowie der jährliche Betriebsaufwand für Reviews, Tests, Schulungen, Dokumentationspflege, Lieferantenbewertungen und die Bearbeitung von Sicherheitsvorfällen.

Ein wirksames Informationssicherheits-Managementsystem oder eine bestehende Zertifizierung kann den Aufwand für Inventarisierung, Risikobewertung, Dokumentenlenkung und Audits reduzieren, sofern die entsprechenden Regelungen im betrachteten Bereich tatsächlich umgesetzt und wirksam sind. Sie ersetzt jedoch weder die Bewertung der konkreten gesetzlichen Pflichten noch die Prüfung, ob die vorhandenen Maßnahmen zu den betroffenen Diensten passen. Diesen Zusammenhang erläutert der Beitrag NIS2 und DIN EN ISO 27001: Was eine Zertifizierung leistet und was zur Übereinstimmung mit dem KSC weiterhin fehlt.

Der Zeitbedarf hängt von der Entscheidungsfähigkeit ab

Die Dauer der NIS2-Vorbereitung wird nur selten durch die Geschwindigkeit bestimmt, mit der Verfahren geschrieben werden. Die wesentlichen Engpässe sind belastbare Daten, verfügbare Prozessverantwortliche und Personen, die Änderungen verbindlich freigeben dürfen. Der Projektplan sollte deren tatsächliche Verfügbarkeit, die Taktung des Lenkungsausschusses und den Zeitbedarf für bereichsübergreifende Entscheidungen berücksichtigen. Ein zugesagter Termin für die Übergabe von Dokumenten ist kein belastbarer Fortschrittsindikator, solange Anwendungsbereich, Verantwortlichkeiten und Prioritäten nicht genehmigt sind.

Die Arbeitspakete sollten entsprechend ihren Abhängigkeiten aufgebaut werden. Zunächst sind Anwendungsbereich, Rollen, Prozesse und Assets zu bestimmen. Danach folgen Risikobewertung, Risikobehandlungsplan, Umsetzung der Maßnahmen, Wirksamkeitstests und die Zusammenstellung geeigneter Nachweise. Parallel können Tätigkeiten durchgeführt werden, die auf denselben freigegebenen Annahmen beruhen, beispielsweise die Vertragsinventur und die Überprüfung vorhandener Sicherheitsmaßnahmen. Eine detaillierte Risikobewertung sollte dagegen nicht beginnen, bevor die einzubeziehenden Dienste, Prozesse, Systeme, Informationen und Lieferantenabhängigkeiten feststehen.

Bei der Priorisierung ist zwischen Lücken zu unterscheiden, die Beschaffungen, Vertragsänderungen, technische Integrationen oder Tests erfordern. Jede dieser Kategorien hat eigene Freigabewege und Umsetzungszeiten. Externe Unterstützung kann die Diagnose beschleunigen, Workshops strukturieren und Ergebnisse konsolidieren. Ein Berater kann der Geschäftsleitung jedoch weder die Entscheidung über die Risikoakzeptanz noch über die Investitionsreihenfolge oder die tolerierbare Unterbrechungsdauer eines Dienstes abnehmen. Werden solche Entscheidungen bis zum Projektende vertagt, läuft die Dokumentation den operativen Lösungen voraus und Teile der Analyse müssen wiederholt werden.

Fortschritt sollte deshalb anhand genehmigter Entscheidungen, aufgelöster Abhängigkeiten und nachweislich wirksamer Maßnahmen gemessen werden – nicht anhand der Anzahl erstellter Dokumente. Selbst ein auf wenige Wochen angelegter Zeitplan ist unrealistisch, wenn keine aktuelle Systemliste, kein Vertragsregister der Lieferanten und keine abgestimmten Prozessverantwortlichen vorhanden sind. Das Projektteam kann dann zwar einen Sollzustand beschreiben, aber keine verlässliche Verantwortung für Betriebsfortführung, Wiederherstellung und Lieferantensteuerung festlegen.

Die Prozessmodellierung sollte genau diese Entscheidungen unterstützen und nicht lediglich die Dokumentationsmenge erhöhen. Eine Orientierung für die angemessene Detailtiefe bietet der Vergleich „BPMN oder Flussdiagramm – welches Werkzeug eignet sich besser für die Abbildung von Qualitätsprozessen?“. Geeignet ist in diesem Zusammenhang das Werkzeug, das Rollen, Verantwortungsübergaben, Informationsabhängigkeiten sowie Bereiche mit Sicherungs- oder Vertretungsbedarf eindeutig sichtbar macht.

Die größten Risiken entstehen durch falsche Annahmen

Für eine erfolgreiche NIS2-Vorbereitung ist die Qualität der zugrunde liegenden Annahmen häufig wichtiger als die Anzahl erledigter Aufgaben. Bei einer internen Umsetzung liegen die größten Risiken in einer fehlerhaften Bestimmung des Anwendungsbereichs, übersehenen Geschäftsabhängigkeiten und der Reduzierung von Cybersicherheit auf eine reine IT-Aufgabe. Dadurch können Produktionsprozesse, Logistik, Instandhaltung, Versorgungskontinuität oder Verpflichtungen gegenüber Kunden unberücksichtigt bleiben. Zudem fehlt häufig die unabhängige Sicht auf interne Praktiken, die nur deshalb als ausreichend gelten, weil sie bisher nicht zu einer sichtbaren Störung geführt haben.

Externe Unterstützung beseitigt diese Risiken nicht automatisch. Ein Anbieter erhöht das Risiko, wenn er ein einheitliches Dokumentenpaket ohne Analyse der Dienste, Prozesse und Abhängigkeiten liefert, Prozessverantwortliche nicht einbindet oder das für den späteren Betrieb erforderliche Wissen nicht überträgt. So entsteht ein System, das vom Verfasser der Dokumentation abhängt und nicht von den Personen getragen wird, die für den laufenden Betrieb verantwortlich sind.

Deshalb kann es sinnvoll sein, Umsetzung und unabhängige Abschlussbewertung voneinander zu trennen – insbesondere dann, wenn derselbe Anbieter den Anwendungsbereich definiert, die Risiken bewertet und Maßnahmen ausgewählt hat. Die Entscheidung über die Akzeptanz des Restrisikos muss bei der zuständigen Leitung verbleiben.

Scheinkonformität zeigt sich an Abweichungen zwischen Vorgabe und Praxis: Eine Richtlinie beschreibt einen anderen Ablauf als den tatsächlich gelebten Prozess, das Risikoregister beeinflusst weder Prioritäten noch Investitionen und das Verfahren zur Behandlung von Sicherheitsvorfällen wurde nie erprobt. Eine Dokumentationslücke liegt vor, wenn erforderliche Festlegungen fehlen oder widersprüchlich sind. Eine operative Lücke besteht, wenn die Organisation eine Tätigkeit nicht ausführen, keine Verantwortung zuordnen oder keinen belastbaren Wirksamkeitsnachweis vorlegen kann. Ein zusätzliches Formular kann die erste Lücke schließen, ersetzt aber weder einen Test noch eine Entscheidung oder eine tatsächliche Prozessänderung.

Ein Beispiel ist ein Werk mit einem freigegebenen Meldeverfahren für Sicherheitsvorfälle, dessen Produktionsmitarbeiter jedoch nicht wissen, wie sie den Ausfall eines Steuerungs- oder Planungssystems melden sollen. Gleichzeitig wurden mit dem Dienstleister weder Eskalationsweg und Ansprechpartner noch Regelungen für Ereignisse außerhalb der Geschäftszeiten vereinbart. Das Dokument existiert, doch während einer Störung gehen die ersten Minuten für die Klärung von Zuständigkeiten verloren. Eine solche Lücke wird erst durch eine Übung sichtbar, an der Anwender, Prozessverantwortliche, IT, Leitung und Dienstleister beteiligt sind.

Ein Readiness-Audit sollte daher die Handlungsfähigkeit und die Verfügbarkeit belastbarer Nachweise bewerten, nicht nur die Vollständigkeit der Dokumentation. Geeignete Kennzahlen sind unter anderem die Anzahl offener Maßnahmen aus früheren Audits und Tests, Ergebnisse von Wiederherstellungsübungen, Erkenntnisse aus der Auswertung von Vorfällen und Betriebsstörungen sowie der Anteil kritischer Lieferanten, die bewertet wurden und für die abgestimmte Anforderungen bestehen. Grundlage müssen stets die tatsächlichen Daten der Organisation sein. Das Vorgehen wird im Beitrag „NIS2-Audit in einem Produktionsunternehmen – wie sich die Bereitschaft für die neuen Pflichten bewerten lässt“ vertieft.

Ein hybrides Modell bietet meist die beste Steuerbarkeit

Das Umsetzungsmodell sollte aus der tatsächlichen Leistungsfähigkeit der Organisation abgeleitet werden und nicht ausschließlich aus einem Vergleich von Beratungssätzen. Eine interne Umsetzung ist sinnvoll, wenn das Projekt über einen kompetenten Verantwortlichen verfügt, die Risikomanagementprozesse ausreichend reif sind, Inventare von Assets und Abhängigkeiten aktuell gehalten werden und Schlüsselpersonen sowohl Zeit als auch Kompetenz zur Interpretation der Anforderungen haben. Umfassendere externe Unterstützung ist bei erheblichen Kompetenzlücken, dezentralen Strukturen, wesentlichen technologischen Abhängigkeiten, hohem Zeitdruck oder einem bislang wenig strukturierten Managementsystem gerechtfertigt.

In vielen Fällen bietet ein hybrides Modell die beste Kontrolle über Kosten, Zeit und Risiken. Die Organisation behält die Verantwortung für Entscheidungen, Quelldaten, Risikoeigentümerschaft und operative Maßnahmen. Der Berater übernimmt Diagnose, Methodik, Moderation von Workshops, Analysen mit besonderem Fachwissen und die Qualitätssicherung der Ergebnisse.

Mindestens folgende Aufgaben müssen in der Organisation verbleiben:

• Bewertung der Bedeutung von Prozessen und Diensten;
• Benennung der Risikoeigner;
• Akzeptanz des Restrisikos;
• Festlegung der Investitionsprioritäten;
• Bestätigung der praktischen Wirksamkeit der Maßnahmen.

Die Geschäftsleitung kann ihre Verantwortung für die organisationale Resilienz nicht auf einen Auftragnehmer übertragen.

Ein Unternehmen mit mehreren Werken kann Informationen zu Diensten, Assets, Lieferanten und Auswirkungen möglicher Störungen intern erheben, weil ihre verlässliche Bewertung betriebliche Erfahrung voraussetzt. Ein externer Spezialist kann anschließend die Bewertungsmethodik strukturieren, Widersprüche hinterfragen, bereichsübergreifende Workshops moderieren und die Vollständigkeit der Nachweise prüfen. Ob diese Aufgabenteilung wirtschaftlich ist, hängt von der Zahl und Kompetenz der tatsächlich verfügbaren Personen ab – nicht von der formalen Größe des Projektteams.

Angebote sollten anhand identischer Liefergegenstände und Abnahmekriterien verglichen werden. Referenzen sind nach Vergleichbarkeit von Branche, Größenordnung, Prozessen und technologischem Umfeld zu bewerten, nicht allein nach der Anzahl abgeschlossener Projekte. Der Vertrag sollte Liefergegenstände, Abnahmekriterien, die Pflicht zur Ausrichtung an den tatsächlichen Prozessen, Wissenstransfer, Vertraulichkeit und Zugriff auf sensible Daten, Verantwortung für Korrekturen sowie den Unterstützungsumfang nach Projektabschluss eindeutig regeln. Das Vergütungsmodell sollte nicht die Anzahl erstellter Dokumente belohnen, sondern das Erreichen vereinbarter und überprüfbarer Ergebnisse.

Die praktische Abgrenzung der Verantwortung von Geschäftsleitung, Prozessverantwortlichen und unterstützenden Funktionen erläutert der Beitrag NIS2 in der Managementpraxis: Anforderungen in Entscheidungen, Verantwortlichkeiten und tatsächliche organisationale Resilienz überführen.

Die Entscheidung auf Nachweise und dauerhafte Betriebsfähigkeit stützen

Der Wahl des Umsetzungsmodells sollte eine kompakte organisatorische Bestandsaufnahme vorausgehen. Zu bestätigen sind Projektumfang, Projektverantwortung, verfügbare Kompetenzen, vorhandene Wirksamkeitsnachweise und die wichtigsten Lücken. Erst danach lässt sich entscheiden, welche Arbeiten intern übernommen werden und wo ein Spezialist das Risiko von Fehlinterpretationen, Auslassungen oder wiederholten Tätigkeiten reduziert.

Die Entscheidung der Geschäftsleitung sollte drei Varianten vergleichen: interne Umsetzung, hybrides Modell und umfassendere externe Unterstützung. Für jede Variante sind dieselben Kriterien anzuwenden:

• Gesamtkosten einschließlich Personalaufwand, Nacharbeiten und laufendem Betrieb;
• Zeit bis zum Erreichen einer belastbaren operativen Handlungsfähigkeit;
• Fehlerrisiko und Wahrscheinlichkeit wiederholter Arbeiten;
• tatsächliche Verfügbarkeit der erforderlichen Kompetenzen;
• Fähigkeit der Organisation, die Lösungen eigenständig aufrechtzuerhalten.

Der Beschluss oder die dokumentierte Entscheidung der Geschäftsleitung sollte das gewählte Modell, die Verantwortungsabgrenzung, den Projektverantwortlichen, die Ressourcen, das Berichtswesen, die Abnahmekriterien und geeignete Wirksamkeitskennzahlen festlegen. Diese Kennzahlen sollten aus den Prozessen der Organisation abgeleitet werden und nicht aus universellen Schwellenwerten ohne betrieblichen Kontext.

Eine Umsetzung sollte nicht anhand der Anzahl erstellter Richtlinien abgenommen werden. Das Ziel ist ein reproduzierbares und belastbares Vorgehen: eindeutige Rollen, dokumentierte Risikoentscheidungen, umgesetzte Maßnahmen, erprobte Reaktionen auf Störungen und Sicherheitsvorfälle, gesteuerte Lieferanten sowie verlässliche Aufzeichnungen. Ein freigegebenes Reaktionsverfahren belegt keine Einsatzbereitschaft, wenn ein Test veraltete Kontaktdaten, unklare Eskalationswege oder das Fehlen einer entscheidungsbefugten Person aufzeigt.

Die Abnahmekriterien sollten die Übereinstimmung von Dokumentation und Praxis, den Abschluss vereinbarter Maßnahmen, Testergebnisse, Wissenstransfer und einen eindeutigen Plan für die weitere Verbesserung einschließlich interner Audits umfassen. Als Abnahmenachweise kommen unter anderem Freigaben, Register, Testergebnisse, Schulungsprotokolle, Risikoentscheidungen und Bestätigungen über abgeschlossene Maßnahmen infrage. Die Vorbereitung und Pflege solcher Nachweise erläutert der Beitrag NIS2- und KSC-Dokumentation vor einer Prüfung: Welche Richtlinien, Register und Nachweise tatsächlich erforderlich sind.

Die Nachhaltigkeit der Lösung lässt sich erst beurteilen, wenn die Mitwirkung des Beraters reduziert wird. Prozessverantwortliche sollten Register dann selbstständig aktualisieren, Risikoentscheidungen treffen, Testergebnisse auswerten und Korrekturmaßnahmen einleiten können. Funktioniert das System nur aufgrund des Wissens des Auftragnehmers, ist das Projekt nicht abgeschlossen: Die Organisation hat Dokumentation erhalten, aber keine Fähigkeit aufgebaut, sie wirksam zu betreiben und weiterzuentwickeln.