Cloud Sovereignty + 15 Factor App: Die architektonische Brücke zwischen Recht und Technik

TL;DR

• Das Cloud Sovereignty Framework der EU definiert, was digitale Souveränität erreichen soll – die 15-Factor-App-Prinzipien definieren, wie eine konkrete Anwendungsarchitektur diese Ziele technisch umsetzt.
• SOV‑3 (Data & AI) wird operativ greifbar, wenn Konfiguration (inklusive Verschlüsselungskeys) komplett aus dem Code herausgelöst und als BYOK-Setup in standardisierten Umgebungen verwaltet wird – ganz im Sinne von Factor 3 „Config“.
• SOV‑4 (Operational), SOV‑6 (Technology) und SOV‑7 (Security) lassen sich direkt auf moderne Architekturprinzipien mappen: Backing Services, API-First, Open Source, Telemetry und durchgängige Authentifizierung machen Portabilität, Exit-Fähigkeit und Auditierbarkeit zur eingebauten Eigenschaft.
• Eine 15-Factor-konforme Anwendung kann zwischen Cloud-Providern migriert werden, ohne dass der Anwendungscode verändert werden muss – Konfiguration, APIs und Infrastruktur-Abstraktionen tragen die Last der Migration. Das entspricht exakt der Exit-Fähigkeit, die das Cloud Sovereignty Framework fordert.
• ayedo kombiniert eine souveräne Infrastruktur nach Cloud Sovereignty Framework mit 15-Factor-basierter Anwendungs-Paketierung. Mit unserem Portability Assessment machen wir sichtbar, wie portabel Ihre Anwendungen heute sind – und wie Sie regulatorische Anforderungen architektonisch sauber erfüllen können.

---

Warum Cloud Souveränität eine Architekturfrage ist

Regulatorische Anforderungen sind längst kein reines Legal-Thema mehr. Spätestens seit die EU-Kommission mit Version 1.2.1 des Cloud Sovereignty Frameworks im Oktober 2025 einen konkreten Bewertungsrahmen veröffentlicht hat, ist klar: Wer souveräne Cloud-Dienste beschaffen oder anbieten will, braucht nachvollziehbare technische Antworten.

Gleichzeitig stehen viele Verantwortliche in der Technik vor einer praktischen Frage:
Wie übersetze ich Vorgaben wie „Exit-Fähigkeit“, „Kundenschlüssel-Hoheit“ oder „Offene Standards“ in Architekturentscheidungen, die mein Team tatsächlich umsetzen kann?

Genau hier treffen zwei Welten aufeinander:

• Das Cloud Sovereignty Framework formuliert Souveränitätsziele (SOV‑1 bis SOV‑8) und schafft Klarheit für Beschaffung und Audits.
• Die 15-Factor App formuliert Architekturprinzipien für Cloud-native Anwendungen, mit denen Portabilität, Sicherheit und Transparenz zur strukturellen Eigenschaft der Software werden.

Zusammen bilden beide Frameworks eine Brücke zwischen Recht und Technik: Souveränitätsziele als „Was“, 15-Factor als „Wie“.

---

Zwei Frameworks, eine gemeinsame Sprache

Cloud Sovereignty Framework: Ziele und Nachweise

Das Cloud Sovereignty Framework definiert acht Souveränitätsziele, von strategischer und rechtlicher Verankerung (SOV‑1, SOV‑2) bis hin zu technischen und betrieblichen Aspekten (SOV‑3 bis SOV‑7) und Nachhaltigkeit (SOV‑8).

Für Architekten und Engineering-Verantwortliche sind insbesondere vier Ziele maßgeblich:

• SOV‑3: Data & AI Sovereignty
  Kundenschlüssel-Hoheit, Datenlokalisierung, auditierbare Zugriffe, verifizierbare Löschungen, Kontrolle über AI-Modelle und Pipelines.

• SOV‑4: Operational Sovereignty
  Exit-Fähigkeit, EU-basierte Operations, vollständige Dokumentation und Source-Transparenz, Kontrolle über Subunternehmer.

• SOV‑6: Technology Sovereignty
  Offene Standards, nicht-proprietäre APIs, Open-Source-Zugänglichkeit, Architektur-Transparenz und Portabilität.

• SOV‑7: Security & Compliance Sovereignty
  EU-basierte Security Operations, durchgängige Log-Zugriffe, EU-konforme Incident-Meldungen, unabhängige Audits.

