What Should a Cloud Sovereignty Audit Actually Deliver?

A cloud sovereignty audit can sound more definite than it is. Some assessments stop after confirming that data sits in an EU region and the cloud provider holds familiar certifications. Others begin with the assumption that every workload must move. Neither gives a management team enough information to make a sound decision.

A useful audit connects business requirements to technical evidence. It shows which systems depend on which organisations, where control could be lost, which risks matter for each workload and what can realistically be changed. The result should help a board answer an auditor or customer while giving the technical team a sequence of work it can execute.

The European Commission's Cloud Sovereignty Framework now provides a common vocabulary for this work. It assesses providers across strategic, legal, data, operational, supply-chain, technological, security and environmental dimensions. The Commission built it for public procurement, however, so a private company still needs to translate those questions into its own decisions.

Start with the decision the audit must support

The starting point is usually a business event. A customer has added a data-location clause, an auditor wants evidence about third-party access, the board has asked about dependence on one supplier, or a cloud contract is approaching renewal. Each trigger creates a different question and a different deadline.

That question should appear on the first page of the audit. It might be whether patient-data workloads need a different operating model, whether the company can give a major customer the contractual assurance it requested, or which dependencies should be reduced before the next renewal. Without this framing, the assessment can collect a large amount of accurate information without resolving anything.

The scope also needs boundaries. A cloud sovereignty audit can identify legal exposure, contractual gaps and questions that require specialist advice. It is not a legal opinion, a GDPR certification or proof of compliance with every rule that applies to the organisation. Stating that limit makes the findings more credible and prevents a technical review from making claims it cannot support.

The first deliverable should therefore be a short decision brief. It records why the audit is happening, which systems and legal entities are in scope, who owns the decision, what evidence will be accepted and when a conclusion is needed. The board and the technical team should agree on that brief before anyone begins scoring providers.

Map the workloads, data and hidden dependencies

An account list is not an infrastructure map. A production application may run in an EU cloud region while relying on identity, logging, code deployment, support access, encryption keys or backups controlled somewhere else. A software supplier may also depend on its own cloud platform, creating an exposure that never appears in the customer's cloud console.

The Commission's implementation guidance says an assessment should examine every technical layer and follow the chain of suppliers and subcontractors, rather than stop at the company named in the contract. For critical services, it points specifically to compute, storage, networking, security, identity and access management, and important platform services. This is the level at which an audit starts to reveal who can actually operate, interrupt or change a system.

Each workload record should identify its business owner, purpose, data types, operational importance and acceptable downtime. It should then record where data is stored and processed, which company holds the contract, who can administer the environment, where support is delivered, who controls encryption keys, how recovery works and which interfaces would be needed to leave.

Unknown answers are findings, not blanks to hide. If nobody can confirm where a backup copy is held or which subcontractor handles a support request, the audit has identified an evidence gap. The resulting deliverables should include an architecture and data-flow map, a dependency register and an index linking every important statement to a contract, technical setting, audit report or provider response.

This discipline is already visible in regulated sectors. The European Central Bank's cloud outsourcing guide recommends that supervised banks maintain an up-to-date inventory of cloud assets and assess where data may be stored and processed, including through subcontractors. The guide applies to the banks the ECB supervises, but the underlying method is useful to any company that needs a defensible view of its cloud estate.

Classify risk workload by workload

Sovereignty is rarely an all-or-nothing requirement for an entire company. A public website, an internal development environment and a system holding patient records do not need identical controls. Applying the strictest standard to all three may create cost and complexity without reducing a meaningful risk.

The audit should classify each workload before assessing whether its current provider is suitable. Relevant questions include how sensitive the data is, how long the business can operate without the system, which jurisdictions can affect it, whether qualified people in Europe can run it, how dependent it is on proprietary technology and what evidence a customer or regulator expects.

The Commission's framework uses Sovereignty Effectiveness Assurance Levels from SEAL-0 to SEAL-4. These describe increasing degrees of European jurisdiction, technological control and independence from non-EU dependencies. They are useful reference points, but they were designed to assess cloud offers in a procurement exercise, not to assign one mandatory target to every private-sector workload.

