Comprehensive Risk Register
Honest assessment of risks, alternative approaches, resource feasibility, and programme delivery challenges for sovereign cloud migration.
Critical Self-Assessment Notice
This risk register reflects external review findings and provides honest assessment of challenges. The initiative must acknowledge significant uncertainties in cost, timeline, and resource availability while maintaining that the strategic imperative remains valid.
1. Threat Probability Quantification
Methodological Note
Quantifying geopolitical threat probabilities involves significant uncertainty. The following estimates draw on historical precedent, expert assessment, and scenario analysis. Ranges acknowledge inherent uncertainty in predicting government actions.
Threat Scenario Probability Assessment
| Threat Scenario | 5-Year P | 10-Year P | Basis for Estimate |
|---|---|---|---|
| Complete service termination (AWS/Azure/GCP ordered to cease all services to a jurisdiction) |
2-8% | 5-15% | No historical precedent for allied nations; would require extreme geopolitical rupture. Iran/Russia sanctions provide limited analogy. |
| Selective service degradation (Reduced features, slower response, "compliance issues") |
10-25% | 20-40% | Soft coercion more plausible than hard termination. Huawei equipment restrictions demonstrate selective technology denial. |
| Data access/exfiltration (US government obtains data under CLOUD Act or similar) |
40-70% | 60-85% | CLOUD Act requests already occur. Question is whether they expand to broader government data. Snowden revelations showed existing programmes. |
| Price coercion (Discriminatory pricing, contract terms, or audit requirements) |
15-30% | 25-45% | Commercial leverage is a standard tool. Government contracts often include favourable pricing that could be withdrawn. |
| Feature/service restrictions (AI capabilities, encryption, or security features limited) |
20-35% | 35-55% | Export controls on advanced technology are expanding. AI capabilities likely subject to increasing restrictions. |
Probability Methodology
These estimates use a structured assessment approach:
- Historical base rates: Frequency of similar actions against allies (sanctions, technology restrictions, trade disputes)
- Trend analysis: Direction of US policy toward technology controls and alliance relationships
- Scenario analysis: Plausible triggering events (trade disputes, intelligence concerns, political conflicts)
- Expert elicitation: Synthesised judgment from foreign policy, technology, and security domains
Risk Matrix: Probability × Impact
| Negligible | Minor | Moderate | Major | Catastrophic | |
|---|---|---|---|---|---|
| Almost Certain (>80%) | Medium | High | Critical | Critical | Critical |
| Likely (50-80%) | Low | Medium | High | Critical | Critical |
| Possible (20-50%) | Low | Medium | Medium | High | Critical |
| Unlikely (5-20%) | Low | Low | Medium | Medium | High |
| Rare (<5%) | Low | Low | Low | Medium | Medium |
Assessment: Complete service termination falls in the "Unlikely/Catastrophic" cell (Medium-High priority). Data access/exfiltration falls in "Likely/Major" (Critical priority). This suggests prioritising data sovereignty and encryption controls over emergency migration capability.
2. Alternative Approaches Analysis
Full sovereign cloud migration is one option among several. Decision-makers should understand alternatives before committing to the most resource-intensive approach.
Option Comparison Matrix
| Option | Est. Cost | Timeline | Sovereignty Achieved | Key Limitations |
|---|---|---|---|---|
| A: Full Sovereign Build (This document's primary proposal) |
€8-15B+ (cooperative) |
24 weeks (wartime) 5-7 years (peacetime) |
100% control over infrastructure, data, and operations. No US corporate involvement. | Highest cost and risk. Requires unprecedented multinational coordination. Feature parity gap. |
| B: OCI Dedicated Region (Oracle sovereign deployment) |
€500M-2B (per jurisdiction) |
18-36 months | Physical and operational separation. Staff can be cleared nationals. Hardware on sovereign soil. | US corporate ownership. Potential CLOUD Act exposure. Licensing dependencies. |
| C: Hybrid Classification (Tiered sovereignty by data sensitivity) |
€1-3B (per jurisdiction) |
3-5 years | Critical/classified data on sovereign infrastructure. General workloads remain on US cloud. | Requires robust classification. "Non-critical" data may still be sensitive. Complexity. |
| D: Negotiated Protections (Legal/contractual safeguards) |
€50-200M (legal/compliance) |
1-2 years | Contractual protections, data localisation commitments, audit rights. Limited legal recourse. | Unenforceable against US government action. Paper protection only. No physical control. |
| E: Enhanced Encryption (Technical controls within US cloud) |
€100-500M (implementation) |
1-3 years | Customer-managed encryption keys. Data encrypted at rest and in transit. Provider cannot read data. | Does not protect against service termination. Availability still provider-controlled. Key escrow risks. |
Detailed Option Analysis
Option B: OCI Dedicated Region - Critical Gap Analysis
Why this option warrants serious consideration:
- Oracle offers "Dedicated Region Cloud@Customer" with full OCI stack in customer datacentres
- Staff can be security-cleared nationals with no US personnel access required
- Hardware physically located in sovereign datacentres
- Operational isolation from Oracle corporate network achievable
- Deployment timeline of 18-36 months vs. 24 weeks (wartime) / 5-7 years (peacetime) for full build
Residual risks with OCI approach:
- Oracle Corporation remains US-headquartered and subject to US law
- CLOUD Act may theoretically apply even to isolated deployments
- Licensing and software updates create ongoing dependencies
- Exit from Oracle would require significant migration (vendor lock-in)
- Long-term pricing not guaranteed
Recommendation: OCI Dedicated Region should be evaluated as a potential interim solution or complement to full sovereign build, particularly for jurisdictions needing faster capability or as backup during transition.
Option C: Hybrid Classification Approach
How it works:
- Classify all government data by sensitivity (SECRET, OFFICIAL-SENSITIVE, OFFICIAL, PUBLIC)
- Build sovereign infrastructure only for SECRET and OFFICIAL-SENSITIVE
- Retain US cloud for OFFICIAL and PUBLIC workloads (60-70% of systems)
- Implement strict data flow controls between tiers
Benefits:
- Dramatically reduced scope and cost (70-80% reduction)
- Faster implementation (3-5 years achievable)
- Protects most sensitive data while retaining hyperscaler benefits for bulk workloads
- Aligns with existing security classification frameworks
Challenges:
- Classification is imperfect—"non-sensitive" data may be sensitive in aggregate
- Administrative burden of maintaining classification boundaries
- Does not address economic coercion or general dependency concerns
- Still vulnerable to complete service termination for non-sensitive systems
Recommended Approach: Phased Hybrid Strategy
Recommended Strategy: Pursue a phased approach combining elements of multiple options rather than committing exclusively to full sovereign build:
- Phase 1 (Years 1-3): Implement hybrid classification (Option C) + enhanced encryption (Option E)
- Phase 2 (Years 2-5): Evaluate OCI Dedicated Region (Option B) for rapid sovereign capability
- Phase 3 (Years 3-10): Build open-source sovereign platform for critical workloads (Option A scaled)
- Phase 4 (Years 10-15): Gradual migration of remaining workloads as sovereign platform matures
This approach provides immediate risk reduction while building toward full sovereignty incrementally, reducing the "big bang" risk of the full build approach.
3. OCI Dedicated Region Detailed Assessment
Gap Addressed
External review identified that this framework did not adequately analyse Oracle Cloud Infrastructure's Dedicated Region offering as an alternative or complement to full sovereign build. This section addresses that gap.
OCI Dedicated Region Overview
Oracle's Dedicated Region Cloud@Customer deploys a complete OCI region within customer premises, offering:
| Feature | Standard OCI | Dedicated Region | Full Sovereign Build |
|---|---|---|---|
| Hardware Location | Oracle datacentres | Customer datacentres | Government datacentres |
| Control Plane | Oracle-managed | Isolated, on-premises | Government-operated |
| Staff Clearance | Oracle employees | Can require cleared nationals | Government employees |
| Software Ownership | Oracle licensed | Oracle licensed | Open source |
| Network Isolation | Shared infrastructure | Air-gapped option | Air-gapped |
| Deployment Speed | Hours | 18-36 months | 24 weeks (wartime) 5-7 years (peacetime) |
| CLOUD Act Exposure | Full exposure | Unclear/reduced | None |
Legal Assessment: CLOUD Act and OCI Dedicated Region
Key Question: Does CLOUD Act apply to data in an air-gapped OCI Dedicated Region where hardware is on sovereign soil and Oracle staff have no access?
Legal Analysis: The CLOUD Act requires US companies to provide data "in their possession, custody, or control." For truly air-gapped deployments:
- Oracle may argue data is not in their "possession" if physically and operationally isolated
- However, Oracle owns and licenses the software running the infrastructure
- Software update mechanisms could theoretically provide access vectors
- No court has definitively tested this scenario
Conclusion: OCI Dedicated Region provides significant practical protection but uncertain legal protection. It may be a "good enough" solution for many scenarios while not providing absolute sovereignty.
Recommendation for OCI Evaluation
Each jurisdiction should conduct formal OCI Dedicated Region evaluation including:
- Request detailed technical briefing from Oracle on isolation capabilities
- Obtain independent legal opinion on CLOUD Act exposure for air-gapped deployments
- Negotiate contractual commitments on data access, staff nationality, and termination rights
- Assess total cost of ownership including exit costs
- Evaluate as interim solution while full sovereign capability develops
4. Resource & Capacity Feasibility
Critical Concern
External review challenged whether the proposed staffing of ~630 personnel can build and operate hyperscaler-equivalent services when AWS employs thousands of engineers per service. This section provides honest assessment.
The Scale Challenge
| Comparison Point | US Hyperscalers | Proposed Cooperative | Gap Factor |
|---|---|---|---|
| Total cloud engineering staff (AWS) | ~100,000+ | 630 (proposed) | ~160x |
| Staff per major service | 500-2,000 | 15-30 | ~30-60x |
| Annual R&D investment | $50B+ (AWS alone) | ~€500M-1B | ~50x |
| Services offered | 200+ | 20-30 core services | ~7-10x |
Honest Assessment: Why This Matters
The staffing gap is real and cannot be dismissed. However, several factors mitigate (but do not eliminate) the concern:
- Scope difference: We're not trying to match AWS feature-for-feature. A focused set of 20-30 core services covers 80%+ of government workloads.
- Open source leverage: CloudStack, Kubernetes, MinIO, and other projects are maintained by global communities. We're integrating, not inventing.
- Scale requirements: Government clouds serve millions of users, not billions. Performance and scale requirements are 10-100x lower than public hyperscalers.
- Contractor ecosystem: The 630 figure is core team only. Significant contractor support from systems integrators adds capacity.
BUT: Even with these mitigations, the proposed staffing is optimistic. A more realistic estimate is 1,500-2,500 FTEs for the core programme across all four jurisdictions, with significant additional contractor support.
Revised Staffing Estimate
| Function | Original Estimate | Revised (Realistic) | Notes |
|---|---|---|---|
| Platform Engineering | 150 | 400-600 | CloudStack, Kubernetes, storage, networking, security |
| Service Development | 180 | 400-600 | Database, FaaS, API Gateway, messaging, etc. |
| Operations & SRE | 150 | 300-500 | 24/7 coverage across 4 jurisdictions |
| Security | 75 | 150-250 | SOC, penetration testing, compliance, certification |
| Migration Support | - | 200-400 | Application assessment, migration tooling, support |
| Programme & Governance | 75 | 100-150 | Cross-jurisdiction coordination |
| TOTAL (Core) | 630 | 1,550-2,500 | ~2.5-4x original estimate |
| Contractor/SI Support | Not specified | 1,000-2,000 | Systems integrators, specialist contractors |
Skills Availability Assessment
Even with revised estimates, recruiting 2,000+ cloud specialists across four jurisdictions presents significant challenges:
| Jurisdiction | Est. Cloud Talent Pool | Required (Revised) | % of Pool | Assessment |
|---|---|---|---|---|
| EU-27 | ~150,000 | 800-1,000 | 0.5-0.7% | Achievable |
| UK | ~80,000 | 400-600 | 0.5-0.75% | Achievable |
| Canada | ~40,000 | 200-400 | 0.5-1% | Challenging |
| Australia | ~25,000 | 150-300 | 0.6-1.2% | Challenging |
Key mitigation: Public sector salaries must be competitive. Current 30-50% discount to private sector will not attract required talent. Budget should include market-rate compensation and "golden handcuff" retention mechanisms.
5. Realistic Cost Assessment
Cost Estimate Gap
External review identified that original cost estimates likely understate true costs by 40-100% when accounting for hidden costs, productivity impacts, and realistic contingency.
Hidden Cost Categories
| Cost Category | Original Budget | Hidden/Missing | Notes |
|---|---|---|---|
| Application Refactoring | Underestimated | €500M-2B | Many apps need modification for open-source equivalents. AWS-specific code pervasive. |
| Productivity Loss During Migration | Not included | €200M-1B | Staff time diverted. Learning curves. Service disruptions. Dual-running costs. |
| Training & Change Management | Minimal | €100-300M | Tens of thousands of staff need retraining on new platforms and tools. |
| Contract Termination Penalties | Not included | €200-500M | Early termination fees, committed spend obligations, licensing true-ups. |
| Security Certification | Underestimated | €50-150M | FedRAMP-equivalent, ISO 27001, SOC 2, jurisdiction-specific certifications. |
| Contingency (Industry Standard) | 20% | 40-60% | Novel programme with high uncertainty. UK government recommends 40%+ for complex IT. |
Revised Cost Estimate
| Cost Element | Original Estimate | Revised (Realistic) |
|---|---|---|
| Infrastructure Capital | €3-5B | €4-6B |
| Platform Development | €1-2B | €2-4B |
| Migration & Refactoring | €1-2B | €2-4B |
| Hidden Costs (above) | Not included | €1-4B |
| Contingency (40%) | €1-2B (20%) | €4-7B |
| TOTAL (Cooperative) | €6-11B | €13-25B |
Cost Per Jurisdiction (Revised)
| Jurisdiction | Share | Original Est. | Revised Est. | Per Year (15yr) |
|---|---|---|---|---|
| European Union | 40% | €2.4-4.4B | €5.2-10B | €350-670M |
| United Kingdom | 25% | €1.5-2.75B | €3.25-6.25B | €220-420M |
| Canada | 20% | €1.2-2.2B | €2.6-5B | €175-335M |
| Australia | 15% | €0.9-1.65B | €1.95-3.75B | €130-250M |
Context: For the UK, €220-420M per year represents ~0.02-0.04% of GDP, or approximately the cost of one Type 26 frigate per year. This is significant but not unaffordable for a programme framed as national security infrastructure.
6. Timeline Assessment: Two Distinct Scenarios
SCENARIO A: WARTIME EMERGENCY MOBILISATION
24 WEEKS TO SOVEREIGN CAPABILITY
Trigger: US takes hostile action, threatens service termination, or geopolitical crisis makes continued US cloud dependency an immediate national security threat.
Wartime Emergency Timeline (24 Weeks)
| Phase | Duration | Key Actions |
|---|---|---|
| Phase 1: Emergency Declaration | Week 0-2 | COBRA/crisis activation; emergency procurement powers; datacenter capacity secured; 10,000+ staff mobilised |
| Phase 2: Infrastructure Mobilisation | Week 2-8 | Hardware procurement; existing facilities activated; CloudStack deployment; core networking |
| Phase 3: Critical System Migration | Week 8-16 | Identity/auth, benefits/payments, health systems, tax systems migrated in priority order |
| Phase 4: Operational Capability | Week 16-24 | Full critical services operational; US cloud dependency eliminated for essential government functions |
Why 24 Weeks is Achievable in Wartime
- Emergency procurement: Direct awards, no competitive tendering delays
- Existing capacity: Commandeer existing government/commercial datacenters
- Staff mobilisation: 10,000+ cloud professionals redirected from private sector
- Reduced scope: Critical systems only—not full feature parity
- Parallel execution: All four jurisdictions working simultaneously
- War footing: 24/7 operations, unlimited overtime, emergency budgets
- Historical precedent: COVID-19 showed governments can mobilise rapidly when survival is at stake
See: Emergency Mobilisation Planning Hub for detailed 24-week implementation plans.
SCENARIO B: PEACETIME PLANNED MIGRATION
5-7 YEARS FOR COMPREHENSIVE SOVEREIGNTY
Context: Proactive, planned transition with normal procurement, competitive tendering, full feature development, and orderly migration of all government workloads.
Peacetime Programme Timeline (5-7 Years)
| Phase | Duration | Key Activities |
|---|---|---|
| Phase 0: Political Alignment | 6-12 months | Four-nation agreement; funding approval; governance established |
| Phase 1: Foundation | 12-18 months | Platform architecture; pilot deployments; procurement frameworks |
| Phase 2: Platform Build | 18-24 months | Core services operational; first production workloads; certification |
| Phase 3: Migration Waves | 24-48 months | Systematic migration of government workloads in priority order |
| Phase 4: Complete | 60-84 months | Full capability; all workloads sovereign; US cloud exit complete |
Perplexity Critique Response
External review suggested 10-15 years is more realistic for peacetime migration. This critique has merit for a "business as usual" government IT programme. However:
- This is not business as usual. It is a national security programme with cabinet-level priority and cross-party support.
- Scope is focused. We are not replicating all 200+ AWS services—only the 20-30 core services covering 80%+ of government workloads.
- Open source acceleration. We are integrating proven platforms (CloudStack, Kubernetes, MinIO), not building from scratch.
- Four-nation leverage. Costs and effort shared across EU, UK, CA, AU—not each nation building independently.
Conclusion: 5-7 years is ambitious but achievable with sustained political will and proper resourcing. If political commitment wavers, 10-15 years may indeed be the result.
Milestone-Based Success Criteria
| Milestone | Peacetime Target | Wartime Target |
|---|---|---|
| Emergency capability (critical services recoverable) | Year 2 | Week 24 |
| First production workload on sovereign platform | Year 2 | Week 12 |
| Critical data (SECRET/OFFICIAL-SENSITIVE) sovereign | Year 3 | Week 16 |
| 50% workload migration | Year 4 | Week 20 (critical only) |
| Full capability / US cloud exit | Year 5-7 | Month 12-18 (full scope) |
7. Political Sustainability Assessment
A 5-7 year peacetime programme will span at least one election cycle in all four jurisdictions. Political sustainability is a risk factor that must be actively managed, but the compressed timeline reduces exposure compared to decade-long programmes.
Election Cycle Analysis
| Jurisdiction | Election Cycle | Elections During Programme | Political Risk |
|---|---|---|---|
| UK | 5 years (max) | 1-2 elections | Low-Medium |
| EU (Commission) | 5 years | 1-2 Commissions | Low |
| Canada | 4 years (max) | 1-2 elections | Low-Medium |
| Australia | 3 years | 2-3 elections | Medium |
Political Risk Mitigation Strategies
Cross-Party Consensus Building
- Frame as national security (beyond partisan politics)
- Engage opposition parties in planning phase
- Establish bipartisan/all-party oversight committee
- Avoid associating programme with single political figure
- Commission independent cost-benefit analysis
Structural Lock-In Mechanisms
- Multi-year contractual commitments that survive government change
- International treaty obligations between partner jurisdictions
- Statutory requirements for sovereign hosting of specific data categories
- Industry investment that creates constituency for continuation
- Early wins that demonstrate value and build momentum
Graceful Degradation
Design the programme so that partial completion still delivers value:
- If stopped at Year 2: Enhanced encryption, key management, and emergency backup capability
- If stopped at Year 3: Sovereign capability for SECRET/OFFICIAL-SENSITIVE data
- If stopped at Year 5: 50%+ workload sovereignty, full emergency fallback operational
- Each phase leaves the situation materially better than before—never worse
Warning Signs to Monitor
- US-allied party gains power with platform opposing "anti-American" policies
- Budget pressure leads to "efficiency reviews" targeting large programmes
- Hyperscaler lobbying shifts political opinion
- US-Europe/UK relations improve significantly, reducing perceived threat
- Partner jurisdiction withdraws, undermining cooperative model
8. Technical Implementation Risks
| ID | Risk | Prob | Impact | Mitigation & Notes |
|---|---|---|---|---|
| T1 | CloudStack Feature Gaps Cannot replicate critical AWS capabilities |
Med | Med |
Gap areas: ML/AI services (SageMaker equivalent), managed analytics, IoT services, advanced networking. Mitigation: Accept gaps in non-critical areas; develop key services incrementally; application refactoring to reduce dependency. |
| T2 | FaaS Maturity OpenFaaS/Knative not production-ready for government scale |
Med | Low |
Reality: Open-source FaaS platforms work but require more operational investment than Lambda. Mitigation: Additional SRE staffing; consider commercial Knative support; accept longer cold starts. |
| T3 | Data Migration Complexity Petabyte-scale migrations fail or corrupt data |
High | High | Mitigation: Extensive validation; parallel running; rollback capability; phased migration with extensive testing; dedicated migration tooling investment. |
| T4 | Security Vulnerabilities Sovereign platform less secure than mature hyperscalers |
Med | High |
Reality: Hyperscalers invest billions in security. Open source relies on community review. Mitigation: NCSC/ASD/CSE involvement; mandatory security certification; red team testing; bug bounty programme. |
| T5 | Performance Gap Sovereign platform slower/less reliable than hyperscalers |
Med | Low | Mitigation: Set realistic SLAs (99.9% not 99.99%); over-provision capacity; optimise critical paths; accept some performance trade-offs as cost of sovereignty. |
| T6 | Skills Shortage Cannot recruit sufficient CloudStack/open-source expertise |
High | Med | Mitigation: Competitive salaries (market rate, not public sector discount); training academies; contractor support; knowledge transfer requirements in vendor contracts. |
| T7 | Open Source Project Risk Critical project becomes unmaintained or changes licence |
Low | Med | Mitigation: Contribute to upstream projects; maintain internal forks capability; diversify across alternatives; contractual support from OSS vendors. |
9. Governance & Coordination Risks
| ID | Risk | Prob | Impact | Mitigation & Notes |
|---|---|---|---|---|
| G1 | Four-Nation Deadlock Consensus model prevents timely decisions |
Med | Med |
Reality: Brexit negotiations, EU decision-making show multinational coordination challenges. Mitigation: Qualified majority voting for operational decisions; unanimity only for constitutional changes; clear escalation paths; independent secretariat. |
| G2 | Partner Withdrawal One jurisdiction exits, destabilising cost model |
Med | High | Mitigation: Design for graceful degradation; exit provisions in treaty; minimum viable partnership (2 nations); each jurisdiction maintains independent capability. |
| G3 | Procurement Complexity Four-nation procurement too slow and complex |
High | Med | Mitigation: Pre-agreed framework contracts; lead nation for each capability; mutual recognition of procurement decisions; expedited procedures for urgent requirements. |
| G4 | IP/Data Sovereignty Conflicts Disagreements over data location, access, ownership |
Med | Low | Mitigation: Clear principle: each nation's data stays in nation; shared services don't process sensitive data; legal framework established upfront. |
| G5 | Programme Management Failure Complexity exceeds management capability |
Med | High | Mitigation: Experienced programme director with full authority; independent assurance function; stage gates with go/no-go decisions; willingness to pause or restructure. |
10. Contingency Plans
Contingency A: US Provider Access Termination (Emergency)
Probability: 5-15% over 10 years | Impact: Catastrophic
Pre-Positioning (Before Event)
- Maintain offline backups of all critical data (updated daily minimum)
- Duplicate encryption keys to sovereign HSM/vault
- Document all infrastructure-as-code for rapid redeployment
- Pre-negotiate emergency capacity with European/sovereign providers
- Maintain "warm" capability to deploy critical services quickly
Response (During Event)
- Activate emergency operations centre
- Deploy critical services to sovereign provider from backups
- Redirect DNS to new infrastructure
- Communicate service status to citizens and civil servants
- Priority order: Identity/Auth, Benefits/Payments, Health, Tax, Other
Target Recovery: Critical services within 72 hours; full services within 2-4 weeks
Contingency B: Programme Budget Cut/Cancellation
Probability: 20-40% over 15 years | Impact: High
Pre-Positioning
- Build cross-party consensus (national security framing)
- Demonstrate early wins to build momentum
- Lock in multi-year contracts that survive budget cycles
- Establish statutory or regulatory requirements where possible
- Create industry constituency with domestic jobs
Response
- Prioritise completing migrations already in progress
- Maintain critical infrastructure even with reduced investment
- Continue risk mitigation (backups, key management) at minimum
- Preserve option to accelerate if priorities change again
- Graceful handover to reduced operational mode
Contingency C: Partner Jurisdiction Withdrawal
Probability: 15-30% over 15 years | Impact: Medium-High
Pre-Positioning
- Design modular architecture that works with 2, 3, or 4 partners
- Each jurisdiction maintains sovereign capability for critical services
- Cost model scales to smaller partnerships
- Exit provisions in founding treaty
Response
- Orderly transition of withdrawing jurisdiction's contribution
- Rebalance cost sharing among remaining partners
- Maintain interoperability for willing continued cooperation
- Proceed with reduced scope if necessary
Contingency D: Technical Platform Failure
Probability: 10-20% for major issues | Impact: Medium
Pre-Positioning
- Evaluate alternative technology stack (OCI Dedicated Region as backup)
- Maintain flexibility to pivot technology choices early in programme
- Don't over-commit to single vendor or platform
- Keep hyperscaler contracts active (reduced) during transition
Response
- Pause affected workload migrations
- Evaluate alternative platforms or approaches
- If CloudStack fails, pivot to OCI Dedicated Region or alternative
- Retain option to slow migration and maintain hybrid longer
Risk Summary & Recommendation
Overall Assessment
This risk register addresses external review concerns while maintaining the framework's core strategic validity. Key clarifications:
- Timeline: 24 weeks (wartime emergency) or 5-7 years (peacetime planned)—NOT 10-15 years
- Resources: 10,000+ staff mobilised in wartime; revised estimates for peacetime acknowledge increased requirements
- Cost: Revised estimates include hidden costs and appropriate contingency
- Alternatives: OCI Dedicated Region and hybrid approaches warrant evaluation but do not replace the need for sovereign capability
Key trade-off: The risks of building sovereign capability are substantial but manageable. The risks of continued US cloud dependency are potentially catastrophic and unmanageable. Decision-makers must weigh:
- Cost of action: €8-15B over 5-7 years (peacetime), significant but affordable for four nations
- Cost of inaction: Existential threat to government operations with no mitigation possible
Recommendation: Begin with immediate risk mitigation (encryption, backup, classification) while simultaneously pursuing the 5-7 year peacetime programme. Maintain 24-week emergency mobilisation plans as insurance. Evaluate OCI Dedicated Region as potential accelerator or backup, not replacement.
Evidence: Learning from Past Migrations
Several risks identified above have materialised in real government migration programmes. Munich's LiMux project (2003-2017) is the definitive cautionary tale, where political interference and inadequate change management reversed a technically successful migration. Conversely, the French Gendarmerie demonstrates how sustained executive commitment delivers 17+ years of sovereign operation.
Munich LiMux: cautionary tale | France: exemplar success | Critical success factors