Diese Ziele sind bewusst technologieoffen formuliert – das Framework schreibt nicht vor, welchen Stack Sie wählen sollen. Es verlangt jedoch, dass Sie technische Entscheidungen so treffen, dass diese Ziele nachvollziehbar erreicht werden können.

15-Factor App: Architekturprinzipien für Portabilität

Die 15-Factor App erweitert die bekannten 12-Factor-Prinzipien um drei moderne Anforderungen:

• Factor 13 – API First
  Konsistente, klar definierte APIs als primäre Schnittstelle – idealerweise mit offenen Standards wie OpenAPI.

• Factor 14 – Telemetry
  Beobachtbarkeit durch Metriken, Logs und Traces als integraler Bestandteil der Anwendung.

• Factor 15 – Authentication & Authorization
  Security als Querschnittsfunktion – von Transportverschlüsselung über OAuth2/OIDC bis hin zu fein granularem RBAC.

Gemeinsam sorgen die 15 Faktoren dafür, dass Anwendungen:

• unabhängig vom darunterliegenden Cloud-Provider funktionieren,
• klar erkennbare Schnittstellen zu Backing Services haben,
• Konfiguration und Secrets strikt vom Code trennen,
• und Sicherheits- sowie Compliance-Anforderungen als strukturelle Eigenschaft abbilden.

Damit liefern sie genau die technische „Grammatik“, um die Souveränitätsziele in konkrete Architektur- und Designentscheidungen zu übersetzen.

---

SOV‑3 und Factor 3: Datenhoheit durch Konfigurationshoheit

SOV‑3: Data & AI Sovereignty fordert unter anderem:

• Kundenschlüssel-Hoheit (BYOK / HSM),
• lückenlose Zugriffsprotokollierung,
• strikte Datenlokalisierung,
• transparente, auditierbare AI-Pipelines.

Auf Architekturebene ist das eng mit Factor 3 – Config verknüpft:
Konfiguration – inklusive aller sicherheitskritischen Parameter – gehört in die Umgebung, nicht in den Code. Das klingt banal, ist aber die Grundlage für Datenhoheit.

In einem souveränen, 15-Factor-orientierten Setup bedeutet das:

• Verschlüsselungs- und Signaturschlüssel liegen unter Kontrolle der Kundenseite (Bring Your Own Key), werden aber ausschließlich über Konfiguration in die Anwendung eingebunden. Der Anwendungscode „kennt“ nur Abstraktionen – etwa einen Key-Provider oder eine KMS-API.
• Datenlokalisierung ist eine Eigenschaft der Plattform und Konfiguration (z. B. Auswahl des Storage-Backends, Region, Cluster-Standort), nicht hart im Code verankert.
• AI-Modelle und Pipelines werden so modelliert, dass Speicherorte, Parameter und Datenpfade vollständig über Konfiguration gesteuert werden können.

Das Zusammenspiel von SOV‑3 und Factor 3 führt zu einem zentralen Architekturprinzip:
Die Anwendung ist datensouverän, weil sie jederzeit mit anderen Keys, anderen Storage-Endpunkten und anderen Regionen betrieben werden kann – ohne Codeänderungen. Damit wird der Wechsel von Cloud-Provider A zu einem souveränen Provider B technisch beherrschbar und rechtlich belastbar.

---

SOV‑4, Factor 4 und 13: Exit-Fähigkeit als Designziel

SOV‑4: Operational Sovereignty verlangt eine Exit- und Migrationsfähigkeit ohne Lock-in. Das ist kein reines Vertrags- oder Prozess-Thema, sondern eine direkte Folge der Anwendungs- und Plattformarchitektur.

Die 15-Factor App adressiert das mit mindestens zwei Faktoren:

• Factor 4 – Backing Services
  Jede externe Ressource (Datenbank, Messaging, Object Storage, AI-Service) wird als austauschbare Ressource betrachtet, die über Konfiguration referenziert wird.

• Factor 13 – API First
  Die öffentliche und interne Schnittstellengestaltung folgt offenen, dokumentierten Standards und ist nicht an proprietäre Plattform-Spezifika gebunden.

Konkret bedeutet das für die Exit-Fähigkeit:

1. Service-Austausch ohne Codeänderung
   Wenn eine Anwendung ihre Datenbank, ihren Object Storage oder ihren Message Bus nur über Konfiguration und standardisierte Drivers anspricht, lässt sich der unterliegende Dienst wechseln, ohne dass der Anwendungscode angepasst werden muss.

