Wenn ich einen Cloud-Anbieter prüfe, reicht ein Zertifikat allein nicht aus. Für Deutschland brauche ich meist fünf Blickwinkel zugleich: ENISA für Risikofelder, NIST für technische Kontrollen, ISO/IEC 27001 für Prozesse, BSI C5 für prüfbare Nachweise und EUCS als künftigen EU-Maßstab.

Kurz gesagt: Ich achte auf vier Fragen:

  • Sind Daten und Systeme geschützt?
  • Passen DSGVO, Verträge und Drittstaatentransfers?
  • Hält der Dienst Ausfälle aus?
  • Wie schwer wird ein Wechsel des Anbieters?

Der Kern des Artikels ist einfach: Kein Rahmen deckt alles allein ab.
Für deutsche Firmen ist meist diese Reihenfolge sinnvoll:

  • ENISA für die erste Risikoaufnahme
  • NIST für konkrete Technik-Prüffragen
  • ISO/IEC 27001 für ISMS und Zuständigkeiten
  • BSI C5 für Berichte und Freigaben
  • EUCS für künftige Beschaffung in der EU

Gerade bei stark digitalisierten Abläufen zählt das sofort. Wenn ein Cloud-Dienst ausfällt, Daten falsch verarbeitet werden oder der Exit nicht klappt, wird aus IT-Risiko schnell ein Geschäftsproblem.

Quick Comparison

Ansatz Wofür ich ihn zuerst nutze Starker Punkt Grenze
ENISA Frühe Risikoanalyse Blick auf Sicherheit, Compliance, Ausfälle und Lock-in Kein formaler Nachweis
NIST Technik-Prüfung Genaue Kontrollfragen zu IAM, Logging, Mandantentrennung EU-/DE-Recht nicht im Fokus
ISO/IEC 27001 Governance und ISMS Klare Prozesse, Rollen, Risikobehandlung Cloud-Themen oft zu allgemein
BSI C5 Anbieterbewertung in Deutschland Prüfberichte für Cloud-Dienste, oft direkt nutzbar Scope und Berichtstyp genau prüfen
EUCS Planung für die nächsten Jahre EU-weites Schema für IaaS, PaaS und SaaS Stand 12.07.2026 noch nicht breit im Markt

Wenn ich Cloud-Risiken sauber bewerten will, kombiniere ich also Risikoanalyse, Kontrollprüfung, Governance und prüfbare Nachweise - statt auf nur ein Framework zu setzen.

Cloud-Sicherheitsrahmen im Vergleich: ENISA, NIST, ISO 27001, BSI C5 & EUCS

Cloud-Sicherheitsrahmen im Vergleich: ENISA, NIST, ISO 27001, BSI C5 & EUCS

1. ENISA Cloud Computing Security Risk Assessment

ENISA

EU-Compliance

ENISA passt gut zu europäischen Compliance-Prüfungen, weil das Framework Datenschutz, Vertragsprüfung und grenzüberschreitende Datenflüsse von Anfang an mit einbezieht. Das macht ENISA besonders nützlich, wenn ein Cloud-Anbieter im EU-Kontext zuerst strukturiert geprüft werden soll. Neben der rechtlichen Sicht gibt es auch eine klare Risikologik für technische und organisatorische Kontrollen.

Cloud-spezifische Tiefe

ENISA nennt 35 Cloud-Risiken. Dazu gehören 8 Top-Risiken wie Vendor Lock-in, Kontrollverlust über den Anbieter, Isolation Failure und Resource Exhaustion. Diese Risiken werden nach Eintrittswahrscheinlichkeit und Schaden auf einer Skala von 0 bis 8 bewertet. Gerade Vendor Lock-in zeigt gut, wie breit ENISA denkt: Es geht nicht nur um Technik, sondern auch um Exit-Szenarien und Governance.

Bewertbarkeit in der Praxis

