The detailed audit checklist for the Digital Sovereignty Assessment Framework. Each control specifies what is being assessed, how to verify it, and what evidence to collect. Use this for self-assessment or as the basis for a formal infrastructure audit.
For each control, score your organisation as Yes (1.0), Partial (0.5), or No (0.0). Collect the specified evidence to support your assessment. Average the control scores within each category, then apply the category weight to produce your weighted score.
A self-assessment takes approximately 4-6 hours for a team familiar with the infrastructure. A guided assessment with our engineers takes 2-4 hours and includes gap analysis and remediation recommendations.
| # | What Is Assessed | How to Verify | Evidence to Collect |
|---|---|---|---|
| 1.1 | Full administrative access to the infrastructure control plane | Confirm root/admin credentials are held by your organisation. Verify no vendor super-admin can override your access controls. | Control plane access audit log. IAM policy export showing admin role holders. Vendor contract clause on access rights. |
| 1.2 | No unilateral vendor service termination capability | Review vendor ToS and contract for suspension/termination clauses. Identify conditions under which vendor can disable service without your consent. | Vendor contract sections on termination. ToS clauses on acceptable use and suspension. Legal review memo. |
| 1.3 | Independent capacity management | Confirm you can add or remove compute, storage, and network capacity without vendor approval, procurement lead time, or quota requests. | Capacity change log showing self-service actions. Procurement process documentation. Vendor quota/limit configuration. |
| 1.4 | Hypervisor and hardware under your control | Identify who owns and operates the hypervisor layer. Confirm physical hardware is under your direct or contractual control with audit rights. | Hardware asset inventory. Hypervisor licence and deployment records. Co-location contract with audit clause. Firmware version baseline. |
| 1.5 | No remote kill-switch or phone-home telemetry | Audit all software components for licence-enforcement daemons, telemetry endpoints, or remote disable capabilities. Network-monitor outbound connections. | Network traffic analysis showing outbound telemetry. Software licence audit. Vendor disclosure on remote management capabilities. |
| 1.6 | Operations staff under your organisational authority | Confirm all personnel with infrastructure access are employees or direct contractors under your legal jurisdiction and HR policies. | Operations team roster with employment status. Contractor agreements. Jurisdictional residency confirmation. |
| 1.7 | Documented change management process independent of vendor | Verify change requests, approvals, and rollbacks are managed by your team without vendor ticketing or approval gates. | Change management policy document. Recent change request logs. Approval workflow configuration. |
| # | What Is Assessed | How to Verify | Evidence to Collect |
|---|---|---|---|
| 2.1 | Physical data location is known and documented | Identify exact facility addresses for all primary data, backups, and replicas. Confirm no data resides in abstracted or undisclosed locations. | Data residency map with facility addresses. Storage configuration showing replication targets. Vendor disclosure on data placement. |
| 2.2 | No unauthorised cross-border data transfer | Review data flows for any transfer across jurisdictional boundaries. Confirm explicit approval process exists for any cross-border movement. | Data flow diagram. Network policy rules restricting cross-border transfer. Approval records for any permitted transfers. |
| 2.3 | Encryption key ownership and control | Confirm encryption keys are generated, stored, and rotated by your organisation using your own KMS — not a vendor-provided key management service. | KMS deployment documentation. Key generation and rotation logs. HSM ownership records. Vendor KMS independence confirmation. |
| 2.4 | No third-party data access without audit trail | Confirm all access to data — including vendor support access — requires documented authorisation and produces an immutable audit log. | Access control policy. Audit log samples showing all access events. Vendor support access procedure and logging. |
| 2.5 | Metadata and logs held in-jurisdiction | Verify that access logs, analytics data, DNS query logs, and other metadata are stored in the same jurisdiction as primary data. | Log storage configuration. Analytics platform deployment location. DNS and CDN log retention settings. |
| 2.6 | Backup jurisdiction matches primary data jurisdiction | Confirm all backup and disaster recovery copies reside within your designated jurisdiction. No cross-border backup replication. | Backup configuration showing target locations. DR site facility address. Replication policy documentation. |
| 2.7 | Data classification and handling policy enforced | Verify a data classification scheme exists and is technically enforced — not just documented. Different classification levels have different residency and access controls. | Data classification policy. Technical enforcement configuration (DLP rules, storage policies). Classification audit results. |
| # | What Is Assessed | How to Verify | Evidence to Collect |
|---|---|---|---|
| 3.1 | Encryption keys generated and held by your organisation | Confirm key generation occurs on hardware you own. Keys never transit vendor systems. Key material is not escrowed with any third party. | Key generation ceremony records. HSM ownership and location documentation. Key escrow policy (confirming no escrow). |
| 3.2 | PKI infrastructure operated internally | Verify your organisation operates its own certificate authority for internal services. Root and intermediate CAs are under your control. | CA hierarchy diagram. Certificate issuance logs. CA server deployment and access records. |
| 3.3 | Incident response independent of vendor | Confirm your IR plan can be executed without opening vendor support tickets. Verify you can isolate, investigate, and remediate without vendor involvement. | Incident response plan. Recent IR exercise report. Contact escalation matrix (showing internal-only paths). |
| 3.4 | Security audit logs stored independently | Confirm all security-relevant logs are shipped to and retained on infrastructure you control — not stored solely within the vendor's logging service. | Log shipping configuration. SIEM deployment documentation. Log retention policy and storage location verification. |
| 3.5 | Penetration testing without vendor approval | Confirm you can conduct penetration testing and vulnerability scanning against your infrastructure without requesting vendor permission or notification. | Vendor pen testing policy. Recent pen test report. Scope documentation showing no vendor-imposed restrictions. |
| 3.6 | Identity provider under organisational control | Verify the identity provider (IdP) for infrastructure access is operated by your organisation. No dependency on a third-party IdP for break-glass access. | IdP deployment documentation. Authentication flow diagram. Break-glass procedure showing IdP independence. |
| 3.7 | Network security controls independently managed | Confirm firewall rules, IDS/IPS, and network segmentation are configured and managed by your team on infrastructure you control. | Firewall rule export. Network architecture diagram. IDS/IPS deployment records. Change management logs for network security. |
| # | What Is Assessed | How to Verify | Evidence to Collect |
|---|---|---|---|
| 4.1 | Operations continue if primary vendor ceases service | Confirm a tested failover plan exists that does not depend on the primary vendor's infrastructure, APIs, or personnel. | Business continuity plan. Failover test results. Alternative infrastructure documentation. |
| 4.2 | Sanctions resilience | Assess whether sanctions against the vendor's home jurisdiction would immediately terminate service. Identify single-jurisdiction dependencies. | Vendor incorporation jurisdiction list. Sanctions impact analysis. Alternative vendor identification for critical services. |
| 4.3 | Data export within 72 hours | Test full data export from the platform. Measure time to export all data to portable formats. Confirm export does not require vendor assistance. | Data export test results with timing. Export format documentation. Self-service export procedure. |
| 4.4 | Multi-site failover runbooks | Verify documented, tested runbooks exist for failing over all critical services to an alternative site without third-party dependency. | Failover runbooks. Most recent failover drill report. Recovery time objective (RTO) measurements. |
| 4.5 | Proprietary API alternatives identified | Catalogue all proprietary API dependencies. Confirm open-standard alternatives are identified and documented for each. | API dependency inventory. Alternative mapping document. Migration effort estimates for each proprietary API. |
| 4.6 | Infrastructure-as-code portability | Confirm infrastructure definitions use portable formats (Terraform with multiple provider support, Ansible, etc.) rather than vendor-specific templates. | IaC repository review. Provider abstraction layer documentation. Multi-provider deployment test results. |
| 4.7 | Contractual exit terms documented and tested | Review vendor contracts for exit provisions: data return timeline, format, cost, and assistance obligations. Confirm terms are exercisable in practice. | Contract exit clauses. Data return SLA documentation. Exit cost estimate. Previous exit exercise results if available. |
| # | What Is Assessed | How to Verify | Evidence to Collect |
|---|---|---|---|
| 5.1 | AI inference runs on your infrastructure | Confirm all production AI inference occurs on hardware you own or directly control. No prompt data is transmitted to external API endpoints. | AI deployment architecture diagram. Network traffic analysis confirming no external API calls. GPU/compute inventory for inference workloads. |
| 5.2 | Training data remains in your environment | Verify training and fine-tuning datasets never leave your infrastructure boundary. Confirm no vendor platform ingests your data for model improvement. | Training pipeline architecture. Data flow diagram for ML workflows. Vendor data usage policy review. |
| 5.3 | Model auditability and modifiability | Confirm you have access to model weights, can inspect model behaviour, and can modify or fine-tune models without vendor involvement. | Model licence documentation. Model weight storage location. Fine-tuning procedure and access records. |
| 5.4 | No commercial API dependency for production AI | Verify no production workload depends on a commercial model API (OpenAI, Anthropic, Google, etc.) as a runtime requirement. | Application dependency inventory. API call logs. Fallback architecture documentation. |
| 5.5 | Open-weight models with permissive licences | Confirm production models are open-weight with licences that permit commercial use, modification, and redistribution without restriction. | Model licence inventory. Licence compliance review. Open-weight model deployment records. |
| 5.6 | AI supply chain transparency | Verify the provenance of all models in use — training data sources, model lineage, and any third-party components in the AI pipeline. | Model provenance documentation. Training data source inventory. AI bill of materials. |
| 5.7 | Prompt and response data retention under your control | Confirm all prompt inputs and model outputs are logged and retained on your infrastructure. No third party retains copies of your AI interactions. | AI logging configuration. Data retention policy for AI interactions. Third-party data retention policy review. |
| # | What Is Assessed | How to Verify | Evidence to Collect |
|---|---|---|---|
| 6.1 | Core platform uses community-governed open-source projects | Inventory all infrastructure components. Confirm core components (OS, hypervisor, orchestration, storage, networking) are community-governed open-source projects. | Software bill of materials. Project governance documentation for each core component. Foundation/community affiliation records. |
| 6.2 | No proprietary forks in the critical path | Identify any vendor-specific forks of open-source projects in the stack. Confirm these are not in the critical path for operations. | Component inventory with fork identification. Critical path analysis. Vendor fork licence terms. |
| 6.3 | Licence terms permit modification and redistribution | Review licences for all infrastructure components. Confirm they permit modification, redistribution, and commercial use without restriction. | Licence compliance audit report. Licence inventory spreadsheet. Legal review of restrictive clauses. |
| 6.4 | Community governance independent of single vendor | Verify governance of critical open-source projects is not controlled by a single commercial entity. Check for foundation-based governance. | Project governance documents. Contributor diversity analysis. Foundation membership records. |
| 6.5 | Source code publicly auditable without NDA | Confirm source code for all critical infrastructure components is publicly available and can be audited without signing a non-disclosure agreement. | Source code repository URLs. Access verification (no authentication required). NDA inventory confirming no code-access NDAs. |
| 6.6 | Ability to fork and self-maintain | Confirm your team has the technical capability and legal right to fork any critical component and maintain it independently if upstream support ends. | Fork feasibility assessment for critical components. Internal engineering capability inventory. Licence fork-rights confirmation. |
| # | What Is Assessed | How to Verify | Evidence to Collect |
|---|---|---|---|
| 7.1 | You control the software version and update schedule | Confirm you decide when software updates are applied. Verify no vendor can force an update or deprecate a version you depend on without your consent. | Update policy documentation. Version pinning configuration. Recent update decision log showing self-directed timing. |
| 7.2 | No unilateral feature deprecation | Review vendor history and contractual terms for feature deprecation. Confirm no mechanism exists for removing features you rely on without your agreement. | Vendor deprecation policy. Contract clauses on feature continuity. History of vendor deprecation decisions affecting your workloads. |
| 7.3 | Fork and maintain capability | Confirm the codebase can be forked and maintained independently. Verify your team has the skills and resources to do so if required. | Fork rights confirmation (licence review). Internal engineering assessment of maintenance capability. Estimated effort for independent maintenance. |
| 7.4 | No forced migrations or upgrade deadlines | Confirm no vendor-imposed deadlines force you to migrate to new versions, platforms, or architectures against your operational timeline. | Vendor migration notification history. Contract clauses on platform continuity. End-of-life policy documentation. |
| 7.5 | Configuration autonomy | Confirm all infrastructure configuration changes can be made by your team without vendor support tickets, approval workflows, or professional services engagement. | Recent configuration change log. Support ticket history for configuration requests. Self-service configuration capability documentation. |
| 7.6 | API stability and backward compatibility | Verify APIs you depend on have stability guarantees. Confirm breaking changes require notification and migration path with reasonable timelines. | API versioning policy. Breaking change notification history. API deprecation timeline documentation. |
| # | What Is Assessed | How to Verify | Evidence to Collect |
|---|---|---|---|
| 8.1 | No extra-territorial legislation exposure | Identify the incorporation jurisdiction of every infrastructure vendor. Assess whether any are subject to CLOUD Act, FISA 702, UK IPA, or equivalent. | Vendor incorporation jurisdiction list. Extra-territorial legislation applicability analysis. Legal counsel opinion. |
| 8.2 | Vendors incorporated in your legal jurisdiction | Confirm all infrastructure vendors — including sub-processors — are incorporated in your legal jurisdiction or jurisdictions with adequate legal protections. | Vendor and sub-processor incorporation registry. Adequacy decision documentation for non-local jurisdictions. |
| 8.3 | Contracts governed by your national law | Review governing law clauses in all vendor contracts. Confirm disputes are resolved under your national legal system. | Contract governing law clause inventory. Dispute resolution clause review. Legal jurisdiction confirmation for each vendor. |
| 8.4 | No compelled disclosure provisions | Review all vendor agreements for provisions that compel data disclosure to foreign governments, law enforcement, or intelligence agencies without your knowledge. | Contract clause review for compelled disclosure. Transparency report from vendors. Legal analysis of disclosure obligations. |
| 8.5 | Regulatory compliance independently verifiable | Confirm GDPR, NIS2, DORA, or sector-specific compliance is independently audited and certified — not solely based on vendor self-certification. | Independent audit reports. Certification documents. Compliance assessment methodology documentation. |
| 8.6 | Data processing agreements with all sub-processors | Confirm data processing agreements (DPAs) exist with all vendors and sub-processors that handle your data, with clear scope and obligation definitions. | DPA inventory. Sub-processor list with DPA status. DPA review for adequacy of terms. |
| 8.7 | Incident notification obligations contractually defined | Confirm vendor contracts include specific incident notification timelines that meet your regulatory requirements (e.g., 24-hour notification for NIS2). | Incident notification clauses in vendor contracts. Regulatory requirement mapping. Notification timeline comparison. |
| # | What Is Assessed | How to Verify | Evidence to Collect |
|---|---|---|---|
| 9.1 | Full stack replication at zero additional licensing cost | Confirm the entire infrastructure stack can be replicated at a second site without purchasing additional software licences. | Licence terms for all software components. Replication cost estimate. Second-site deployment test results. |
| 9.2 | No per-unit licensing in the infrastructure stack | Audit all software for per-instance, per-CPU, per-socket, or per-user licensing that scales cost with capacity. | Complete licence inventory with pricing model. Cost projection for 2x and 5x capacity scenarios. Per-unit licence identification. |
| 9.3 | Free data egress | Confirm data can be transferred out of the platform without egress fees or transfer charges. Calculate total cost of full data export. | Vendor pricing documentation for data transfer. Egress cost calculation for full data volume. Contract clauses on transfer fees. |
| 9.4 | Capacity scaling without contract renegotiation | Confirm you can increase or decrease infrastructure capacity without renegotiating vendor contracts, purchasing additional licences, or requesting quota increases. | Scaling procedure documentation. Recent scaling actions and associated costs. Vendor quota or limit configuration. |
| 9.5 | Predictable TCO over 5-year horizon | Confirm total cost of ownership is predictable and under your control. No vendor can unilaterally increase costs (as Broadcom did with VMware licensing). | 5-year TCO projection. Vendor price change history. Contract clauses on pricing stability. Cost comparison with open-source alternatives. |
| 9.6 | No contractual lock-in or minimum commitment | Review contracts for minimum commitment terms, early termination penalties, or volume commitments that constrain your ability to reduce or exit. | Contract term and commitment clauses. Early termination penalty documentation. Minimum spend obligation inventory. |
Use this checklist for self-assessment, or request a guided assessment where our engineers walk through every control with your CTO and CISO team.