Sovereign Cloud
Sovereign cloud, assessed honestly and built properly
We tell you which of your workloads actually need to move, what it would cost, and how fast you could exit. Then we build the target environment to a standard that survives an audit.
The problem
Sovereignty is now a procurement question, and it needs a workload-level answer
The conversation has moved. European procurement now scores sovereignty against defined objectives rather than accepting assurances. NIS2 and DORA are in force. Customers, regulators, and boards are asking questions that an architecture diagram cannot answer: where does this data actually reside, who can technically access it, what happens if this provider relationship becomes unavailable, and how long would it take us to move.
Two failure modes are common, and they are opposites.
The first is answering with a contract. Provider commitments, regional configuration, and a data processing agreement are necessary and are not the same as sovereignty. If the technical dependencies make a move a three-year programme, the exit clause is decorative.
The second is over-reacting: a blanket migration mandate applied to workloads that never needed it, which costs a great deal, delivers little regulatory relief, and burns the organizational goodwill you will need for the workloads that genuinely do have to move.
Both come from the same gap: no workload-level analysis.
What we do
What we do
We assess at workload level
Not a policy position, a classified inventory. Which workloads carry which regulatory exposure, what their actual technical dependencies are, what a move would take, and where the answer is that they should stay. The workloads that should stay are as important an output as the ones that should move.
We analyze exit, technically
The question DORA-scope organizations need answered, and the one generic sovereignty advice never touches: not whether there is an exit clause, but how long an exit would actually take, given the managed services, proprietary APIs, identity constructs, key management, and data gravity that are in your architecture right now. Named per dependency, rated for portability.
We build the target
Landing zones on European sovereign infrastructure: tenancy, network, identity, key management, policy as code, observability, audit, and a Kubernetes runtime foundation where container workloads are in scope. Automated, reproducible, and evidenced against the controls that drove them.
We migrate
Workload migration in waves, sequenced so the workloads that give you the most regulatory relief for the least effort go first.
We operate, if you want us to
Day-2 operations with a European delivery model where your requirements demand one.
Our offerings
How we engage
Sovereignty readiness assessment
Workload classification, gap analysis, dependency and exit-readiness analysis, target options, and a costed roadmap.
Outcome
A defensible answer to the sovereignty question, at workload level.
Target architecture and provider selection
Independent evaluation of European sovereign targets against your specific requirements.
Outcome
A decision you can justify, made on evidence rather than on a relationship.
Sovereign landing zone
The automated, governed foundation: tenancy, network, identity, keys, policy, observability, audit, runtime.
Outcome
A production-ready target with a compliance evidence pack.
Migration delivery
Wave planning and execution, including re-platforming where managed service dependencies require it.
Outcome
Workloads moved, with the regulatory relief documented.
Exit readiness and portability engineering
For organizations staying where they are but required to demonstrate portability.
Outcome
An exit position that is tested rather than asserted.
Sovereign platform operations
Day-2 operations under a delivery model that meets your residency and personnel requirements.
Outcome
A compliant environment that stays compliant.
How we work
Our consulting approach
We are independent, and this is structural
We do not resell cloud services and we hold no volume commitments with any provider. We hold partnerships, including with STACKIT, because partnerships give us engineering access, not because they give us margin on your consumption. When the analysis says a workload should stay where it is, that is what we will tell you.
We work to the objectives, not to the slogan
European procurement now assesses sovereignty against defined objectives: data residency and jurisdiction, operational sovereignty and personnel access, technical control and key custody, supply chain, transparency, portability and exit, resilience, and open standards. We assess against that structure because it is the vocabulary your tenders, auditors, and board will use.
We are precise about what is required and what is emerging
The EU Cloud Sovereignty Framework is binding for European institutional procurement and is being adopted as a reference model more widely. It is not, today, a general legal obligation on private enterprises. We will not tell you otherwise to accelerate a decision, and we would suggest treating any supplier who does with caution.
We build the exit at design time
Every landing zone we build ships with exit path documentation for each component, maintained rather than written once. Building the exit later means building it under pressure.
We produce evidence, not claims
Every control we implement is mapped to the obligation that drove it, with implementation evidence. An auditor assesses evidence; we make sure you have some.
What you get
Your measurable outcomes
From an assessment
Workload classification and sovereignty gap matrix
Dependency register with portability ratings, named per dependency
Exit-readiness analysis with realistic time and effort ranges
Target architecture options with the trade-offs stated plainly
Costed, sequenced migration roadmap
Regulatory mapping: NIS2, DORA, GDPR, EU Data Act, EU AI Act where in scope
A board-ready executive presentation
From a build
Landing zone design with full control mapping
The running environment in your sovereign tenancy
All infrastructure and policy as code, in your repositories
Compliance evidence pack
Exit path documentation
Operator runbook and enablement
Where this sits in the stack
The substrate everything else inherits
Sovereignty decided late is expensive, because every layer above it inherits its constraints. A developer platform built without a view on where it will run has to be rebuilt when the workloads move. An AI platform built on the assumption that data can leave the jurisdiction cannot be deployed when it turns out that it cannot.
This is why we build the substrate and the layers above it as one architecture.
Packaged offers
Start with a defined step
4 weeks
Cloud Sovereignty Readiness Assessment
Four weeks to a clear, evidence-based answer: which of your workloads meet European sovereignty requirements, which do not, what it would cost to move them, and how fast you could exit if you had to.
10 weeks
Sovereign Cloud Landing Zone
A production-ready, compliant, fully automated foundation on a European sovereign cloud, in ten weeks, ready to receive your workloads.
FAQ
Questions we get asked
Do we actually have to move off our current provider?
Frequently not, or not for most workloads. The useful question is which specific workloads carry which specific exposure. Blanket migration mandates are expensive and usually deliver less regulatory relief than a targeted move of the 10 to 20 percent of workloads that carry the real exposure. Our assessment is designed to find that subset.
What does a sovereign target cost compared to what we run now?
Run cost is usually comparable and sometimes lower. The real cost is in migration and in re-platforming where you depend on managed services that have no equivalent. That is exactly what the dependency analysis quantifies, and it is why we model migration cost separately from run cost.
Is the EU Cloud Sovereignty Framework mandatory for us?
It is binding for European institutional procurement and is increasingly used as the reference model in national and sectoral tenders. For most private enterprises it is not a direct legal obligation today. It is, however, the clearest shared vocabulary available, which is why we assess against it even for clients with no procurement exposure to it.
Which sovereign provider do you recommend?
It depends on the workload class, and we will not answer it before the analysis. We work across European sovereign providers and across the sovereign offerings of the major providers. Since we take no margin on your consumption, we have no reason to prefer one.
Can you support us in a tender response?
Yes. We support bid teams on the technical sovereignty sections, including control mapping and evidence. Contact us early, because the evidence is much easier to assemble before the deadline than during the final week.
What is driving the question?
A tender requirement, a regulatory obligation, a customer commitment, and a board mandate all lead to different answers. Tell us which one you are dealing with and we will tell you what a sensible first step looks like.