Drittparteienrisiken unter DSGVO, NIS2 und DORA

Derselbe Lieferant kann Pflichten in den Bereichen Datenschutz, Cybersicherheit und operationale Resilienz auslösen. Ein Lohnabrechnungsdienstleister verarbeitet personenbezogene Daten; ein Managed-Service-Provider verfügt über privilegierte Zugriffe; eine Cloud-Plattform unterstützt geschäftskritische Anwendungen. Manchmal tut ein einziger Lieferant alles drei.

Ein gemeinsamer Lieferanteneintrag hilft Teams, die Bewertung zu koordinieren, sofern jede Pflicht erkennbar bleibt. Für einen CTO besteht die praktische Herausforderung darin, vertragliche Zusagen mit der technischen Realität zu verbinden: worauf der Lieferant zugreifen kann, wie sich Ausfälle fortpflanzen, welche Maßnahmen nachgewiesen sind und ob die Organisation sich erholen oder aussteigen kann.

Klären Sie die Anwendbarkeit, bevor Sie Bewertungen zusammenführen

Diese Instrumente überschneiden sich, gelten aber nicht für jede Organisation und jeden Lieferanten in gleicher Weise.

Artikel 28 DSGVO verlangt, dass Verantwortliche nur mit Auftragsverarbeitern arbeiten, die hinreichende Garantien bieten. Ein Vertrag nach Artikel 28 ist nicht schon deshalb angemessen, weil ein Lieferant Daten erhält: Klären Sie zuerst die tatsächliche Verarbeitungsrolle.

Die Artikel 20 bis 23 NIS2 regeln die Aufsicht durch die Leitungsorgane, Risikomanagementmaßnahmen und die Meldung erheblicher Sicherheitsvorfälle. NIS2 ist eine Richtlinie, die durch nationales Recht umgesetzt wird; Anwendungsbereich und Verfahren erfordern daher Prüfungen für die jeweilige Rechtsordnung.

DORA gilt seit dem 17. Januar 2025. Die Verordnung erfasst in erster Linie bestimmte Finanzunternehmen; gewöhnliche IKT-Dienstleister können vertraglichen Anforderungen ihrer Kunden unterliegen, während für benannte kritische IKT-Drittdienstleister ein eigener Überwachungsrahmen gilt. Für erfasste Finanzunternehmen wirkt DORA in den relevanten NIS2-Bereichen als sektorspezifisches Unionsrecht. Setzen Sie nicht automatisch beide Maßnahmenkataloge doppelt um.

Bauen Sie den Eintrag um die Abhängigkeit herum auf

Beginnen Sie mit dem Dienst, nicht mit dem Lieferantenfragebogen. Ein Lieferant kann mehrere Dienste mit unterschiedlichen Daten, Zugriffen und unterschiedlicher betrieblicher Bedeutung erbringen.

Halten Sie als praktische Grundlage fest:

• Dienst, juristische Person des Lieferanten, fachlich verantwortliche Person, technisch verantwortliche Person und prüfende Personen.
• Unterstützte Funktionen, Systeme, Integrationen und privilegierte Zugriffe.
• Kategorien personenbezogener Daten, Verarbeitungszwecke, Standorte und Unterauftragsverarbeiter.
• Verfügbarkeitsanforderungen, Wiederherstellungsziele und tolerierbare Störungen.
• Zugrunde liegende Anbieter, vertragliche Abhängigkeiten und realistische Alternativen.
• Anwendbare Pflichten, Datum der Nachweise, offene Lücken und Entscheidungen.

Ermitteln Sie, welche Funktionen nach einer Kompromittierung oder einem Ausfall versagen oder sich verschlechtern würden. Ein Lieferant, der wenige sensible Daten speichert, kann dennoch Authentisierung oder Bereitstellungs-Pipelines steuern. Umgekehrt kann ein Dienst mit geringem Verfügbarkeitsrisiko hochsensible personenbezogene Daten offenlegen.

Halten Sie diese Dimensionen getrennt, statt sie zu einem unerklärten Wert „hohes Risiko“ zusammenzufassen. Verbinden Sie bei Finanzunternehmen, die DORA unterliegen, dieses betriebliche Inventar mit dem vorgeschriebenen Informationsregister über vertragliche Vereinbarungen zu IKT-Dienstleistungen; eine allgemeine Lieferantenliste genügt nicht unbedingt.

Verwenden Sie Nachweise wieder, ohne Schlussfolgerungen blind zu übernehmen

Ein Sicherheitsbericht, eine Datenflusskarte oder ein Wiederherstellungstest kann mehrere Prüfungen stützen. Prüfen Sie Dienstumfang, Berichtszeitraum, Ausschlüsse, Ausnahmen und Pflichten auf Kundenseite, bevor Sie sich darauf verlassen.