Die Fragenkataloge lassen sich direkt in RFPs und Vertragsprüfungen einsetzen. Für branchenspezifische Vorgaben ist aber eine Anpassung durch IT-Sicherheit, Recht, Compliance und Einkauf nötig. Wenn dieses Team ein gemeinsames Scoring nutzt, bleiben Bewertungen zwischen Anbietern besser vergleichbar. Das ist vor allem dann wichtig, wenn Ausfälle eines Anbieters sofort die Verfügbarkeit und den Geschäftsbetrieb treffen.

Abdeckung operativer Resilienz

ENISA behandelt Betriebsunterbrechungen ausdrücklich als Risikofälle, etwa bei DDoS, Ressourcenerschöpfung, Anbieterausfällen und Übernahmen. Das Framework empfiehlt Multi-Region- und Multi-Provider-Ansätze innerhalb der EU, um Single Points of Failure zu senken. Für kritische Dienste gehören klar festgelegte RTO- und RPO-Werte sowie regelmäßige Tests der Notfallpläne fest zu dieser Prüfung.

Für aktuelle Cloud-Architekturen ist ENISA nur die Basis; technische Detailprüfung folgt in den stärker kontrollorientierten Rahmenwerken.

Im nächsten Schritt zeigt NIST, wie sich diese Risiken stärker kontrollorientiert prüfen lassen.

2. NIST Cloud Risk Guidance

NIST

Rechtliche Einordnung

NIST ist technisch sehr nah an der Praxis, taugt in Deutschland aber nicht allein als Compliance-Grundlage. Für die rechtliche Seite müssen DSGVO, BDSG und BSI-Vorgaben dazukommen. Während ENISA Risiken eher breit sammelt und ordnet, macht NIST daraus konkrete Kontrollfragen.

Cloud-spezifische Tiefe

Mit SP 800-144 gibt es bei NIST eine eigene Quelle für Risiken in der Public Cloud. Dort geht es ganz konkret um Multi-Mandantenfähigkeit, den Kontrollverlust über den Datenspeicherort, die Abhängigkeit von der Zugriffsverwaltung des Anbieters und das Modell der geteilten Verantwortung.

Die Referenzarchitektur für Cloud Computing in SP 500-292 beschreibt zudem die Rollen von Cloud Consumer, Provider, Auditor, Broker und Carrier. Das hilft dabei, Zuständigkeiten sauber zu trennen und bei der Vertragsprüfung klarer zu sehen.

Damit verschiebt NIST den Blick: weg von einer bloßen Risikoliste, hin zur Prüfung von Verantwortung.

Bewertbarkeit in der Praxis

SP 800-144 lässt sich gut als Prüfliste für die Bewertung von Anbietern nutzen. Die Fragen sind dabei sehr direkt:

  • Wie sauber trennt der Anbieter einzelne Mandanten?
  • Wie läuft das Schlüsselmanagement?
  • Wer steuert und prüft die Protokollierung?

NIST verlangt, dass diese Punkte vor der Einführung geklärt werden. Auch Verträge sollten ausdrücklich festhalten, wer für Verfügbarkeit, Incident Response, Datenkontrolle und Wiederherstellung zuständig ist.

Abdeckung operativer Resilienz

Resilienz entsteht nicht erst im Störfall. Sie zieht sich durch den ganzen Lebenszyklus eines Cloud-Dienstes: vom Onboarding über die Migration bis zum Exit. Genau da wird es in vielen Projekten heikel. Ein Anbieterwechsel sollte nicht erst dann durchdacht werden, wenn er schon ansteht.

Portabilität und Wechseloptionen müssen daher früh in der Architektur mitgedacht werden. Neben Recovery-Plänen und SLA-Werten gehört auch die Frage auf den Tisch, wie leicht ein geordneter Ausstieg möglich ist und ob der Anbieter das sauber dokumentiert.

NIST ist das technische Rückgrat, keine Deutschland-Compliance-Lösung. Es braucht immer eine Ergänzung durch EU- und DE-spezifische Rahmenwerke.

Im nächsten Schritt zeigt der ISO/IEC-27001-basierte Ansatz, wie sich diese Kontrollen in Governance übersetzen lassen.

3. ISO/IEC 27001-basierte Cloud-Risikobewertung

Regulatorischer Nachweis

