Praxisorientierte Einordnung zu NIS2, DORA und ISO 27001: Anforderungen an Drittparteien im Vergleich: Anforderungen verstehen, Risiken priorisieren und eine belastbare Umsetzung für Lieferanten- und Drittparteienrisikomanagement aufbauen.
NIS2, DORA und ISO/IEC 27001 verlangen keine identische Lieferantensteuerung. NIS2 ist eine EU-Richtlinie für ein hohes gemeinsames Cybersicherheitsniveau und wird national umgesetzt. DORA ist eine unmittelbar geltende EU-Verordnung für digitale operationale Resilienz im Finanzsektor mit detaillierten Anforderungen an ICT-Drittparteien. ISO/IEC 27001 ist ein freiwillig nutzbarer, zertifizierbarer Managementsystemstandard, sofern keine vertragliche oder andere Verpflichtung besteht.
In der Praxis überschneiden sich die Themen: Risiko, Auswahl, Vertrag, Überwachung, Vorfälle, Kontinuität und Exit. Unternehmen sollten daraus kein dreifaches Kontrollsystem bauen. Sinnvoll ist ein gemeinsames TPRM, das je nach Betroffenheit zusätzliche Nachweise und Entscheidungswege aktiviert. Dieser Vergleich zeigt Gemeinsamkeiten, Unterschiede und eine integrierte Umsetzung.
Zuerst den Rechts- und Anwendungscharakter verstehen
NIS2 verpflichtet Mitgliedstaaten zur Umsetzung und richtet Anforderungen an wesentliche und wichtige Einrichtungen in bestimmten Sektoren. Die konkrete Pflicht eines Unternehmens hängt von nationaler Umsetzung, Größe, Tätigkeit und Sonderregeln ab. Rechtliche Betroffenheit muss fachkundig geprüft werden.
DORA gilt für die im Verordnungstext genannten Finanzunternehmen und adressiert ICT-Risikomanagement, Vorfälle, Resilienztests und Drittparteienrisiko. ISO/IEC 27001 definiert Anforderungen an ein Informationssicherheitsmanagementsystem für den selbst festgelegten Scope. Eine Zertifizierung bestätigt das Managementsystem in diesem Scope, nicht automatisch die Erfüllung jeder gesetzlichen Detailpflicht.
Die Kernlogik von NIS2
NIS2 verlangt angemessene und verhältnismäßige technische, operative und organisatorische Maßnahmen zur Steuerung von Risiken für Netz- und Informationssysteme. Die Richtlinie nennt unter anderem Sicherheit der Lieferkette einschließlich Beziehungen zu direkten Anbietern und Dienstleistern.
Die Risikobetrachtung soll Schwachstellen der direkten Anbieter und Dienstleister sowie die allgemeine Qualität ihrer Produkte und Sicherheitspraktiken berücksichtigen. Weitere Themen wie Incident Handling, Business Continuity, Kryptografie, Zugriff und Schwachstellenmanagement beeinflussen Drittparteien ebenfalls.
Die Kernlogik von DORA
DORA behandelt ICT-Drittparteienrisiko als integralen Bestandteil des ICT-Risikomanagements. Finanzunternehmen bleiben für die Einhaltung verantwortlich, auch wenn ICT-Leistungen ausgelagert werden. Kritische oder wichtige Funktionen erhalten besondere Aufmerksamkeit.
Die Verordnung adressiert Strategie, Register von Informationsbeziehungen, Due Diligence, Vertragsinhalte, Konzentrationsrisiko, Überwachung und Exit. Bestimmte kritische ICT-Drittdienstleister können auf europäischer Ebene beaufsichtigt werden. Das ändert nicht die Verantwortung des einzelnen Finanzunternehmens für seine Beziehung.
Die Kernlogik von ISO/IEC 27001
ISO/IEC 27001 verlangt, Informationssicherheitsrisiken im Scope systematisch zu bewerten und zu behandeln. Die Annex-A-Referenzkontrollen der Ausgabe 2022 enthalten einen eigenen Themenbereich zu Lieferantenbeziehungen, einschließlich Prozessen, Vertragsanforderungen, ICT-Lieferkette, Monitoring und Änderungsmanagement.
Die Organisation wählt Kontrollen risikobasiert und begründet Ein- oder Ausschlüsse in ihrer Erklärung zur Anwendbarkeit. Der Standard ist managementsystemorientiert: Verantwortlichkeit, Kompetenz, dokumentierte Information, Leistungsbewertung, Audit und Verbesserung sind ebenso wichtig wie einzelne Lieferantenklauseln.
Vergleich auf einen Blick
| Aspekt | NIS2 | DORA | ISO/IEC 27001 |
|---|---|---|---|
| Art | EU-Richtlinie, national umzusetzen | EU-Verordnung | internationaler Managementsystemstandard |
| Adressaten | wesentliche/wichtige Einrichtungen nach Scope | definierte Finanzunternehmen | jede Organisation mit gewähltem ISMS-Scope |
| Drittparteienfokus | Lieferkettensicherheit als Risikomaßnahme | detaillierter ICT-Drittparteien-Lebenszyklus | risikobasierte Lieferantenkontrollen |
| Kritikalität | angemessen und verhältnismäßig | kritische oder wichtige Funktionen zentral | aus Risikoanalyse und Scope |
| Nachweis | nach nationalem Aufsichts- und Umsetzungsrahmen | umfangreiche Dokumentation, Register und Aufsicht | ISMS-Nachweise und gegebenenfalls Zertifizierung |
Die Regelwerke sind nicht austauschbar. ISO/IEC 27001 kann ein strukturiertes Managementsystem und wiederverwendbare Nachweise liefern, ersetzt aber keine spezifische rechtliche Prüfung unter NIS2 oder DORA. Unternehmen sollten gemeinsame Controls zentral steuern und zusätzliche Anforderungen je Geltungsbereich eindeutig zuordnen.
Governance und Leitungsverantwortung
NIS2 stärkt die Verantwortung von Leitungsorganen für Risikomanagementmaßnahmen und deren Überwachung. Lieferkettenrisiko kann daher nicht vollständig an Einkauf oder Security delegiert werden. Die Leitung muss angemessene Steuerung und Ressourcen sicherstellen.
DORA weist dem Leitungsorgan umfassende Verantwortung für den ICT-Risikomanagementrahmen zu. Drittparteienstrategie, Risikotoleranz und wesentliche Abhängigkeiten gehören in diese Steuerung. ISO 27001 fordert Führung, Verantwortlichkeiten und Integration des ISMS in Geschäftsprozesse. Ein gemeinsames TPRM-Gremium kann alle drei Perspektiven bedienen.
Inventar und Informationsregister
Ein vollständiges Lieferanteninventar ist für jede risikobasierte Steuerung notwendig. NIS2 schreibt nicht in jedem Detail dasselbe Registerformat vor, verlangt aber eine belastbare Betrachtung der Lieferkettenbeziehungen und Risiken.
DORA enthält spezifische Anforderungen an ein Register von Informationen zu vertraglichen Vereinbarungen über ICT-Dienstleistungen. Die Detailtiefe und einschlägige technische Standards sind zu berücksichtigen. ISO 27001 lässt das Format offen, erwartet aber ausreichende dokumentierte Information und Nachweise für Risikobehandlung und Lieferantenkontrollen.
Kritische Lieferanten und Funktionen bestimmen
NIS2 folgt einem proportionalen Risikansatz. Unternehmen sollten Geschäftsfolgen, Zugriff, Daten, Ausbreitungswirkung und Anbieterqualität berücksichtigen. Nationale Leitlinien oder sektorale Vorgaben können Details ergänzen.
DORA verwendet die Kategorie kritischer oder wichtiger Funktionen als zentrale Bezugsgröße für strengere Bewertung, Verträge, Tests und Exit. ISO 27001 schreibt keine einheitliche Tiering-Terminologie vor; die Organisation entwickelt sie aus Risiko und Scope. Ein integriertes Modell kann DORA-Kategorien als regulatorisches Flag zusätzlich zum allgemeinen Risiko-Tier führen.
Due Diligence vor Vertragsabschluss
Alle drei Ansätze unterstützen eine Prüfung vor der Beauftragung, aber DORA konkretisiert ICT-Drittparteien stärker. Finanzunternehmen müssen Eignung, Risiken, Konzentration, Interessenkonflikte und weitere Faktoren abhängig von der Leistung bewerten.
Für NIS2 sollte Due Diligence zeigen, dass Risiken in direkten Anbieterbeziehungen angemessen berücksichtigt wurden. ISO 27001 verlangt risikobasierte Kontrollen und Lieferantenvereinbarungen; die konkrete Prüftiefe bestimmt die Organisation. Evidenz sollte immer auf den tatsächlichen Service bezogen sein.
Vertragliche Sicherheitsanforderungen
NIS2 nennt Lieferkettensicherheit als Risikomaßnahme, während konkrete Vertragsgestaltung aus Umsetzung, Risiko und weiteren Rechtsgebieten folgt. Sinnvolle Klauseln betreffen Schutz, Vorfälle, Schwachstellen, Unterauftragnehmer, Kontinuität, Nachweise und Exit.
DORA enthält detaillierte Mindestinhalte für vertragliche Vereinbarungen über ICT-Dienste und zusätzliche Elemente bei Unterstützung kritischer oder wichtiger Funktionen. Dazu zählen Leistungsbeschreibung, Standorte, Datenschutz, Service Levels, Unterstützung bei Vorfällen, Prüf- und Zugangsrechte, Kündigung sowie Exit. ISO 27001 fordert, relevante Informationssicherheitsanforderungen in Lieferantenvereinbarungen zu adressieren, lässt die Form risikobasiert.
Unterauftragnehmer und mehrstufige Lieferketten
NIS2 richtet den unmittelbaren Fokus auf Beziehungen zu direkten Anbietern, betrachtet aber auch Qualität und Schwachstellen der Lieferkette. Eine Organisation muss verstehen, welche Abhängigkeiten ihre Leistung prägen.
DORA adressiert Subcontracting bei ICT-Diensten, insbesondere für kritische oder wichtige Funktionen, deutlich. Transparenz, Bedingungen und Änderungen sind wichtig. ISO 27001 betrachtet ICT-Lieferkettenrisiken und die Steuerung von Lieferantenleistungen; konkrete Rechte müssen vertraglich umgesetzt werden.
Monitoring und periodische Überprüfung
Ein einmaliger Fragebogen erfüllt keinen der Ansätze überzeugend. NIS2 verlangt laufend angemessene Risikomaßnahmen. Veränderungen bei Anbieter, Schwachstellen oder Service müssen bewertet werden.
DORA verlangt Überwachung vertraglicher Leistung und ICT-Drittparteienrisiken, einschließlich Audit- und Prüfmechanismen. ISO 27001 referenziert Monitoring, Review und Änderungsmanagement von Lieferantenservices. Ein gemeinsamer Review-Kalender kann Zertifikate, Berichte, Findings, Vorfälle, Leistungsdaten und Änderungen abdecken.
Incident-Meldung und Zusammenarbeit
NIS2 enthält Meldepflichten für erhebliche Sicherheitsvorfälle. Ein betroffener Anbieter muss Informationen so rechtzeitig liefern, dass das Unternehmen Bewertung und Meldung erfüllen kann. Verträge und operative Kontakte müssen dies unterstützen.
DORA regelt Management und Meldung ICT-bezogener Vorfälle für Finanzunternehmen. Drittparteienverträge und Prozesse müssen schnelle Unterstützung, Informationen und Kooperation ermöglichen. ISO 27001 verlangt Incident Management im ISMS; Lieferantenanforderungen werden entsprechend Risiko eingebunden. Eine 24/7-Meldestrecke sollte praktisch getestet werden.
Business Continuity und Recovery
NIS2 nennt Business Continuity, Backup Management, Disaster Recovery und Krisenmanagement unter den Risikomaßnahmen. Lieferanten, die kritische Leistungen unterstützen, müssen in diese Fähigkeit integriert sein.
DORA verbindet BIA, kritische oder wichtige Funktionen, ICT-Business-Continuity, Response/Recovery, Backups und Tests detailliert. Ausgelagerte Funktionen bleiben Teil des Test- und Steuerungsrahmens. ISO 27001 enthält Kontrollen zur Informationssicherheit während Störungen und zur ICT-Bereitschaft für Business Continuity; Ausgestaltung folgt Risiko.
Konzentrationsrisiko
DORA hebt Konzentrationsrisiko bei ICT-Drittparteien und schwer substituierbaren Diensten ausdrücklich hervor. Das betrifft einzelne Anbieter und Abhängigkeiten über das Finanzsystem. Exit und Alternativen sind eng damit verbunden.
NIS2 und ISO 27001 können Konzentration über allgemeinen Risikoansatz erfassen, schreiben aber nicht identisch denselben DORA-Mechanismus vor. Unternehmen sollten dennoch Cloud-, Region-, Plattform- und Unterauftragnehmerkonzentration im Portfolio auswerten.
Audit-, Zugangs- und Prüfungsrechte
DORA legt für relevante ICT-Verträge umfassende Zugangs-, Inspektions- und Auditrechte sowie Kooperation mit Behörden nahe beziehungsweise fest. Pooled Audits und Zertifikate können Teile unterstützen, dürfen notwendige Rechte nicht unvertretbar beschränken.
ISO 27001 erwartet angemessene Überwachung und Review; konkrete Auditklauseln leiten sich aus Risiko ab. NIS2-Nachweise müssen je nach nationaler Aufsicht und Maßnahme verfügbar sein. In der Praxis werden Rechte proportional gestaltet und durch unabhängige Berichte effizient ergänzt.
Exit und Kündigung
DORA behandelt Exit-Strategien für ICT-Dienstleistungen besonders ausführlich, damit Finanzunternehmen ohne unangemessene Störung, Complianceverlust oder Datenrisiko aus einer Beziehung wechseln können. Pläne, Alternativen und Übergangszeiten sind wichtig.
NIS2 erfordert angemessene Risikosteuerung, wodurch Exit bei kritischen Abhängigkeiten relevant wird. ISO 27001 adressiert Änderungen und Beendigung von Lieferantenbeziehungen über risikobasierte Kontrollen. Ein integriertes Programm plant Datenexport, Zugangsentzug, Migration und Löschung bereits beim Onboarding.
Managementsystem und Zertifizierung
ISO/IEC 27001 kann als strukturierende Basis dienen: Kontext, Risikoanalyse, Maßnahmen, interne Audits, Managementbewertung und Verbesserung. Ein Zertifikat kann Kunden Vertrauen geben, wenn Scope und Aussagekraft passen.
Es ist aber kein pauschaler Rechtskonformitätsnachweis für NIS2 oder DORA. Regulatorische Anforderungen müssen separat gemappt und erfüllt werden. Umgekehrt kann eine regulatorisch konforme Einzelkontrolle ohne funktionierendes Managementsystem dauerhaft schwer zu pflegen sein.
Nachweise sinnvoll wiederverwenden
Ein zentrales Kontrollregister ordnet Anforderungen, Verantwortliche und Evidenz mehreren Rahmenwerken zu. Beispielsweise kann ein Lieferanten-Tiering sowohl NIS2-Risikosteuerung, DORA-Kritikalität als auch ISO-Risikobehandlung unterstützen. Die jeweilige Aussagegrenze bleibt markiert.
Vermeiden Sie dreifache Fragebögen und Vertragslisten. Pflegen Sie Serviceinventar, Due-Diligence-Bericht, Vertrag, Monitoring und Exit zentral. Zusätzliche regulatorische Felder werden als Attribute ergänzt.
Ein integriertes Zielprozessmodell
- Servicebedarf, Daten, Zugriff und Geschäftsabhängigkeit erfassen.
- Rechtliche Betroffenheit und regulatorische Flags bestimmen.
- Inhärentes Risiko und Kritikalität einstufen.
- Due Diligence mit servicebezogener Evidenz durchführen.
- Rest-Risiko, Ausnahme und Managemententscheidung dokumentieren.
- Vertragsanforderungen nach Baseline und Zusatzmodulen vereinbaren.
- Technisches Onboarding und Verantwortungsgrenzen abnehmen.
- Leistung, Sicherheit, Kontinuität und Änderungen überwachen.
- Incident- und Recovery-Übergaben testen.
- Exit vorbereiten und Offboarding nachweisen.
Beispiel: Kritischer Cloud-Service im Finanzunternehmen
Ein Cloud-Service unterstützt eine kritische Funktion und verarbeitet vertrauliche Daten. DORA-Flag und Tier 1 werden gesetzt. Die Due Diligence prüft Sicherheit, Resilienz, Unterauftragnehmer, Regionen und Konzentration. Der Vertrag erhält die erforderlichen DORA-Inhalte sowie ISO-basierte Sicherheitsanforderungen.
Das ISMS führt die Beziehung im Risikoregister und überwacht Findings. BCM und ICT-Continuity testen Ausfall und Recovery. NIS2 kann je nach Betroffenheit zusätzliche Lieferketten- und Meldeanforderungen spiegeln. Ein gemeinsamer Datensatz bedient mehrere Nachweise.
Beispiel: Softwarelieferant eines Industrieunternehmens
Der Lieferant verteilt signierte Software auf Produktionssysteme. Die Beziehung ist wegen Ausbreitungswirkung kritisch, obwohl keine Datenverarbeitung stattfindet. NIS2-orientierte Lieferkettensicherheit und ISO-Risikobehandlung verlangen Secure-Development-, Update- und Incident-Kontrollen.
DORA ist nicht einschlägig, sofern das Unternehmen nicht in dessen Anwendungsbereich fällt. Das TPRM nutzt dennoch Best Practices wie klare Unterauftragnehmer- und Exit-Regelung. Technisch werden gestufte Updates und Rollback getestet.
Häufige Fehlinterpretationen
„ISO-zertifiziert bedeutet NIS2-konform“: Scope und gesetzliche Details müssen separat bewertet werden. „DORA betrifft nur den Anbieter“: Das Finanzunternehmen bleibt für seine Risiken und Pflichten verantwortlich. „NIS2 verlangt denselben Vertrag wie DORA“: Die Rahmenwerke besitzen unterschiedliche Detailtiefe.
„Ein Fragebogen genügt“: Alle Ansätze benötigen Lebenszyklussteuerung und Nachweise. „Nur direkte Lieferanten sind relevant“: Unterauftragnehmer und Konzentration können die eigentliche Abhängigkeit bilden.
Eine 90-Tage-Harmonisierung
In Monat eins werden Betroffenheit, bestehende Inventare und Kontrollkataloge gemappt. Monat zwei vereinheitlicht Tiering, Due-Diligence-Module und Vertragsbaseline. Regulatorische Zusatzfelder für DORA und NIS2 werden ergänzt.
Monat drei pilotiert den Prozess mit kritischen Services, bereinigt Doppelkontrollen und definiert Nachweise sowie Managementreporting. Offene Rechtsfragen werden mit zuständigen Experten geklärt. Der Bestand wird anschließend risikobasiert migriert.
Fazit: Ein Prozess, mehrere Anforderungsprofile
NIS2, DORA und ISO 27001 teilen die Idee risikobasierter Lieferantensteuerung, unterscheiden sich aber bei Rechtsnatur, Adressaten und Detailgrad. DORA konkretisiert ICT-Drittparteien im Finanzsektor, NIS2 verankert Lieferkettensicherheit breit im Cyberrisikomanagement, ISO 27001 liefert eine Managementsystemstruktur.
BlackMount harmonisiert im Drittparteienrisikomanagement mehrere Rahmenwerke in einem Lebenszyklus. Unternehmen erhalten eindeutige regulatorische Flags, wiederverwendbare Nachweise und angemessene Prüftiefe statt paralleler Kontrollwelten.