The framework also acknowledges its own limits. Its implementation guidance says full SEAL-4 sovereignty is not currently realistic across some supply chains, particularly chips and hardware. A good audit therefore avoids turning a high score into an absolute objective. It assigns a proportionate requirement, records the reason and identifies the control gap between the requirement and the present setup.

The deliverable is a workload risk register that both audiences can read. The board sees which business functions carry material exposure and why. The technical team sees the specific issue, such as foreign administrative access, an undocumented subprocessor, a proprietary database dependency or an untested recovery path.

Test provider claims against evidence

Cloud marketing often compresses several different ideas into the word "sovereign". EU data residency, a European operating company, locally employed support staff and independence from foreign legal control are separate properties. One does not prove the others.

The Commission's first tender assessed provider answers, supporting documents and public information. Its guidance also notes that self-assessment and self-declaration required significant verification effort from the buyer. That is an important lesson for a private audit: a questionnaire is the beginning of the evidence process, not its conclusion.

For every material claim, the audit should record the source, date and confidence level. Strong evidence may include contractual commitments, corporate ownership records, named subprocessor lists, technical architecture, key-management settings, export tests and independent audit reports. A brochure or sales presentation can identify a claim worth checking, but it should not close the question.

The provider assessment should also stay neutral. Exposure to another jurisdiction is not automatically unacceptable, and European ownership does not automatically make a service suitable. The required controls depend on the workload, while the technical fit depends on the services, skills and operating model the company actually needs.

The deliverable should be an evidence matrix showing the requirement, the provider's answer, the supporting material, any unresolved question and the resulting gap. Procurement can use the same document to request clearer clauses at renewal. Engineering can use it to validate whether a proposed alternative supports the workload in practice.

Turn findings into explicit decisions

An audit is incomplete if every finding ends with "consider migration". Each workload needs a recorded decision: stay as it is, stay with additional controls, renegotiate the contract, reduce a technical dependency, migrate to another provider, or retire the system. The rationale should be clear enough that someone outside the project can understand it six months later.

Staying can be a sound result. A workload may contain no sensitive data, tolerate the identified jurisdictional exposure and depend heavily on a managed service with no practical alternative. In that case, the audit should record why the present arrangement remains acceptable and which event would trigger another review.

Migration recommendations need the same honesty. Moving compute to a European provider will not resolve a dependency if identity, deployment, monitoring and backups remain tied to the previous platform. The recommendation should state the expected benefit, the technical trade-offs, the prerequisites and the operational risk of making the change.

This is where a sovereignty audit becomes more useful than a provider ranking. It produces a portfolio of decisions matched to actual systems. Sensitive workloads can receive stronger controls without forcing the company into a disruptive programme for everything else.

Finish with a roadmap someone can execute

The final report should distinguish immediate evidence and contract work from engineering changes that belong near a renewal or planned platform upgrade. Sequencing matters because identity, networking, backups and data transfer often need to move before an application can. The roadmap should show dependencies, decision owners, target dates and the conditions that must be met before each step starts.

For financial institutions, the ECB offers a useful test of whether this plan is concrete enough. Its guide says a cloud exit plan should identify qualified alternatives, critical milestones, required tasks and skills, expected time and costs, and should be reviewed and tested regularly. Even outside banking, an audit that recommends migration without answering those questions has not yet produced an executable recommendation.

A complete audit pack should contain six connected outputs:

• a decision brief defining the question, scope and owner;
• an architecture, data-flow and dependency map;
• a workload risk register with proportionate control requirements;
• an evidence matrix for current and candidate providers;
• a decision register stating what stays, changes or moves;
• a prioritised roadmap with dependencies, owners and review triggers.

The board does not need every technical detail in its summary, but the evidence must remain available behind it. The technical team should be able to trace each recommendation to a workload and a verified gap. Procurement should know which answers and clauses it still needs from suppliers.

That is the practical standard for a cloud sovereignty audit. It gives management a defensible answer, gives engineers a realistic next step and leaves room for the conclusion that migration is unnecessary for part, or all, of the estate.

Thinking about migration? Book a free consultation to discuss your situation.