Bottom line: Digital sovereignty is not decided at repatriation, but already at the signing of the cloud contract – through control structure, third-country access, and the provider’s technical access capabilities.
Anyone who fails to clarify jurisdiction, operator access, and exit options with the cloud provider before signing the contract will be negotiating from a weak position by the time repatriation comes around, at the latest. A list of questions shows which points should be addressed in the contract beforehand.
Dependence on a cloud provider builds up over years – through interfaces, proprietary functions, data volumes, and established operational workflows. Anyone who only questions this dependence at the point of exit – that is, during the repatriation of data and workloads – has little negotiating leverage left. Much, however, can still be shaped at the time of contract signing or renewal. For companies with ISO 27001 certification, this has even been mandatory since 2022: the standard requires security requirements for cloud services to be defined before the service is used. The article names six questions that should be clarified early on for this purpose.
First: Who controls the provider? The server location alone says little – what matters is which corporate group and which jurisdiction the provider is subject to. Even European providers who operate their platform on AWS, Azure, or Google Cloud can bring US legal dependency into the house via the supply chain. It becomes problematic when the control structure changes subsequently, for example through the acquisition of a European provider by a US corporation: the data stays in place, but control shifts abroad. Without a contractual obligation to disclose changes to the control structure, the customer lacks options for response in a worst-case scenario.
Second: How does the provider handle access from third countries? If support teams in third countries handle technical incidents, it should be disclosed which roles access which data, how this is logged, and whether a contractual limitation to European locations is possible. A far more significant case is when a foreign authority requests customer data: the US CLOUD Act can obligate providers under US jurisdiction to hand over data even if it is stored on European servers – whereas the GDPR does not permit disclosure based solely on such an order. Since responsibility for data-protection-compliant use remains with the customer organization, the contract should obligate the provider to provide notification where permissible, to limit disclosure to the necessary extent, and to make use of available legal remedies.
Third: Can the provider technically access the data? The article distinguishes between the assurance “We do not access it” and the technical state “We cannot access it.” Only if the provider can neither read plaintext data nor use the encryption keys is it unable to hand over readable content even when ordered to by an authority. If, on the other hand, a technical access path exists, it is solely the contract and the provider’s internal processes that determine whether and how it is used.
For CISOs, the list of questions provides a basis for contract negotiations and due diligence reviews in cloud procurement, as well as for documentation within ISO 27001 audits. The points mentioned – control structure, third-country access, and technical access capabilities – can be adopted as evaluation criteria in existing provider assessments and contract templates before a long-term commitment arises.
Source: www.it-daily.net · Published August 14, 2026
Lumi AI News — AI-assisted curation pursuant to Art. 50 EU AI Act. Paraphrasing and classification by Lumi News Pipeline v1.8.3.