Drittparteienmanagement nach NIS2 — vom Vertrag bis zum Audit-Recht

Wer NIS2 ernst nimmt, kommt schnell an einen Punkt, an dem das eigene Sicherheitskonzept allein nicht mehr reicht. Spätestens beim ersten Cloud-Anbieter, beim IT-Outsourcing-Vertrag oder beim Sub-Auftragnehmer für die Wartung der OT-Systeme verschiebt sich die Frage: Wie steuern Sie Cybersecurity-Anforderungen über Vertragsgrenzen hinweg? Genau hier setzt Drittparteienmanagement nach NIS2 an — und genau hier wird aus „Lieferanten sind dein Risiko” eine konkrete vertragliche Pflicht mit messbaren Mindestbereichen.

Für österreichische Unternehmen ist die Lage durch das NISG 2026 jetzt klar: Ab 1. Oktober 2026 müssen wesentliche und wichtige Einrichtungen nachweisen, dass Lieferantenrisiken systematisch erfasst, vertraglich abgesichert und laufend überprüft werden. Dieser Beitrag zeigt das vereinte Pflichten-Heft — wie die drei relevanten Quellen-Ebenen ineinandergreifen, was in Verträgen stehen muss, wie das Audit-Recht praktisch funktioniert und wie eine KMU-Realität asymmetrischer Vertragsmacht zwischen Großkonzern und eigenen Sub-Lieferanten konkret aussieht.

Drei Quellen, ein Pflichten-Stack

Drittparteienmanagement nach NIS2 wird häufig vereinfacht als „eine Pflicht aus der EU-Richtlinie” verstanden. Das stimmt — aber nur als Einstiegspunkt. In Wahrheit greifen drei Regelungs-Ebenen zusammen, die ein operatives Pflichten-Bündel ergeben:

• NIS2-Richtlinie (EU) 2022/2555, Artikel 21(2)(d) → das Was und Warum. Der politische Rahmen — die Anforderung, Lieferketten in das Risikomanagement einzubeziehen, ist hier verankert. Umgesetzt in Österreich durch § 32 Absatz 4 Litera d NISG 2026 (BGBl I 94/2025).
• NIS2-Durchführungsverordnung (EU) 2024/2690, Anhang 5 → das Wie technisch-methodisch. Für die Adressaten der Verordnung (Cloud-Anbieter, MSPs, Vertrauensdiensteanbieter und weitere Sektoren) konkretisiert Anhang 5.1 das Lieferketten-Konzept und listet in 5.1.4 die acht Vertrags-Mindestbereiche. Für andere Einrichtungen funktioniert die DV als Auslegungs-Maßstab, an dem sich die nationale Aufsicht orientieren wird.
• ISO/IEC 27001:2022 und 27002:2022, Annex A.5.19 bis A.5.23 → das Wie operativ im ISMS-Alltag. Wer ISO 27001 implementiert oder zertifiziert, bekommt fünf konkrete Controls für Lieferanten-Beziehungen, ergänzt durch detaillierte Implementation-Guidance in ISO 27002. Diese Ebene ist nicht rechtlich verpflichtend, aber faktisch der Standard, an dem sich Auditoren und Großkunden orientieren.

Eine vierte Ebene gehört dazu, sobald die Risikobewertung von Lieferanten methodisch sauber aufgesetzt werden soll: ISO/IEC 27005:2022 stellt den Risikomanagement-Rahmen, mit dem die Tier-Einteilung und die Behandlungs-Entscheidung („Vertragsklauseln verschärfen / Lieferanten wechseln / Risiko akzeptieren”) strukturiert begründet werden kann.

Wer diese vier Ebenen kennt, vermeidet die häufigste Falle: NIS2-Lieferantenmanagement als reine Vertrags-Übung zu behandeln. Verträge sind die Sichtoberfläche — die operative Wirkung entsteht erst, wenn die Vertragsanforderungen mit dem ISMS-Prozess (ISO 27001/27002) und der Risiko-Methodik (ISO 27005) verzahnt sind.

Was Artikel 21(2)(d) NIS2 + § 32 NISG 2026 verlangen