2. API-Stabilität als Vertragsgrundlage
   Ein API-First-Ansatz sorgt dafür, dass sowohl interne Komponenten als auch externe Konsumenten auf wohldefinierte Verträge setzen. Beim Provider-Wechsel bleibt die API-Stuktur stabil; nur der Zielendpunkt oder die Infrastruktur dahinter ändert sich.

3. Dokumentierte Exit-Runbooks
   SOV‑4 fordert explizite Exit-Prozesse. In einer 15-Factor-Architektur lassen sich diese Prozesse weitgehend standardisieren: Export von Daten über offene Formate, Re-Konfiguration von Endpunkten, Wiederinbetriebnahme auf der Zielplattform.

So wird aus einer abstrakten Forderung des Cloud Sovereignty Frameworks eine sehr konkrete Architekturentscheidung:
Backing Services strikt abstrahieren, APIs standardisieren – dann ist Exit-Fähigkeit kein Projektchaos, sondern ein geplanter, testbarer Prozess.

---

SOV‑6, Factor 13 und 2: Technologie-Souveränität durch offene APIs und Open Source

SOV‑6: Technology Sovereignty fordert unter anderem:

• nicht-proprietäre APIs und Protokolle,
• Open-Source-Zugänglichkeit (Audit, Modifikation, Weitergabe),
• Architektur-Transparenz und minimale Lock-ins.

Das lässt sich direkt mit zwei 15-Factor-Prinzipien verbinden:

• Factor 13 – API First
  Eine konsequente API-First-Strategie zwingt das Team, sich früh zu entscheiden: Binden wir uns an proprietäre Spezial-APIs eines Hyperscalers oder nutzen wir offene Standards, die auch andere Provider anbieten?

• Factor 2 – Dependencies
  Abhängigkeiten werden explizit deklariert und möglichst über offene, standardisierte Ecosysteme (z. B. CNCF-Projekte, etablierte Open-Source-Komponenten) gelöst.

Aus SOV‑6 ergeben sich damit für die Architektur mehrere Leitlinien:

• Open-Source-Komponenten bevorzugen, die auditierbar und notfalls eigenbetrieben sind; das reduziert strukturelle Abhängigkeiten.
• Standardisierte APIs wählen, etwa S3-kompatiblen Object Storage, OIDC für Identity, gängige Message-Bus-Protokolle – statt proprietäre Spezialdienste zu verwenden.
• Transparenz sicherstellen, indem Architektur, Datenflüsse und Abhängigkeiten dokumentiert werden und als verifizierbare Evidenz für Audits zur Verfügung stehen.

Mit einer solchen Architektur können Sie regulatorisch nachvollziehbar argumentieren, dass Ihre Technologieentscheidungen den Souveränitätsanspruch ernst nehmen – ohne Innovation auszubremsen.

---

SOV‑7, Factor 15 und 14: Security & Compliance als Querschnittseigenschaft

SOV‑7: Security & Compliance Sovereignty verlangt:

• EU-basierte Security Operations und Incident Response,
• vollständigen Zugriff auf Logs und Alerts,
• EU-konforme Incident-Meldungen und unabhängige Audits.

Auf Anwendungsebene sind hier zwei 15-Factor-Prinzipien zentral:

• Factor 14 – Telemetry
  Die Anwendung liefert von sich aus alle relevanten Metriken, Logs und Traces – in einem Format, das Provider-unabhängige Auswertung ermöglicht.

• Factor 15 – Authentication & Authorization
  Sicherheitsmechanismen sind integraler Teil der Anwendung – mit standardisierten Protokollen wie TLS, OAuth2, OIDC und rollenbasierter Autorisierung.

In Kombination mit einer souveränen Plattform ergeben sich dadurch mehrere Vorteile:

• Log- und Metrik-Kontrolle: Wenn Anwendungen ihre Telemetrie über offene Protokolle (z. B. standardisierte Logging-Formate, etablierte Metrik-Protokolle) liefern, können Betreiber Logs in einer EU-kontrollierten Toolchain sammeln und auswerten – unabhängig vom ursprünglichen Cloud-Provider.
• Security-Portabilität: Durch Nutzung standardisierter Authentifizierungs- und Autorisierungsmechanismen bleibt die Sicherheitsarchitektur beim Providerwechsel konsistent. Ein Wechsel des Identity Providers oder der Plattform ändert Konfiguration und Integrationspunkte, aber nicht die grundlegende Security-Logik der Anwendung.
• Auditierbarkeit: Telemetrie und Security-Events lassen sich in evidenzfähige Reports überführen, die SOV‑7-Nachweise praktisch unterstützen – etwa im Kontext von NIS2, DORA oder sektoralen Regulierungen, die ab 2025/2026 schrittweise scharf geschaltet werden.

