A structured, auditable framework for measuring how much control your organisation actually holds over its digital infrastructure. 9 weighted categories. 60+ individual controls. One composite score.
Each control is assessed against a three-point scale. Category scores are weighted. The final sovereignty score is a percentage from 0 to 100.
The control is fully implemented. Evidence is independently verifiable. No third-party dependency exists for this control.
The control is partially met. Implementation relies on vendor contractual assurances, SLA commitments, or third-party tooling rather than direct organisational control.
The control is not met. A third party holds the decision-making authority, access, jurisdiction, or technical capability that the control requires.
For each category, the average score of its controls (0.0 to 1.0) is multiplied by the category weight. The final sovereignty score is the sum of all weighted category scores, expressed as a percentage.
| Score Range | Rating | Interpretation |
|---|---|---|
| 85 - 100 | Sovereign | Robust sovereign posture. Infrastructure under genuine organisational control across all key categories. Minor gaps may exist in lower-weighted categories. |
| 65 - 84 | Partial Control | Material sovereign gaps exist. Likely exposure in data sovereignty, operational control, or security categories. Remediation roadmap recommended. |
| 40 - 64 | At Risk | Significant sovereign exposure. Core infrastructure decisions are made or constrained by third parties. Strategic review required. |
| Below 40 | Critical Risk | Critical sovereign risk. The organisation does not meaningfully control its own infrastructure. A single vendor action, sanctions event, or policy change could disrupt operations. |
Categories that represent existential risk to operations carry the highest weight. The weights below represent the default profile; they can be adjusted for sector-specific assessments.
| # | Category | Weight | What It Measures |
|---|---|---|---|
| 01 | Operational Control | 20% | Whether your organisation holds ultimate administrative authority over its infrastructure — control plane access, capacity decisions, and the absence of external kill switches. |
| 02 | Data Sovereignty | 20% | Physical location of all data, encryption key ownership, cross-border transfer controls, backup jurisdiction, and metadata residency. |
| 03 | Security Sovereignty | 15% | Organisational control over encryption, PKI, incident response, security logging, and the ability to conduct independent penetration testing. |
| 04 | Survivability | 15% | Ability to continue operations if a vendor ceases service — through bankruptcy, sanctions, commercial dispute, or policy change. |
| 05 | AI & Model Sovereignty | 10% | Whether AI inference and training run within your infrastructure, using models you can inspect, audit, and modify without API dependency. |
| 06 | Open Source Freedom | 5% | Degree to which the core platform relies on community-governed, openly licensed software rather than proprietary or vendor-controlled forks. |
| 07 | Feature & Roadmap Control | 5% | Whether you control your software versions, update schedule, and feature set — or whether a vendor dictates these on their timeline. |
| 08 | Legal & Compliance | 5% | Exposure to extra-territorial legislation (CLOUD Act, FISA 702), governing law of vendor contracts, and independent regulatory compliance verification. |
| 09 | Replication & Cost Independence | 5% | Ability to replicate the full stack at a second site without licensing cost, scale without renegotiation, and exit without punitive egress fees. |
For each category: what it measures, the 5 key controls, and what Yes, Partial, and No look like in practice.
Measures whether your organisation is the ultimate decision-maker for its infrastructure operations. This includes administrative access to the control plane, the ability to add or remove capacity independently, and the absence of any mechanism by which a third party can unilaterally suspend or terminate your environment.
| Yes (1.0) | Partial (0.5) | No (0.0) |
|---|---|---|
| You operate the control plane on infrastructure you own or directly contract. No third party can suspend your service. Capacity decisions are yours alone. | You have administrative access via a vendor console, but the vendor retains super-admin rights, can revoke access under their ToS, or controls the underlying hypervisor layer. | The vendor owns and operates the control plane. Your access is a tenancy within their system. They can terminate service per their terms with limited notice. |
Measures organisational control over the physical location, access, and jurisdictional exposure of all data — including backups, replicas, metadata, and access logs. Data sovereignty is not met by selecting a cloud region; it requires control over where data physically resides and who can compel access to it.
| Yes (1.0) | Partial (0.5) | No (0.0) |
|---|---|---|
| All data resides on infrastructure you control. Encryption keys are held in your own KMS. No extra-territorial legislation applies. Full audit trail for all access. | Data resides in a vendor's "sovereign region" but the vendor is subject to extra-territorial legislation (e.g., CLOUD Act). Keys are "customer-managed" but stored on vendor HSMs. | Data location is abstracted by the vendor. Cross-border replication occurs by default. Vendor holds encryption keys or has technical access to decrypt. No independent audit trail. |
Measures whether your organisation independently controls its security posture — encryption, certificate authority, incident response, audit logging, and vulnerability testing — without requiring vendor involvement or permission.
| Yes (1.0) | Partial (0.5) | No (0.0) |
|---|---|---|
| Your organisation operates its own KMS, PKI, and SIEM. Incident response is handled internally. Pen testing requires no external approval. Logs are stored on your systems. | You use vendor-provided "customer-managed" key services. Logs are available through vendor APIs but stored on vendor infrastructure. Pen testing requires notification. | Vendor manages encryption, certificates, and logging. Incident response requires opening a vendor support ticket. Security testing requires written vendor approval and is restricted in scope. |
Measures whether your infrastructure can continue operating if a critical vendor ceases to provide service — whether through bankruptcy, sanctions, commercial dispute, acquisition, or unilateral policy change. Survivability is the ultimate test of sovereignty: if the vendor disappears tomorrow, do you still have a working system?
| Yes (1.0) | Partial (0.5) | No (0.0) |
|---|---|---|
| Infrastructure is self-hosted or uses commodity providers with tested failover. Open APIs throughout. Full data export tested quarterly. Runbooks maintained and rehearsed. | Partial migration path exists but has not been tested end-to-end. Some proprietary services have identified alternatives but no failover runbooks. Data export is theoretically possible but untested. | Deep dependency on proprietary APIs and services with no documented alternatives. Egress fees make migration prohibitively expensive. No failover runbooks. Vendor loss means extended outage. |
Measures whether AI and machine learning workloads are under organisational control — covering inference location, training data residency, model transparency, and independence from commercial API providers. As AI becomes embedded in critical workflows, sovereignty over the AI layer becomes a core infrastructure concern.
| Yes (1.0) | Partial (0.5) | No (0.0) |
|---|---|---|
| All inference on private GPU infrastructure. Open-weight models deployed and auditable. Training data stays in-jurisdiction. No external API calls for AI functionality. | Primary inference is local but fallback routes to commercial APIs. Models are open-weight but fine-tuning occurs on vendor infrastructure. Some prompt data leaves your environment. | AI workloads run entirely on commercial APIs. Every prompt and response is transmitted to and logged by a third-party provider. Model behaviour is opaque and unauditable. |
Measures the degree to which your infrastructure stack relies on genuinely open-source software — with community governance, permissive licensing, public source code, and the right to fork. Proprietary forks with restricted source access create a dependency that can be weaponised at any time.
| Yes (1.0) | Partial (0.5) | No (0.0) |
|---|---|---|
| Entire stack is open-source with permissive or copyleft licensing. Governance is community-driven. Source is publicly available. You can fork and maintain independently. | Core components are open-source but critical plugins, drivers, or management layers are proprietary. "Open-core" model where essential features require a commercial licence. | Platform is proprietary or uses a vendor-controlled fork with restricted source access. Licence terms prohibit modification or redistribution. No independent audit of source code. |
Measures whether your organisation controls its own software versions, update schedule, and feature set — or whether a vendor dictates when features appear, change, or disappear. Forced upgrades and unilateral deprecations are a direct sovereignty risk.
| Yes (1.0) | Partial (0.5) | No (0.0) |
|---|---|---|
| You choose when to update. You can pin versions indefinitely. The codebase can be forked and maintained. No external party can deprecate features you depend on. | You can delay updates but the vendor sets an end-of-support date. Some configuration requires vendor support. Feature deprecations are announced with reasonable notice. | Vendor pushes updates on their schedule. Features appear and disappear based on vendor commercial priorities. Configuration changes require support tickets. No fork rights. |
Measures exposure to extra-territorial legislation and the degree to which vendor contracts, governing law, and regulatory compliance are under your organisational and jurisdictional control. A US-headquartered vendor is subject to US law regardless of where its servers are located.
| Yes (1.0) | Partial (0.5) | No (0.0) |
|---|---|---|
| All vendors incorporated in your jurisdiction. Contracts governed by your national law. No extra-territorial data access obligations. Compliance independently audited and certified. | Primary vendor is local but relies on sub-processors in foreign jurisdictions. Contracts include choice-of-law clauses but vendor parent company is subject to extra-territorial law. Compliance is self-certified. | Primary vendor is US-headquartered and subject to CLOUD Act. Contract governed by foreign law. Compelled disclosure provisions exist. No independent compliance verification. |
Measures the financial and technical freedom to replicate, scale, and exit your infrastructure without punitive costs. Egress fees, per-socket licensing, and contract lock-in are deliberate mechanisms that constrain sovereignty by making alternatives economically unviable.
| Yes (1.0) | Partial (0.5) | No (0.0) |
|---|---|---|
| Open-source stack with no per-unit licensing. Free data transfer. Full replication tested. Costs are hardware and personnel only — predictable and under your control. | Some components carry licensing costs but they are fixed and predictable. Egress fees exist but are capped or negotiated. Replication is possible but involves additional licence procurement. | Per-unit licensing across the stack. Egress fees make migration prohibitively expensive. Cost increases are imposed unilaterally (e.g., Broadcom/VMware). Vendor controls your cost structure. |
Use the detailed controls checklist for self-assessment, or request a guided assessment with our engineering team.