Nach ENISA und NIST kommt mit ISO/IEC 27001 die Governance-Ebene ins Spiel. Der Standard liefert einen prüfbaren Nachweis für Steuerung und Organisation, ersetzt aber keine Prüfung, die gezielt auf Cloud-Dienste schaut. Klausel 6.1 und die Kontrollen aus Annex A lassen sich auf Art. 32 und Art. 28 DSGVO abbilden. In regulierten Branchen oder bei kritischen Prozessen sollten zusätzlich cloud-spezifische Nachweise wie BSI-C5-Berichte eingeplant werden.

Für die Bewertung eines Cloud-Dienstes zählt also nicht nur das Zertifikat an sich. Entscheidend ist, wie die Vorgaben im Dienst selbst umgesetzt werden.

Begrenzte Cloud-Tiefe

ISO/IEC 27001 ist technologieneutral. Genau darin liegt ein Vorteil, aber auch ein Haken: Cloud-Themen wie Mandantenisolation, Datenlokation und Admin-Zugriffe werden damit nicht automatisch tief genug geprüft. Diese Punkte müssen separat bewertet werden. Ergänzend helfen ISO/IEC 27017 und 27018.

Besonders heikel wird es beim Shared-Responsibility-Modell. Wenn die Aufgabenteilung zwischen Cloud-Anbieter und Kunde nicht ausdrücklich dokumentiert ist und Kontrollen nicht sauber zugeordnet werden, entstehen schnell Verantwortungslücken. Auf dem Papier sieht dann alles ordentlich aus, im Betrieb fehlt aber am Ende genau die Zuständigkeit für einen kritischen Schritt.

Prüfablauf

Der Ansatz nach ISO/IEC 27001 folgt einem klaren Ablauf: Zuerst wird der ISMS-Scope festgelegt, danach werden Cloud-Assets inventarisiert. Anschließend identifiziert man Bedrohungen und Schwachstellen, bewertet Eintrittswahrscheinlichkeit und Auswirkung, ordnet passende Kontrollen aus Annex A zu und erstellt einen Risikobehandlungsplan.

Im Vendor-Assessment liefert ISO/IEC 27001 damit vor allem den Governance-Rahmen, nicht den speziellen Cloud-Nachweis. C5-Reports oder SOC-2-Berichte können hier als Evidenz dienen, ersetzen aber keine eigene Risikobewertung.

Die eigentliche Knackfrage bleibt im Alltag oft dieselbe: Wie belastbar sind diese Kontrollen im laufenden Betrieb?

Resilienz und Exit

Business Continuity bleibt in ISO/IEC 27001 eher allgemein. Cloud-typische Ausfälle, Multi-Cloud-Fehler und SaaS-Abhängigkeiten müssen deshalb als eigene Risiken ins ISMS aufgenommen werden. Das gilt auch für Vendor-Lock-in. Solche Risiken sollten dokumentiert, nach Eintrittswahrscheinlichkeit und Auswirkung bewertet und auf Annex-A-Kontrollen zu Lieferantenbeziehungen und Business Continuity gemappt werden.

Zusätzlich gehört die vertragliche Absicherung dazu. Exit-Strategien und Datenportabilität sollten nicht nur grob erwähnt, sondern klar geregelt sein.

BSI C5 schließt genau diese Cloud-Lücke.

4. BSI C5

BSI C5

Praxisnutzen in Deutschland

Während ISO/IEC 27001 eher die Governance-Seite beschreibt, liefert C5 den prüfbaren Nachweis für Cloud-Dienste. BSI C5 – der Cloud Computing Compliance Criteria Catalogue des Bundesamts für Sicherheit in der Informationstechnik – ist in Deutschland ein direkt nutzbarer Rahmen, um Cloud-Anbieter zu bewerten. Wer einen Anbieter vor Prüfern oder Aufsichtsbehörden begründen muss, hat mit einem aktuellen C5-Bericht eine belastbare Grundlage für Ausschreibung, Audit und Freigabe.

Cloud-spezifische Tiefe

