Architecture Principles
Foundational principles for sovereignty, security, open standards, and governance that guide all technical decisions across the multi-national sovereign cloud initiative.
Core Principles
These principles provide the foundation for all technical and operational decisions. Each principle is non-negotiable and must be demonstrated in all architecture decisions, procurement activities, and implementation choices.
Principle 1: Sovereignty First
Statement: All government data, operations, and infrastructure must remain under the exclusive legal jurisdiction and operational control of the host nation.
Rationale
Foreign legal frameworks (CLOUD Act, FISA 702, IEEPA) can compel US-headquartered providers to disclose data, deny service, or modify operations regardless of where data is physically stored. True sovereignty requires eliminating all US entities from the supply chain.
Implications
- No US-headquartered company in any tier of the supply chain
- Data residency within national borders (or approved partner jurisdictions)
- Subject only to domestic law and international agreements the nation has signed
- Encryption keys held under sovereign control, not provider control
- Control plane infrastructure located within sovereign jurisdiction
- No dependencies on services routed through US infrastructure
Compliance Test
"Can any foreign government legally compel access to, modification of, or denial of this service?" The answer must be "No" for all critical government workloads.
Principle 2: Open Standards & Portability
Statement: Infrastructure and applications must be built on open standards that enable portability between providers and prevent vendor lock-in.
Rationale
Migrating from US hyperscalers to sovereign providers only to create new lock-in defeats the purpose. Open standards ensure workloads remain portable, enabling future flexibility and negotiating leverage.
Implications
- Kubernetes (CNCF) for container orchestration, not proprietary managed services
- S3-compatible APIs for object storage
- Standard SQL databases (PostgreSQL, MariaDB) over proprietary options
- OIDC/SAML for identity federation
- OpenTelemetry for observability
- OpenTofu/Ansible for infrastructure-as-code (provider-agnostic)
- OCI-compliant container images
Compliance Test
"Can this workload be migrated to a different provider within 90 days without major re-architecture?" The answer should be "Yes" for most workloads.
Principle 3: Security by Design
Statement: Security controls must be embedded in architecture from inception, not bolted on afterwards. Zero trust principles apply throughout.
Rationale
Government workloads are high-value targets. Sovereign infrastructure must exceed the security posture of commercial providers while maintaining operational agility.
Implications
- Zero Trust Architecture: Never trust, always verify
- Encryption at rest and in transit (TLS 1.3 minimum)
- Sovereign key management with HSM backing
- Network micro-segmentation
- Immutable infrastructure and container security
- Continuous security monitoring and SIEM
- Regular penetration testing and red team exercises
- Security certification to national standards (ISO 27001, SOC 2, national frameworks)
Compliance Test
"Has this architecture undergone threat modelling and does it meet national security framework requirements?"
Principle 4: Resilience & Availability
Statement: Infrastructure must be designed to withstand failures, attacks, and disruptions while maintaining service continuity.
Rationale
Government services must remain available during crises - exactly when foreign adversaries might attempt disruption. Resilience must be inherent, not dependent on single points of failure.
Implications
- Multi-region deployment within sovereign territory
- Geographic redundancy of critical services
- Automated failover and disaster recovery
- Regular DR testing and chaos engineering
- No single points of failure in critical paths
- Defined RTO/RPO for each service tier
- Graceful degradation under load or partial failure
Compliance Test
"If one datacentre is completely unavailable, can services continue within defined RTO/RPO?"
Principle 5: Cooperative Interoperability
Statement: Infrastructure across partner jurisdictions must be interoperable to enable cooperation, mutual aid, and shared capability development.
Rationale
Multi-national cooperation multiplies the value of sovereign investment. Common standards enable shared services, pooled expertise, and mutual support during crises.
Implications
- Common API standards across partner sovereign clouds
- Federated identity for cross-jurisdiction access (where appropriate)
- Shared security threat intelligence
- Common incident response protocols
- Interoperable disaster recovery capabilities
- Shared training and certification programmes
Compliance Test
"Can a workload designed for UK sovereign cloud be deployed on EU or Australian sovereign cloud with minimal modification?"
Principle 6: Transparency & Auditability
Statement: All infrastructure components, configurations, and operations must be auditable and transparent to authorised oversight bodies.
Rationale
Government must be able to demonstrate compliance, investigate incidents, and maintain democratic accountability. Opacity is incompatible with public trust.
Implications
- Preference for open-source software where security-appropriate
- Full audit trails for all access and changes
- Supply chain transparency (SBOM for all components)
- Regular third-party security audits
- Published security certifications and compliance status
- Clear incident reporting to oversight bodies
Compliance Test
"Can an auditor trace any action back to an authenticated user and understand the full software supply chain?"
Principle 7: Cost Effectiveness
Statement: Sovereign infrastructure must deliver value for money while achieving sovereignty objectives. Cost is a constraint, not an excuse for compromise.
Rationale
Public funds must be spent wisely. Sovereignty has a cost, but that cost must be justified and optimised. The alternative (foreign dependency) also has costs that must be quantified.
Implications
- Total cost of ownership (TCO) analysis for all decisions
- Right-sizing and auto-scaling to avoid waste
- Shared services across departments to achieve economies of scale
- Multi-national cooperation to share development costs
- Regular cost optimisation reviews
- Quantify risk reduction value when comparing costs
Compliance Test
"Has TCO been calculated including risk mitigation value, and does the solution represent best value?"
Applying the Principles
Principle Hierarchy
When principles conflict, apply them in priority order:
- Sovereignty First - Non-negotiable for critical government workloads
- Security by Design - Cannot be compromised for convenience
- Resilience & Availability - Government services must remain operational
- Open Standards & Portability - Avoid creating new dependencies
- Cooperative Interoperability - Maximise value of sovereign investment
- Transparency & Auditability - Maintain public trust
- Cost Effectiveness - Optimise within constraints
Exception Process
Any deviation from these principles requires:
- Formal risk assessment documenting the deviation
- Approval from the Technical Steering Committee (TSC)
- Time-bound remediation plan
- Ongoing monitoring until compliance achieved