Security und Compliance werden damit nicht als externes Add-on behandelt, sondern als integrales, portables Architekturmerkmal.

---

Portabilität, Exit-Fähigkeit und die Rolle der 15 Faktoren

Das Cloud Sovereignty Framework fordert ausdrücklich Exit-Fähigkeit und Portabilität – insbesondere in SOV‑4 und SOV‑6. Die 15-Factor App liefert den architektonischen Unterbau, um diese Anforderungen umzusetzen:

• Keine Provider-spezifischen Annahmen im Code
  Konfiguration, Endpunkte und Credentials sind ausgelagert, Provider-spezifische Dienste sind abstrahiert oder durch offene Äquivalente ersetzt.

• Klares Schnittstellen-Design
  API-First und wohldefinierte Service Contracts ermöglichen es, Dienste zu migrieren oder neu zu implementieren, ohne Konsumenten zu brechen.

• Starke Trennung von Build, Release und Run
  Das Build-Artefakt bleibt identisch, egal auf welcher Plattform es später ausgeführt wird; Unterschiede liegen in der Konfiguration und in der angebundenen Infrastruktur.

Damit wird Portabilität nicht mehr als „nice to have“ im Architektur-Review diskutiert, sondern als messbare Eigenschaft:
Wie viele Ihrer Anwendungen könnten Sie heute auf eine andere, souveräne Cloud verschieben, ohne Code zu ändern?

---

Beispiel aus der Praxis: Migration ohne Code-Änderungen

Stellen wir uns ein realitätsnahes Szenario vor:

Ein europäischer Finanzdienstleister betreibt mehrere kritische Anwendungen auf einem großen internationalen Cloud-Provider. Mit Blick auf NIS2 (geltend für wesentliche Einrichtungen seit dem 17. Oktober 2024) und nationale Anforderungen soll ein Teil der Workloads auf einen souveränen EU-Provider verlagert werden, der das Cloud Sovereignty Framework mindestens auf SEAL‑4 erfüllt.

Die Anwendungen sind konsequent nach 15-Factor-Prinzipien gebaut:

• Konfiguration (inklusive aller Secrets und Keys) liegt in der Umgebung.
• Backing Services (Datenbanken, Messaging, Object Storage) werden über standardisierte APIs angesprochen.
• Die Deployment-Pipeline baut ein unveränderliches Artefakt, das auf jedem Kubernetes-Cluster lauffähig ist.
• Telemetrie, Authentifizierung und Autorisierung folgen offenen Standards.

Die Migration verläuft in klaren Schritten:

1. Zielplattform vorbereiten
   Ein souveräner Provider stellt eine kompatible, standardisierte Umgebung bereit – etwa eine Kubernetes-basierte Plattform mit offenen Komponenten für Netzwerk, Storage und Monitoring.

2. Backing Services bereitstellen
   Datenbanken, Object Storage und weitere Services werden auf der Zielplattform bereitgestellt – mit identischen oder kompatiblen Protokollen. Daten werden über offene Formate repliziert oder migriert.

3. Konfiguration anpassen
   Endpunkte, Credentials, Schlüsselmaterial und Regionsangaben werden für die Zielumgebung eingerichtet – ohne Änderung am Anwendungscode.

4. Deployment durchführen
   Das bestehende Build-Artefakt wird auf dem neuen Kubernetes-Cluster ausgerollt. Die Anwendung läuft technisch identisch – nur gegen andere, souverän kontrollierte Backing Services.

5. Schrittweise Umschaltung und Validierung
   Durch Telemetrie und Logging kann das Team präzise verfolgen, ob die neue Umgebung alle Anforderungen erfüllt. Der Traffic wird kontrolliert umgeschwenkt, Rollback-Szenarien sind klar definiert.

Die zentrale Beobachtung:
Die Migrationsarbeit liegt nahezu ausschließlich in Konfiguration, Datenmigration und Plattformaufbau, nicht im Anwendungscode. Genau diese Trennung ist es, die das Cloud Sovereignty Framework als Exit-Fähigkeit fordert – und die 15-Factor App architektonisch absichert.

---

Häufige Fragen

1. Reicht es, wenn mein Cloud-Provider das Cloud Sovereignty Framework erfüllt?