C5 schaut auf ganz konkrete Kontrollen im Cloud-Betrieb. Dazu gehören etwa Mandantenisolation, Logging, Identity & Access Management, Kryptografie und die Steuerung von Subdienstleistern. Der Katalog umfasst rund 121 Kriterien in 17 Themenbereichen. Dabei trennt C5 zwischen Basis- und Zusatz-Kriterien. So lassen sich normale Anforderungen und höhere Schutzbedarfe sauber voneinander abgrenzen.

Bewertung in der Praxis

C5 ist kein Zertifikat mit Siegel, das man kurz abhakt. Es handelt sich um eine Attestierung nach ISAE 3000, und der eigentliche Maßstab ist der Prüfbericht. Typ 1 bewertet den Stichtag, Typ 2 die Wirksamkeit über einen Zeitraum von 6 bis 12 Monaten.

Für die Praxis heißt das: Am besten fordern Sie einen aktuellen Typ-2-Bericht an. Prüfen Sie dann genau, ob der Scope auch die Dienste umfasst, die Sie am Ende einkaufen wollen. Sonst sieht der Bericht auf dem Papier gut aus, sagt aber über den konkret genutzten Dienst nur bedingt etwas aus.

Resilienz und Betriebskontinuität

C5 behandelt Business Continuity, Disaster Recovery, Kapazitätsmanagement und Incident-Response als eigene Prüfbereiche. Das ist im Alltag nützlich, weil man damit sehr konkrete Fragen stellen kann:

  • Gibt es getestete Wiederherstellungsprozesse?
  • Sind Redundanzen dokumentiert?
  • Wie werden Vorfälle eskaliert?

Ein C5-Bericht liefert dazu prüfbare Nachweise. Gleichzeitig bleibt eine Grenze bestehen: C5 zeigt, ob der Anbieter Baseline-Kontrollen für Resilienz eingerichtet hat. Die eigenen Recovery-Ziele und Exit-Pläne muss ein Unternehmen trotzdem selbst festlegen. Genau an dieser Stelle knüpft EUCS an und zielt auf eine europaweite Zertifizierung.

5. EUCS

EUCS

Regulatorische Einordnung

Nach C5 kommt mit EUCS der geplante, EU-weit einheitliche Prüfrahmen für Cloud-Dienste. EUCS – das European Union Cybersecurity Certification Scheme for Cloud Services – ist das von ENISA entwickelte EU-Zertifizierungsschema für Cloud-Dienste. Es soll eine gemeinsame Sicherheitsbasis in der EU schaffen und fügt sich in Vorgaben wie DSGVO, NIS2 und den Data Act ein.

Für Unternehmen in NIS2-relevanten Sektoren kann EUCS später auch bei der Beschaffung eine Rolle spielen. EUCS-Zertifizierungen lassen sich dann als Kriterium bei der Anbieterauswahl nutzen. Anders gesagt: EUCS ergänzt nationale Prüfrahmen um eine einheitliche Zertifizierung auf EU-Ebene. Für die Auswahl von Cloud-Anbietern wird das Schema damit vor allem als künftiger EU-Maßstab wichtig.

Cloud-spezifische Kontrollen

EUCS ist klar auf Cloud-Dienste zugeschnitten und deckt IaaS, PaaS und SaaS ab. Genau das macht den Rahmen für viele Teams interessant: Er bleibt nicht bei allgemeinen Governance-Vorgaben stehen, sondern schaut auf Themen, die im Cloud-Betrieb jeden Tag zählen.

Dazu gehören unter anderem:

  • Mandantenisolation
  • Sicherheit der Virtualisierung
  • sichere APIs
  • Identity & Access Management
  • Logging für Cloud-Workloads

Das Schema arbeitet mit drei Sicherheitsstufen (Assurance Levels):

Stufe Zielgruppe Anforderungsniveau
Basic Niedriges Risiko, Standardbedrohungen Grundlegende Sicherheitsmaßnahmen
Substantial Mittleres Risiko Erweiterte Kontrollen und systematisches Risikomanagement
High Hochkritische Workloads Strengste technische und organisatorische Anforderungen

Bewertung in der Praxis