So deckt ein Bericht über die Infrastruktur des Lieferanten nicht unbedingt den Zugriff seines Supportpersonals auf Kundendatensätze ab. Eine dokumentierte Datensicherungsrichtlinie zeigt nicht, dass die Wiederherstellung die Wiederherstellungsanforderungen Ihrer Anwendung erfüllt.

Führen Sie eine Matrix, die Nachweise den Fragen zuordnet:

Ein ISO-Zertifikat oder ein SOC-2-Bericht gibt innerhalb seines Geltungsbereichs Sicherheit; keines von beiden begründet DSGVO- oder NIS2-Konformität. Bewahren Sie die Begründung der prüfenden Person, nicht nur das hochgeladene Dokument. Die Bewertung von Sicherheitsnachweisen sollte eine wiederholbare technische Prüfung sein, kein Abhaken von Siegeln.

Übersetzen Sie Anforderungen in Verträge und Maßnahmen

Nach Artikel 28 DSGVO müssen die Bedingungen der Auftragsverarbeitung Gegenstand, Dauer, Art und Zweck der Verarbeitung, die Art der Daten und die Kategorien betroffener Personen regeln. Sie umfassen außerdem dokumentierte Weisungen, Vertraulichkeit, Sicherheit, Bedingungen für Unterauftragsverarbeiter, Unterstützung, Löschung oder Rückgabe sowie Informations- und Prüfpflichten. Internationale Datenübermittlungen erfordern eine gesonderte Bewertung nach Kapitel V; Hosting in der EU allein klärt Fragen zu Zugriffen und Weiterübermittlungen nicht.

Artikel 21 NIS2 umfasst die Sicherheit der Lieferkette und die Berücksichtigung von Schwachstellen und Cybersicherheitspraktiken unmittelbarer Lieferanten. Praktische vertragliche Erwartungen können Zugriffsbeschränkungen, den Umgang mit Schwachstellen, Mitwirkung bei Vorfällen und die Bereitstellung von Nachweisen umfassen. Passen Sie diese an den Dienst und die nationalen Anforderungen an, statt ein einziges allgemeingültiges Klauselpaket als rechtlich ausreichend zu behandeln.

Artikel 30 DORA legt vertragliche Bestimmungen für IKT-Dienstleistungen fest, mit zusätzlichen Anforderungen für Dienstleistungen, die kritische oder wichtige Funktionen unterstützen. Prüfen Sie Leistungsbeschreibungen, Standorte, Datenschutz und Datenwiederherstellung, Unterstützung, Kündigung und relevante Aufsichtsrechte. Bei kritischen oder wichtigen Funktionen verdienen Service-Levels, Berichterstattung, Notfallmaßnahmen, Mitwirkung bei Tests, Prüfrechte und Übergangsregelungen besondere Aufmerksamkeit.

Verifizieren Sie dann die Umsetzung. Sagt ein Vertrag beschränkte administrative Zugriffe zu, beschaffen Sie Nachweise zu Rollentrennung, Authentisierung, Genehmigung und Protokollierung. Sagt er Löschung zu, klären Sie, was mit Datensicherungen und aufbewahrten Datensätzen geschieht. Weisen Sie rechtliche und technische Lücken den jeweils zuständigen prüfenden Personen zu.

Gestalten Sie Übergaben bei Vorfällen vor dem Vorfall

Die Richtlinie eines Lieferanten zur Reaktion auf Vorfälle kann eine Sicherheitsbewertung stützen und Meldepflichten dennoch ungeklärt lassen. Legen Sie Kontaktwege, Eskalationsabdeckung, Erstinformationen, Erwartungen an Aktualisierungen und die Verantwortung für die Sicherung von Beweismitteln fest.

Nach Artikel 33 und 34 DSGVO benachrichtigt ein Auftragsverarbeiter den Verantwortlichen unverzüglich. Der Verantwortliche prüft eine Meldung an die Aufsichtsbehörde unverzüglich und möglichst binnen 72 Stunden, nachdem ihm die Verletzung bekannt wurde, es sei denn, die Verletzung führt voraussichtlich nicht zu einem Risiko für die Rechte und Freiheiten natürlicher Personen. Ein hohes Risiko kann eine Benachrichtigung der betroffenen Personen erfordern, vorbehaltlich von Ausnahmen. Dokumentieren Sie die Begründung, wenn keine Meldung erforderlich ist.

Die Meldestufen der NIS2 auf EU-Ebene für erhebliche Sicherheitsvorfälle umfassen eine Frühwarnung innerhalb von 24 Stunden, eine Meldung innerhalb von 72 Stunden und in der Regel einen Abschlussbericht innerhalb eines Monats nach der Meldung; prüfen Sie die nationalen und sektoralen Vorschriften. DORA hat einen eigenen Meldeweg für schwerwiegende IKT-bezogene Vorfälle. Ersetzen Sie diese Bewertungen nicht durch ein einziges Kennzeichen „Sicherheitsverletzung beim Lieferanten“.

