Practical guide 03 / 05
Sovereign cloud for government is more than a data-centre location. It should enable secure use while preserving the organisation’s ability to control data, operate the service and make a realistic decision to change providers later.
The practical answer: assess the workload before the platform
Take one service and evaluate its protection needs, dependencies, recovery requirements and exit conditions. Only then compare operating models. A familiar assurance label does not establish suitability by itself. The BSI explains that C5 attestation is not BSI certification and is not sufficient on its own to meet every requirement of its external-cloud minimum standard. [1]
The dependency becomes visible at renewal
Consider a service that works well until its contract approaches expiry. No one has tested a complete export, and only the existing supplier understands deployment. An alternative appears technically possible, but the organisation cannot estimate the transition reliably.
That is the difference between a documented intention to switch and an actual capability. Cloud sovereignty should be expressed as evidence of control and viable options, not as a product label.
Where public-sector cloud lock-in develops
The container moves; the surrounding services do not
An application may use standard containers while depending on proprietary databases, identity services and workflow engines. Inspect the whole dependency chain. Moving the container to another Kubernetes cluster is of limited value if essential services outside the cluster cannot be replaced.
A data export is not a working application
Downloaded files do not recreate a complete service. Relationships, versions, permissions, key dependencies and retention metadata may be essential. Export duration, available bandwidth and transfer fees also affect the transition. Test these properties with a representative dataset rather than assuming that an export button proves portability.
Key control is described too broadly
Customer-controlled keys can limit certain access paths. Whether a provider can access plaintext also depends on processing, permissions and the operating model. BYOK and HYOK are therefore not universal proof that provider access is impossible. The meaningful evidence is an explicit account of data processing and key flows.
Assessment question: For one critical service, can the organisation identify who may read data, change identities, deploy software and restore the system? If those answers are unclear, start there.
The target: reliable primary operations with a realistic exit
Separate data, identity and operating dependencies
Define export formats and required metadata. Document roles and machine identities, not only named users. Authentication standards can ease integration, but they do not guarantee that a replacement service interprets roles and groups in the same way. Test the mapping and its business effects.
Control access to resources, not just network segments
A private connection does not replace authorisation. NIST describes Zero Trust as a resource-focused approach that does not grant implicit trust solely because of network location. [2] In practice, the target design needs bounded privileges, reviewable approvals and controls over administrative access.
Make operations reproducible and transferable
Keep infrastructure definitions, configuration, build artefacts, monitoring and recovery instructions in a controlled handover package. Infrastructure as code is not automatically provider-independent: proprietary modules can retain significant lock-in. Record what can be reused and what must be reimplemented during a move.
A primary platform with a tested transition path may be more appropriate than maintaining two complete platforms continuously. Multi-cloud is an option, not the objective. Decide from service impact, costs, team capability and actual continuity requirements.
How to run a credible cloud exit exercise
1. Define the scenario precisely
A planned migration before contract expiry differs from sudden provider unavailability. Specify the alternative environment, data scope, tolerable interruption and whether the original provider is assumed to remain available. Otherwise, the exercise can demonstrate a capability that does not match the scenario leadership has in mind.
2. Export and reconcile
Check records, attachments, references and access rules. Measure transfer time and remediation work. Log discrepancies and review them with the business owner. The target test environment needs appropriate protection: an exit exercise is not permission to copy sensitive information into an uncontrolled environment.
3. Rebuild on an alternative target
Use documented artefacts and instructions. Reissue or rotate credentials through a controlled process, and verify certificates, name resolution and interfaces. Run business reference tests and a defined load test. Record which steps can be completed without intervention from the incumbent operator.
4. Turn findings into a decision
The useful output is a register of transition obstacles, owners, remediation options and effort. It can inform contract requirements and the next modernisation phase. This is more actionable than a generic sovereignty score that hides assumptions behind a single number.
Keep the objectives distinct: recovery time and tolerated data loss describe continuity requirements. They are not automatically the delivery deadlines for a complete provider exit. Both need explicit assumptions, tests and acceptance.
Combine C5 evidence, lifecycle cost and procurement
Read a C5 report in relation to its service scope, review period, findings and responsibilities retained by the customer. The BSI provides a guide for evaluating these reports. [3] A logo in a sales deck does not replace this review. Nor does an attestation independently establish the lawfulness of every data-processing scenario or complete technological sovereignty.
Price the transition as well as the platform
Lifecycle cost includes infrastructure, operating staff, licences, networking, backup, assurance and eventual transition. A lower monthly service price can come with substantial integration and exit work. Compare like-for-like scenarios rather than collapsing different responsibilities into one monthly figure.
Illustrative example: a transition requires 30 person-days of adaptation and ten days of testing. That is 40 person-days before parallel operations and data-transfer charges. A successful file export alone would expose only part of this effort. This is a planning illustration, not a project estimate.
A bounded starting point with Insight42
Review a critical workload before its next migration or contract renewal. Insight42 lists a Sovereign Cloud Assessment within its published services. [4] A useful engagement can combine a data-flow model, dependency register, review of operating evidence and an executable exit-test plan. Agree the scope, depth and deliverables before commissioning.
Contact: support@insight42.com. Identify the service, current operating model and upcoming decision. General descriptions are sufficient for an initial discussion; do not send credentials or confidential architecture material.
Frequently asked questions about sovereign cloud
Is a German data centre sufficient?
No. Location does not fully explain administrative access, subcontractor involvement or whether applications and data remain transferable. Those questions must be answered for the specific service and contractual arrangement.
Is Kubernetes required?
No. A well-documented virtual machine may be more appropriate for a small, stable service. Kubernetes makes sense where its orchestration and automation benefits justify the operational overhead. Choose the platform from the workload, not the reverse.
Is C5 a BSI certification?
No. The BSI distinguishes independent C5 attestation from BSI certification. Assess the specific report and your organisation’s requirements instead of treating an attestation as a blanket approval. [1]
Must we operate two clouds continuously?
Not necessarily. Depending on the objective, a tested recovery option or exit path may be sufficient. Continuous parallel operation is justified only where concrete requirements warrant the additional complexity and cost.
The takeaway: Good cloud procurement does not stop at onboarding. It also creates the technical and organisational conditions for a future transition.
Sources and technical references
[1] BSI: FAQ zum Mindeststandard Externe Cloud-Dienste
[2] NIST: SP 800-207, Zero Trust Architecture
[3] BSI: Auswertungsleitfaden für C5-Prüfberichte
[4] Insight42: Souveräne Cloud Beratung
Sources checked: 27 September 2026. Calculations and diagrams are illustrative.