top of page

NIS2 Lieferkette wirksam und prüfbar steuern

Autorenbild: Hakan Cobanoglu
Hakan Cobanoglu
29. Aug.
5 Min. Lesezeit

Wenn ein externer Fernwartungszugang in der Produktion offenbleibt, ein Cloud-Anbieter einen sicherheitsrelevanten Vorfall zu spät meldet oder ein SAP-Dienstleister unkontrolliert produktive Berechtigungen erhält, liegt das Risiko nicht mehr nur beim Lieferanten. Die NIS2 Lieferkette macht diese Abhängigkeiten zu einem Führungs- und Steuerungsthema des betroffenen Unternehmens. Entscheidend ist nicht, ob jeder Dienstleister dieselben Sicherheitsstandards wie das eigene Haus erfüllt. Entscheidend ist, ob kritische Leistungen, Zugriffe und Datenflüsse nachvollziehbar bewertet, vertraglich geregelt und im Betrieb kontrolliert werden.

Für viele Unternehmen ist das anspruchsvoller als die Umsetzung einzelner technischer Schutzmaßnahmen. Lieferantenmanagement, Informationssicherheit, Einkauf, Fachbereiche, IT-Betrieb und Compliance arbeiten häufig mit unterschiedlichen Datenbeständen und Verantwortlichkeiten. Gerade bei S/4HANA-Transformationen, hybriden Betriebsmodellen oder der Nutzung von KI- und Datenplattformen entstehen neue Abhängigkeiten, die in klassischen Lieferantenlisten nicht ausreichend sichtbar sind.

Was NIS2 in der Lieferkette konkret verlangt

NIS2 verpflichtet erfasste Einrichtungen zu angemessenen und verhältnismäßigen Maßnahmen für das Risikomanagement der Cybersicherheit. Dazu gehört ausdrücklich die Sicherheit der Lieferkette, einschließlich sicherheitsrelevanter Beziehungen zu unmittelbaren Lieferanten und Dienstleistern. Maßgeblich sind dabei nicht nur Beschaffungsprozesse, sondern die tatsächlichen Auswirkungen einer Leistung auf kritische Systeme, Prozesse und Informationen.

Die Vorgaben ersetzen keine Einzelfallbewertung. Ein Reinigungsdienstleister ohne System- oder Standortzugriff ist anders zu behandeln als ein Managed-Service-Provider mit administrativem Zugriff auf Netzwerkkomponenten. Ebenso kann ein kleiner Spezialanbieter für Laborsteuerung, OT-Fernwartung oder zentrale SAP-Schnittstellen kritischer sein als ein großer Rahmenvertragspartner mit geringem technischem Einfluss.

In Deutschland ist die jeweils anwendbare nationale Umsetzung neben dem europäischen NIS2-Rahmen zu berücksichtigen. Die Frage, ob ein Unternehmen erfasst ist, welche Pflichten im Einzelfall gelten und wie Verträge rechtlich auszugestalten sind, sollte bei Bedarf durch die rechtlich eigenständige Quteco Rechtsanwaltsgesellschaft mbH eingeordnet werden. Die operative Steuerung der Risiken bleibt jedoch eine Aufgabe, die sich nicht allein durch Vertragsklauseln erledigt.

NIS2 Lieferkette beginnt mit einer belastbaren Abhängigkeitsanalyse

Eine vollständige Lieferantenliste ist kein belastbarer Nachweis für beherrschte Drittparteirisiken. Sie zeigt meist Namen, Warengruppen und Vertragswerte, aber nicht, welcher Partner Zugang zu welcher Umgebung hat, welche Daten verarbeitet werden oder welche Betriebsprozesse bei einem Ausfall beeinträchtigt wären.

Der erste praktische Schritt ist deshalb eine Abhängigkeitsanalyse entlang der kritischen Services. Ausgangspunkt können Geschäftsprozesse sein: Auftragsabwicklung, Energieversorgung, Produktion, Logistik, Laborbetrieb oder Kundenportale. Von dort wird nachvollzogen, welche Anwendungen, Infrastrukturkomponenten, Datenflüsse und externen Leistungen erforderlich sind. Besonders relevant sind externe Administratoren, Hosting- und Cloud-Leistungen, Integrationspartner, Softwarewartung, Telekommunikation, Sicherheitsdienstleister sowie Anbieter mit Zugriff auf Produktions- und Gebäudeleittechnik.

