Souveräne Cloud für KMU: die Checkliste, die zählt

Digitale Souveränität ist für viele KMU noch ein Begriff, der irgendwo zwischen Compliance-Pflicht und IT-Strategie schwebt, theoretisch wichtig, praktisch unklar. Dabei stellt sich die Frage nicht, ob man sich damit auseinandersetzen muss, sondern wann. DSGVO-Bußgelder, NIS2-Anforderungen und wachsende Kundenerwartungen machen Cloud-Souveränität zu einem operativen Thema. Diese Checkliste gibt euch eine konkrete Grundlage, um eure Cloud-Situation zu bewerten und fundierte Entscheidungen zu treffen. Geht es konkret um die Anbieterauswahl, hilft unser Framework für Sovereign Cloud Anbieter im Vergleich.

Was digitale Souveränität für KMU wirklich bedeutet

Digitale Souveränität beschreibt die Fähigkeit, selbst zu kontrollieren, wo eure Daten liegen, wer auf sie zugreifen kann und unter welchem Rechtssystem das passiert. Das klingt simpel, ist es aber in der Praxis nicht, gerade weil viele Cloud-Dienste diese Fragen bewusst unscharf lassen.

Für ein KMU bedeutet das konkret: Ihr seid verantwortlich für die Einhaltung der DSGVO, auch wenn ihr einen externen Cloud-Anbieter nutzt. Und ihr müsst nachweisen können, dass ihr diese Kontrolle tatsächlich habt, nicht nur vertraglich vereinbart.

Souveränität ist mehr als ein Serverstandort

Der Irrtum, der sich am hartnäckigsten hält: „Unsere Daten liegen in Deutschland, also sind wir sicher." Das stimmt nicht. Der Unterschied zwischen Datenresidenz und Datensouveränität ist genau hier entscheidend.

Entscheidend ist nicht nur, wo ein Server steht, sondern:

• Wer hat technischen Zugriff? Auch ein Server in Frankfurt kann von einem US-Unternehmen betrieben werden, das dem CLOUD Act gegenüber der DSGVO unterliegt und damit US-Behörden auf Anfrage Zugriff gewähren muss.
• Wie ist die Verschlüsselung geregelt? Liegen eure Schlüssel beim Anbieter oder bei euch?
• Wie ist die Betreiberstruktur? Ist das Unternehmen, das den Dienst betreibt, europäisch und europäischem Recht unterworfen?

Diese drei Punkte sind die erste Ebene jeder souveränen Cloud-Entscheidung.

Warum der Handlungsdruck für KMU gestiegen ist

Lange Zeit war das Thema Cloud-Souveränität vor allem für Behörden und Konzerne relevant. Das hat sich geändert, weshalb Cloud-Souveränität zur Führungsaufgabe geworden ist.

Die DSGVO gilt seit 2018 für jedes Unternehmen, das personenbezogene Daten verarbeitet, also praktisch alle. Die Anforderungen an Auftragsverarbeitungsverträge, Datentransfers in Drittländer und Löschfristen sind real und werden von Aufsichtsbehörden zunehmend aktiv geprüft.

NIS2 im Überblick: Wen es trifft und was zu tun ist

Die NIS2-Richtlinie für DevOps-Teams, die seit Oktober 2024 in Deutschland gilt, erweitert den Kreis der betroffenen Unternehmen erheblich. Wer mehr als 50 Mitarbeitende hat oder in einem der definierten kritischen Sektoren tätig ist, fällt unter NIS2.

Was das für den Cloud-Betrieb bedeutet:

• Ihr müsst Sicherheitsmaßnahmen im Cloud-Bereich nachweisen können
• Incidents müssen innerhalb von 24 Stunden gemeldet werden
• Lieferketten, also auch eure Cloud-Anbieter, müssen auf Sicherheitsanforderungen geprüft werden

Kurzum: Die Zeit, in der man Cloud-Entscheidungen rein nach Preis und Convenience getroffen hat, ist für viele KMU vorbei.

Die Checkliste: souveräne Cloud für KMU

Nutzt diese Liste wie einen kleinen Due-Diligence-Prozess. Ideal ist, wenn ihr die Punkte mit eurem Cloud-Anbieter gemeinsam durchgeht und euch Nachweise geben lasst.

1) Daten, Workloads und Risiko sauber einordnen (Startpunkt)