EUCS befindet sich weiter im Entwurfsstadium; Zertifikate werden derzeit noch nicht ausgestellt. Für deutsche Unternehmen heißt das ganz schlicht: Es gibt aktuell noch keinen breiten Markt mit EUCS-zertifizierten Cloud-Anbietern.

Trotzdem lohnt sich der Blick schon heute. Viele der Anforderungen lassen sich bereits jetzt als Referenz-Checkliste in Ausschreibungen und Due-Diligence-Prozessen nutzen. Ebenso sinnvoll ist es, den Zertifizierungsstand von Anbietern aktiv abzufragen. So wird EUCS schon vor dem Start des Markts zu einem brauchbaren Prüfmaßstab.

Zertifikate sind auf drei Jahre ausgelegt und verlangen während der Laufzeit regelmäßige Audits.

Betriebliche Resilienz

Auf den Stufen Substantial und High fordert EUCS nachweisbare Maßnahmen für Resilienz. Dazu zählen dokumentierte Notfall- und Wiederanlaufpläne, Redundanz- und Failover-Mechanismen sowie klar definierte RTOs und RPOs.

Hinzu kommen Pflichten zur Transparenz bei Störungen und beim Wiederanlauf gegenüber Kunden. Kunden sollen also nachvollziehen können, wie kritische Dienste im Störungsfall weiterbetrieben werden. Das ist nicht nur Papier für Auditoren. Diese Vorgaben lassen sich direkt in SLA-Reviews und in Architekturentscheidungen übersetzen, etwa bei Multi-Region-Deployments oder bei der Backup-Strategie.

Damit wird EUCS schon heute ganz praktisch nutzbar – sowohl für die SLA-Prüfung als auch für Architekturentscheidungen.

Wie sich die Rahmenwerke in der Praxis unterscheiden

Bei der Anbieterprüfung verfolgen ENISA, NIST, ISO/IEC 27001, BSI C5 und EUCS nicht alle dasselbe Ziel. Genau das macht die Einordnung in der Praxis so wichtig. Die Matrix unten zeigt, welcher Ansatz sich für welchen Zweck am besten eignet.

Prüfdimension Stark Moderat Derzeit nur indirekt
Recht und Compliance (DSGVO, DPAs, SCCs) BSI C5, ENISA ISO/IEC 27001, EUCS NIST
Sicherheitskontrollen (IAM, Protokollierung, Verschlüsselung) NIST, BSI C5 ISO/IEC 27001, EUCS ENISA
Kontinuität und Ausfallrisiko (SLA, RTO/RPO, Redundanz) BSI C5, ENISA ISO/IEC 27001, NIST EUCS
Anbieterabhängigkeit und Exit-Risiko ENISA ISO/IEC 27001, EUCS NIST, BSI C5

Die folgende Einordnung geht tiefer auf die Stärken und Schwächen der fünf Ansätze ein.

Recht und Compliance

Für deutsche Unternehmen ist BSI C5 der direkteste Prüfmaßstab. BSI C5 ist dafür der direkteste Nachweis. Das ist in der Praxis oft der Punkt, an dem viele Teams zuerst ansetzen: weniger Theorie, mehr prüfbarer Beleg.

ENISA hilft dabei, Datenschutz- und Transfer-Risiken einzuordnen, ersetzt aber weder eine Zertifizierung noch die Prüfung von Verträgen. EUCS geht noch einen Schritt weiter und greift Themen wie Datenlokation in der EU, die Begrenzung behördlicher Zugriffe und die EU-Rechtswahl auf. Der Haken: Eine breite Zertifizierungspraxis gibt es dafür noch nicht.

ISO/IEC 27001 hilft, vertragliche Sicherheitsanforderungen und Datenresidenz sauber zu ordnen. Was es aber nicht leistet: die Prüfung von DPAs und SCCs ersetzen. NIST ist in diesem Feld am schwächsten, weil das Rahmenwerk nicht auf EU-Transferregeln zugeschnitten ist.

Sicherheitskontrollen

Wenn es um IAM, Protokollierung und Verschlüsselung geht, liefert NIST die genauesten Kontrollfragen. Wer wissen will, ob technische Schutzmaßnahmen nur auf dem Papier stehen oder sauber umgesetzt sind, bekommt hier die schärfsten Fragen an die Hand.

