Most sovereignty debates are still framed as a false binary.
One side argues for strict national isolation. The other argues for full dependence on global hyperscalers. Both positions miss the architecture problem.
For a CTO, digital readiness is not a branding decision. It is a survivability design decision.
If you read my previous sovereignty and capacity pieces, this article is the execution layer.
- Cloud Resource Hoarding: Why Elasticity Breaks Under Capacity Pressure explains why cloud scale depends on long lead-time power, hardware, and logistics pipelines.
- Sovereign Cloud: The History and Why the Model Breaks explains why separate sovereign cloud models failed economically and operationally.
- Sovereign Cloud Is a Buzzword. Control Is the Real Question explains why control objectives matter more than marketing labels.
This post answers the practical question: what do we build now?
The strategic mistake in current sovereignty debates
Most public arguments still treat data location as the core variable.
It is not.
Data location matters for legal and regulatory reasons. Control continuity matters for national and enterprise survival.
A country can keep data local and still lose operational control if identity, management plane dependencies, and update channels are externally coupled with no tested fallback.
This is the critical distinction.
The real CTO question is simple:
How do we use global cloud scale for speed and security, while retaining the ability to operate under degraded geopolitical or provider conditions?
The scale paradox is real
No sentimental framing changes the economics.
A national cloud strategy built for a population of roughly 5.5 million cannot match the feature velocity, security telemetry, and engineering depth of hyperscalers serving global demand.
It also cannot easily replicate hyperscaler procurement and logistics posture. The largest providers pre-buy hardware years ahead, lock supplier capacity through multi-year agreements, and operate global deployment chains that span chips, memory, networking, power infrastructure, and field operations. Cloud Resource Hoarding: Why Elasticity Breaks Under Capacity Pressure details why this is structurally hard to reproduce at national scale.
Threat intelligence is a scale business. Large providers see attack patterns across regions before those patterns hit smaller markets. That detection lead time is practical defense value.
Security investment is also a scale business. The largest providers spend at levels that no single small nation or enterprise coalition can replicate consistently.
Local capacity is not irrelevant. It should be designed as strategic leverage, not as a full replacement fantasy.
In Norway, large infrastructure investments in northern data center capacity have changed the hardware conversation. Figures often cited in public debate include investment projections around 66 billion NOK for the Narvik area. Needs verification.
Even if the exact number changes, the architecture point stands. Hardware presence is not equivalent to sovereignty. Control design is.
The objective shift: from lock-in fear to portability discipline
Most organizations still describe the risk as lock-in.
A better framing is evacuation readiness.
The failure mode is not that you run workloads on a global platform. The failure mode is that you cannot move, rehydrate, or continue critical functions when legal, political, contractual, or technical conditions shift.
Portability is not a slide in a strategy deck. It is measurable engineering capability.
A portable architecture has:
- Open interfaces for core services where substitution risk is high.
- Data export and replay paths tested under time constraints.
- Identity and access failover patterns documented and exercised.
- Management plane dependency mapping with known break points.
- Runbooks that specify who invokes continuity modes and under which triggers.
If these capabilities do not exist, the organization does not have sovereignty. It has optimism.
The 80/20 continuity model
Most enterprises should not optimize for total independence.
They should optimize for continuity under stress.
I prefer an 80/20 operating heuristic:
- Keep roughly 80 percent of workloads on high-scale global platforms to maximize velocity, ecosystem access, and security capabilities.
- Keep roughly 20 percent as core survival services on sovereign-controlled or jurisdiction-assured infrastructure with independent recovery procedures.
The 20 percent is not random.
It includes systems required to keep the state or business alive during a severe disruption window:
- Identity anchors and emergency access controls.
- Priority communication and incident coordination systems.
- Payment, settlement, or critical citizen service pathways.
- Minimal analytics and audit evidence pipelines needed for command decisions.
This is not a cost optimization pattern. It is a continuity architecture pattern.
The Ukraine lesson for architecture teams
One lesson from modern conflict zones is clear. Fixed infrastructure is vulnerable. Portable infrastructure can survive.
No serious architecture should assume data centers are invisible or untouchable. Large facilities are physically discoverable through commercial satellite imagery and open-source mapping, regardless of provider brand.
In escalated conflicts, high-profile foreign-owned facilities can become symbolic or practical targets. The architecture implication is universal and not vendor-specific. Never design continuity around the assumption that physical sites will be left alone.
When physical sites are disrupted, continuity depends on how quickly critical systems can shift operation domains and re-establish trust boundaries.
Treat data as liquid, not solid.
If your architecture requires a specific building, a specific region, or a single control plane to function, your resilience claim is fragile.
If your architecture can relocate stateful services through pre-tested replication, key custody procedures, and identity continuity protocols, your resilience claim is credible.
The minimum viable digital readiness stack
CTOs need a concrete baseline, not another sovereignty slogan.
Start with this minimum stack:
-
Control objective matrix. Define residency, jurisdiction, admin access, telemetry, and continuity objectives separately. Avoid single-axis sovereignty scoring.
-
Tiered workload classification. Label workloads as mission-critical, continuity-critical, regulated-sensitive, and standard. Map each tier to explicit failover requirements.
-
Dual-path identity strategy. Document primary and emergency identity operations. Test loss-of-provider scenarios for high-privilege access workflows.
-
Portable data contracts. Require exportable formats, schema versioning, and replay tooling for continuity-critical systems.
-
Quarterly evacuation drills. Run controlled portability exercises with measured RTO and RPO outcomes.
-
Contracted ceasefire protocol. Pre-negotiate legal, support, and operational triggers for service continuity in geopolitical events.
The phrase matters. Cooperation is a relationship. A ceasefire protocol is an executable mechanism.
What to ask your platform team this quarter
If you want to know whether your organization is digitally ready, ask seven questions.
- Which five services must survive a 72-hour geopolitical disruption, and where is their validated fallback?
- Which dependencies in our control plane sit outside our legal comfort zone?
- Which workloads can be redeployed to an alternate environment within agreed RTO and RPO targets?
- Which data sets are technically exportable today without vendor custom tooling?
- Which emergency access paths still depend on the primary provider identity stack?
- Which runbook has not been exercised in the last two quarters?
- Which executive has clear authority to trigger continuity mode?
An organization that cannot answer these quickly does not have readiness. It has assumptions.
Verdict
The sovereignty debate needs to mature.
Isolation is not realistic for most economies. Blind dependence is not responsible for critical systems.
The winning model is partnership with engineered optionality.
Use global hyperscalers for their scale, security telemetry, and platform velocity. Build your architecture so critical functions can survive if those assumptions fail.
That is digital readiness in 2026.
Not isolation. Not surrender.
Architectural redundancy.
I work at Microsoft. The views expressed here are my own and based solely on publicly available information. This content is for educational purposes and does not represent official Microsoft guidance or commitments.