• Datenklassifizierung vorhanden: Welche Daten liegen in der Cloud (personenbezogen, vertraulich, geistiges Eigentum)? Welche Kategorien sind kritisch?
• Workload-Typen erfasst: Web-Apps, Datenbanken, CI/CD, Analytics, Backups, Logs. Was läuft wo?
• Schutzbedarf bestimmt: Welche Systeme müssen besonders verfügbar sein (RTO/RPO, Business-Kritikalität)?
• Compliance-Anforderungen gesammelt: DSGVO, Branche (z. B. KRITIS-nahe Anforderungen), Kundenverträge, interne Policies.

2) Rechtliche Basis (DSGVO & Verträge)

• AVV nach Art. 28 DSGVO abgeschlossen: Mit klaren TOMs (technische und organisatorische Maßnahmen) und aktuellen Anhängen.
• Rollenmodell klar: Wer ist Verantwortliche:r, wer Auftragsverarbeiter, gibt es gemeinsame Verantwortlichkeit, wer ist Subprocessor?
• Subunternehmerliste transparent: Vollständig, aktuell, mit Informations- und Widerspruchsmechanismen bei Änderungen.
• Drittländer-Transfers bewertet: Findet irgendein Zugriff oder Transfer außerhalb EU/EWR statt (Support, Monitoring, Remote-Admin, Telemetrie)? Wenn ja: Rechtsgrundlage, Risikoanalyse, zusätzliche Maßnahmen.
• Behördenzugriff und Offenlegung geregelt: Welche Pflichten hat der Anbieter bei Anfragen? Gibt es Transparenzberichte, Benachrichtigungspflichten, Rechtsschutz?
• Exit-Klauseln vertraglich stark: Datenportabilität, Übergangsfristen, Unterstützung bei Migration, Kosten, Fristen, Löschung, Nachweise.

3) Standort, Betreiberstruktur und Governance (Souveränität im Kern)

• Datenresidenz verbindlich: Welche Daten müssen in der EU bleiben, und ist das vertraglich zugesichert?
• Betreiberstruktur geprüft: Wer betreibt die Infrastruktur wirklich (juristische Einheit, Eigentümerstruktur, Konzernbezug)? Welches Recht gilt?
• Administrativer Zugriff begrenzt: Wer kann administrieren, von wo, unter welchen Kontrollen (4-Augen, JIT/JEA, Approval-Flows)?
• Mandantenfähigkeit und Isolation nachvollziehbar: Wie wird Tenant-Isolation umgesetzt (Netzwerk, Storage, IAM)?

4) Sicherheitsnachweise und Audits (beweisfähig werden)

• Zertifizierungen und Scope passen: ISO 27001, BSI C5, SOC 2, ausgerichtet am EU Cloud Sovereignty Framework. Decken sie den konkreten Service ab (nicht nur das Unternehmen)?
• Audit-Unterlagen verfügbar: Auditberichte, Statement of Applicability, ggf. Pen-Test-Zusammenfassungen.
• Sicherheitsprozesse dokumentiert: Vulnerability-Management, Patch-Policy, Secure SDLC, Change-Management.
• Incident-Prozess klar: Meldewege, Reaktionszeiten, forensische Unterstützung, Root-Cause-Analysen.

5) Identitäten, Zugriffe und Schlüssel (Kontrolle über Zugriff = Kontrolle über Daten)

• IAM-Integration vorhanden: SSO (SAML/OIDC), MFA verpflichtend, rollenbasierte Rechte, least privilege.
• Privileged Access abgesichert: Admin-Zugänge nur über PAM, zeitlich begrenzt (JIT), protokolliert, approvals.
• Schlüsselverwaltung geklärt: Wer hält die Verschlüsselungsschlüssel? BYOK oder HYOK möglich? Wo liegen die HSMs?
• Verschlüsselung in Transit und at Rest: Technisch belegt, inklusive Backups, Snapshots, Object Storage.
• Secrets-Management etabliert: Kein Secrets-in-Code. Rotationsprozesse, Trennung von Zuständigkeiten.

6) Logging, Monitoring und Nachvollziehbarkeit (Audit-Logs sind Pflicht, nicht Luxus)

• Audit-Logs verfügbar und exportierbar: Wer hat was getan? Admin-Aktionen, API-Calls, Änderungen an Policies.
• Log-Aufbewahrung und Integrität: Retention, Manipulationsschutz, Zugriffskontrolle, Zeit-Synchronisation.
• Security-Monitoring integriert: SIEM-Anbindung, Alarmierung, Use Cases (z. B. ungewöhnliche Zugriffe, Datenabflüsse).

7) Architektur: Portierbarkeit und Vendor Lock-in aktiv vermeiden