BSI C5 ist ähnlich stark auf Cloud-Szenarien ausgerichtet. Für deutsche Einkäufer ist das besonders nützlich, weil sich der C5-Prüfbericht direkt als Lieferantennachweis anfordern lässt. Das spart Zeit und macht Gespräche mit Anbietern oft klarer.

ISO/IEC 27001 legt die Governance-Basis. Bei Cloud-nativen Konfigurationen und bei Grenzen rund um Wechselrisiken bleibt das Rahmenwerk aber weniger präzise. ENISA liefert brauchbare Risikoszenarien, taugt jedoch nicht als Werkzeug zur Prüfung einzelner technischer Maßnahmen. EUCS legt Mindestkontrollen für Zertifizierungsstufen fest, ist in der Praxis aber noch nicht so weit wie C5.

Kontinuität und Ausfallrisiko

Bei Kontinuität und Ausfallrisiko spielt BSI C5 seine Stärke klar aus. Das Rahmenwerk verlangt attestierte Betriebs- und Wiederanlaufprozesse, die sich direkt mit SLA-Klauseln abgleichen lassen. Das ist im Alltag viel mehr als nur ein Häkchen in einer Tabelle.

ENISA hilft beim szenariobasierten Denken: Was passiert bei Ausfällen, und wie stark trifft das den Geschäftsbetrieb? Gerade für Risiko-Workshops ist das nützlich.

ISO/IEC 27001 stärkt die Prozessseite, braucht aber bei Cloud-Themen Zusatzfragen, etwa zu regionaler Redundanz oder zu konkreten RTO/RPO-Zielen. NIST unterstützt bei der Einordnung von Backups und Wiederherstellungszielen, liefert für sich allein aber keine vollständige Cloud-Bewertung in diesem Feld. EUCS ist hier noch eher ein Signal für die Richtung, weil die praktische Prüf- und Zertifizierungspraxis noch reift.

Damit wird Resilienz zur operativen Prüfgröße und nicht bloß zur Backup-Frage.

Anbieterabhängigkeit und Exit-Risiko

Für Wechselrisiken ist ENISA das klarste Rahmenwerk. Das ist ein Punkt, der in Beschaffungsprojekten gern zu spät kommt. Erst läuft alles gut, dann merkt man, wie schwer ein Ausstieg werden kann.

ISO/IEC 27001 Annex A 5.23 und EUCS helfen dabei, Vertrags-Governance, Transparenz und Datenportabilität zu ordnen. Was beide nicht liefern, ist eine komplette Methode für Migration oder Exit. NIST und BSI C5 helfen eher auf der technischen Seite; die eigentliche Exit-Planung bleibt davon getrennt.

Für eine belastbare Exit-Strategie braucht es daher immer noch eine eigene Prüfung von Datenexporten und Übergangssupport.

Im nächsten Abschnitt folgen die Stärken und Schwächen je Ansatz.

Stärken und Schwächen der einzelnen Bewertungsansätze

Die Matrix zeigt die grobe Einordnung. In der Praxis zählt aber mehr als nur die Frage, was ein Rahmenwerk abdeckt. Entscheidend ist, wie gut sich damit ein Cloud-Anbieter nachweisbar prüfen lässt.

Rahmenwerk Vorteile Einschränkungen Empfohlener Einsatz
ENISA Strukturierter Risikokatalog mit breiter Abdeckung von Governance-, Technik- und Compliance-Risiken Kein Zertifizierungsstandard, keine Attestierung, muss durch formale Nachweise ergänzt werden Frühe Risikoidentifikation, Workshops
NIST Granulare, technisch präzise Kontrollen für Cloud-native Architekturen Kaum auf DSGVO, BSI-Anforderungen oder EU-Recht ausgerichtet Technische Härtung, interne Kontrollprüfung
ISO/IEC 27001 Reifes ISMS, wiederholbare Prüfprozesse, global anerkannt Wenig Cloud-spezifische Tiefe, nicht handlungsleitend, braucht Erweiterungen Governance-Grundlage, Lieferantenprüfung
BSI C5 In Deutschland stark relevant, auditbasiert, cloud-spezifische Kriterien Hoher Prüfaufwand, besonders für kleinere Organisationen Öffentliche Auftraggeber, KRITIS, regulierte Branchen
EUCS EU-weite Harmonisierung, Signal für digitale Souveränität, drei Vertrauensstufen Noch in Entwicklung, politische Debatten, geringe aktuelle Einsatzreife Vorausplanung, zukünftige EU-weite Beschaffung

