DORA-IKT-Exit-Strategien mit ISO 27001-Maßnahmen
Um 07:42 Uhr an einem Montag erhält der Leiter des Fintech-Betriebs die Nachricht, die niemand lesen möchte: Der cloudbasierte Anbieter für Transaktionsüberwachung des Unternehmens hat einen schweren regionalen Ausfall erlitten. Um 08:15 Uhr fragt der Chief Risk Officer, ob der betroffene Service eine kritische oder wichtige Funktion unterstützt. Um 08:40 Uhr will die Rechtsabteilung wissen, ob der Vertrag Übergangshilfe, Datenexport, Löschung und Auditrechte vorsieht. Um 09:05 Uhr sucht der CISO nach Nachweisen, dass der Exit-Plan tatsächlich getestet und nicht nur geschrieben wurde.
In einem anderen Finanzdienstleistungsunternehmen öffnet Sarah, CISO einer schnell wachsenden Fintech-Plattform, eine Informationsanforderung im Vorfeld einer DORA-Compliance-Prüfung. Die Fragen wirken vertraut, bis sie den Abschnitt zu IKT-Drittdienstleistern erreicht, die kritische oder wichtige Funktionen unterstützen. Die Auditoren fragen nicht, ob das Unternehmen eine Lieferantenrichtlinie hat. Sie verlangen dokumentierte, getestete und belastbare Exit-Strategien.
Ihre Gedanken springen zum zentralen Cloud-Anbieter, der die Plattform hostet, und anschließend zum Managed Security Service Provider, der Bedrohungen rund um die Uhr überwacht. Was passiert, wenn der Cloud-Anbieter von einer geopolitischen Störung betroffen ist? Was passiert, wenn der MSSP von einem Wettbewerber übernommen wird? Was passiert, wenn ein kritischer SaaS-Anbieter insolvent wird, den Service einstellt oder nach einem schweren Vorfall das Vertrauen der Kunden verliert?
Die unbequeme Antwort ist in vielen Unternehmen gleich. Es gibt eine Lieferantenrisikobewertung, einen Business-Continuity-Plan, einen Vertragsordner, ein Cloud-Inventar und vielleicht einen Backup-Bericht. Es gibt jedoch keine einheitliche, auditbereite DORA-IKT-Exit-Strategie für IKT-Drittdienstleister, die geschäftliche Kritikalität, vertragliche Rechte, technische Portabilität, Kontinuitätspläne, Backup-Nachweise, Datenschutzpflichten und Managementfreigabe miteinander verbindet.
DORA verändert den Stellenwert des Lieferantenmanagements. Nach der Verordnung (EU) 2022/2554 müssen Finanzunternehmen IKT-Drittparteienrisiken als Teil des Rahmenwerks für das Management von IKT-Risiken steuern. Sie bleiben vollständig für die Einhaltung verantwortlich, führen ein Register der IKT-Dienstleistungsverträge, unterscheiden IKT-Vereinbarungen, die kritische oder wichtige Funktionen unterstützen, bewerten Konzentrations- und Unterauftragsrisiken und pflegen Exit-Strategien für kritische Abhängigkeiten von IKT-Drittdienstleistern. DORA gilt ab dem 17. Januar 2025 und legt einheitliche EU-Anforderungen an das Management von IKT-Risiken, die Meldung von Vorfällen, Resilienztests, den Informationsaustausch und das Management von IKT-Drittparteienrisiken für ein breites Spektrum von Finanzunternehmen fest.
Eine DORA-Exit-Strategie ist kein Absatz in einem Lieferantenvertrag. Sie ist ein Kontrollsystem. Sie muss gesteuert, risikobeurteilt, technisch umsetzbar, vertraglich durchsetzbar, getestet, nachgewiesen und kontinuierlich verbessert werden.
Der Ansatz von Clarysec kombiniert die Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, Enterprise-Richtlinienvorlagen und Zenith Controls: The Cross-Compliance Guide Zenith Controls, um aus der Montagsfrage eine vorbereitete Antwort zu machen.
Warum DORA-Exit-Strategien in echten Audits scheitern
Die meisten Schwächen von DORA-IKT-Exit-Strategien sind strukturell, bevor sie technisch werden. Die Organisation hat einen Lieferantenverantwortlichen, aber keinen rechenschaftspflichtigen Risikoeigner. Es gibt Backup-Jobs, aber keine Nachweise zur Wiederherstellung. Es gibt einen Due-Diligence-Fragebogen für Lieferanten, aber keine dokumentierte Entscheidung, ob der Anbieter eine kritische oder wichtige Funktion unterstützt. Es gibt Formulierungen zur Vertragsbeendigung, aber keinen Übergangszeitraum, der auf den Business-Continuity-Plan abgestimmt ist.
DORA führt diese Bausteine zusammen. Article 28 legt die allgemeinen Grundsätze für das Management von IKT-Drittparteienrisiken fest, einschließlich der Pflicht, Risiken durch IKT-Drittdienstleister über den gesamten Lebenszyklus zu steuern und angemessene Exit-Strategien aufrechtzuerhalten. Article 30 definiert detaillierte vertragliche Anforderungen für IKT-Services, die kritische oder wichtige Funktionen unterstützen, einschließlich Servicebeschreibungen, Standorten der Datenverarbeitung, Sicherheitsvorkehrungen, Zugriffs- und Auditrechten, Unterstützung bei Vorfällen, Zusammenarbeit mit zuständigen Behörden und Kündigungsrechten.
Die Verordnung ist zudem verhältnismäßig ausgestaltet. Articles 4 und 16 erlauben bestimmten kleineren oder ausgenommenen Unternehmen die Anwendung eines vereinfachten Rahmenwerks für das Management von IKT-Risiken. Vereinfacht bedeutet jedoch nicht undokumentiert. Kleinere Finanzunternehmen benötigen weiterhin ein dokumentiertes Management von IKT-Risiken, kontinuierliche Überwachung, resiliente Systeme, die unverzügliche Identifizierung von IKT-Vorfällen, die Identifizierung wesentlicher Abhängigkeiten von IKT-Drittdienstleistern, Backup und Wiederherstellung, Geschäftskontinuität, Reaktion und Wiederherstellung, Tests, Lessons Learned und Schulung.
Ein kleines Fintech kann nicht sagen: „Wir sind zu klein für Exit-Planung.“ Es kann sagen: „Unsere DORA-Exit-Strategie ist an unsere Größe, unser Risikoprofil und die Komplexität unserer Services angepasst.“ Der Unterschied liegt in den Nachweisen.
Für Unternehmen, die zusätzlich in den nationalen Anwendungsbereich von NIS2 fallen, wirkt DORA als sektorspezifischer Rechtsakt der Union für überschneidende Cybersicherheitspflichten im Finanzsektor. NIS2 bleibt im breiteren Ökosystem relevant, insbesondere für Managed Service Provider, Managed Security Service Provider, Cloud-Anbieter, Rechenzentren und Anbieter digitaler Infrastruktur. NIS2 Article 21 verstärkt dieselben Themen: Risikoanalyse, Umgang mit Informationssicherheitsvorfällen, Aufrechterhaltung des Geschäftsbetriebs, Sicherheit der Lieferkette, sichere Beschaffung, Wirksamkeitsbewertung, Schulung, Kryptografie, Zugriffskontrolle, Asset-Management und Authentifizierung.
Aufsichtsbehörden, Kunden, Auditoren und Leitungsorgane können die Frage unterschiedlich formulieren, doch der Kern bleibt derselbe: Können Sie aus einem kritischen IKT-Anbieter aussteigen, ohne die Kontrolle über Servicekontinuität, Daten, Nachweise oder Kundenauswirkungen zu verlieren?
Die Exit-Strategie in das ISMS integrieren
ISO/IEC 27001:2022 liefert das Managementsystem-Rückgrat für die DORA-Exit-Planung.
Die Klauseln 4.1 bis 4.4 verlangen, dass die Organisation ihren Kontext, interessierte Parteien, gesetzliche, regulatorische und vertragliche Anforderungen, den ISMS-Geltungsbereich, Schnittstellen, Abhängigkeiten und Prozesse definiert. An dieser Stelle identifiziert ein Finanzunternehmen DORA, Kundenverpflichtungen, Auslagerungserwartungen, Cloud-Abhängigkeiten, Datenschutzpflichten, Unterauftragnehmer und IKT-Services innerhalb der ISMS-Grenzen.
Die Klauseln 5.1 bis 5.3 verlangen Führung, Richtlinie, Ressourcen, Rollenzuweisung und Rechenschaftspflicht. Dies entspricht dem Governance-Modell von DORA, in dem das Leitungsorgan das Management von IKT-Risiken definiert, genehmigt, überwacht und dafür verantwortlich bleibt, einschließlich IKT-Business-Continuity, Reaktions- und Wiederherstellungsplänen, IKT-Auditplänen, Budgets, Resilienzstrategie und Richtlinie zum IKT-Drittparteienrisiko.
Die Klauseln 6.1.1 bis 6.1.3 überführen Exit-Planung in Risikobehandlung. Die Organisation definiert Risikokriterien, führt wiederholbare Risikobeurteilungen durch, identifiziert Risiken für Vertraulichkeit, Integrität und Verfügbarkeit, weist Risikoeigner zu, bewertet Auswirkungen und Eintrittswahrscheinlichkeit, wählt Behandlungsoptionen aus, vergleicht Maßnahmen mit Anhang A, erstellt eine Erklärung zur Anwendbarkeit (SoA), bereitet einen Risikobehandlungsplan vor und holt die Genehmigung des Risikoeigners sowie die Akzeptanz des Restrisikos ein.
Klausel 8.1 verlangt anschließend operative Planung und Steuerung. Die Organisation muss ISMS-Prozesse planen, umsetzen und steuern, dokumentierte Informationen aufbewahren, die zeigen, dass Prozesse wie geplant durchgeführt wurden, Änderungen steuern und extern bereitgestellte Prozesse, Produkte oder Services kontrollieren, die für das ISMS relevant sind.
ISO/IEC 27005:2022 stärkt diesen Ansatz. Klausel 6.2 empfiehlt Organisationen, Anforderungen interessierter Parteien zu identifizieren, einschließlich ISO/IEC 27001:2022 Anhang A-Maßnahmen, branchenspezifischer Standards, nationaler und internationaler Vorschriften, interner Vorgaben, vertraglicher Anforderungen und bestehender Maßnahmen aus früherer Risikobehandlung. Die Klauseln 6.4.1 bis 6.4.3 erläutern, dass Risikokriterien rechtliche und regulatorische Aspekte, Lieferantenbeziehungen, Datenschutz, betriebliche Auswirkungen, Vertragsverletzungen, Tätigkeiten von Drittparteien und Reputationsfolgen berücksichtigen sollten. Die Klauseln 8.2 bis 8.6 unterstützen eine Maßnahmenbibliothek und einen Behandlungsplan, die ISO/IEC 27001:2022 Anhang A mit DORA, NIS2, GDPR, Kundenverpflichtungen und internen Richtlinien kombinieren können.
Das Betriebsmodell ist klar: ein Anforderungsinventar, ein Lieferantenrisikoregister, eine Erklärung zur Anwendbarkeit, ein Risikobehandlungsplan und ein Nachweispaket für jedes kritische Exit-Szenario.
Die ISO/IEC 27001:2022-Maßnahmen, die DORA-Exit-Planung verankern
DORA-Exit-Strategien werden auditbereit, wenn Lieferanten-Governance, Cloud-Portabilität, Kontinuitätsplanung und Backup-Nachweise als zusammenhängende Kontrollkette behandelt werden.
Clarysecs Zenith Controls ordnet ISO/IEC 27001:2022 Anhang A-Maßnahmen Kontrollattributen, Auditnachweisen und Erwartungen aus mehreren Compliance-Perspektiven zu. Es ist kein separates Kontrollrahmenwerk. Es ist Clarysecs Cross-Compliance-Leitfaden, um zu verstehen, wie ISO/IEC 27001:2022-Maßnahmen Audit-, regulatorische und operative Ergebnisse unterstützen.
| ISO/IEC 27001:2022 Anhang A-Maßnahme | Rolle in der Exit-Strategie | Unterstützte DORA-Nachweise | Fokus des Auditors |
|---|---|---|---|
| A.5.19 Informationssicherheit in Lieferantenbeziehungen | Etabliert den Prozess für das Lieferantenrisikomanagement | Lieferantenklassifizierung, Verantwortlichkeit für Abhängigkeiten, Risikobeurteilung | Wird Lieferantenrisiko konsistent gesteuert? |
| A.5.20 Berücksichtigung von Informationssicherheit in Lieferantenvereinbarungen | Überführt Exit-Erwartungen in durchsetzbare Vertragsbedingungen | Kündigungsrechte, Auditrechte, Übergangshilfe, Unterstützung bei Vorfällen, Datenrückgabe und Löschung | Unterstützt der Vertrag den Exit-Plan tatsächlich? |
| A.5.21 Management der Informationssicherheit in der IKT-Lieferkette | Erweitert die Prüfung auf Unterauftragnehmer und nachgelagerte Abhängigkeiten | Transparenz zu Unterauftragnehmern, Lieferkettenrisiko, Bewertung von Konzentrationsrisiken | Versteht das Unternehmen verborgene Abhängigkeiten? |
| A.5.22 Überwachung, Überprüfung und Änderungsmanagement von Lieferantendienstleistungen | Hält Lieferantenrisiken bei Serviceänderungen aktuell | Überprüfungsaufzeichnungen, Bewertungen von Serviceänderungen, Nachverfolgung von Abhilfemaßnahmen | Erfolgt die Lieferantenaufsicht fortlaufend? |
| A.5.23 Informationssicherheit bei der Nutzung von Cloud-Services | Steuert Onboarding, Nutzung, Management, Portabilität und Ausstieg aus Cloud-Services | Datenexport, Löschung, Migrationsunterstützung, Nachweise zu Vendor Lock-in | Kann das Unternehmen Daten zurückholen und sicher entfernen? |
| A.5.30 IKT-Bereitschaft für die Aufrechterhaltung des Geschäftsbetriebs | Testet, ob kritische IKT-Services innerhalb geschäftlicher Toleranzen wiederhergestellt oder ersetzt werden können | Kontinuitätspläne, Wiederherstellungsziele, Rückfallregelungen, getestete Ausweichverfahren | Ist der Exit unter Störungsbedingungen technisch umsetzbar? |
| A.8.13 Informationssicherung | Stellt wiederherstellbare Daten für Exit- oder Ausfallszenarien bereit | Backup-Zeitpläne, Ergebnisse von Wiederherstellungstests, Integritätsprüfungen | Können Daten innerhalb von RTO und RPO wiederhergestellt werden? |
Für eine DORA-IKT-Exit-Strategie für IKT-Drittdienstleister sollte der Prüfpfad Folgendes zeigen:
- Der Lieferant ist klassifiziert und mit Geschäftsprozessen verknüpft.
- Der Service wurde daraufhin bewertet, ob er eine kritische oder wichtige Funktion unterstützt.
- Das Exit-Risiko ist mit einem rechenschaftspflichtigen Risikoeigner erfasst.
- Vertragsklauseln unterstützen Übergang, Zugriff, Audit, Datenrückgabe, Datenlöschung, Zusammenarbeit und Kontinuität.
- Cloud-Portabilität und Interoperabilität wurden validiert.
- Backups und Wiederherstellungstests belegen die Wiederherstellbarkeit.
- Temporäre Substitution oder alternative Verarbeitung wurde dokumentiert.
- Ergebnisse von Exit-Tests wurden überprüft, nachgebessert und an das Management berichtet.
Vertragssprache ist die erste Kontinuitätskontrolle
Ein Vertrag sollte die erste Kontinuitätskontrolle sein, kein Hindernis für Kontinuität. Wenn der Anbieter kurzfristig kündigen, Exporte verzögern, den Zugriff auf Protokolle beschränken, undefinierte Übergangsgebühren verlangen oder Migrationsunterstützung verweigern kann, ist die Exit-Strategie fragil.
In Zenith Blueprint erläutert die Phase „Controls in Action“, Schritt 23, Maßnahme 5.20, dass Lieferantenvereinbarungen die praktischen Sicherheitsanforderungen enthalten sollten, die einen Exit ermöglichen:
Wesentliche Bereiche, die typischerweise in Lieferantenvereinbarungen geregelt werden, umfassen:
✓ Vertraulichkeitspflichten, einschließlich Umfang, Dauer und Einschränkungen der Offenlegung gegenüber Dritten;
✓ Verantwortlichkeiten für Zugriffskontrolle, etwa wer auf Ihre Daten zugreifen darf, wie Zugangsdaten verwaltet werden und welche Überwachung eingerichtet ist;
✓ technische und organisatorische Maßnahmen für Datenschutz, Verschlüsselung, sichere Übertragung, Backup und Verfügbarkeitszusagen;
✓ Meldefristen und Protokolle für Vorfallsmeldungen, häufig mit definierten Zeitrahmen;
✓ Auditrechte, einschließlich Häufigkeit, Umfang und Zugriff auf relevante Nachweise;
✓ Kontrollen für Unterauftragnehmer, die verlangen, dass Ihr Lieferant gleichwertige Sicherheitsverpflichtungen an seine nachgelagerten Partner weitergibt;
✓ Regelungen zum Vertragsende, etwa Datenrückgabe oder Vernichtung, Asset-Rückgabe und Kontodeaktivierung.
Diese Liste verbindet die vertraglichen Erwartungen aus DORA Article 30 mit ISO/IEC 27001:2022 Anhang A-Maßnahme A.5.20.
Die Enterprise-Richtliniensprache von Clarysec macht denselben Punkt operativ. In der Supplier Dependency Risk Management Policy Supplier Dependency Risk Management Policy, Abschnitt „Umsetzungsanforderungen“, Klausel 6.4.3, heißt es:
Technische Rückfalloptionen: Sicherstellen von Datenportabilität und Interoperabilität zur Unterstützung eines Serviceübergangs, falls erforderlich (z. B. regelmäßige Backups in Standardformaten von einem SaaS-Anbieter, um eine Migration zu ermöglichen).
Dieselbe Richtlinie verlangt in Klausel 6.8.2:
Ein Recht auf Übergangshilfe (Exit-Assistance-Klausel), wenn ein Anbieterwechsel erforderlich ist, einschließlich fortgesetzter Leistungserbringung während eines definierten Übergangszeitraums.
Diese Klausel entscheidet häufig, ob eine Exit-Strategie ein Audit übersteht. Sie verwandelt den Ausstieg von einem abrupten Abbruch in einen gesteuerten Übergang.
Für kleinere Unternehmen verlangt die Third-Party and Supplier Security Policy-sme Third-Party and Supplier Security Policy - SME, Abschnitt „Governance-Anforderungen“, Klausel 5.3.6:
Kündigungsbedingungen, einschließlich sicherer Datenrückgabe oder Vernichtung
Für Enterprise-Umgebungen verlangt die Third party and supplier security policy Third party and supplier security policy, Abschnitt „Umsetzungsanforderungen der Richtlinie“, Klausel 6.5.1.2:
Rückgabe oder zertifizierte Vernichtung aller im Eigentum der Organisation stehenden Informationen
Diese Richtlinienanforderungen müssen direkt auf Vertragsklauseln, Lieferantenverfahren, Exit-Runbooks und Auditnachweise zurückführbar sein.
Cloud-Exit: Portabilität testen, bevor sie benötigt wird
Cloud-Services sind der Bereich, in dem DORA-Exit-Strategien häufig vage werden. Das Unternehmen geht davon aus, dass es Daten exportieren kann, aber niemand hat das Format getestet. Es geht davon aus, dass eine Löschung erfolgen wird, aber das Aufbewahrungsmodell des Anbieters umfasst Backups und replizierten Speicher. Es geht davon aus, dass ein alternativer Anbieter die Daten übernehmen kann, aber Schemata, Identitätsintegrationen, Verschlüsselungsschlüssel, Geheimnisse, Protokolle, Programmierschnittstellen und Ratenbegrenzungen verlangsamen die Migration stärker, als die Auswirkungstoleranz erlaubt.
ISO/IEC 27001:2022 Anhang A-Maßnahme A.5.23 adressiert dieses Lebenszyklusproblem, indem sie Informationssicherheitsmaßnahmen für Beschaffung, Nutzung, Management und Ausstieg aus Cloud-Services verlangt.
Clarysecs Cloud Usage Policy-sme Cloud Usage Policy - SME, Abschnitt „Umsetzungsanforderungen der Richtlinie“, Klausel 6.3.4 verlangt:
Datenexportfähigkeit vor dem Onboarding bestätigt (z. B. zur Vermeidung von Vendor Lock-in)
Klausel 6.3.5 verlangt:
Bestätigung sicherer Löschverfahren vor Kontoschließung
Diese Anforderungen gehören an den Anfang des Lieferantenlebenszyklus. Warten Sie nicht bis zur Kündigung, um zu fragen, ob Daten exportiert werden können. Warten Sie nicht bis zur Kontoschließung, um zu fragen, ob Löschungsnachweise vorhanden sind.
Ein praxisgerechter DORA-Cloud-Exit-Test sollte Folgendes umfassen:
- Export eines repräsentativen Datenbestands im vereinbarten Format.
- Validierung von Vollständigkeit, Integrität, Zeitstempeln, Metadaten und Zugriffskontrollen.
- Import des Datenbestands in eine Staging-Umgebung oder ein alternatives Werkzeug.
- Bestätigung der Handhabung von Verschlüsselungsschlüsseln und der Rotation von Geheimnissen.
- Bestätigung des Protokollexports und der Aufbewahrung des Prüfpfads.
- Dokumentation der Löschverfahren des Anbieters, einschließlich Backup-Aufbewahrung und Löschzertifizierung.
- Erfassung von Problemen, Abhilfemaßnahmen, Verantwortlichen und Fälligkeitsterminen.
- Aktualisierung der Lieferantenrisikobeurteilung, der Erklärung zur Anwendbarkeit und des Exit-Plans.
Portabilität ist kein Beschaffungsversprechen. Sie ist eine getestete Fähigkeit.
Ein einwöchiger Sprint für einen auditbereiten DORA-Exit-Plan
Betrachten wir ein Zahlungsinstitut, das einen SaaS-Anbieter für Betrugsanalysen nutzt. Der Anbieter verarbeitet Transaktionsdaten, Kundenkennungen, Gerätetelemetrie, Verhaltenssignale, Betrugsregeln, Scoring-Ergebnisse und Fallnotizen. Der Service unterstützt einen kritischen Betrugserkennungsprozess. Das Unternehmen nutzt außerdem ein Cloud-Data-Warehouse zur Speicherung exportierter Analyseergebnisse.
Der CISO benötigt eine DORA-IKT-Exit-Strategie für IKT-Drittdienstleister, die einem internen Audit und einer aufsichtsrechtlichen Prüfung standhält. Ein einwöchiger Sprint kann die Lücken offenlegen und die Nachweiskette aufbauen.
Tag 1: Lieferanten klassifizieren und Exit-Szenario definieren
Unter Verwendung von Zenith Blueprint, Phase „Controls in Action“, Schritt 23, Arbeitspunkte für die Maßnahmen 5.19 bis 5.37, beginnt das Team mit der Überprüfung und Klassifizierung des Lieferantenportfolios:
Erstellen Sie eine vollständige Liste der aktuellen Lieferanten und Dienstleister (5.19) und klassifizieren Sie sie anhand ihres Zugriffs auf Systeme, Daten oder operative Steuerung. Prüfen Sie für jeden klassifizierten Lieferanten, ob Sicherheitserwartungen eindeutig in Verträgen verankert sind (5.20), einschließlich Vertraulichkeit, Zugriff, Vorfallsmeldung und Compliance-Verpflichtungen.
Der Lieferant wird als kritisch klassifiziert, weil er eine kritische oder wichtige Funktion unterstützt, sensitive Betriebsdaten verarbeitet und die Ergebnisse der Transaktionsüberwachung beeinflusst.
Das Team definiert drei Exit-Auslöser:
- Insolvenz des Anbieters oder Einstellung des Services.
- Wesentliche Sicherheitsverletzung oder Vertrauensverlust.
- Strategische Migration zur Reduzierung des Konzentrationsrisikos.
Tag 2: Anforderungsinventar und Risikodatensatz aufbauen
Das Team erstellt ein einheitliches Anforderungsinventar für DORA-IKT-Drittparteienrisiken, ISO/IEC 27001:2022-Lieferanten- und Cloud-Maßnahmen, GDPR-Pflichten für personenbezogene Daten, Kundenvertragsverpflichtungen und interne Risikobereitschaft.
Nach GDPR bestätigt das Unternehmen, ob Transaktionskennungen, Gerätekennungen, Standortsignale und Verhaltensanalysen sich auf identifizierte oder identifizierbare Personen beziehen. Die Grundsätze aus GDPR Article 5, einschließlich Integrität, Vertraulichkeit, Speicherbegrenzung und Rechenschaftspflicht, werden Teil der Exit-Nachweisanforderung. Wenn der Exit eine Übermittlung an einen neuen Anbieter umfasst, müssen Rechtsgrundlage, Zweck, Minimierung, Aufbewahrung, Auftragsverarbeiterbedingungen und Schutzmaßnahmen dokumentiert werden.
Der Risikodatensatz umfasst Folgendes:
| Risikoelement | Beispieleintrag |
|---|---|
| Risikoaussage | Unfähigkeit, den Anbieter für Betrugsanalysen innerhalb der Auswirkungstoleranz zu verlassen |
| Auswirkung | Verzögerte Betrugserkennung, finanzieller Verlust, regulatorischer Verstoß, Kundenschaden |
| Eintrittswahrscheinlichkeit | Mittel, basierend auf Anbieterkonzentration und proprietären Formaten |
| Risikoeigner | Leiter Financial Crime Technology |
| Behandlung | Vertragsänderung, Exporttest, Bewertung alternativer Anbieter, Backup-Verifikation, Runbook-Test |
| Restrisiko-Genehmigung | CRO-Genehmigung nach Testnachweisen und Überprüfung der Abhilfemaßnahmen |
Tag 3: Vertragslücken schließen
Rechtsabteilung und Beschaffung vergleichen den Vertrag mit den Lieferantenklauseln von Clarysec. Sie ergänzen Übergangshilfe, fortgesetzte Leistungserbringung während eines definierten Übergangszeitraums, Zugriff auf Audit- und Nachweismaterial, Benachrichtigung über Unterauftragnehmer, Datenexportformat, Zertifizierung sicherer Löschung, Zusammenarbeit bei Vorfällen und Zusagen zu Wiederherstellungszeiten.
Die Business Continuity Policy and Disaster Recovery Policy Business Continuity Policy and Disaster Recovery Policy, Abschnitt „Umsetzungsanforderungen der Richtlinie“, Klausel 6.5.1, legt fest:
Verträge mit kritischen Lieferanten müssen Kontinuitätspflichten und Zusagen zu Wiederherstellungszeiten enthalten.
Für KMU verlangt die Business Continuity Policy and Disaster Recovery Policy-sme Business Continuity Policy and Disaster Recovery Policy - SME, Abschnitt „Risikobehandlung und Ausnahmen“, Klausel 7.2.1.4, dass Teams:
temporäre Substitutionspläne für Lieferanten oder Partner dokumentieren
Diese Klausel macht aus „wir migrieren“ eine handlungsfähige Rückfalloption: welcher Anbieter, welches interne Ausweichverfahren, welcher manuelle Prozess, welcher Datenextrakt, welcher Verantwortliche und welcher Genehmigungsweg.
Tag 4: Datenportabilität und Wiederherstellbarkeit aus Backups testen
Das Technologieteam exportiert Betrugsregeln, Falldaten, Transaktions-Scoring-Ergebnisse, Protokolle, Konfiguration, API-Dokumentation und Benutzerzugriffslisten. Es testet, ob die Daten in einer kontrollierten Umgebung wiederhergestellt oder weiterverwendet werden können.
Die Backup and Restore Policy-sme Backup and Restore Policy - SME, Abschnitt „Governance-Anforderungen“, Klausel 5.3.3, verlangt:
Wiederherstellungstests werden mindestens vierteljährlich durchgeführt, und die Ergebnisse werden dokumentiert, um die Wiederherstellbarkeit zu verifizieren
Die Enterprise-Backup and Restore Policy Backup and Restore Policy, Abschnitt „Durchsetzung und Compliance“, Klausel 8.3.1, ergänzt:
Backup-Protokolle, Konfigurationseinstellungen und Testergebnisse regelmäßig auditieren
In Zenith Blueprint, Phase „Controls in Action“, Schritt 19, Maßnahme 8.13, warnt Clarysec, warum dies entscheidend ist:
Wiederherstellungstests sind der Punkt, an dem die meisten Organisationen zurückfallen. Ein Backup, das nicht rechtzeitig oder überhaupt nicht wiederhergestellt werden kann, ist eine Belastung, kein Vermögenswert. Planen Sie regelmäßige Wiederherstellungsübungen ein, auch wenn sie nur teilweise erfolgen, und dokumentieren Sie das Ergebnis.
Das Team stellt fest, dass exportierte Fallnotizen keine Anhänge enthalten und API-Ratenbegrenzungen einen vollständigen Export zu langsam für das definierte Wiederherstellungsziel machen. Das Problem wird protokolliert, zugewiesen und durch einen Vertragsnachtrag sowie eine technische Neugestaltung des Exports behoben.
Tag 5: Exit-Tabletop und Nachweisprüfung durchführen
Das Team führt eine Tabletop-Übung durch: Der Lieferant kündigt nach einem schweren Vorfall die Beendigung in 90 Tagen an. Der Betrieb muss die Betrugsüberwachung fortführen, während Daten migriert werden.
In Zenith Blueprint, Phase „Controls in Action“, Schritt 23, Maßnahme 5.30, erläutert Clarysec den Teststandard:
IKT-Bereitschaft beginnt lange vor einer Störung. Sie umfasst die Identifizierung kritischer Systeme, das Verständnis ihrer Abhängigkeiten und ihre Zuordnung zu Geschäftsprozessen.
Derselbe Abschnitt ergänzt:
Die im Business-Continuity-Plan definierten Wiederherstellungszeitziele (RTOs) und Wiederherstellungspunktziele (RPOs) müssen sich in technischen Konfigurationen, Verträgen und im Infrastrukturdesign widerspiegeln.
Das Nachweispaket umfasst Lieferantenklassifizierung, Risikobeurteilung, Vertragsklauseln, Exit-Runbook, Datenexportergebnisse, Nachweise zur Wiederherstellung aus Backups, Löschverfahren, Bewertung alternativer Anbieter, Tabletop-Protokoll, Protokoll der Abhilfemaßnahmen, Managementfreigabe und Restrisikoentscheidung.
Der CISO kann die Frage des Leitungsorgans nun mit Nachweisen beantworten, nicht mit Optimismus.
Cross-Compliance: ein Exit-Plan, mehrere Audit-Perspektiven
Eine starke DORA-Exit-Strategie reduziert doppelte Compliance-Arbeit über ISO/IEC 27001:2022, NIS2, GDPR, NIST und COBIT 2019-Governance-Erwartungen hinweg.
| Rahmenwerk oder Vorschrift | Was sie in Bezug auf Exit-Planung verlangt | Von Clarysec empfohlene Nachweise |
|---|---|---|
| DORA | Exit-Strategien für kritische oder wichtige IKT-Services aufrechterhalten, Drittparteienrisiken steuern, Resilienz testen, Verträge und Abhängigkeiten dokumentieren | Lieferantenregister, Kritikalitätsklassifizierung, Vertragsklauseln, Exit-Test, Übergangsplan, Auditrechte, Bewertung von Konzentrationsrisiken |
| NIS2 | Für relevante Einrichtungen: Sicherheit der Lieferkette, Aufrechterhaltung des Geschäftsbetriebs, Backup, Disaster Recovery, Krisenmanagement, Umgang mit Informationssicherheitsvorfällen und Governance-Rechenschaftspflicht steuern | Lieferantenrisikobeurteilung, Kontinuitätsplan, Incident-Playbooks, Managementfreigabe, Korrekturmaßnahmen |
| GDPR | Personenbezogene Daten während Übermittlung, Rückgabe, Löschung, Migration und Aufbewahrung mit Rechenschaftspflicht sowie geeigneten technischen und organisatorischen Maßnahmen schützen | Datenflussübersicht, Auftragsverarbeiterbedingungen, Exportnachweise, Löschzertifizierung, Aufbewahrungsregeln, Abstimmung mit dem Verfahren bei Datenschutzverletzungen |
| ISO/IEC 27001:2022 | Lieferanten-, Cloud-, Kontinuitäts-, Vorfalls-, Audit-, Überwachungs- und Verbesserungsmaßnahmen im ISMS betreiben | Erklärung zur Anwendbarkeit, Risikobehandlungsplan, Aufzeichnung des internen Audits, Managementbewertung, dokumentierte Verfahren |
| NIST Cybersecurity Framework 2.0 | Externe Abhängigkeiten steuern, Lieferanten identifizieren, Services schützen, auf Störungen reagieren und den Betrieb wiederherstellen | Abhängigkeitsinventar, Lieferantenrisikodatensätze, Schutzmaßnahmen, Reaktionsverfahren, Wiederherstellungstest, Lessons Learned |
| COBIT 2019 | Governance über Sourcing, Lieferantenleistung, Risiko, Servicekontinuität, Assurance und Einhaltung nachweisen | Governance-Entscheidungen, Verantwortlichkeit, KPIs, Lieferantenaufsicht, Kontinuitätsnachweise, Assurance-Berichte |
Der wichtige Punkt ist nicht, dass ein Rahmenwerk ein anderes ersetzt. Der Nutzen besteht darin, dass ein gut aufgebautes ISMS Nachweise einmal erzeugen und intelligent wiederverwenden kann.
Clarysecs Zenith Controls hilft Teams, sich auf diese Audit-Perspektiven vorzubereiten, indem ISO/IEC 27001:2022-Maßnahmen mit Auditnachweisen und erwarteten Ergebnissen aus mehreren Rahmenwerken verbunden werden.
| Audit-Perspektive | Wahrscheinliche Auditfrage | Nachweise, die die Frage in der Regel beantworten |
|---|---|---|
| ISO/IEC 27001:2022-Auditor | Wird der Lieferanten- und Cloud-Exit innerhalb des ISMS, der Risikobeurteilung, der SoA und des internen Auditprogramms gesteuert? | ISMS-Geltungsbereich, Risikobeurteilung, SoA, Lieferantenverfahren, Cloud-Exit-Verfahren, Ergebnisse interner Audits, Maßnahmen aus der Managementbewertung |
| DORA-Aufsicht oder internes DORA-Audit | Können Sie aus einem kritischen IKT-Anbieter aussteigen, ohne unvertretbare Störungen, Datenverlust oder regulatorische Verstöße zu verursachen? | Kritikalitätsbewertung, DORA-Lieferantenregister, Exit-Strategie, Vertragsklauseln, Übergangstest, Bewertung von Konzentrationsrisiken, Protokoll der Abhilfemaßnahmen |
| NIST-orientierter Prüfer | Haben Sie externe Abhängigkeiten gesteuert und identifiziert, kritische Services geschützt und Reaktions- und Wiederherstellungsfähigkeiten getestet? | Abhängigkeitsinventar, Zugriffskontrollen, Überwachung, Vorfalleskalation, Wiederherstellungstest, Lessons Learned |
| COBIT 2019- oder ISACA-Auditor | Ist der Lieferanten-Exit gesteuert, verantwortet, gemessen und abgesichert durch Managementziele wie APO10 Managed Vendors und DSS04 Managed Continuity? | RACI, Managementfreigabe, KPIs, Lieferantenleistungsüberprüfung, Assurance-Nachweise, Problemnachverfolgung |
| Datenschutzauditor | Können personenbezogene Daten gemäß GDPR-Pflichten zurückgegeben, migriert, eingeschränkt, gelöscht oder sicher aufbewahrt werden? | Verzeichnis der Verarbeitungstätigkeiten, Auftragsverarbeiterklauseln, Exportnachweise, Löschzertifikat, Aufbewahrungsbegründung, Workflow für Datenschutzverletzungen |
Ein häufiger Auditmangel ist fragmentierte Nachweisführung. Der Lieferantenverantwortliche hat den Vertrag. Die IT hat Backup-Protokolle. Die Rechtsabteilung hat den Auftragsverarbeitungsvertrag. Risk hat die Bewertung. Compliance hat die regulatorische Zuordnung. Niemand hat die vollständige Darstellung.
Clarysec löst dies, indem das Nachweispaket um das Exit-Szenario herum aufgebaut wird. Jedes Dokument beantwortet eine Auditfrage: Welcher Service wird beendet, warum ist er kritisch, welche Daten und Systeme sind betroffen, wer verantwortet das Risiko, welche vertraglichen Rechte ermöglichen den Exit, welche technischen Mechanismen ermöglichen die Migration, welche Kontinuitätsregelungen halten den Betrieb aufrecht, welcher Test belegt, dass der Plan funktioniert, welche Probleme wurden behoben und wer hat das Restrisiko genehmigt?
Die Clarysec-Checkliste für DORA-Exit-Strategien
Nutzen Sie diese Checkliste, um eine DORA-IKT-Exit-Strategie für IKT-Drittdienstleister von einem Dokument in ein auditierbares Kontrollset zu überführen.
| Kontrollbereich | Mindesterwartung | Aufzubewahrende Nachweise |
|---|---|---|
| Lieferantenklassifizierung | Identifizieren, ob der Lieferant kritische oder wichtige Funktionen unterstützt | Lieferantenregister, Kritikalitätsentscheidung, Abhängigkeitsübersicht |
| Vertragliche Durchsetzbarkeit | Übergangshilfe, Datenexport, Löschung, Audit, Zusammenarbeit bei Vorfällen und Kontinuitätspflichten aufnehmen | Vertragsklauseln, Nachträge, rechtliche Prüfung |
| Cloud-Portabilität | Exportfähigkeit vor dem Onboarding und regelmäßig während des Betriebs bestätigen | Exporttestergebnisse, Dokumentation des Datenformats, Migrationsnotizen |
| Datenschutz | Rückgabe, Löschung, Aufbewahrung, Übermittlung personenbezogener Daten sowie Auftragsverarbeiterpflichten adressieren | Datenflussübersicht, Auftragsverarbeitungsvertrag, Löschzertifizierung, Aufbewahrungsentscheidung |
| Backup und Wiederherstellung | Wiederherstellbarkeit anhand von RTO und RPO testen | Wiederherstellungsprotokolle, Testbericht, Aufzeichnung der Abhilfemaßnahmen |
| Substitutionsplanung | Alternativen Anbieter, manuelles Ausweichverfahren oder internen Prozess definieren | Substitutionsplan, Tabletop-Protokoll, Verantwortlichenliste |
| Governance | Risikoeigner und Managementfreigabe zuweisen | Risikodatensatz, Restrisikoakzeptanz, Protokoll der Managementbewertung |
| Auditbereitschaft | Richtlinien, Maßnahmen, Verträge, Tests und Korrekturmaßnahmen verknüpfen | Index des Nachweispakets, interner Auditbericht, Vorgangsverfolgungssystem |
Exit-Planung in eine leitungsorganfähige Resilienzkontrolle überführen
Wenn Ihre DORA-Exit-Strategie nur eine Vertragsklausel ist, ist sie nicht bereit. Wenn Ihr Backup nie wiederhergestellt wurde, ist es nicht bereit. Wenn Ihr Cloud-Anbieter Daten exportieren kann, aber niemand die Vollständigkeit validiert hat, ist er nicht bereit. Wenn Ihr Leitungsorgan die Restrisikoentscheidung nicht einsehen kann, ist sie nicht bereit.
Clarysec unterstützt CISOs, Compliance-Manager, Auditoren und Geschäftsverantwortliche beim Aufbau von DORA-IKT-Exit-Strategien für IKT-Drittdienstleister, die praktikabel, verhältnismäßig und auditbereit sind. Wir kombinieren den Zenith Blueprint Zenith Blueprint für die Umsetzungsreihenfolge, Zenith Controls Zenith Controls für Cross-Compliance-Zuordnung und Richtlinienvorlagen wie die Supplier Dependency Risk Management Policy Supplier Dependency Risk Management Policy, Cloud Usage Policy - SME Cloud Usage Policy - SME, Third-Party and Supplier Security Policy - SME Third-Party and Supplier Security Policy - SME und Business Continuity Policy and Disaster Recovery Policy Business Continuity Policy and Disaster Recovery Policy, um eine vollständige Kontroll-zu-Nachweis-Kette zu schaffen.
Ihr nächster Schritt ist einfach und wertstiftend: Wählen Sie in dieser Woche einen kritischen IKT-Lieferanten aus. Klassifizieren Sie ihn, prüfen Sie seinen Vertrag, testen Sie einen Datenexport, verifizieren Sie eine Wiederherstellung, dokumentieren Sie einen Substitutionsplan und erstellen Sie ein Nachweispaket.
Diese einzelne Übung zeigt, ob Ihre DORA-Exit-Strategie eine echte Resilienzfähigkeit ist oder nur ein Dokument, das im Audit scheitern wird.
Frequently Asked Questions
About the Author
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council