Die NIS2-Richtlinie listet in Artikel 21 Absatz 2 Buchstabe d die Sicherheit der Lieferkette explizit als verpflichtenden Risikomanagement-Bereich: erfasst werden die „sicherheitsbezogenen Aspekte der Beziehungen zwischen jeder Einrichtung und ihren unmittelbaren Anbietern oder Diensteanbietern”.

Artikel 21 Absatz 3 präzisiert, dass die Einrichtungen bei der Wahl der Maßnahmen die spezifischen Schwachstellen ihrer unmittelbaren Anbieter, die Gesamtqualität der Produkte und die Cybersicherheitspraxis der Anbieter berücksichtigen — einschließlich der Sicherheit ihrer Entwicklungsprozesse — sowie die Ergebnisse der gemäß Artikel 22 Absatz 1 durchgeführten koordinierten Risikobewertungen kritischer Lieferketten.

In Österreich ist diese Pflicht durch § 32 Absatz 4 Litera d NISG 2026 umgesetzt. § 32 Absatz 4 listet zehn Mindestbereiche, die jedes Risikomanagement abdecken muss — Litera d ist der Lieferketten-Bereich und übernimmt die NIS2-Formulierung im Wortlaut.

Praktisch heißt das: Wer ab 1.10.2026 als wesentliche oder wichtige Einrichtung im Sinne des NISG 2026 betroffen ist, muss drei Dinge nachweisen können — ein dokumentiertes Drittparteien-Konzept, vertraglich umgesetzte Sicherheitsanforderungen und ein laufendes Monitoring der Lieferanten-Compliance. Wie genau diese drei Punkte ausgestaltet werden, ergibt sich aus dem Zusammenspiel von DV 2024/2690 (technische Konkretisierung) und ISO 27001/27002 (operative Standardisierung).

Lieferanten-Kritikalitäts-Tiering — die Eingangsentscheidung

Bevor Verträge erstellt werden, muss klar sein, wer überhaupt unter die Lieferanten-Pflicht fällt und in welcher Intensität. ISO 27002 § 5.19 schlägt eine Asset-bezogene Klassifizierung vor: identifiziert werden die Lieferanten nach ihrem Zugriff auf Informations-Assets, die für die Vertraulichkeit, Integrität oder Verfügbarkeit relevant sind. Die NIS2-DV verlangt in Anhang 5.1.2 zusätzlich, dass Auswahlkriterien für Lieferanten dokumentiert sind — darunter die Cybersicherheitspraxis des Anbieters, dessen Fähigkeit zur Erfüllung von Sicherheits-Spezifikationen und die Gesamtqualität der angebotenen Produkte und Dienstleistungen.

Maßgeblich sind dabei fünf Achsen: Systemzugriff, Datenzugriff, Verfügbarkeitseinfluss, physischer Zutritt zu IT-Bereichen und Ersetzbarkeit (Konzentrationsrisiko). Schon eine einzelne Achse kann ein höheres Tier rechtfertigen — ein nicht ersetzbarer Single-Source-Lieferant gehört auch ohne Datenzugriff risikoseitig nach oben. In der Praxis lässt sich der Lieferantenkreis nach drei Kritikalitätsstufen ordnen:

Tier A — kritische Anbieter. Anbieter mit direktem Systemzugriff, mit Zugriff auf vertrauliche Daten oder mit Einfluss auf die Verfügbarkeit kritischer Dienste. Typisch: IT-Outsourcing-Partner, Managed Service Provider, Cloud-Anbieter für ERP-, CRM- und SaaS-Buchhaltungs-/Lohnverrechnungs-Systeme, OT-Wartungs-Dienstleister bei produzierenden Unternehmen. Hier greift die volle Vertrags-Schärfe.

Tier B — relevante Anbieter. Anbieter ohne direkten System-Zugriff, aber mit mittelbarer Sicherheitsrelevanz. Typisch: On-Premise-Buchhaltungssoftware-Hersteller ohne laufenden Datenzugriff, dezentrale SaaS-Tools, Marketing-Plattformen, Wartungsfirmen ohne dauernden Zugriff. Hier reichen reduzierte Vertragsschärfe und anlassbezogene Prüfungen.