Nein. Ein souveräner Provider ist eine wichtige Voraussetzung, aber keine Garantie dafür, dass Ihre Anwendungen portabel und exit-fähig sind.

Das Cloud Sovereignty Framework bewertet primär den Dienst des Providers entlang der acht SOV-Ziele. Wenn Ihre Architektur jedoch tief in proprietäre Services eingebaut ist, bleibt der Lock-in bestehen – auch auf einer souveränen Plattform.

Die Kombination aus:

• souveräner Infrastruktur und
• 15-Factor-konformen Anwendungen

ist der pragmatische Weg, um sowohl regulatorische Anforderungen als auch technische Portabilität zu erreichen.

2. Müssen wir alle 15 Faktoren „perfekt“ umsetzen, um regulatorisch compliant zu sein?

In der Praxis selten. Entscheidend ist, dass Sie:

• die relevanten Souveränitätsziele (SOV‑3, SOV‑4, SOV‑6, SOV‑7) verstehen,
• diese auf Architekturprinzipien mappen (Config, Backing Services, API-First, Telemetry, Auth),
• und eine konsistente Dokumentation Ihrer Entscheidungen vorlegen können.

Oft ist es sinnvoll, mit einem realistischen Zielbild zu starten:
Welche Anwendungen müssen kurz- bis mittelfristig exit-fähig sein? Wo droht am meisten Lock-in? Darauf aufbauend lassen sich die wichtigsten Faktoren priorisieren – etwa Konfigurationshoheit, Backing Service-Abstraktion und API-First-Design.

3. Wie unterstützt ayedo konkret bei Portabilität und Exit-Fähigkeit?

Wir sehen unsere Rolle darin, beide Welten zusammenzubringen:

• Auf Plattformseite stellen wir eine souveräne, Kubernetes-basierte Umgebung bereit, die auf offenen Standards und Open-Source-Komponenten basiert – ausgelegt auf Konformität mit dem Cloud Sovereignty Framework.
• Auf Anwendungsseite helfen wir, bestehende Workloads entlang der 15-Factor-Prinzipien zu bewerten und Schritt für Schritt zu modernisieren – von Konfigurations-Refactoring bis zur Vereinheitlichung von Backing Services und APIs.

Ziel ist nicht ein theoretisch „perfektes“ Modell, sondern eine konkret erreichbare Portabilität, die auditierbar ist und echte Exit-Optionen eröffnet.

Weitere Fragen? Siehe unsere FAQ

---

Von der Theorie zur Umsetzung

Die Verbindung von Cloud-Souveränität und moderner Software-Architektur ist keine abstrakte Vision, sondern eine sehr konkrete Gestaltungsaufgabe. Das Cloud Sovereignty Framework definiert, welche Ziele erreicht werden müssen. Die 15-Factor App liefert einen erprobten, technischen Rahmen, um diese Ziele in der täglichen Arbeit von Architektur- und Platform-Teams zu verankern.

Wir bei ayedo haben unsere Lösungen bewusst entlang dieser Brücke aufgebaut:

• Unsere souveräne Plattform stellt eine standardisierte, portable Grundlage bereit – auf Basis von Kubernetes, offenen APIs und auditierbaren Open-Source-Komponenten.
• Unsere Packaging- und Delivery-Ansätze orientieren sich strikt an den 15-Factor-Prinzipien: klare Trennung von Code und Konfiguration, Backing Services als austauschbare Ressourcen, API-First, Telemetrie und durchgängige Security.
• In Projekten kombinieren wir technisches Know-how mit regulatorischem Verständnis: Wir übersetzen SOV‑3, SOV‑4, SOV‑6 und SOV‑7 in konkrete Architektur-Guidelines, Migrationspfade und Evidenzen, die Sie gegenüber Aufsicht, Interner Revision und Kunden vertreten können.

Ein zentraler Baustein ist dabei unser Portability Assessment:
Wir analysieren gemeinsam mit Ihrem Team, wie portabel Ihre heutigen Anwendungen wirklich sind, wo versteckte Lock-ins lauern, und welche konkreten Schritte erforderlich sind, um Exit-Fähigkeit im Sinne des Cloud Sovereignty Frameworks zu erreichen – ohne unnötige Replatforming-Großprojekte.

Wenn Sie Portabilität, Souveränität und Compliance nicht getrennt, sondern als ein zusammenhängendes Architekturthema angehen möchten, ist jetzt der richtige Zeitpunkt, den Status quo messbar zu machen.

Portability Assessment