Die Punkte darunter zeigen genauer, wo die einzelnen Ansätze stark sind und wo sie ohne Ergänzung zu kurz greifen.

ENISA: breiter Risikorahmen, begrenzte direkte Absicherung

ENISA deckt Governance-, Technik- und Compliance-Risiken breit ab und ist damit gerade in frühen Projektphasen ein guter Startpunkt. Das hilft etwa in Workshops, bei der ersten Risikoaufnahme oder wenn Teams erst einmal sortieren müssen, wo die dicken Brocken liegen.

Für Beschaffung reicht das allein aber nicht. Sobald formale Einkaufsprozesse oder regulatorische Pflichten ins Spiel kommen, braucht es zusätzliche Nachweise, zum Beispiel BSI C5, ISO/IEC 27001 oder vertragliche Prüfmechanismen.

Für technische Detailkontrollen führt der nächste Schritt meist zu NIST.

NIST: klare Kontrollen, schwächere EU-Rechtsausrichtung

NIST ist vor allem für technische Teams stark. Die Kontrollkataloge aus CSF 2.0 und SP 800-53 liefern klare Prüfpunkte für IAM, Protokollierung, Netzwerksegmentierung und Workload-Härtung. Wenn ein Security-Team wissen will, was genau geprüft werden soll, ist NIST oft nah an der Praxis.

Die Schwäche liegt an anderer Stelle: DSGVO, BSI-Grundschutz oder branchenspezifische Vorgaben wie KRITIS oder BaFin-Rundschreiben sind im NIST-Rahmen nicht inhärent abgebildet. Für deutsche Organisationen heißt das: NIST gut als technische Basis nutzen, die rechtliche Compliance aber separat über EU-konforme Rahmenwerke absichern.

Die Governance-Sicht bringt dann ISO/IEC 27001 ins Spiel.

ISO/IEC 27001-basierte Bewertung: starke Governance, begrenzte Cloud-Tiefe

ISO/IEC 27001 liefert mit Annex A 5.23 in der Version 2022 erstmals einen expliziten Steuerungsansatz für Cloud-Dienste, von der Beschaffung bis zum Ausstieg. Das ist für Governance wichtig, weil Verantwortlichkeiten, Prozesse und Prüfabläufe sauber aufgesetzt werden können.

Bei Cloud-spezifischen Themen wie Multi-Tenant-Risiken, Container-Sicherheit oder feingranularem Logging bleibt der Standard jedoch weniger präzise als BSI C5. Anders gesagt: ISO/IEC 27001 schafft das Dach, aber nicht immer die feine technische Tiefe. Für kritische oder stark regulierte Workloads braucht es deshalb cloud-spezifische Ergänzungen.

Wenn es um den konkreten Nachweis gegenüber Cloud-Anbietern geht, ist C5 meist näher an der Sache.

BSI C5: hohe Relevanz in Deutschland, höherer Prüfaufwand

BSI

BSI C5 hat in Deutschland einen hohen Stellenwert und liefert einen starken Nachweiswert, bringt aber auch spürbaren Prüfaufwand mit. Der Standard ist branchenübergreifend nutzbar, in einzelnen Sektoren wie dem Gesundheitswesen schon verpflichtend, und Anbieter ohne C5-Nachweis müssen in deutschen Ausschreibungen oft mit deutlich mehr Prüfaufwand rechnen.

Genau da liegt der Haken: C5-Audits sind umfangreich, viele Kriterien müssen ausgelegt werden, und kleinere Organisationen ohne eigene Prüfkompetenz brauchen dafür oft externe Hilfe. Das ist kein K.-o.-Punkt, aber man sollte den Aufwand nicht kleinreden.