Tier C — unkritische Anbieter. Lieferanten ohne IT-/Daten-Relevanz, etwa Bürobedarf, Gebäudereinigung ohne Zutritt zu IT-Bereichen. Reinigung oder Wartung mit nächtlichem Zutritt zu Büro- oder Serverräumen rückt dagegen in Tier B — der physische Zutritt ist ein klassischer Angriffsvektor. Hier gilt die NIS2-Lieferantenpflicht im Regelfall nicht in der vollen Tiefe — eine dokumentierte Risikoabwägung ist trotzdem sinnvoll, damit die Klassifizierung selbst nachweisbar ist.

Die Tier-Einteilung selbst sollte nach ISO/IEC 27005:2022 methodisch durchgeführt werden: Risikokriterien definieren (§ 6.4), Risiken pro Lieferant identifizieren (§ 7.2), analysieren und bewerten (§ 7.3 und § 7.4). Das macht die Tier-Zuordnung nachvollziehbar und im Auditfall verteidigbar. „Tier A weil wir es so spüren” reicht nicht — die Zuordnung muss aus einem dokumentierten Bewertungsschritt resultieren.

Das vereinte Pflichten-Heft — die acht Vertrags-Mindestbereiche mit ISO-Mapping

Die NIS2-Durchführungsverordnung 2024/2690 konkretisiert in Anhang 5.1.4 acht Bereiche, die in Lieferantenverträgen geregelt sein müssen, soweit angemessen. Die folgende Tabelle ordnet jeden Bereich auf das passende ISO-27001-Annex-A-Control zu — damit Unternehmen mit bestehendem oder geplantem ISMS direkt sehen, wo die NIS2-Pflicht auf vorhandene Strukturen aufsetzt:

DV 5.1.4	Vertrags-Bereich	ISO 27001:2022 Annex A	Tier-A-Schärfe
(a)	Cybersicherheits-Anforderungen (Standards: ISO 27001, BSI-Grundschutz, sektor-spezifische Frameworks; Schwachstellen-Behebung; Patch-Frequenzen)	A.5.20 + A.5.19	Standard-Benennung verbindlich, Reifegrad-Nachweis
(b)	Schulungs- und Zertifizierungs­anforderungen (Mindest-Qualifikation für Personal mit System-Zugriff, dokumentierte Schulungsnachweise)	A.5.20 + A.6.3 (Awareness, education and training)	Personal-Qualifikation nachweisbar
(c)	Zuverlässigkeits-Überprüfungen (Background-Check-Standards für Lieferanten-Personal mit kritischem Zugriff)	A.6.1 (Screening)	Background-Check-Pflicht
(d)	Unverzügliche Meldepflicht für Sicherheitsvorfälle (typisch 24 Stunden ab Kenntniserlangung)	A.5.20 + A.5.24 (Incident management planning)	24-Stunden-Frist, definierter Kanal
(e)	Prüf- und Auditmöglichkeiten (Audit-Recht des Auftraggebers oder bevollmächtigten Drittprüfers; Frequenz geregelt)	A.5.22 (Monitoring, review and change management)	Jährliches Audit-Recht
(f)	Schwachstellen-Behebungs-Verpflichtungen (Mitwirkung bei Schwachstellen-Untersuchung, Fristen für Behebung)	A.5.20 + A.8.8 (Vulnerability management)	Kritisch innerhalb 7 Tagen
(g)	Sub-Auftragnehmer-Cybersicherheits-Anforderungen (Kaskaden-Weitergabe)	A.5.21 (ICT supply chain)	Genehmigungs­vorbehalt für neue Sub-Auftragnehmer
(h)	Datenbehandlungs-Pflichten bei Vertragskündigung (Rückgabe, Löschung, Übergabe-Modalitäten)	A.5.23 (Cloud services exit) + A.8.10 (Information deletion)	Detaillierte Exit-Klausel