Als praktische Empfehlung sollten Sie einen Vorfall beim Lieferanten mit unvollständigen Informationen üben. Testen Sie, ob Teams betroffene Dienste, Exposition, betriebliche Auswirkungen und Meldeentscheidungen feststellen können, ohne auf einen abschließenden Bericht zur Ursache zu warten.

Beispiel: ein Dienst, drei Prüfwege

Angenommen, ein erfasstes Finanzunternehmen nutzt eine gehostete Kundensupportplattform, die personenbezogene Daten verarbeitet und eine Funktion unterstützt, die es nach DORA als kritisch oder wichtig eingestuft hat.

Der Lieferant stellt einen Prüfbericht, eine Richtlinie zu Vorfällen und eine Zusammenfassung eines Wiederherstellungstests bereit. Die Sicherheit stellt fest, dass die Maßnahmen für administrative Zugriffe nachgewiesen sind, der Wiederherstellungstest die Integration des Kunden jedoch ausschließt.

Der Datenschutz stellt gesondert einen unklaren Prozess für Änderungen bei Unterauftragsverarbeitern und ungeklärte Übermittlungsregelungen für Fernzugriffe fest. Die DORA-Prüfung ergibt, dass Übergangsunterstützung und relevante Prüfbestimmungen nachgebessert werden müssen.

Der daraus entstehende Maßnahmenplan ist konkret:

• Die technisch verantwortliche Person testet die Wiederherstellung der Integration und dokumentiert das Ergebnis.
• Die Datenschutzprüfung klärt die Fragen zu Unterauftragsverarbeitern und Übermittlungen.
• Recht und Einkauf schließen die vertraglichen Lücken.
• Die verantwortliche Person entscheidet, ob eine vorübergehende Nutzung mit Bedingungen und Überprüfungsdatum akzeptabel ist.

Nachweise werden wiederverwendet, doch keine der drei Schlussfolgerungen wird aus einer anderen abgeleitet. Eine bestandene Sicherheitsprüfung schließt weder die Datenschutz- noch die Resilienzlücken.

Überwachen Sie Änderungen, Konzentration und einen umsetzbaren Ausstieg

Legen Sie die Prüfhäufigkeit nach Abhängigkeit und Risiko fest. Lösen Sie zusätzliche Prüfungen nach Vorfällen, größeren Änderungen am Dienst, neuen Unterauftragsverarbeitern, geänderten Datenstandorten, Eigentümerwechseln oder Vertragsverlängerungen aus.

Schauen Sie hinter die Namen der Lieferanten: Mehrere Dienste können von derselben Cloud-Region, demselben Identitätsanbieter oder demselben Unterauftragnehmer abhängen. Bewerten Sie korrelierte Störungen und ob die vorgesehene Alternative dieselbe Abhängigkeit teilt. Artikel 29 DORA regelt ausdrücklich die Bewertung des IKT-Konzentrationsrisikos.

Pflegen Sie einen verhältnismäßigen Ausstiegsplan mit Datenexport, Migration, Fortführung, Entzug von Zugriffen und Löschnachweisen. Testen Sie die Nutzbarkeit von Exporten und klären Sie, wer den Ersatz betreiben kann. Ein Kündigungsrecht ist nützlicher, wenn die Organisation es auch umsetzen kann.

Auch die Folgen unterscheiden sich. Die DSGVO kennt nach Art des Verstoßes gestaffelte Bußgeldrahmen; NIS2 verlangt nationale Sanktionsregelungen mit unterschiedlichen Höchstbeträgen für wesentliche und wichtige Einrichtungen. Sanktionen nach DORA gegenüber Finanzunternehmen hängen von den anwendbaren Regelungen ab, während Sanktionen im Rahmen der Überwachung kritischer Dienstleister davon getrennt sind. Modellieren Sie das Risiko nicht anhand einer vermeintlich einheitlichen Geldbuße.

Beginnen Sie mit einer folgenreichen Abhängigkeit

Wählen Sie einen Lieferanten, der eine wichtige Funktion unterstützt. Gleichen Sie dessen Dienstinventar, Verträge, Nachweise, offene Risiken und Ausstiegsannahmen ab. Schließen Sie mit benannten Verantwortlichen und getrennten, datierten Schlussfolgerungen für jede anwendbare Pflicht ab.

In Secani können Teams den Dienst und den externen Dienstleister modellieren, Anforderungen und Maßnahmen mit Nachweisen verbinden und Lücken als Aufgaben mit Verantwortlichen verfolgen. Von Menschen geprüfte Entscheidungen, Quellverweise, Kommentare und Zeitstempel bewahren die Begründung. Das unterstützt einen gemeinsamen Lieferantenkontext, ohne die unterschiedlichen Beurteilungen zu Datenschutz, Sicherheit und Resilienz zu verdecken.