Digital contracts · Technology governance
Your cloud is European. Can you actually leave it?
Technology sovereignty becomes practical when you examine access, dependencies and the terms of departure.
Case statusResearch closed on 28 September 2026 · check for changes before taking a decision.
01
Europe proposes a sovereignty framework
On 3 June 2026, the European Commission presented a communication on technology sovereignty, accompanied by an open-source strategy. The package includes a proposed Cloud and AI Development Act, or CADA. These documents express a policy direction: strengthening control over digital infrastructure and services. A communication does not, merely by existing, impose a new general obligation on businesses. [1,2]
The CADA presentation distinguishes four levels of sovereignty, with location in the Union only the first. That detail matters to buyers: a European data centre does not by itself answer every question about control. The pages consulted describe a proposal. They do not establish that these levels are already general requirements applying to every small business. [3]
02
Turn a marketing term into something you can test
For an upcoming purchase, we suggest separating three questions: where does the service operate, who can act on it and how could the business replace it? This is a recommendation for contract management, not an exhaustive legal definition of sovereignty. A single commercial adjective cannot adequately describe a technical architecture and a legal relationship. The answers also need to match your actual use.
Ask which providers are involved, who has administrative access and which functions depend on a third-party licence or service. Compare the answers with the contractual documents. A product presentation may be too general to establish what has been promised for your configuration. Precise responsibilities require examination of the contract and the rules applicable to the activity concerned.
Departure deserves particular attention. A promised export may be difficult to use without metadata, histories or documentation needed to transfer it elsewhere. Conversely, a dependency does not always justify an immediate change. The aim is to know its cost, timing and consequences before extending a commitment. A migration test alone establishes no general conclusion about legal compliance.
03
The Law Right approach: test an exit before renewal
- Choose an important service and request a trial export using fictional data or data suitable for the test. Ask the relevant team to check completeness and reusability. Record the manual operations required: they give an initial indication of the work departure would involve. Also note what the test could not establish, rather than treating an incomplete exercise as a full migration assessment.
- Compare the experience with written commitments on available formats, assistance, deadlines, costs and arrangements for returning or deleting information. Identify points requiring negotiated clarification. This checklist is a discussion aid; it is not presented as a set of clauses legally required in every agreement. A useful response should explain the proposed service in terms your team can verify.
- Give someone responsibility for monitoring critical dependencies and renewal dates. A replacement option becomes useful when it has an owner, an estimate and a timetable. Research closed on 28 September and needs updating before publication. Further legislative developments concerning CADA remain to be checked; this draft does not anticipate their outcome.
Sovereignty needs scrutiny at every layer.
Where is the equipment, and who can control access to it?
Explanatory schematic: illustrative relationships, not a measurement of dependencies or a legal conclusion.Control over a service also depends on your documented ability to replace it.