Die Tabelle zeigt: Die acht NIS2-DV-Bereiche werden im ISO-27001-Annex-A weitgehend gespiegelt — wer ISO 27001 implementiert hat, hat 80 bis 90 Prozent der NIS2-Anforderungen strukturell schon abgedeckt. Was fehlt, sind in der Regel die NIS2-spezifischen Schwellenwerte (z. B. 24-Stunden-Meldefrist) und die ausdrückliche Sektor-Bezugnahme. Diese Aufstellung deckt den Mindeststandard nach EU-Recht ab. Ein Maximum ist sie nicht — wer in einem österreichischen Tier-1-Liefernetzwerk steht, wird typischerweise zusätzliche branchen­spezifische Anforderungen vorfinden (TISAX-Klauseln im Automotive-Umfeld, sektorale Frameworks bei Energie, Banken-spezifische Pflichten bei Finanzdienstleister-Zulieferern).

Das Audit-Recht — wie es praktisch funktioniert

Der vertragliche Anspruch auf Prüfung und Auditierung — DV-Anhang 5.1.4 Punkt (e) und ISO 27001 A.5.22 — ist der wirksamste Mechanismus, um die Lieferanten-Compliance nicht nur zu vereinbaren, sondern auch zu verifizieren. ISO 27002 § 5.22 ergänzt diese Pflicht um ein laufendes Monitoring: das Monitoring umfasst regelmäßige Überprüfungen der Service-Level-Vereinbarungen, Bewertungen sicherheitsrelevanter Vorfälle und das Management von Änderungen bei Anbietern. Drei Konstellationen kommen in der Praxis vor:

Eigenes Audit. Der Auftraggeber führt — typischerweise mit eigenem Internal-Audit-Team oder mit externen Beratern aus einem Cyber Governance Setup — eine Vor-Ort- oder Remote-Prüfung beim Anbieter durch. Klassische Klausel-Formulierung: „Der Auftraggeber ist berechtigt, nach angemessener Vorankündigung und während der üblichen Geschäftszeiten die Einhaltung der vereinbarten technischen und organisatorischen Maßnahmen durch den Auftragnehmer zu überprüfen oder durch einen zur Verschwiegenheit verpflichteten Dritten überprüfen zu lassen.”

Drittprüfer-Berichte. Der Anbieter legt einen aktuellen Prüfbericht eines anerkannten Drittprüfers vor — typisch ein ISO-27001-Zertifikat, ein SOC-2-Bericht (Type 2) oder ein TISAX-Label im Automotive-Umfeld. Das ist der häufigste Weg bei großen IT-Anbietern und Cloud-Providern. Vorteil: kein eigener Audit-Aufwand, klarer Standard-Vergleich. Grenze: man bekommt nur das, was im Zertifikat-Scope steht.

Standardisierter Fragebogen. Bei Tier-B-Anbietern oder bei sehr kleinen Anbietern ohne Zertifizierung kann ein strukturierter Sicherheits­fragebogen mit Nachweis-Pflicht eine pragmatische Lösung sein. Wichtig: Selbstauskunft allein ist kein Audit. Erst in Kombination mit punktuellen Nachweisen (z. B. tatsächliche Backup-Test-Berichte, nicht nur die Ankreuzfrage „Backups vorhanden? Ja”) entsteht eine belastbare Bewertung.

Die NDA-Konflikt-Falle

Häufig stoßen Audit-Klauseln auf das Konfidenzialitäts-Argument: Der Anbieter weigert sich, fremden Audit-Prüfern Einblick zu gewähren, weil andere Kundendaten gefährdet würden. Hier hilft die in der Praxis bewährte Konstruktion mit einem zur Verschwiegenheit verpflichteten gemeinsamen Drittprüfer. Eine spezialisierte Audit-Gesellschaft führt die Prüfung im Auftrag des Auftraggebers durch, ist dem Anbieter gegenüber zur Verschwiegenheit verpflichtet, und liefert dem Auftraggeber nur das Ergebnis (Compliance ja/nein, identifizierte Lücken), ohne Detail-Evidenz aus anderen Mandantenverhältnissen offenzulegen. Das löst den Konflikt zwischen Audit-Pflicht und NDA-Schutz.

Der KMU-Tier-1-Lieferant — Realität asymmetrischer Vertragsmacht

