Fristen sicher einhalten, Verantwortung behalten

DORA und NIS2 in der Lieferkette

Viele Sicherheitsvorfälle entstehen bei Cloud‑Anbietern, Software‑Herstellern oder ausgelagerten Dienstleistern. Gemeldet werden müssen sie jedoch vom regulierten Unternehmen. Entscheidend sind daher Governance und Verträge, nicht nur Technik.

Digital Operational Resilience Act (DORA): Seit 17. Januar 2025 unmittelbar für Finanzunternehmen in der Europäischen Union anwendbar; Meldeempfänger sind die Finanzaufsichtsbehörden (Bundesanstalt für Finanzdienstleistungsaufsicht – BaFin). DORA enthält verbindliche Anforderungen an das Management von Risiken der Informations‑ und Kommunikationstechnologie sowie Mindestinhalte für Verträge mit IKT‑Dienstleistern (Informations‑ und Kommunikationstechnologie‑Dienstleistern).

Network and Information Security 2 (NIS2): Verpflichtet Unternehmen zu einem systematischen Cybersicherheits‑Risikomanagement einschließlich Sicherheit in der Lieferkette und zu frühzeitigen Meldungen erheblicher Sicherheitsvorfälle an die zuständigen Stellen (in Deutschland an das Bundesamt für Sicherheit in der Informationstechnik – BSI beziehungsweise das zuständige Computer‑Notfallteam – Computer Security Incident Response Team, CSIRT).

Vorrangregel (lex specialis): Für Finanzunternehmen geht DORA NIS2 grundsätzlich vor, wenn beide Regelwerke denselben Gegenstand betreffen (Risikomanagement, Meldepflichten, Aufsicht). Nationale Umsetzung und behördliche Zusammenarbeit sind dennoch zu beachten.

Fünf praxisbewährte Hebel

1. Kritikalität aus Regulierungssicht bewerten

Nicht nur die Geschäftsrelevanz zählt, sondern der mögliche Einfluss auf Meldepflichten und auf „kritische oder wichtige Funktionen“ im Sinn von DORA.
Ergebnis: Eine priorisierte Liste von IKT‑Dienstleistern, abgestimmt zwischen Informationssicherheitsmanagement, operativem Risiko und Einkauf.

2. Meldefähigkeit vertraglich fest verankern

Verbindliche Zeitziele: Erstinformation (zum Beispiel innerhalb von zwei Stunden nach Erkennung beim Dienstleister), strukturierte Zwischeninformationen, Abschlussberichte.
Mindestinhalte abdecken: Betroffene Dienste und Prozesse, Zeiträume, Auswirkungen, Indikatoren, erste Gegenmaßnahmen und Status der Behebung, kompatibel mit DORA‑Vorgaben und NIS2‑Meldeschritten.

3. Technische Fakten und regulatorische Bewertung trennen

Der IKT‑Dienstleister liefert technische Informationen (zum Beispiel Protokolle, Zeitstempel, Indikatoren).
Die Einstufung des Vorfalls und die Meldung an Behörden liegen beim Unternehmen.
Rollenmodell klar definieren: Betrieb (Erkennung und Erstreaktion), Informationssicherheitsbeauftragter bzw. Chief Information Security Officer (Bewertung), „Meldeverantwortliche Person“ (Koordination der Behördenmeldungen), Unternehmenskommunikation und Rechtsabteilung.

4. Kontaktstellen und Wege fest verdrahten

Rund‑um‑die‑Uhr erreichbare Funktionsadresse oder Hotline für Dienstleister, standardisierte Erstinformations‑Formate, eindeutige Eskalationsmatrix.
Eine zentrale Meldeverantwortung koordiniert Meldungen an Finanzaufsicht und Cybersicherheitsbehörden und konsolidiert die Informationen aus der Lieferkette.

5. Gemeinsam üben mit kritischen Dienstleistern

Mindestens einmal pro Jahr: realistische Meldekaskaden mit Zeitzielen, Sub‑Outsourcing‑Ketten und Integration in Ticket‑ oder Automatisierungswerkzeuge (Security Orchestration, Automation and Response – Orchestrierung, Automatisierung und Reaktion) üben.
Erkenntnisse systematisch in Verträge, Runbooks und Schulungen zurückführen.

Ein zentraler Governance‑Grundsatz

Auslagerung reduziert Aufwand aber niemals Verantwortung.

Ein Vorfall kann beim Dienstleister entstehen. Die regulatorische Bewertung, die Entscheidung und die Meldung liegen jedoch immer beim Unternehmen selbst. Diese Trennung ist fachlich und haftungsseitig essenziell.

Vertrags‑Checkliste (kurz und wirksam)

Praxis‑Tipp: Vertragsklauseln, Prozesshandbücher und Automatisierung spiegeln. Was vereinbart ist, wird im Ernstfall gelebt.

Governance‑Blueprint in drei Verantwortungsbereichen

Leitungsorgan (zum Beispiel Geschäftsführung oder Vorstand): Verantwortung für die Gesamtsteuerung des Vorfallmanagements nach DORA und NIS2; Zielbild, Kennzahlen, regelmäßige Unterrichtung.
Informationssicherheitsmanagement: Einheitliche Klassifikation von Vorfällen und Schwellenwerte, Zuordnung zu DORA und NIS2, Entscheidungsvorlagen, Lessons Learned.
Betrieb und Meldeorganisation: Erkennung, Datenerhebung, Triage, Behördenmeldungen und Kommunikationskoordination; Rollen‑ und Verantwortlichkeitsmatrix (RACI) klar definiert.

Normative Stütze: ISO/IEC 27002:2022 (Lieferkette und Lieferantenmanagement), ISO/IEC 27035 (Management von Sicherheitsvorfällen), ISO 22301/22313 (Business Continuity).

Wie die HUG Sie aufsichtssicher macht

Analyse der Betroffenheit und Zuordnung: DORA gegenüber NIS2, Meldewege, Schnittstellen zu kritischen oder wichtigen Funktionen.
Architektur der Meldeprozesse: Klassifikationsschema, Vorlagen, Integration in Ticketsysteme oder Automatisierung, Rollen und Verantwortlichkeiten.
Vertrags‑ und Lieferanten‑Upgrade: DORA‑konforme Klauselpakete, Durchreichung an Unterauftragnehmer, Kontrolle des Sub‑Outsourcings.
Übungen und Befähigung: Meldekaskaden mit kritischen Dienstleistern, Kurzschulungen für Leitungsorgane, strukturierter Verbesserungszyklus.

Fazit

Drittanbieter entscheiden heute maßgeblich über Meldegeschwindigkeit, Informationsqualität und Aufsichtsfestigkeit.
Wer DORA und NIS2 ernst nimmt, macht Lieferketten governancefähig – organisatorisch, vertraglich und technisch.
Cybersicherheit endet nicht an der Unternehmensgrenze.
Weniger melden ist keine Lösung, klüger melden schon.