Cloud Security in Deutschland — Rechtliche Anforderungen
Cloud Security in Deutschland unterliegt einem komplexen Rechtsrahmen aus DSGVO, NIS2, IT-Sicherheitsgesetz 2.0 und BSI-C5-Katalog. Unternehmen müssen sowohl technische als auch rechtliche Anforderungen erfüllen. Wer Cloud-Dienste nur als IT-Einkauf behandelt, unterschätzt 2026 das Bußgeld- und Haftungsrisiko deutlich.
Die wichtigsten Eckdaten sind schnell genannt: Der BSI-C5-Katalog umfasst 121 Kriterien, Art. 28 DSGVO verlangt bei Auftragsverarbeitung einen belastbaren Vertrag, die NIS2-Richtlinie setzt seit dem 18. Oktober 2024 den europäischen Umsetzungsmaßstab für Cybersicherheits-Governance, und laut Bitkom nutzen bereits rund 82 Prozent der Unternehmen in Deutschland Cloud-Services. Genau deshalb ist Cloud Compliance heute kein Spezialthema für Konzerne, sondern ein operatives Thema für Geschäftsführung, IT, Datenschutz und Fachbereiche.
Die praktische Leitlinie lautet: Prüfen Sie Cloud Security immer in fünf Ebenen zugleich. Erstens Datenschutz und Auftragsverarbeitung. Zweitens technische Sicherheitsmaßnahmen. Drittens Drittlandtransfer und Zugriffsrisiken. Viertens vertragliche Nachweise wie BSI C5. Fünftens Betreiberpflichten, wenn über die Cloud auch KI-Systeme eingesetzt werden. Wenn Sie die Schnittstelle zwischen Datenschutz und KI zuerst sortieren möchten, lesen Sie ergänzend KI-Verordnung vs. DSGVO, DSGVO und AI Act — Brauche ich zwei Schulungen? und unsere EU AI Act Schulung.
DSGVO und Cloud: Art. 28, Drittlandtransfer und Schrems II
Cloud-Nutzung ist datenschutzrechtlich zulässig, aber nur unter klaren Bedingungen. Sobald ein Cloud-Anbieter personenbezogene Daten im Auftrag verarbeitet, liegt regelmäßig eine Auftragsverarbeitung nach Art. 28 DSGVO vor. Unternehmen brauchen dann einen Auftragsverarbeitungsvertrag, der Gegenstand, Dauer, Art der Daten, Kategorien betroffener Personen, Unterauftragsverhältnisse, Löschung, Kontrollrechte und Sicherheitsmaßnahmen sauber regelt.
Der häufigste Praxisfehler ist nicht das Fehlen eines Vertrags, sondern das blinde Vertrauen in Standardunterlagen des Providers. Ein AV-Vertrag allein löst weder Zugriffsrisiken noch alle internationalen Transferfragen. Prüfen Sie deshalb immer, welche Dienste konkret genutzt werden, wo Daten gespeichert werden, welche Support-Zugriffe möglich sind und welche Unterauftragnehmer eingebunden sind. Gerade bei KI- und SaaS-Diensten verschwimmt sonst schnell, welche Daten in welcher Region tatsächlich verarbeitet werden. Für die vertragliche Tiefenprüfung hilft auch unser Beitrag zur KI-Verordnung vs. DSGVO.
Drittlandtransfers bleiben der sensibelste Teil deutscher Cloud-Compliance. Nach dem Schrems-II-Urteil des EuGH reichen Standardvertragsklauseln allein nicht automatisch aus, wenn im Empfängerland unverhältnismäßige Behördenzugriffe drohen. Unternehmen müssen deshalb zusätzlich prüfen, ob technische und organisatorische Schutzmaßnahmen den Transfer im konkreten Fall ausreichend absichern. Dazu gehören insbesondere starke Verschlüsselung, ein belastbares Schlüsselmanagement, Datenminimierung, Pseudonymisierung und eine ehrliche Bewertung administrativer Fernzugriffe.
Der EU-US Data Privacy Framework kann Transfers an zertifizierte US-Unternehmen erleichtern, beseitigt aber nicht jede Prüfpflicht. Entscheidend ist, welche Gesellschaft Vertragspartner ist, welche Produktvariante gebucht wird, ob Daten für Training oder Support weiterverarbeitet werden und ob außerhalb des zertifizierten Rahmens weitere Zugriffe stattfinden. Für besonders sensible Daten ist eine echte EU-Only-Architektur oft die robustere Lösung als ein später erklärungsbedürftiger Transfermechanismus.
Datenschutzrechtlich gilt deshalb eine einfache Priorität: Erst Datenklassifizierung, dann Anbieterprüfung, dann Vertrag, dann technische Absicherung. Wer umgekehrt zuerst einkauft und erst danach nach Rechtsgrundlage, Löschkonzept und Transfermechanik fragt, produziert vermeidbare Nacharbeiten. Wenn Ihr Unternehmen diese Fragen ohnehin im Governance-Kontext bündeln will, lohnt sich zusätzlich unser Überblick zu AI Act, NIS2 und DSGVO.
NIS2, BSIG und Cloud-Provider
NIS2 macht Cloud Security zu einem Governance-Thema des Managements. Die Richtlinie (EU) 2022/2555 erfasst digitale Infrastrukturen und digitale Dienste ausdrücklich und verlangt ein dokumentiertes Risikomanagement für Netz- und Informationssysteme. In der deutschen Umsetzung materialisieren sich diese Pflichten über das BSIG und sektorspezifische Vorgaben. Für Cloud-Computing-Dienste ist die Kernaussage klar: Wer kritische oder wichtige digitale Leistungen anbietet, muss Sicherheitsorganisation, Incident Response, Lieferkettensicherheit und Resilienz belastbar nachweisen.
Für Kunden bedeutet das zweierlei. Erstens müssen betroffene Cloud-Provider selbst strengere Sicherheitsanforderungen erfüllen. Zweitens steigt auch auf Kundenseite der Prüfungsmaßstab, wenn eigene Prozesse von solchen Diensten abhängen. Spätestens wenn ein Ausfall der Cloud den Geschäftsbetrieb, regulatorische Meldepflichten oder wesentliche Dienstleistungen gefährdet, reicht eine reine Preis-Leistungs-Entscheidung nicht mehr aus.
Besonders relevant sind unter NIS2 und BSIG Maßnahmen zu Risikoanalyse, Business Continuity, Backup, Krisenmanagement, Zugangssicherheit, Multi-Faktor-Authentifizierung, Verschlüsselung, Lieferkettenkontrolle und Vorfallbearbeitung. Genau diese Elemente sollten auch in Ihren Cloud-Verträgen und Anbieter-Assessments sichtbar werden. Wer nur ein Marketing-PDF des Providers ablegt, aber keine Nachweise zu Notfallkonzept, Log-Prozessen, Patch-Management und Subunternehmern einholt, erfüllt typischerweise nicht den erforderlichen Sorgfaltsmaßstab.
Cloud ist damit nicht automatisch reguliert, aber oft geschäftskritisch. Für Unternehmen in regulierten Branchen, im Gesundheitswesen, in der öffentlichen Hand oder in NIS2-nahen Sektoren ist die Cloud-Auswahl deshalb immer auch eine Frage der aufsichtsrechtlichen Verteidigungsfähigkeit. Ergänzend dazu lohnt sich der Blick auf AI Act, NIS2 und DSGVO im Vergleich und auf CRA + NIS2 + AI Act.
BSI C5-Testat: Was es ist und wann es relevant wird
BSI C5 ist der wichtigste deutsche Sicherheitsnachweis für professionelle Cloud-Services. Der vom Bundesamt für Sicherheit in der Informationstechnik veröffentlichte Cloud Computing Compliance Criteria Catalogue definiert 17 Themenbereiche mit insgesamt 121 Kriterien und dient in Deutschland als anerkannter Referenzrahmen für Cloud-Sicherheit, Transparenz und Prüfbarkeit.
Für viele Unternehmen ist C5 nicht deshalb wichtig, weil das Gesetz wörtlich ein Testat verlangt, sondern weil Kunden, Aufsichtsbehörden und Vergabestellen es faktisch als belastbaren Mindestnachweis ansehen. Das gilt besonders für öffentliche Beschaffung, Gesundheitswesen, kritische Infrastrukturen und große Unternehmensgruppen mit erhöhten Audit-Anforderungen. Auch im Mittelstand ist C5 inzwischen oft das schnellste Signal, dass ein Anbieter seine Cloud-Kontrollen strukturiert prüfen lässt.
Der Unterschied zwischen Typ 1 und Typ 2 ist praktisch erheblich. Ein Typ-1-Bericht bewertet die Angemessenheit der beschriebenen Kontrollen zu einem bestimmten Zeitpunkt. Ein Typ-2-Bericht prüft zusätzlich, ob diese Kontrollen über einen Zeitraum hinweg tatsächlich wirksam betrieben wurden. Für sensible oder regulatorisch relevante Workloads ist deshalb Typ 2 der deutlich stärkere Nachweis.
Wichtig ist aber die Einschränkung: Ein C5-Testat ersetzt keine eigene Prüfung. Es sagt nicht automatisch, dass Ihr konkreter Vertrag, Ihre Konfiguration oder Ihre Datenflüsse rechtssicher sind. Prüfen Sie immer, welche Services, Regionen, Subservice-Organisationen und Ausschlüsse vom Bericht abgedeckt sind. Ein Anbieter kann durchaus für bestimmte Kernservices ein gutes Testat haben, während Zusatzmodule, Supportwege oder KI-Funktionen anders zu bewerten sind.
AI Act und Cloud-KI: Betreiberpflichten bei ChatGPT, Azure OpenAI und Copilot
Cloud-KI ist nicht nur eine Datenschutzfrage, sondern seit dem 2. Februar 2025 auch eine AI-Act-Frage. Sobald Unternehmen cloudbasierte KI-Systeme beruflich einsetzen, handeln sie regelmäßig als Betreiber und müssen nach Art. 4 der EU-VO 2024/1689 ein ausreichendes Maß an KI-Kompetenz sicherstellen. Für Hochrisiko-Systeme kommen je nach Einsatzkontext weitere Pflichten hinzu.
Für Betreiberpflichten ist die einschlägige Primärquelle im AI Act Art. 26, nicht Art. 25. Das ist wichtig, weil in der Praxis häufig mit falschen Artikelnummern gearbeitet wird. Art. 26 regelt Pflichten der Betreiber hochriskanter KI-Systeme, etwa die Nutzung nach Gebrauchsanweisung, die Überwachung des Betriebs, die Sicherstellung relevanter Eingabedaten, die Kontrolle menschlicher Aufsicht und gegebenenfalls die Aufbewahrung von Logs. Wer Cloud-KI für HR, Zugangskontrolle, Bonitätsprüfung oder andere sensible Entscheidungen nutzt, sollte diese Betreiberperspektive ausdrücklich prüfen.
Für Standard-Tools wie ChatGPT oder Azure OpenAI lautet die operative Frage deshalb nicht nur: "Ist der Anbieter DSGVO-konform?" Die wichtigere Frage lautet: "Für welchen Zweck setzen wir das System ein, mit welchen Daten, in welcher Rolle und mit welchen internen Freigaben?" Genau dort entscheidet sich, ob aus einem normalen Produktivitätstool ein AI-Act- oder Datenschutzrisiko wird. Mehr dazu finden Sie in KI Self-Hosting vs. Cloud API und in ChatGPT im Unternehmen und dem AI Act.
Die sicherste Linie für Cloud-KI ist eine gemeinsame Governance aus Beschaffung, Datenschutz, Informationssicherheit und Fachbereich. Definieren Sie zugelassene Tools, verbotene Datentypen, Prompt-Regeln, Protokollierung, Rollenrechte und Eskalationswege. Wer erst nach einem sensiblen Prompt-Leak oder einer problematischen KI-Entscheidung damit beginnt, arbeitet nicht präventiv, sondern reaktiv.
Shared Responsibility Model: Was der Provider sichert und was Sie selbst tragen
Shared Responsibility ist der zentrale Denkfehler bei Cloud Security. Viele Unternehmen kaufen einen großen Cloud-Anbieter und unterstellen dann implizit, das Sicherheitsproblem sei ausgelagert. Tatsächlich verlagert die Cloud Verantwortung, sie beseitigt sie nicht.
Der Provider verantwortet typischerweise Rechenzentrum, physische Sicherheit, Basisinfrastruktur, Kernplattform, Redundanz auf Infrastrukturebene und bestimmte Sicherheitsfunktionen des Dienstes. Der Kunde verantwortet dagegen Identitäten, Rollenrechte, Mandantenkonfiguration, Netzsegmente, Schlüsselmanagement im eigenen Einflussbereich, Datenklassifizierung, Löschkonzepte, Protokollierung, erlaubte Nutzungszwecke und die Frage, welche Inhalte überhaupt in die Cloud gelangen dürfen.
Gerade bei SaaS und GenAI ist diese Grenze oft missverständlich, weil die Bedienoberfläche einfach wirkt. Ein einfacher Upload in einen Assistenten kann aber zugleich Datenschutz, Geheimnisschutz, Exportkontrolle und AI-Governance berühren. Deshalb müssen Fachbereiche verstehen, dass "vom Anbieter verschlüsselt" nicht automatisch "rechtlich freigegeben" bedeutet. Für diese Governance-Perspektive hilft auch unser Beitrag zu Shadow-KI im Unternehmen.
Die richtige praktische Frage lautet daher nie nur "Ist der Anbieter sicher?", sondern immer "Welche Restverantwortung bleibt bei uns?" Erst wenn diese Antwort dokumentiert ist, wird aus technischer Cloud-Nutzung eine belastbare Compliance-Entscheidung.
Tabelle: Cloud-Security-Anforderungen in Deutschland
| Anforderung | Rechtsgrundlage | Betroffen | Typische Maßnahme |
|---|---|---|---|
| Auftragsverarbeitung | Art. 28 DSGVO | Unternehmen mit personenbezogenen Daten in der Cloud | AV-Vertrag, Unterauftragsliste, Lösch- und Auditklauseln |
| Sicherheit der Verarbeitung | Art. 32 DSGVO | Alle Verantwortlichen und Auftragsverarbeiter | Verschlüsselung, MFA, Berechtigungskonzept, Logging |
| Drittlandtransfer | Kapitel V DSGVO, Schrems II, DPF | Cloud mit Nicht-EWR-Bezug | SCC, Transfer-Folgenabschätzung, EU-Only-Setup |
| Cybersicherheits-Governance | NIS2, BSIG | Wesentliche und wichtige Einrichtungen, Cloud-Dienste | Risikomanagement, Incident Response, BCM, Lieferkettenprüfung |
| Cloud-Sicherheitsnachweis | BSI C5 | Cloud-Provider, öffentliche Hand, regulierte Branchen | C5-Bericht prüfen, Scope und Gültigkeit kontrollieren |
| KI-Kompetenz | Art. 4 EU-VO 2024/1689 | Anbieter und Betreiber von KI-Systemen | Schulung, Richtlinie, Freigabeprozess, Nachweis |
| Betreiberpflichten bei Hochrisiko-KI | Art. 26 EU-VO 2024/1689 | Unternehmen mit Hochrisiko-KI in Cloud-Umgebungen | Gebrauchsvorgaben, Log-Prüfung, Human Oversight, Datenqualität |
Praktische Checkliste: 10 Punkte für DSGVO-konforme Cloud-Nutzung
Die schnellste Prüfung beginnt mit zehn Fragen. Wenn Sie mehrere Punkte nicht sauber beantworten können, ist Ihr Cloud-Setup rechtlich meist noch nicht belastbar.
- Haben Sie alle Cloud-Dienste mit Datenarten, Zweck und Fachbereich inventarisiert?
- Liegt für jeden relevanten Dienst ein aktueller AV-Vertrag nach Art. 28 DSGVO vor?
- Ist dokumentiert, in welchen Regionen Daten gespeichert und administrativ verarbeitet werden?
- Haben Sie Drittlandbezüge, Supportzugriffe und Unterauftragnehmer ausdrücklich geprüft?
- Sind Verschlüsselung, MFA, Rollenrechte und Logging verbindlich umgesetzt?
- Haben Sie für kritische Dienste Notfall-, Backup- und Exit-Szenarien dokumentiert?
- Prüfen Sie C5-, ISO- oder vergleichbare Nachweise nicht nur formal, sondern auf konkreten Scope?
- Gibt es klare Regeln, welche personenbezogenen oder vertraulichen Inhalte nicht in Cloud-KI eingegeben werden dürfen?
- Sind Datenschutz, IT-Sicherheit, Einkauf und Fachbereich in einem gemeinsamen Freigabeprozess verbunden?
- Haben Mitarbeitende eine dokumentierte Schulung zu zulässiger Cloud- und KI-Nutzung erhalten?
Diese Checkliste ist bewusst knapp. Sie ersetzt kein vollständiges Assessment, zeigt aber sehr schnell, ob Ihr Unternehmen Cloud als gesteuerte Infrastruktur oder als unkontrollierten Werkzeugkasten betreibt. Wenn Sie die Governance-Seite der Schulung vertiefen wollen, ist unsere EU AI Act Schulung der direkte Anschluss.
Fazit: Cloud Security in Deutschland ist Vertrags-, Sicherheits- und Governance-Arbeit zugleich
Cloud Security in Deutschland ist 2026 keine reine Technikfrage mehr. Wer personenbezogene Daten, geschäftskritische Prozesse oder cloudbasierte KI nutzt, muss DSGVO, Transferregeln, NIS2-nahe Sicherheitsanforderungen, C5-Nachweise und interne Betreiberverantwortung gemeinsam steuern. Genau an dieser Verzahnung scheitern viele Projekte: Der Vertrag ist da, aber die Konfiguration nicht. Der Anbieter hat ein Testat, aber der Scope passt nicht. Das Tool ist praktisch, aber die interne Nutzung ist ungeregelt.
Die wirtschaftlichste Reihenfolge lautet deshalb: Daten und Workloads klassifizieren, Anbieter- und Transfermodell prüfen, Sicherheitsnachweise einholen, Restverantwortung dokumentieren und Mitarbeitende schulen. Wenn Sie diese Baseline sauber aufsetzen, sinkt nicht nur das Bußgeldrisiko. Sie reduzieren auch Betriebsunterbrechungen, Fehlbeschaffungen und spätere Governance-Korrekturen.
Wenn Sie Cloud-KI, Betreiberpflichten und KI-Kompetenz in Ihrem Unternehmen strukturiert absichern wollen, nutzen Sie als nächsten Schritt unsere EU AI Act Schulung. Ergänzend helfen Ihnen die Beiträge KI-Verordnung vs. DSGVO, AI Act vs. NIS2 vs. DSGVO, KI Self-Hosting vs. Cloud API und Shadow-KI im Unternehmen bei der operativen Einordnung.
Häufige Fragen zu Cloud Security in Deutschland
Welche Cloud-Sicherheitsanforderungen gelten in Deutschland?
In Deutschland gelten für Cloud-Nutzung je nach Konstellation Datenschutz, Transferregeln, IT-Sicherheitsanforderungen und bei Cloud-KI zusätzlich AI-Act-Pflichten. Besonders häufig relevant sind Art. 28 und Art. 32 DSGVO, Regeln zu Drittlandtransfers, NIS2-nahe Governance-Pflichten und der BSI-C5-Maßstab bei sicherheitskritischen oder öffentlichen Einsatzszenarien.
Was ist BSI C5 und brauche ich es?
BSI C5 ist der deutsche Standardnachweis für Cloud-Sicherheitskontrollen. Sie brauchen nicht zwingend selbst ein Testat, sollten aber bei der Auswahl relevanter Provider prüfen, ob ein aktueller C5-Bericht für den konkret genutzten Dienst vorliegt. Für öffentliche Auftraggeber und regulierte Branchen ist das oft faktisch Pflichtstoff.
Darf ich personenbezogene Daten in die Cloud legen?
Ja, wenn Rechtsgrundlage, AV-Vertrag, Sicherheitsmaßnahmen und gegebenenfalls Transfermechanismus sauber organisiert sind. Verboten ist nicht die Cloud an sich, sondern die unkontrollierte Verarbeitung ohne passende vertragliche, technische und organisatorische Absicherung.
Was bedeutet Shared Responsibility bei Cloud Security?
Shared Responsibility bedeutet, dass Cloud-Anbieter und Kunde unterschiedliche Teile derselben Sicherheitskette tragen. Ohne eigenes Rollenmodell, Berechtigungskonzept, Logging und Datenregeln bleibt Ihr Unternehmen auch bei einem starken Provider angreifbar.
Welche Cloud-Anbieter haben BSI C5 Testat?
Mehrere große Anbieter verfügen für einzelne Dienste und Regionen über C5-Prüfberichte. Prüfen Sie aber immer den konkreten Scope, den Zeitraum, den Berichtstyp und die betroffenen Regionen, statt sich allein auf Vertriebsaussagen zu verlassen.