Die meisten Organisationen glauben, die Bewertung von Cloud-Anbietern bedeute, einen SOC 2-Bericht zu prüfen, kurz auf ein ISO-Zertifikat zu schauen und die Sache abzuhaken. Unter DORA und NIS2 wird diese Abkürzung zur regulatorischen Haftung. Cloud-Risiko ist heute Geschäftsrisiko ; und Regulatoren erwarten den Nachweis, dass Sie es verstehen.
DORA und NIS2 haben die Spielregeln verändert. Regulators no longer care whether your cloud provider has “good security.” Sie wollen wissen, ob Sie weiter operieren können, wenn Ihr Anbieter ausfällt.
Das bedeutet:
- tiefgehende Bewertungen
- vertragliche Transparenz
- Konzentrationsrisikoanalyse
- laufende Überwachung
- Exit-Strategien
- echte Governance, keine Checklisten
Die meisten Organisationen sind dafür nicht bereit ; und Auditoren wissen das.
So bewerten Sie Cloud-Anbieter unter DORA und NIS2 richtig.
1. Beginnen Sie mit der Kritikalität: Nicht alle Cloud-Dienste sind gleich
Der größte Fehler von Organisationen ist, jeden SaaS- oder Cloud-Dienst gleich zu behandeln.
Unter DORA und NIS2 müssen Sie Anbieter nach Geschäftsauswirkung klassifizieren:
- kritisch
- wichtig
- nicht kritisch
Kritische Dienste betreffen direkt:
- Geschäftskontinuität
- kundenseitige Abläufe
- Finanztransaktionen
- regulatorische Verpflichtungen
- Sicherheit
- Kerninfrastruktur
Anekdote: A client labelled their CRM as “low risk” because “marketing uses it.” Es stellte sich heraus, dass 60 % der Umsatz-Pipeline davon abhingen. Unter DORA ist das kritisch.
Regulatoren erwarten Priorisierung. Beginnen Sie dort.
2. Fordern Sie Transparenz zu Architektur, Abhängigkeiten und Unterauftragsverarbeitern
Unter NIS2 und DORA benötigen Sie Klarheit über:
- Datenspeicherorte
- Unterauftragsverarbeiter
- Infrastrukturabhängigkeiten
- Multi-Region-Failover-Design
- Datenresidenz und jurisdiktionelle Exposition
Cloud-Anbieter lieben vage Diagramme und Marketing-Floskeln. Regulatoren wollen Konkretes.
Ihr Risiko ist das Risiko des Lieferanten Ihres Lieferanten.
3. Bewerten Sie operative Resilienz, nicht nur Sicherheitskontrollen
ISO 27001 und SOC 2 informieren über Security-Hygiene. DORA und NIS2 wollen wissen:Können Ihre Abläufe einen Ausfall des Cloud-Anbieters überstehen?
Fordern Sie an:
- RTO/RPO für den gesamten Stack
- tatsächliche Ausfallhistorie
- Ergebnisse von Failover-Tests
- Kapazitätsmanagement-Kennzahlen
- Zeitpläne für die Incident-Eskalation
- Service-Level-Reife
- Zuverlässigkeit der Statusseite (die Historie zählt)
Anekdote: A SaaS vendor claimed “99.99% uptime.” Die öffentliche Statusseite zeigte acht Ausfälle in 6 Monaten. Ihre Bewertung muss der Realität entsprechen ; nicht dem Marketing.
4. Klären Sie den Umgang mit schwerwiegenden Incidents (DORA hat klare Erwartungen)
DORA verlangt vertragliche Klarheit zu:
- Incident-Klassifizierung
- Meldezeitplänen
- Informationsaustausch
- Lieferung von Root-Cause-Analysen
- Eskalationswegen
Hat Ihr Cloud-Anbieter keinen ausgereiften Incident-Response-Prozess, erben Sie die Lücke.
Eine Erfahrung aus der Praxis: Ein Dienstleister lieferte RCAs regelmäßig 30 Tage zu spät ; jedes Mal. Unter DORA wird das zu Ihrem regulatorischen Problem.
Wenn ein Anbieter Ihre regulatorischen Meldefristen nicht unterstützen kann, ist er für Sie nicht konform.
5. Bewerten Sie Konzentrationsrisiko und Single Points of Failure
Das ist der Teil, den die meisten Unternehmen ignorieren ; und wo Regulatoren am stärksten nachfragen werden.
Zu stellende Fragen:
- Stützen sich mehrere kritische Dienste auf denselben Cloud-Anbieter?
- Sind wir an einen Anbieter gebunden, ohne tragfähige Alternative?
- Wie hoch sind die Wechselkosten?
- Wie viele unserer kritischen Prozesse hängen von AWS/Azure/GCP ab?
- Verfügen wir über geografische Redundanz?
- Are two “vendors” actually the same because they share infrastructure?
Anekdote: A bank thought they had “redundancy” because they used two SaaS services. Beide liefen in derselben AWS-Region.
Sie können Dienste auslagern. Die Verantwortung können Sie nicht auslagern.
6. Fordern Sie vertragliche Kontrolle (DORA macht das verpflichtend)
DORA verlangt verpflichtende Vertragsklauseln für als kritisch eingestufte IKT-Dienste.
Ihr Vertrag muss abdecken:
- Audit- und Inspektionsrechte
- Performance-Reporting
- Sicherheitsverpflichtungen
- Exit- und Übergangspläne
- Resilienzanforderungen
- Incident-Benachrichtigung
- Transparenz zu Unterauftragnehmern
- Unterstützung bei Vertragsbeendigung
- Verschlüsselungsverantwortlichkeiten
Anekdote: Ein SaaS-Anbieter verweigerte Audit-Rechte. Unter DORA ist das ein Ausschlusskriterium. Punkt.
Wenn ein Anbieter keine Aufsicht zulässt, können Sie ihn nicht einsetzen.
7. Bewerten Sie laufende Überwachung, nicht einmalige Assessments
NIS2 und DORA betonen beide kontinuierliche Aufsicht, keine jährlichen Checklisten.
Sie benötigen:
- vierteljährliche Sicherheitsstatusberichte
- jährliche SOC-Berichte
- Echtzeit-Verfügbarkeitsüberwachung
- Aktualisierungszyklen für Lieferantenfragebögen
- Folgenabschätzungen bei regulatorischer Relevanz von Änderungen
- Neubewertung nach schwerwiegenden Incidents
If the vendor “doesn’t do ongoing reviews,” walk away.
Anekdote: Ein SaaS-Anbieter aktualisierte seinen SOC 2-Bericht nur alle 18 bis 24 Monate. Unter NIS2 und DORA ist das für kritische Systeme nicht akzeptabel.
8. Testen Sie Exit- und Portabilitätspläne (die am häufigsten ignorierte Anforderung)
DORA schreibt explizit das Testen von Exit-Strategien vor. NIS2 erwartet operative Kontinuität.
Cloud-Anbieter müssen nachweisen:
- Sie können Ihre Daten extrahieren
- Sie können ohne Betriebsunterbrechung migrieren
- Formate sind portabel
- Zeitpläne sind angemessen
- Unterstützung ist während des Exits verfügbar
Anekdote: One vendor said, “We provide data export.” Der Export war ein proprietäres Binary-Blob. Null Portabilität.
Wenn Sie einen Anbieter nicht verlassen können, können Sie ihn nicht nutzen.
9. Entwickeln Sie ein Cloud-Anbieter-Bewertungsmodell, das mit DORA und NIS2 übereinstimmt
Der einfachste Weg, Bewertungen zu skalieren, ist ein Scoring-Modell.
Empfohlene Kategorien:
- Sicherheit (ISO/SOC)
- Operative Resilienz
- Reife des Incident Managements
- Regulatorische Konformität
- Transparenz und Dokumentation
- Anbieterabhängigkeit (Unterauftragsverarbeiter)
- Vertragsstärke
- Konzentrationsrisiko
- Exit-Machbarkeit
- Überwachbarkeit
Jede Kategorie wird mit 1 bis 5 bewertet. Der gewichtete Score bestimmt die Risikoklassifizierung.
10. Ordnen Sie Cloud-Anbieter-Nachweise allen Frameworks zu
ISO → Zugriff, Protokollierung, Backups GDPR → Verarbeiter, Übermittlungen, Datenschutz NIS2 → Resilienz, Lieferkette, Incident-Meldung DORA → IKT-Governance, Testing, Aufsicht
Statt mehrerer Assessments:Verwenden Sie einen einzigen Fragebogen, der allen Frameworks zugeordnet ist.
Ein Assessment. Mehrfache Compliance. Null Doppelarbeit.
Abschließender Gedanke
Die Bewertung von Cloud-Anbietern ist keine Beschaffungsformalität mehr. Unter DORA und NIS2 ist sie ein zentraler Bestandteil Ihrer operativen Resilienzstrategie.
Die Organisationen, die erfolgreich sein werden, sind diejenigen, die:
- Anbieter nach Kritikalität klassifizieren
- Transparenz einfordern
- Resilienz bewerten, nicht nur Sicherheit
- Vertragsstärke durchsetzen
- kontinuierlich überwachen
- Abhängigkeitsrisiken minimieren
- echte Exit-Optionen aufbauen
Cloud-Risiko ist regulatorisches Risiko. Wenn Ihre Anbieter versagen, werden Regulatoren fragen, warum Sie diese nicht ordnungsgemäß bewertet haben.
Nutzen Sie diesen Moment, um von formellen Anbieterprüfungen zu echter Governance überzugehen.
Wenn Sie ein einheitliches, regulatorisch belastbares Lieferantenbewertungssystem für DORA, NIS2, GDPR und ISO 27001 aufbauen möchten, vermitteln wir genau das im Cyber Academy DORA Lead Manager oder NIS2 Lead Implementer Course Nehmen Sie an der nächsten Session teil und sichern Sie Ihre gesamte digitale Lieferkette ab.