In der österreichischen Industrie ist die Lieferantenposition oft nicht symmetrisch. Ein steirisches Maschinenbau-Unternehmen mit 200 Mitarbeitenden, das Tier-1-Zulieferer für einen Großkonzern aus dem Voestalpine-, Magna- oder AVL-Umfeld ist, kennt zwei Realitäten gleichzeitig:

Als Empfänger von NIS2-Lieferanten-Klauseln aus dem Großkunden-Vertrag. Die Klauseln sind in der Regel nicht verhandelbar — Tier-1-Lieferanten unterzeichnen Standard-Anhänge mit dokumentations- und auditpflichtiger Sicherheits-Mindestschwelle. Verhandelbar sind in der Praxis nur die Frequenz von Audits, die Kosten-Verteilung von Audit-Reisen, die Eskalations- und Klärungs-Pfade. Wer mehrere Großkunden mit unterschiedlichen Klauseln bedient, kann sich durch eine konsolidierte ISO-27001-Zertifizierung positionieren — sie deckt in der Regel den Großteil der Anforderungen ab und reduziert den Audit-Aufwand auf eine Stelle pro Jahr.

Als Vertragspartner seiner eigenen Sub-Lieferanten. Hier ist man in der Position, die NIS2-Klauseln auf der eigenen Seite vorzugeben. Dieser Mechanismus heißt Kaskaden-Prinzip — die Anforderungen aus dem Vertrag mit dem Großkunden werden auf die eigenen Sub-Auftragnehmer weitergegeben. Wenn der Großkunde 24-Stunden-Meldepflicht und jährliches Audit-Recht fordert, muss diese Anforderung auch in der Vereinbarung mit dem eigenen IT-Dienstleister auftauchen.

Standardvertrags-Anbieter sind die schwierigste Konstellation. Microsoft, AWS, Google Cloud, große SaaS-Anbieter (Salesforce, SAP, Workday) verhandeln keine individuellen NIS2-Klauseln. Hier greift ISO 27001 A.5.23 — die spezielle Control für Cloud-Dienste — mit drei pragmatischen Wegen:

• Sub-Processor-Listen mitführen — alle Cloud-Anbieter veröffentlichen Listen ihrer eigenen Unter-Auftragnehmer. Diese Listen werden Teil der eigenen Risikoanalyse, auch wenn man sie nicht ändern kann.
• Auf öffentliche Zertifizierungen vertrauen — ISO 27001, SOC 2 Type 2, ggf. C5-Testierung in Deutschland, BSI-Cloud-Auditschema. Die Zertifikate sind das vertragliche Surrogat für individuelle Audit-Rechte.
• Cloud-Exit-Strategie nach A.5.23 — wenn ein Standardvertrags-Anbieter regelmäßig NIS2-Lücken aufweist und nicht nachbessert, gehört er in die mittelfristige Migrations-Roadmap. ISO 27002 § 5.23 verlangt explizit Prozesse für Cloud-Acquisition, Use, Management und Exit — diese Entscheidung trägt die Geschäftsführung, nicht die IT.

Sub-Auftragnehmer-Kaskade nach A.5.21 — wie tief reicht die Pflicht?

Das Kaskaden-Prinzip ist der schwierigste Teil der NIS2-Lieferantensteuerung. Anhang 5.1.4 der Durchführungsverordnung verlangt, dass Anbieter ihren eigenen Sub-Auftragnehmern Cybersicherheits-Anforderungen weitergeben. ISO 27001 A.5.21 (Managing information security in the ICT supply chain) konkretisiert das: die Implementation-Guidance in ISO 27002 § 5.21 nennt unter anderem die Pflicht, Sicherheitsanforderungen entlang der ICT-Lieferkette weiterzugeben, die Sub-Auftragnehmer-Strukturen zu kennen und auf Schwachstellen in Komponenten und Sub-Komponenten zu reagieren.