Für jede relevante Beziehung sollten mindestens vier Fragen beantwortbar sein: Welche Leistung wird erbracht? Welche Systeme, Daten oder Standorte sind betroffen? Welche Zugriffsrechte bestehen tatsächlich? Welche betrieblichen Folgen hätte ein Sicherheitsvorfall oder Ausfall? Diese Informationen müssen nicht in einem einzigen Tool liegen. Sie müssen aber konsistent zusammengeführt werden können, etwa aus CMDB, Vertragsmanagement, Berechtigungsmanagement, SAP-Rollenmodellen, Netzwerkdokumentation und Verfahrensverzeichnissen.

Die Qualität dieser Datenbasis entscheidet über die Qualität aller folgenden Kontrollen. Werden etwa technische Service-Accounts nicht einem externen Partner zugeordnet oder bleiben Datenflüsse zwischen S/4HANA, Middleware und Cloud-Plattformen unklar, wird die Kritikalität zu niedrig bewertet. Das führt zu Lücken, die bei Audits, Vorfällen oder Go-Lives sichtbar werden.

Kritikalität nicht nur nach Umsatz oder Vertragswert bewerten

Die Priorisierung sollte den technischen und operativen Schaden abbilden. Ein bewährtes Schema kombiniert die Auswirkungen auf Verfügbarkeit, Integrität und Vertraulichkeit mit der Art des Zugriffs, der Ersetzbarkeit des Dienstleisters und der Erkennbarkeit eines Vorfalls. Auch Konzentrationsrisiken gehören in die Bewertung: Mehrere kritische Prozesse können von demselben Cloud-Anbieter, Integrationspartner oder Kommunikationsdienst abhängig sein.

Die Einstufung darf nicht statisch bleiben. Ein Dienstleister, der bisher nur Testdaten verarbeitete, kann mit dem Übergang in den Produktivbetrieb erheblich kritischer werden. Bei Cutover-Planungen sollte deshalb geprüft werden, ob neue externe Zugriffe, Schnittstellen oder Betriebsverantwortlichkeiten entstehen. Die Freigabe eines Go-Lives ohne aktualisierte Drittparteibewertung schafft unnötige Risiken im stabilen Betrieb.

Vertragsklauseln schaffen Verbindlichkeit, aber keine Kontrolle

Verträge sind ein wesentlicher Teil der Steuerung. Sie sollten die Anforderungen an Informationssicherheit, Meldewege, Mitwirkung bei Vorfällen, Unterauftragnehmer, Zugriffsregelungen, Nachweise und Beendigungs- oder Übergaberegelungen nachvollziehbar festlegen. Bei kritischen Services sind auch Wiederanlauf, Datenrückgabe, technische Dokumentation und Exit-Szenarien relevant.

Entscheidend ist die Übersetzung in kontrollierbare Abläufe. Eine Verpflichtung zur Vorfallmeldung hilft nur, wenn Ansprechpartner, Fristen, Eskalationswege und die Schnittstelle zum eigenen Incident-Management festgelegt und getestet sind. Ein zugesagtes Berechtigungskonzept bleibt wirkungslos, wenn externe Konten nicht regelmäßig geprüft, privilegierte Zugriffe nicht zeitlich begrenzt oder Offboarding-Prozesse nicht nachgehalten werden.

Nicht jeder Partner muss mit umfangreichen Fragebögen und Auditrechten belastet werden. Das wäre im Mittelstand oft weder verhältnismäßig noch operativ handhabbar. Für gering kritische Lieferanten können dokumentierte Mindestanforderungen und Selbstauskünfte ausreichen. Bei hochkritischen Partnern sind dagegen konkrete Evidenzen, abgestimmte Notfallverfahren und wiederkehrende Reviews erforderlich. Die Tiefe der Prüfung folgt dem Risiko, nicht der Größe des Lieferantenstamms.

So wird Drittparteirisiko in den Betrieb integriert

Wirksame Lieferkettensteuerung entsteht an den Übergängen zwischen Beschaffung, Projekt und Betrieb. Neue Dienstleister dürfen nicht erst nach Vertragsabschluss in den Sicherheitsprozess kommen. Bereits in der Auswahlphase sollten fachliche Anforderungen, technische Architektur, Datenklassifikation und notwendige Zugriffe bewertet werden. So lassen sich spätere Sonderfreigaben vermeiden, die unter Zeitdruck kaum sauber dokumentiert werden.

