Warum Souveränität eine Strategie und kein Feature ist
Abschnitt betitelt „Warum Souveränität eine Strategie und kein Feature ist“Viele Organisationen behandeln Datenhoheit als Compliance-Kästchen. Das ist ein Fehler. Souveränität ist eine strategische Entscheidung mit tiefgreifenden Folgen für Anbieterauswahl, IT-Architektur, Vertragsgestaltung und Wettbewerbspositionierung.
Die Kernfrage ist nicht: „Sind wir DSGVO-konform?“ Die Kernfrage lautet: „Wer hat im Notfall Zugriff auf unsere Daten — und können wir das steuern?“
Der CLOUD Act: ein konkretes Risiko für regulierte Industrien
Abschnitt betitelt „Der CLOUD Act: ein konkretes Risiko für regulierte Industrien“Der US CLOUD Act (Clarifying Lawful Overseas Use of Data Act, 2018) ermächtigt US-Behörden, von US-Unternehmen Zugriff auf Daten zu fordern — unabhängig davon, wo diese physisch gespeichert sind.
Die Realität: Selbst wenn sich Ihre Daten in einem Rechenzentrum in Frankfurt befinden, kann ein US-Provider gesetzlich verpflichtet sein, diese Daten an US-Behörden herauszugeben.
Für Organisationen in stark regulierten Bereichen ist dies kein theoretisches Risiko, sondern ein konkreter Compliance- und operativer Engpass:
- Automotive: TISAX-Anforderungen
- Banking & Finance: BAIT-/DORA-Compliance
- Gesundheitswesen: KHZG-Regelungen
- Kritische Infrastruktur: KRITIS-/NIS-2-Richtlinien
STACKIT: die souveräne Cloud-Alternative
Abschnitt betitelt „STACKIT: die souveräne Cloud-Alternative“STACKIT (die digitale Marke von Schwarz Digits, dem IT-Powerhouse der Schwarz Gruppe) bietet eine klare Alternative zu außereuropäischen Hyperscalern. Es ist darauf ausgelegt, Drittlandzugriffsrisiken vollständig zu eliminieren.
Souveränitätsmerkmale
Abschnitt betitelt „Souveränitätsmerkmale“| Ausprägung | Bedeutung |
|---|---|
| Deutsche Gesellschaft | Kein US-Cloud-Act-Risiko — keine Offenlegungspflicht gegenüber US-Behörden |
| Rechenzentren in Deutschland & Österreich | DSGVO-native Data Residency, Art. 44 DSGVO kein Anliegen |
| Offene Standards | Aufbauend auf OpenStack, Kubernetes, Terraform — kein proprietärer Vendor-Lock-in |
| Vertragliche Garantien | AVV nach DSGVO Art. 28, transparente Datenverarbeitungsverträge und ein eigenes Datenschutz-Cockpit |
| BSI-C5-Attest | Nachgewiesene High-Level-Sicherheitskontrollen nach deutschem Premium-Standard |
Die vier Säulen der STACKIT-Souveränität
Abschnitt betitelt „Die vier Säulen der STACKIT-Souveränität“- Rechtshoheit: Daten werden ausschließlich unter europäischer Rechtsprechung gespeichert und verarbeitet, abgeschirmt von extraterritorialen Gesetzen.
- Technologische Freiheit: Open-Source-Architekturen sorgen für maximale Transparenz, Code-Prüfbarkeit und problemlose Interoperabilität.
- Organisatorische Unabhängigkeit: Migrationsmuster und Ausstiegsstrategien sind so konzipiert, dass Sie immer die absolute Kontrolle über Ihre operativen Daten behalten.
- Wirtschaftliche Stabilität: Gestützt auf die Finanzkraft der Schwarz Gruppe, die eine langfristige operative Lebensfähigkeit frei von volatilen Marktveränderungen sicherstellt.
Unsere 4-Phasen-Cloud-Advisory-Journey
Abschnitt betitelt „Unsere 4-Phasen-Cloud-Advisory-Journey“Der Übergang in eine souveräne Cloud erfordert eine strukturierte Roadmap. Wir begleiten Ihre Organisation von der Erstbewertung bis zum vollständig konformen, kontinuierlichen Betrieb auf STACKIT.
Phase 1: Sovereignty & Readiness Assessment
Abschnitt betitelt „Phase 1: Sovereignty & Readiness Assessment“Wir prüfen Ihre aktuelle IT-Landschaft, um Abhängigkeiten von Drittanbietern zu identifizieren, bilden Schatten-IT ab und klassifizieren Ihre bestehenden Workloads basierend auf regulatorischen und organisatorischen Anforderungen.
Phase 2: Strategischer Architekturentwurf
Abschnitt betitelt „Phase 2: Strategischer Architekturentwurf“Wir gestalten hybride oder Multi-Cloud-Zielarchitekturen unter Verwendung von Open-Source-Standards. Dies beinhaltet die Einrichtung von Schutzzonen, die Planung von Ausstiegsstrategien und die Sicherstellung einer vollständigen Interoperabilität.
Phase 3: Migration & Compliance-Integration
Abschnitt betitelt „Phase 3: Migration & Compliance-Integration“Wir gleichen die nativen Sicherheitskontrollen von STACKIT an Ihren spezifischen Ordnungsrahmen (BSI IT-Grundschutz, ISO 27001, DSGVO) an. Anschließend führen wir Migrations-Playbooks durch, beginnend mit risikoarmen Piloten, bevor wir Kernsysteme verschieben.
Phase 4: Continuous Governance & AI Evolution
Abschnitt betitelt „Phase 4: Continuous Governance & AI Evolution“Wir etablieren souveräne GRC-Automation (Governance, Risk, Compliance) und schaffen die Voraussetzungen für sichere, souveräne KI-Modelle, die vollständig auf der sicheren Infrastruktur von STACKIT gehostet werden.
Unsere Methodik: dreistufige Workload-Klassifizierung
Abschnitt betitelt „Unsere Methodik: dreistufige Workload-Klassifizierung“Nicht alle Workloads haben die gleichen Souveränitätsanforderungen. Um Over-Engineering oder unnötige Kosten zu vermeiden, klassifizieren wir Ihre Anwendungen in drei verschiedene Tiers:
Tier 1: Souveränität verpflichtend
Abschnitt betitelt „Tier 1: Souveränität verpflichtend“Kriterien: Regulatorische oder vertragliche Verpflichtung zur lokalen Datenspeicherung und -verarbeitung; Daten, die bei Zugriff durch ausländische Behörden erhebliche Haftungsrisiken mit sich bringen; sensible personenbezogene Daten (Art. 9 DSGVO).
Beispiele: Stammdaten von Kunden, Gesundheitsakten, Finanztransaktionen, TISAX-klassifizierte Entwicklungsdateien und KRITIS-Kontrollsysteme.
Voraussetzung: Ausschließlich STACKIT (oder gleichwertige Sovereign Cloud). Kein Deployment auf US-Hyperscalern.
Tier 2: Souveränität bevorzugt
Abschnitt betitelt „Tier 2: Souveränität bevorzugt“Kriterien: Kein hartes Regulierungsveto, aber erhöhter Schutzbedarf. Daten, deren Kompromittierung Reputationsschäden oder Wettbewerbsnachteile verursachen würde.
Beispiele: ERP-Systeme, HR-Datenbanken (ohne besondere Kategorien von personenbezogenen Daten), interne Kommunikationsplattformen und eigene Produktdesigns.
Anforderung: STACKIT bevorzugt; andere sichere europäische Anbieter akzeptabel. US-Hyperscaler sind nicht zu empfehlen.
Tier 3: Flexibel
Abschnitt betitelt „Tier 3: Flexibel“Kriterien: Keine personenbezogenen Daten, nicht sensible Betriebsdaten oder öffentlich zugängliche Werte, bei denen Schnelligkeit und globale Reichweite strikte Souveränität überwiegen.
Beispiele: Öffentliche Webseiten, CDN-Inhalte, Open-Source-Build-Artefakte und isolierte Entwicklungs-Sandboxes.
Anforderung: Jeder Cloud-Anbieter ist akzeptabel.
Entscheidungsbaum Souveränität
Abschnitt betitelt „Entscheidungsbaum Souveränität“Um festzustellen, wo Ihre Workloads hingehören, führen wir Sie durch fünf Kernfragen:
Praktische Schritte
Abschnitt betitelt „Praktische Schritte“Ihre digitale Souveränität zu sichern ist ein aktiver Prozess. Wir arbeiten mit Ihren Teams zusammen, um diese unmittelbaren, praktischen Schritte auszuführen:
- Schritt 1: Workload-Inventar erstellen — Erstellen Sie ein übergreifendes Verzeichnis aller Applikationen und deren jeweiliger Datenkategorien
- Schritt 2: Souveränitätsworkshop — CISO, DSB und Rechtsabteilung zusammenbringen, um die dreistufige Einordnung abzuschließen
- Schritt 3: Souveränitätsmatrix etablieren — Ein lebendiges, geprüftes Dokument aufsetzen, das klare Ownership- und Hosting-Regeln für jeden Workload zuweist
- Schritt 4: Benennung eines Data Sovereignty Officer — Definieren Sie klare Verantwortlichkeit und Souveränitäts-Governance für den Cloud-Betrieb
- Schritt 5: Vertragliche Absicherung — AVV mit STACKIT finalisieren, Datenschutz-Cockpit entsprechend Ihrer Security Baseline konfigurieren