Das funktioniert in der Theorie reibungslos — in der Praxis bricht die Kette spätestens bei Tier-3 ab. Realistisch ist eine dokumentierte Tier-2-Inventarisierung bei kritischen Anbietern. Der Anbieter legt offen, welche Sub-Auftragnehmer eingesetzt werden, und der Auftraggeber kann eine Genehmigung vor Vertragsschluss mit neuen Sub-Auftragnehmern verlangen — typische Klausel: „Der Auftragnehmer informiert den Auftraggeber über jeden geplanten neuen Sub-Auftragnehmer mindestens 60 Tage vor dessen Beauftragung.” Was darunter geschieht (Tier-3 und tiefer) bleibt in der Regel im Vertrauensverhältnis Anbieter zu Sub-Anbieter.

Die wichtige Erkenntnis: Die NIS2-Lieferantenpflicht verlangt Sorgfalt. Eine Erfolgsgarantie ist sie nicht. Wer Tier-1 sauber dokumentiert, Tier-2 inventarisiert und kritische Anbieter aktiv steuert, erfüllt die Anforderungen. Wer das Kaskaden-Mapping bis ins letzte Glied der Kette versucht, scheitert an Ressourcen und Verfügbarkeit — und das ist im Auditfall verstanden.

Risiko-Methodik nach ISO 27005 — wie Sie Lieferanten-Risiken sauber bewerten

NIS2 Artikel 21 Absatz 3 und die DV-Anhang-5.1.3 verlangen eine Risiko-Bewertung — wie genau, lassen beide offen. ISO/IEC 27005:2022 schließt diese Methodik-Lücke. Vier Schritte sind operativ relevant für Lieferanten-Risiken:

1. Risikokriterien definieren (ISO 27005 § 6.4). Welche Schwellenwerte gelten als „kritisch”? Bei Lieferanten typische Achsen: Vertraulichkeits-Schaden (welche Daten kann der Anbieter exfiltrieren?), Verfügbarkeits-Schaden (wie lange können wir ohne den Anbieter funktionieren?), Compliance-Schaden (welche regulatorischen Folgen drohen?). Diese Kriterien sollten unternehmensweit einheitlich sein und als Basis für die Tier-Einteilung dienen.

2. Risiken pro Lieferant identifizieren (§ 7.2). Asset-bezogen (welche Informations-Assets verarbeitet der Anbieter?) und Event-bezogen (welche Szenarien sind realistisch — Datenleck, Erpressung, Ausfall?). Hier ist das Sub-Processor-Mapping des Anbieters wertvoll, weil es zeigt, an wen die eigenen Daten faktisch weitergegeben werden.

3. Analysieren und bewerten (§ 7.3 und § 7.4). Wahrscheinlichkeit und Auswirkung pro Risiko, gegen die in Schritt 1 definierten Kriterien. Das Ergebnis ist eine Risiko-Matrix mit klaren Akzeptanz-Schwellen.

4. Behandeln (§ 8 Risk treatment). Vier Optionen pro Risiko: Modify (Vertragsklauseln verschärfen, technische Mitigationen), Retain (Risiko akzeptieren mit dokumentierter Begründung), Avoid (Lieferant wechseln oder Service intern erbringen), Share (Versicherung, Liability-Klauseln).

Dieser Vier-Schritt-Rahmen verwandelt die Tier-Einteilung von einer Bauchentscheidung in eine nachvollziehbare Bewertung — und liefert im Auditfall die dokumentierte Grundlage für jede Lieferanten-Entscheidung.

Was schiefgehen kann — Behebung, Eskalation, Exit

Lieferantenverträge werden in dem Moment ernst, in dem etwas nicht funktioniert. Drei Szenarien gehören in jeden NIS2-konformen Vertrag:

Audit-Befund mit Mängeln. Was passiert, wenn ein Tier-A-Audit kritische Lücken aufdeckt? Hier braucht der Vertrag eine Behebungs-Klausel mit Fristen (typisch 30–90 Tage je nach Schwere), Berichtspflichten zum Behebungsfortschritt und einer Eskalations-Stufe für Wiederholungsfälle. Vertragsstrafen wirken als Hebel: eine vereinbarte Pauschale von 10.000–50.000 EUR pro Wiederholungsfall — bemessen am Jahresvertragswert und mit Deckelung — verschiebt die Aufmerksamkeit des Anbieters spürbar. Überzogene Beträge nützen nichts: In Österreich unterliegen Vertragsstrafen dem richterlichen Mäßigungsrecht (§ 1336 ABGB), auch im B2B.