In laufenden Projekten bewährt sich ein verbindlicher Kontrollpunkt vor Testabschluss und vor Produktivsetzung. Dort wird geprüft, ob externe Rollen korrekt eingerichtet sind, Schnittstellen dokumentiert wurden, Support- und Eskalationswege stehen und die Verantwortlichkeit für Sicherheitsereignisse klar ist. Bei SAP-Projekten gehören dazu insbesondere technische Nutzer, RFC-Verbindungen, Berechtigungen von Implementierungspartnern, Schnittstellen zu Drittsystemen und der Umgang mit produktionsnahen Daten.

Für den Regelbetrieb braucht es einen festen Takt. Kritische Dienstleister sollten mindestens bei wesentlichen Leistungsänderungen, Vorfällen, Vertragsverlängerungen und Architekturänderungen neu bewertet werden. Die Ergebnisse gehören in ein revisionssicheres Reporting: Welche kritischen Drittparteien bestehen? Welche Kontrollen sind erfüllt? Wo gibt es Abweichungen? Wer verantwortet Maßnahmen und bis wann? Ein Ampelstatus ohne Belege und Maßnahmenhistorie reicht dafür nicht aus.

Kennzahlen, die Steuerbarkeit sichtbar machen

Kennzahlen sollen nicht zusätzliche Bürokratie erzeugen, sondern offene Risiken priorisieren. Sinnvoll sind etwa der Anteil kritisch eingestufter Dienstleister mit aktueller Bewertung, die Zahl ungeprüfter privilegierter externer Konten, die fristgerechte Schließung von Feststellungen sowie die Aktualität von Notfall- und Eskalationskontakten. Ergänzend kann die Zeit bis zur vollständigen Information über einen Vorfall zeigen, ob Meldeketten praktisch funktionieren.

Wichtig ist die Zuordnung: Der Einkauf kann Vertragsnachweise nachhalten, die Informationssicherheit Mindestanforderungen und Risikobewertungen verantworten, der IT-Betrieb Zugriffe kontrollieren und Fachbereiche die Kritikalität der Leistung bestätigen. Eine zentrale Koordination sorgt dafür, dass diese Teilinformationen zu einem steuerbaren Gesamtbild zusammenlaufen. Ohne diese Zuordnung bleibt die Lieferkette ein Sammelbegriff, für den sich im Ernstfall niemand zuständig fühlt.

Typische Lücken bei Daten, KI und externen Betriebsmodellen

Neue Datenplattformen und Enterprise-AI-Anwendungen erweitern die Lieferkette um weitere Abhängigkeiten. Relevant sind nicht nur Modell- oder Plattformanbieter, sondern auch Implementierungspartner, Datenbereitsteller, Betriebsdienstleister und Schnittstellen zwischen Quellsystemen. Bei produktionsnaher KI muss nachvollziehbar sein, welche Daten in welche Umgebung gelangen, wer administrative Zugriffe besitzt und wie Änderungen an Modellen, Datenpipelines oder Berechtigungen kontrolliert werden.

Besondere Aufmerksamkeit verdienen Schattenbeziehungen. Dazu zählen Fachbereichslösungen mit eigenständig beschafften Cloud-Komponenten, externe Supportzugänge ohne zentrale Dokumentation oder Unterauftragnehmer, die in technischen Serviceketten eingesetzt werden. Diese Beziehungen lassen sich selten allein durch einen jährlichen Fragebogen erfassen. Nötig sind abgestimmte Datenflussanalysen, Architektur-Reviews und ein Prozess, der Beschaffung und technische Freigabe zusammenführt.

Die NIS2 Lieferkette wird damit nicht durch ein einmaliges Compliance-Projekt beherrscht. Sie wird steuerbar, wenn Unternehmen kritische Abhängigkeiten mit ihren realen Systemlandschaften verbinden, Kontrollen in Projekt- und Betriebsabläufe integrieren und Abweichungen nachweisbar nachverfolgen.

NIS2-Lieferkette strukturiert prüfen

Ein Quteco Quick Check kann kritische Dienstleister, Zugriffe, Datenflüsse und bestehende Nachweise in einer gemeinsamen Arbeitsgrundlage zusammenführen. Daraus lassen sich priorisierte Maßnahmen für Governance, SAP- und IT-Betrieb sowie revisionssicheres Reporting ableiten; für die rechtliche Einordnung von NIS2-Pflichten kann ergänzend die rechtlich eigenständige Quteco Rechtsanwaltsgesellschaft mbH eingebunden werden. Entscheidend ist ein Vorgehen, das nicht bei einer Richtlinie endet, sondern Verantwortlichkeiten im laufenden Betrieb überprüfbar macht.

 
 
bottom of page