EUCS: künftiger Zertifizierungswert, aktuelle Reifegrenzen

EUCS ist politisch wichtig, operativ heute aber noch nicht belastbar. Debatten über Datenlokalisierung und die Frage, ob Nicht-EU-Anbieter höhere Zertifizierungsstufen erreichen können, sind weiter offen. Dazu kommt: Wirtschaftliche Analysen warnen davor, dass zu strenge Anforderungen den Wettbewerb einschränken könnten.

Stand heute taugt EUCS damit eher als Orientierung für die Planung als als harte Entscheidungsgrundlage im laufenden Einkauf.

Fazit

Entscheidend ist nicht das eine beste Framework. Was in der Praxis zählt, ist die passende Mischung aus Regulatorik, Technik und Prozessreife.

Für deutsche Organisationen bietet sich ein gestufter Ansatz an: C5 als Nachweis, ENISA für Risiken, NIST für Kontrollen und ISO/IEC 27001 für Governance. Damit lässt sich die heutige Prüfung gut abdecken. EUCS kommt als künftiger Standard dazu.

EUCS sollte schon jetzt in Ausschreibungen mitgedacht werden – vor allem bei NIS2-relevanten Workloads.

Für stark digitalisierte Betriebe wird das sofort zum Betriebsrisiko. Bei digitalisierten Prüfdienstleistern wie CUBEE Sachverständigen AG sind Ausfall, Datenverlust und Nachweisbarkeit direkt geschäftskritisch.

Ein sinnvoller Fahrplan für die nächsten 12 bis 24 Monate sieht so aus:

  • Risikokatalog aufbauen
  • C5-Berichte systematisch auswerten
  • NIST-Baselines definieren
  • ISO-27001-Prozess fest im Unternehmen verankern

FAQs

Welches Framework sollte ich zuerst nutzen?

Beginnen Sie zuerst mit einer gründlichen Risikobewertung. Sie setzt den Rahmen, blickt auf das gesamte Unternehmen und ordnet Bedrohungen danach ein, wie stark sie das Geschäft treffen können.

Darauf baut das Schwachstellenmanagement auf. Damit lassen sich technische Sicherheitslücken gezielt finden und schließen. So greifen strategische Prioritäten und technisches Handeln sauber ineinander.

Reicht ein ISO-27001-Zertifikat aus?

Nein. Ein ISO-27001-Zertifikat ist ein wichtiger Nachweis für grundlegende Sicherheitsprozesse, reicht für sich genommen aber nicht aus.

Für die DSGVO braucht es mehr. Dazu gehören ein Auftragsverarbeitungsvertrag, technische und organisatorische Maßnahmen sowie ein rechtlich sauberer Schutz sensibler Fahrzeug- und Kundendaten.

Konkret heißt das zum Beispiel:

  • rollenbasierte Zugriffe, damit nicht jeder alles sehen kann
  • verschlüsselte Datenübertragungen, damit Daten auf dem Weg nicht mitgelesen werden

Das Zertifikat zeigt also: Die Basis stimmt. Für DSGVO-Konformität zählen am Ende aber auch die rechtlichen und technischen Details.

Wie prüfe ich das Exit-Risiko konkret?

Prüfen Sie das Exit-Risiko mit einer systematischen Analyse von Abhängigkeiten und Ausstiegsszenarien. Dazu sollten Sie Datenflüsse und Geschäftsprozesse sauber kartieren, die Geschäftskritikalität bewerten und Risiken nach Eintrittswahrscheinlichkeit und Schadensausmaß ordnen.

Schauen Sie sich außerdem die Verträge genau an. Sind Datenrückgabe und Löschkonzept klar geregelt? Entscheidend ist, dass Daten technisch und rechtlich in einem nutzbaren Format bereitgestellt werden - nicht nur auf dem Papier, sondern so, dass Sie damit auch weiterarbeiten können.

Jährliche Sicherheitsaudits helfen dabei, die Portabilität und Integrität der Datenbestände zu prüfen.

Verwandte Blogbeiträge