• Offene Standards bevorzugt: Kubernetes als Souveränitätsschicht, Container, Terraform/OpenTofu, OpenTelemetry.
• Proprietäre Abhängigkeiten bewusst: Welche Services sind „sticky" (z. B. managed DB mit proprietären APIs)? Exit-Plan vorhanden, um Vendor Lock-in aktiv zu vermeiden.
• Datenformate portierbar: Exporte, Backups, Schema-Migrationen, keine proprietären Export-Restriktionen.
• Netzwerk-Portabilität möglich: DNS, TLS-Zertifikate, IP-Whitelists, VPN/Peering-Optionen dokumentiert.

8) Backup, Recovery und Business Continuity (Souveränität im Notfall)

• RTO/RPO realistisch definiert: Pro System, mit Abnahme durch Fachbereich.
• Backups unter eurer Kontrolle: Zugriff, Export, Schlüssel, Test-Wiederherstellungen (nicht nur „Backup exists").
• Disaster-Recovery getestet: Regelmäßige DR-Übungen, dokumentierte Runbooks.
• Geo-Redundanz geregelt: Falls genutzt: in welchen Regionen, unter welchem Recht, mit welchen Abhängigkeiten.

9) Betrieb, Verantwortlichkeiten und Prozesse im KMU (wer macht was?)

• Rollen intern zugewiesen: Cloud Owner, Security, Datenschutz, Einkauf/Legal, Incident Lead.
• Betriebsmodell klar: Wer patcht, wer eskaliert, wer entscheidet Changes, wie läuft Deployment?
• Schulungen und Richtlinien: Was darf in welche Cloud, wie werden Freigaben erteilt, wie werden Ausnahmen dokumentiert?
• Regelmäßige Reviews geplant: Quartalsweise Sicherheitsreview, jährliche Vertrags- und Anbieterreview, Change-Impact-Assessments.

10) NIS2-Readiness (falls relevant)

• Betroffenheit geprüft und dokumentiert: Schwellenwerte, Sektor, Lieferkette.
• Risikomanagement etabliert: Policies, Verantwortlichkeiten, Maßnahmenkatalog, regelmäßige Bewertung.
• Melde- und Kommunikationsplan: Wer meldet wann, interne Kommunikationskette, Vorlagen.
• Lieferkettensicherheit umgesetzt: Anbieterbewertung, Mindestanforderungen, kontinuierliche Überprüfung.

11) Kosten, Transparenz und „True Cost of Compliance"

• Kostenstruktur verständlich: Compute, Storage, Egress, Managed Services, Support, Audit/Compliance.
• Kostenkontrollen aktiv: Budgets, Alerts, Limits, Tagging/Cost Allocation.
• Compliance-Aufwände eingeplant: Interne Zeit, Audits, Dokumentation, Reviews.

12) Exit- und Migrationsplan (als Pflicht-Dokument)

• Exit-Plan schriftlich: Schritte, Verantwortliche, Zeitplan, Abhängigkeiten.
• Testmigration möglich: Mindestens einmal „Trockenlauf" für Export und Restore in eine alternative Umgebung.
• Löschung und Nachweis: Sichere Löschung nach Vertragsende, Löschprotokolle, Umgang mit Backups/Archiven.

Typische Fehler bei der Cloud-Entscheidung

Vier Muster, die wir immer wieder sehen:

Preis als einziges Kriterium. Günstige Cloud-Dienste sind oft günstig, weil Compliance, Zertifizierungen und souveräne Betreiberstrukturen fehlen. Wer im Nachhinein migrieren muss, zahlt mehr.

AVV nicht gelesen. Viele KMU akzeptieren Musterverträge, ohne zu prüfen, ob sie die eigenen DSGVO-Anforderungen wirklich erfüllen. Der Teufel steckt hier oft in den Annexen.

Souveränität einmalig bewertet. Cloud-Anbieter ändern sich, durch Übernahmen, neue AGBs, geopolitische Entwicklungen. Was heute souverän ist, kann es morgen nicht mehr sein.

Technische Abhängigkeiten unterschätzt. Wer von Anfang an auf proprietäre Services eines einzelnen Anbieters setzt, hat später kaum Verhandlungsmacht und hohe Migrationskosten. Eine dokumentierte Cloud Exit Strategie beugt genau dem vor.

Fazit

Digitale Souveränität in der Cloud ist für KMU kein „Nice-to-have", sondern eine Frage von Risiko, Compliance und Handlungsfähigkeit. Wer sich an klare Kriterien hält, Nachweise einfordert und von Anfang an Portierbarkeit sowie Exit-Optionen mitdenkt, vermeidet teure Fehlentscheidungen. Nutzt die Checkliste als wiederholbaren Prozess und überprüft eure Annahmen regelmäßig, denn Anbieter, Verträge und regulatorische Anforderungen ändern sich.