Last updated on
For regulated enterprises building a compliant, digitally sovereign cloud: sovereignty tiers, governance guardrails, and a pre-migration readiness gate.
Classify workloads into a three-tier sovereignty model (sovereignty-mandatory, sovereignty-preferred, flexible) to minimize risk, for example exposure under the US CLOUD Act.
Many organisations treat data sovereignty as a compliance checkbox. That is a mistake. Sovereignty is a strategic decision with profound consequences for provider selection, IT architecture, contract design and competitive positioning.
The core question is not: “Are we GDPR-compliant?” The core question is: “Who has access to our data in an emergency — and can we control that?”
The US CLOUD Act (Clarifying Lawful Overseas Use of Data Act, 2018) empowers US authorities to demand access to data from US companies — regardless of where that data is physically stored.
The Reality: Even if your data sits in a data centre in Frankfurt, a US provider may be legally obliged to hand that data to US authorities.
For organisations in highly regulated sectors this is not a theoretical risk but a concrete compliance and operational bottleneck:
STACKIT (the digital brand of Schwarz Digits, the IT powerhouse of the Schwarz Group) offers a distinct alternative to non-European hyperscalers. It is designed to completely eliminate third-country access risks.
| Characteristic | Significance |
|---|---|
| German company | No US Cloud Act risk — no obligation to disclose to US authorities |
| Data centres in Germany & Austria | GDPR-native data residency, Art. 44 GDPR not a concern |
| Open standards | Built on OpenStack, Kubernetes, Terraform — zero proprietary vendor lock-in |
| Contractual guarantees | DPA per GDPR Art. 28, transparent data processing agreements, and a dedicated Data Protection Cockpit |
| BSI C5 attestation | Demonstrated high-level security controls under the premier German standard |
Transitioning to a sovereign cloud requires a structured roadmap. We guide your organization from initial assessment to fully compliant, continuous operations on STACKIT.
We audit your current IT landscape to identify third-party dependencies, map shadow IT, and classify your existing workloads based on regulatory and organizational needs.
We design hybrid or multi-cloud target architectures using open-source standards. This includes setting up secure zones, planning exit strategies, and ensuring complete interoperability.
We align STACKIT’s native security controls with your specific regulatory frameworks (BSI IT-Grundschutz, ISO 27001, GDPR). We then execute migration playbooks, beginning with low-risk pilots before moving core systems.
We establish sovereign GRC (Governance, Risk, Compliance) automation and lay the groundwork for adopting secure, sovereign AI models hosted entirely within STACKIT’s secure infrastructure.
Not all workloads have the same sovereignty requirements. To avoid over-engineering or unnecessary costs, we classify your applications into three distinct tiers:
Criteria: Regulatory or contractual obligation for local data storage and processing; data that creates severe liability risks if accessed by foreign authorities; sensitive personal data (Art. 9 GDPR).
Examples: Core customer data, health records, financial transactions, TISAX-classified development files, and KRITIS control systems.
Requirement: Exclusively STACKIT (or equivalent sovereign cloud). No deployment on US hyperscalers.
Criteria: No hard regulatory veto, but elevated protection needs. Data that would cause reputational damage or competitive disadvantage if compromised.
Examples: ERP systems, HR databases (without special categories of personal data), internal communication platforms, and proprietary product designs.
Requirement: STACKIT preferred; other secure European providers acceptable. US hyperscalers are not recommended.
Criteria: No personal data, non-sensitive operational data, or public-facing assets where speed and global reach outweigh strict sovereignty.
Examples: Public websites, CDN content, open-source build artifacts, and isolated development sandboxes.
Requirement: Any cloud provider is acceptable.
To determine where your workloads belong, we guide you through five core questions:
Securing your digital sovereignty is an active process. We work alongside your teams to execute these immediate, practical steps:
Establish binding usage policies across the 12 governance domains, with a focus on IAM, key and secrets management, and network security.
The Cloud Governance Policy defines strategic guidelines and principles. The Cloud Usage Policy translates these guidelines into binding, operational requirements — concrete rules that apply to every person and team that provisions, configures, or operates cloud resources.
A usage policy without structured domains is difficult to enforce: it grows into an opaque ruleset that nobody knows completely and that is expanded inconsistently as new requirements emerge. Structuring into twelve domains creates clarity — each requirement belongs to a clear domain, and stakeholders immediately know which domain is responsible for their topic.
Asset management is the foundation of all other governance domains. Those who don’t know which cloud resources exist can neither secure them, operate them cost-efficiently, nor keep them compliant. A complete inventory of all cloud resources is therefore not an optional measure — it is the prerequisite for functioning governance.
Core obligations: every resource is recorded in a central inventory and kept current; every resource has a responsible team or person assigned; all resources follow defined naming conventions; complete tagging per standard is mandatory. Resources without defined owner and without complete tags are by definition non-compliant and must be immediately rectified or removed.
Uncontrolled cloud consumption leads to significant and unexpected costs. Transparent cost allocation and active management are therefore mandatory requirements for all cloud users — not just the FinOps team.
Every resource must be tagged with mandatory cost allocation tags, budget alerts must be configured, maximum spending limits are technically enforced, and unused or orphaned resources must be regularly identified and removed. Resources with significant cost implications — GPU instances, large database clusters — require explicit approval before deployment.
The chargeback and showback principle ensures that cloud costs are transparently allocated to the causing teams. Cost responsibility without cost transparency is ineffective.
Identities and access permissions are the primary attack vector in cloud environments. The IAM domain defines binding requirements for managing user, service, and system identities, and the governance of access rights.
All access rights are assigned exclusively through roles or groups — never directly to individuals. Every person has an individual, identifiable user identity; shared accounts are prohibited. Multi-factor authentication is mandatory for all cloud resources, without exception for privileged accounts. Access occurs exclusively through the central identity provider — local cloud accounts outside the IdP are not permitted. Privileged access is granted time-limited on a just-in-time basis and regularly reviewed.
Cryptographic keys, secrets, and certificates are critical security assets whose improper management can cause severe security incidents. Secrets are stored exclusively in a dedicated platform-provided secret management service — not in source code, configuration files, or version control systems.
System-managed identities are preferred over static credentials. Secrets and cryptographic keys rotate at defined intervals automatically. Certificates are centrally managed with continuously monitored expiration dates. All access to secrets and keys must be comprehensively logged.
The network architecture forms the foundation for secure and controlled communication between cloud resources and external systems. The fundamental principle is deny-by-default: all network traffic is denied by default. Communication is permitted only through explicitly defined rules.
Cloud resources are separated into logically distinct network segments. External access occurs only through defined and controlled entry points. Publicly accessible web services and APIs must be protected by a Web Application Firewall. Network traffic is continuously monitored for anomalies.
All data processed in the cloud must be classified — the classification is the basis for all downstream protection measures. Data may only be stored and processed in approved cloud regions.
All stored data must be encrypted — databases, storage accounts, and backups without exception. Production data must not be used in non-production environments — synthetic or anonymised datasets must be used instead. Sensitive data must be masked in logs, outputs, and interfaces. Cloud workloads processing personal data must be recorded in the processing activities register.
Vulnerabilities in cloud resources, dependencies, and configurations represent a continuous security risk. All cloud resources are regularly and automatically scanned for vulnerabilities. Identified vulnerabilities are classified and prioritised by CVSS.
Binding remediation deadlines by severity: Critical vulnerabilities (CVSS 9.0–10.0) must be remediated within 72 hours. High vulnerabilities (CVSS 7.0–8.9) within 14 days. Medium vulnerabilities (CVSS 4.0–6.9) within 30 days. Low vulnerabilities in the next regular patch cycle. Container and VM images with critical or high vulnerabilities must not be deployed to production environments.
Continuous monitoring of all cloud resources is essential for early detection of security incidents, misconfigurations, and anomalous behaviour. All cloud resources and workloads must be logged — disabling logging capabilities is not permitted.
Logs are centrally collected and stored — decentralised or isolated log storage is not permitted. Logs must be stored in a tamper-resistant manner. Security-relevant logs must be retained for at least 12 months. Automated alerts must be configured for security-relevant events.
A documented incident response plan for cloud environments is mandatory. Security incidents must be classified, prioritised, and handled according to defined procedures. Critical security incidents require notification of the Cloud Team within 4 hours.
All incidents are fully documented — including causes, impacts, and measures taken. After every significant incident, a structured post-incident review with documented lessons learned must be conducted. Forensic investigability of incidents must be ensured through sufficient log retention and incident documentation.
Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) must be defined for critical applications. These values are the foundation for backup strategy and disaster recovery architecture — without them, no appropriate recovery design can be created.
Backup concepts must meet the defined RPO requirements. Disaster recovery plans must be regularly tested — untested plans are not a safety guarantee. Dependencies between systems must be identified and considered in recovery planning.
All cloud infrastructure must be defined as code and versioned. Manual configuration changes to production resources are not permitted — all changes occur through the defined IaC process. Configuration changes undergo a formal review and approval process.
Configuration deviations (drift) between the desired and actual state must be automatically detected. All configuration changes are versioned and traceable.
All cloud resources must be hardened according to defined security baselines. Platform-provided security services — endpoint protection, vulnerability scanning, log collection — must be activated on all resources. Non-compliant resources must be identified, remediated, or removed.
The defense-in-depth principle is mandatory: multiple, independent security layers rather than a single measure. Security assessments for cloud environments are conducted regularly and upon significant architecture changes.
The twelve domains are not equal in their risk potential. IAM, KSM, and NET form the security-critical core — violations in these domains can cause direct security incidents with significant damage potential. AST and FIN form the governance foundation — without complete inventory and cost transparency, none of the other domains can be effectively enforced.
The CCoE is responsible for maintaining, communicating, and enforcing the usage policy. Regular reviews — at least annually — ensure the policy remains current and accounts for new cloud services and risks.
Translate security, financial, and operational guardrails into technical controls, including hard-mandatory guardrails such as exclusive data residency in Germany.
Cloud governance rests on three equally important pillars. Weakness in any one pillar destabilises the entire framework.
The three pillars form an equilateral triangle: Security Governance stands at the apex, Financial Governance and Operational Governance form the base. Weakness in one pillar destabilises the whole framework — an organisation that operates only Security Governance loses cost control and operational stability; one that focuses only on Operational Governance opens security gaps and budget risk.
Purpose: Ensure that cloud resources introduce no security vulnerabilities, that regulatory requirements are met, and that compliance is demonstrable.
| Guardrail | Description | Enforcement |
|---|---|---|
| Geographic restriction | Resources only in approved cloud regions within Germany | Hard-Mandatory |
| Encryption at rest | All data resources encrypted (AES-256 minimum) | Hard-Mandatory |
| No public access without allowlist | No unrestricted public endpoints | Hard-Mandatory |
| IAM Least Privilege | No wildcard permissions in production | Hard-Mandatory |
| MFA for all human access | Console and API access with MFA | Hard-Mandatory |
| Immutable audit logs | Logs in a separate, non-deletable logging project | Hard-Mandatory |
| Level | Characteristics |
|---|---|
| Level 1: Reactive | Security problems are fixed after incidents. No preventive controls. |
| Level 2: Preventive | Core guardrails implemented. New resources are compliant. Legacy estate still open. |
| Level 3: Proactive | Continuous compliance monitoring. Automatic detection and alerting on deviations. |
| Level 4: Predictive | Automated remediation. Security reviews in CI/CD. Threat modelling for new architectures. |
Realistic target: Level 3 after 12 months.
Purpose: Ensure that cloud spend is transparent, traceable and within budget.
| Guardrail | Description | Enforcement |
|---|---|---|
| Mandatory tagging (6 tags) | No resource without a complete tag set | Hard-Mandatory (deployment blocked) |
| Budget alerts | Alert at >80 % and >100 % of monthly budget | Automatically configured |
| Anomaly detection | Alert at >20 % daily deviation from 7-day average | Automatically configured |
| Sandbox budget caps | Maximum monthly budget per sandbox project | Hard-Cap (resources stopped) |
| Reserved Instance policy | Baseline workloads must be covered with RIs | Advisory (recommended, not enforced) |
Purpose: Ensure that cloud resources are operated, monitored and maintained to defined standards.
| Guardrail | Description | Enforcement |
|---|---|---|
| IaC mandatory for production | No manual portal configuration in production | Process + audit |
| Backup policy | All production data resources with backup policy | Advisory + compliance scan |
| Monitoring minimum requirements | CPU, memory, disk, error rate for all services | Mandatory for go-live |
| Runbook requirement | Every production service has an incident response runbook | Pre-go-live checklist |
| Patch management | Managed services: automatic. IaaS: within 30 days | Monitoring |
| Poor Governance | Good Governance | |
|---|---|---|
| Security | Security reviews as a one-time gate before go-live | Continuous security as code in every pipeline |
| Financial | Monthly cost shock, unknown cost drivers | Daily visibility, teams own their cloud costs |
| Operational | Incident → chaos, nobody knows who is responsible | Alert → runbook → defined team responds in <30 min |
Follow a structured process for deviations from governance standards, including a formal exception log and C-level escalation paths.
Cloud governance only works when it is clear who carries which responsibility. A common mistake is to divide responsibility only between “cloud provider” and “us.” In practice, a more precise distinction is needed across three layers — because within the organisation, not all parties are equally responsible.
Cloud Service Provider (CSP)
The provider delivers the technical foundation: data centres, hardware, network infrastructure, virtualisation, and access to cloud services via APIs and portals. The provider’s responsibility ends where the organisation consumes the provided services.
Cloud Team (CCoE + Platform Team)
The internal Cloud Team is responsible for governance, standards, security requirements, and the technical platform. It does not protect individual applications — it sets the framework within which application teams can work securely. Without this framework, uncontrolled growth results.
Application Teams
The teams building and operating applications are responsible for correctly using the provided platform. They decide on deployments, configurations, and the operation of their workloads — within the boundaries set by the Cloud Team.
The critical insight: “The provider is secure” does not mean that your resources at the provider are securely configured. A misconfigured IAM policy, a publicly accessible storage bucket, a container without a security context — that is the responsibility of the application team, not the provider. The Cloud Team sets the guardrails that detect or prevent such errors.
Within the Cloud Team there is a further important distinction that is frequently blurred in practice, leading to friction.
The Cloud Center of Excellence (CCoE) is responsible for governance and standards — it defines what applies: policies, security requirements, compliance controls, cost management, the service catalogue. It answers the question: “What must and may the cloud look like?” The CCoE advises application teams, establishes guardrails, and monitors compliance.
The Cloud Platform Team is responsible for technical implementation and operations — it implements how: Landing Zone, network infrastructure, automation, self-service platforms, monitoring of platform components. It answers the question: “How is what the CCoE has defined technically realised?”
This separation prevents governance decisions from being silently replaced by technical implementation decisions — and conversely, governance becoming a paper tiger because nobody implements it.
Guardrails are not perfect for every situation. There will be legitimate cases where a team must deviate from a standard. Exception management is the structured process for this.
| Category | Example | Approval level | Maximum duration |
|---|---|---|---|
| Technical necessity | App requires a public IP for operational reasons | CCoE | 90 days, then review |
| Migration phase | Legacy system cannot support encryption in the short term | CCoE | 30 days, then escalation |
| Compliance exception | Regulatory requirement conflicts with technical standard | CISO + CCoE | 12 months, then review |
| Architecture deviation | New technology does not fit standard pattern | CCoE + Architect | 90 days, then standardisation |
The exception process follows five steps: the team requests the exception with justification and planned duration (Request). The CCoE reviews within 2 business days — is the deviation acceptable or must an alternative be found? (Review). On a positive decision, the team completes an exception form: description of the standard, justification for the deviation, risk assessment, mitigation measures, duration and review date — signed by the CCoE Lead, for security exceptions additionally by the CISO (Approval). The exception is documented in the exception log, a calendar reminder is set, and it is listed monthly in the governance report (Monitoring). At the review date, the CCoE decides: close the exception and implement the standard, or request an extension — with CCoE escalation to ensure exceptions do not silently become permanent (Review / Extension).
The CCoE maintains a running exception log — visible to CIO, CISO and Cloud Strategy Board:
| ID | Resource/Workload | Deviated standard | Justification | Duration | Approved by | Status |
|---|---|---|---|---|---|---|
| EXC-001 | payment-service | Public IP | Payment gateway API requires fixed IP | 90 days | CCoE Lead | Active |
| EXC-002 | legacy-erp | Encryption at rest | Migration underway, alternative encryption activated | 30 days | CCoE + CISO | Active |
| EXC-003 | dev-sandbox | Geo-guardrail | Testing with EU partner infrastructure | 14 days | CCoE Lead | Closed |
| Situation | Escalate to |
|---|---|
| Team not following standard, no request submitted | CCoE escalates to the team’s management |
| Exception request rejected, team appeals | CCoE Lead → CIO |
| Compliance finding from external audit | CISO → Cloud Strategy Board |
| Governance conflict between teams | CCoE mediates, CIO decides on escalation |
| Critical security exception requirement | CISO informed immediately, decision with four-eyes principle |
Quarterly, the CCoE delivers a governance report to the Cloud Strategy Board:
Complete a final governance readiness check, evidence of active guardrails, CISO sign-off, and DPO involvement, before migration begins.
The Adoption phase must not start until all five dimensions have reached the “Ready” level. One dimension at “Not ready” is a go/no-go criterion — not an optional point.
| Check point | Ready criterion | Status check |
|---|---|---|
| STACKIT account structure | Organisation → folders → projects defined and created | STACKIT Resource Manager API |
| IAM baseline | Roles, groups, IDP federation configured | IAM audit |
| Network design | VPC design, hub-and-spoke concept complete, CIDR plan | Architecture document |
| Base toolchain | Terraform + STACKIT provider tested, Git workflow defined | Deployment test |
| Core guardrails | At least 5 core guardrails implemented and tested | Guardrail test protocol |
| Observability foundation | Central logging configured, test alert successful | Alert test protocol |
Ready threshold: All 6 points met — no partial credit.
| Check point | Ready criterion |
|---|---|
| Onboarding process | Defined process for new workloads and teams documented |
| Change management | Standard change types for cloud operations defined and aligned with ITIL |
| Incident response | Runbooks created for at least 5 common cloud incident types |
| Backup & recovery | RPO/RTO requirements defined, backup policy implemented and tested |
| Exception process | Guardrail exception process documented and communicated |
Ready threshold: 4 of 5 points met (1 in progress acceptable).
| Check point | Ready criterion |
|---|---|
| CCoE fully staffed | At least 4 FTE active and operational |
| Track A training running | Started for all IT employees |
| First Track C cohort | At least 2 Platform Engineers with Track C completion or in training |
| Cloud Champions network | At least 50 % of teams have a nominated Champion |
| On-call rotation | First on-call rotation for landing zone operations established |
Ready threshold: 4 of 5 points met.
| Check point | Ready criterion |
|---|---|
| Annual cloud budget approved | Signed budget release for Adoption phase available |
| FinOps process established | Tagging standard defined, first showback reports configured |
| Business case tracking | Mechanism for measuring ROI against business case defined |
| OPEX budget adjusted | IT budget process adapted for cloud OPEX spend |
Ready threshold: All 4 points met — budget release is non-negotiable.
| Check point | Ready criterion |
|---|---|
| Core guardrails active | At least 5 hard-mandatory guardrails implemented and tested in production |
| CISO sign-off | Formal CISO approval of the cloud security architecture |
| Compliance framework | GDPR/industry-specific requirements documented and mapped |
| DPO engagement | Data Protection Officer informed about cloud architecture and in agreement |
| Governance reporting | CCoE quarterly reporting template created and agreed with Board |
Ready threshold: All 5 points met — compliance is non-negotiable.
The CCoE produces a readiness scorecard 4 weeks before the planned approval event:
| Dimension | Status | Open items | Responsible | Target date |
|---|---|---|---|---|
| Technical | 🟢 Ready | – | – | – |
| Process | 🟡 4/5 | Incident runbooks missing | Platform Team | [Date] |
| Personnel | 🟢 Ready | – | – | – |
| Financial | 🟢 Ready | – | – | – |
| Governance | 🟡 4/5 | DPO sign-off pending | CCoE Lead | [Date] |
Traffic light logic: 🟢 Ready | 🟡 In progress (ready by approval date) | 🔴 Not ready (approval postponed)