Cloud Sovereignty + 15 Factor App: The Architectural Bridge Between Law and Technology

TL;DR

• The Cloud Sovereignty Framework of the EU defines what digital sovereignty aims to achieve – the 15-Factor App principles define how a concrete application architecture implements these goals technically.
• SOV‑3 (Data & AI) becomes operationally tangible when configuration (including encryption keys) is completely decoupled from the code and managed as a BYOK setup in standardized environments – in line with Factor 3 “Config”.
• SOV‑4 (Operational), SOV‑6 (Technology), and SOV‑7 (Security) can be directly mapped to modern architectural principles: Backing Services, API-First, Open Source, Telemetry, and comprehensive authentication make portability, exit capability, and auditability built-in features.
• A 15-Factor-compliant application can be migrated between cloud providers without changing the application code – configuration, APIs, and infrastructure abstractions bear the migration load. This precisely matches the exit capability demanded by the Cloud Sovereignty Framework.
• ayedo combines sovereign infrastructure according to the Cloud Sovereignty Framework with 15-Factor-based application packaging. With our Portability Assessment, we make visible how portable your applications are today – and how you can meet regulatory requirements architecturally cleanly.

Why Cloud Sovereignty is an Architectural Issue

Regulatory requirements are no longer purely a legal issue. Since the EU Commission published version 1.2.1 of the Cloud Sovereignty Framework in October 2025, it has become clear: Anyone who wants to procure or offer sovereign cloud services needs comprehensible technical answers.

At the same time, many technical managers face a practical question:
How do I translate requirements like “exit capability,” “customer key sovereignty,” or “open standards” into architectural decisions that my team can actually implement?

This is where two worlds meet:

• The Cloud Sovereignty Framework formulates sovereignty goals (SOV‑1 to SOV‑8) and provides clarity for procurement and audits.
• The 15-Factor App formulates architectural principles for cloud-native applications, making portability, security, and transparency structural properties of the software.

Together, both frameworks form a bridge between law and technology: Sovereignty goals as the “what,” 15-Factor as the “how.”

Two Frameworks, One Common Language

Cloud Sovereignty Framework: Goals and Evidence

The Cloud Sovereignty Framework defines eight sovereignty goals, from strategic and legal anchoring (SOV‑1, SOV‑2) to technical and operational aspects (SOV‑3 to SOV‑7) and sustainability (SOV‑8).

For architects and engineering managers, four goals are particularly relevant:

• SOV‑3: Data & AI Sovereignty
  Customer key sovereignty, data localization, auditable access, verifiable deletions, control over AI models and pipelines.

• SOV‑4: Operational Sovereignty
  Exit capability, EU-based operations, complete documentation and source transparency, control over subcontractors.

• SOV‑6: Technology Sovereignty
  Open standards, non-proprietary APIs, open-source accessibility, architectural transparency, and portability.

• SOV‑7: Security & Compliance Sovereignty
  EU-based security operations, comprehensive log access, EU-compliant incident reporting, independent audits.

These goals are deliberately technology-neutral – the framework does not prescribe which stack you should choose. However, it requires you to make technical decisions in a way that these goals can be comprehensibly achieved.

15-Factor App: Architectural Principles for Portability

The 15-Factor App extends the well-known 12-Factor principles with three modern requirements:

• Factor 13 – API First
  Consistent, clearly defined APIs as the primary interface – ideally with open standards like OpenAPI.

• Factor 14 – Telemetry
  Observability through metrics, logs, and traces as an integral part of the application.

• Factor 15 – Authentication & Authorization
  Security as a cross-cutting function – from transport encryption via OAuth2/OIDC to fine-grained RBAC.

Together, the 15 factors ensure that applications:

• function independently of the underlying cloud provider,
• have clearly recognizable interfaces to backing services,
• strictly separate configuration and secrets from code,
• and depict security and compliance requirements as structural properties.

Thus, they provide exactly the technical “grammar” to translate sovereignty goals into concrete architectural and design decisions.

SOV‑3 and Factor 3: Data Sovereignty Through Configuration Sovereignty

SOV‑3: Data & AI Sovereignty demands, among other things:

• Customer key sovereignty (BYOK / HSM),
• seamless access logging,
• strict data localization,
• transparent, auditable AI pipelines.

At the architectural level, this is closely linked to Factor 3 – Config:
Configuration – including all security-critical parameters – belongs in the environment, not in the code. This may sound trivial, but it is the foundation for data sovereignty.

In a sovereign, 15-Factor-oriented setup, this means:

• Encryption and signature keys are under the control of the customer side (Bring Your Own Key), but are integrated into the application exclusively through configuration. The application code “knows” only abstractions – such as a key provider or a KMS API.
• Data localization is a property of the platform and configuration (e.g., selection of the storage backend, region, cluster location), not hard-coded.
• AI models and pipelines are modeled so that storage locations, parameters, and data paths can be fully controlled via configuration.

The interplay of SOV‑3 and Factor 3 leads to a central architectural principle:
The application is data-sovereign because it can be operated at any time with different keys, different storage endpoints, and different regions – without code changes. Thus, the switch from cloud provider A to a sovereign provider B becomes technically manageable and legally defensible.

SOV‑4, Factor 4 and 13: Exit Capability as a Design Goal

SOV‑4: Operational Sovereignty demands exit and migration capability without lock-in. This is not just a contractual or process issue but a direct consequence of application and platform architecture.

The 15-Factor App addresses this with at least two factors:

• Factor 4 – Backing Services
  Every external resource (database, messaging, object storage, AI service) is considered an interchangeable resource referenced through configuration.

• Factor 13 – API First
  The design of public and internal interfaces follows open, documented standards and is not tied to proprietary platform specifics.

Specifically, this means for exit capability:

1. Service Exchange Without Code Changes
   If an application accesses its database, object storage, or message bus only through configuration and standardized drivers, the underlying service can be switched without needing to adjust the application code.

2. API Stability as a Contractual Basis
   An API-first approach ensures that both internal components and external consumers rely on well-defined contracts. When switching providers, the API structure remains stable; only the target endpoint or the infrastructure behind it changes.

3. Documented Exit Runbooks
   SOV‑4 demands explicit exit processes. In a 15-Factor architecture, these processes can be largely standardized: export data via open formats, reconfigure endpoints, reinitialize on the target platform.

Thus, an abstract demand of the Cloud Sovereignty Framework becomes a very concrete architectural decision:
Strictly abstract backing services, standardize APIs – then exit capability is not project chaos but a planned, testable process.

SOV‑6, Factor 13 and 2: Technology Sovereignty Through Open APIs and Open Source

SOV‑6: Technology Sovereignty demands, among other things:

• non-proprietary APIs and protocols,
• open-source accessibility (audit, modification, redistribution),
• architectural transparency and minimal lock-ins.

This can be directly linked to two 15-Factor principles:

• Factor 13 – API First
  A consistent API-first strategy forces the team to decide early: Do we bind ourselves to proprietary special APIs of a hyperscaler, or do we use open standards that other providers also offer?

• Factor 2 – Dependencies
  Dependencies are explicitly declared and preferably resolved through open, standardized ecosystems (e.g., CNCF projects, established open-source components).

From SOV‑6, several guidelines for architecture emerge:

• Prefer open-source components that are auditable and, if necessary, self-hosted; this reduces structural dependencies.
• Choose standardized APIs, such as S3-compatible object storage, OIDC for identity, common message bus protocols – instead of using proprietary special services.
• Ensure transparency by documenting architecture, data flows, and dependencies and making them available as verifiable evidence for audits.

With such an architecture, you can argue in a regulatory-compliant manner that your technology decisions take the sovereignty claim seriously – without stifling innovation.

SOV‑7, Factor 15 and 14: Security & Compliance as a Cross-Cutting Feature

SOV‑7: Security & Compliance Sovereignty demands:

• EU-based security operations and incident response,
• full access to logs and alerts,
• EU-compliant incident reporting and independent audits.

At the application level, two 15-Factor principles are central here:

• Factor 14 – Telemetry
  The application delivers all relevant metrics, logs, and traces by itself – in a format that enables provider-independent evaluation.

• Factor 15 – Authentication & Authorization
  Security mechanisms are an integral part of the application – with standardized protocols like TLS, OAuth2, OIDC, and role-based authorization.

In combination with a sovereign platform, several advantages arise:

• Log and Metric Control: If applications deliver their telemetry via open protocols (e.g., standardized logging formats, established metric protocols), operators can collect and evaluate logs in an EU-controlled toolchain – independent of the original cloud provider.
• Security Portability: By using standardized authentication and authorization mechanisms, the security architecture remains consistent when switching providers. A change of identity provider or platform changes configuration and integration points but not the fundamental security logic of the application.
• Auditability: Telemetry and security events can be transformed into evidence-capable reports that practically support SOV‑7 evidence – for example, in the context of NIS2, DORA, or sectoral regulations that will be gradually enforced from 2025/2026.

Security and compliance are thus not treated as external add-ons but as integral, portable architectural features.

Portability, Exit Capability, and the Role of