Sicherheitsvorfall mit Auswirkung auf die eigene Einrichtung. Der Anbieter ist nach Anhang 5.1.4 zur unverzüglichen Meldung verpflichtet — typisch 24 Stunden ab Kenntniserlangung. Im Vertrag sollte stehen, an wen (definierter Sicherheits-Kontakt, nicht „die zuständige Stelle”), in welcher Form (sicherer Kanal), und mit welcher Mindest-Information (was, wann, welche Daten/Systeme betroffen, welche Sofortmaßnahmen). Diese Detail-Tiefe macht den Unterschied zwischen einer juristisch sauberen Meldung und einer operativ verwertbaren.

Provider-Verlust und Kontinuitäts-Sicherung. Wenn ein kritischer Anbieter ausfällt — Insolvenz, Behörden-Untersagung, Cyberangriff mit längerer Wiederherstellungszeit — muss die eigene Geschäftskontinuität gesichert sein. Eine sinnvolle Vertrags­klausel ist die Exit-Mitwirkungspflicht: Der Anbieter unterstützt definiert beim Übergang zu einem Nachfolge-Anbieter, gibt Daten in einem verwertbaren Format heraus, und löscht eigene Bestände nach Übergabe. Bei Tier-A-Anbietern lohnt sich zusätzlich eine Zweit-Lieferanten-Strategie, auch wenn die laufenden Kosten höher sind — eine Tabletop-Übung mit Provider-Verlust-Szenario macht schnell sichtbar, wo die Lücken sind.

Fazit — vom Vertrag zur laufenden Steuerung

Drittparteienmanagement nach NIS2 läuft als Steuerungs­aufgabe dauerhaft mit. Ein Einmal-Projekt ist es nicht. Verträge sind die Grundlage — aber sie ersetzen nicht die laufende Risikobewertung, das Monitoring der Lieferanten-Compliance und das Update bei wesentlichen Änderungen. Das gilt umso mehr, weil die Geschäftsleitung die Haftung für Lieferantenrisiken nicht delegieren kann — auch nicht durch noch so saubere Vertragsklauseln.

Drei konkrete erste Schritte für die Geschäftsführung:

1. Lieferanten-Inventar erstellen und nach ISO 27005 kritikalisieren — wer sind die Tier-A-, Tier-B- und Tier-C-Anbieter? Welche Verträge laufen mit welchen Anbietern? Wo gibt es Konzentrations­risiken? Ein strukturierter Cyber Reality Check liefert die Antwort in ein bis zwei Tagen.

2. Vertrags-Audit der bestehenden Tier-A-Verträge gegen das vereinte Pflichten-Heft — welche der acht Mindest­bereiche aus Anhang 5.1.4 fehlen oder sind zu schwach geregelt? Welche ISO-27001-Annex-A-Controls sind nicht abgedeckt? Welche Verträge können bei der nächsten Verlängerung angepasst werden, welche brauchen einen sofortigen Zusatz?

3. Drittparteien-Konzept dokumentieren — die Risiko-Klassifizierung, die Audit-Frequenz, die Eskalations­pfade, das Monitoring-Regime nach ISO 27001 A.5.22. Das Konzept ist die Compliance-Grundlage gegenüber der Aufsicht — und der erste Punkt, den Auditoren prüfen werden.

Ein strukturiertes Mandat in der NIS2-Beratung deckt diese drei Schritte typischerweise in einem 3- bis 6-Monats-Programm ab, mit dokumentierten Ergebnissen, die im Auditfall standhalten. Drittparteienmanagement gehört zur NIS2-Pflicht. Die Frage am 1. Oktober 2026 wird sein, ob die eigene Steuerung zeigen kann, was sie steuert — und ob das Drei-Quellen-Pflichten-Heft (NIS2 + DV + ISO) sauber integriert ist oder nur als drei voneinander unabhängige Compliance-Inseln existiert.