Control Cannot Be Promised

A supplier can promise not to surrender your data. It can put that promise in a contract. It can build a data centre in your country, appoint local executives, and describe its service as sovereign.

Then somebody asks the supplier what happens if a different government issues a lawful demand.

On 10 June 2025, before a French Senate inquiry, Microsoft’s public-affairs and legal director in France, Anton Carniaux, was asked whether he could guarantee that data entrusted to Microsoft through French public procurement would never be transferred to the US authorities without French authorities’ express agreement.

His answer was short: “Non, je ne peux pas le garantir.” He added that, according to Microsoft’s account, such a transfer had not happened in the circumstances discussed. ¹

The answer did not prove that Microsoft had handed over the data. It revealed the limit of a guarantee.

This is where the word sovereign becomes interesting.

If a capability depends on somebody else’s permission, it may be protected, regulated, or resilient. But the limits of its independence still have to be established.

1. An honest answer at the wrong moment

At the 10 June hearing, Anton Carniaux described Microsoft’s procedures for examining and contesting demands. He disputed the suggestion that Microsoft had cut off the International Criminal Court’s cloud services. The record should be read as testimony, not as proof of a broader alleged service shutdown. ¹

When asked to guarantee that data would never be disclosed under a valid US demand without the French authorities’ approval, he refused to give a guarantee he could not support.

That is not an admission of a past transfer. Nor is it proof that every Microsoft product or configuration has identical exposure.

It is an encounter between two kinds of language.

One is the language of marketing: the service is secure, local, compliant, resilient, sovereign.

The other is the language of authority: a particular government can issue a particular legal instrument against a particular legal entity, and the entity may be obliged to act.

The American statute is unusually direct. Title 18, section 2713, as added by the CLOUD Act, addresses disclosure obligations for material within the possession, custody or control of a covered provider, regardless of whether it is located inside or outside the United States. ²

The statute does not say that every server in Europe is automatically open to US agencies. Equally, putting a server on European soil does not make every associated US legal obligation disappear.

The European Data Protection Board’s final June 2025 guidance on Article 48 GDPR separately addresses the conditions under which organisations can respond lawfully to requests from authorities in third countries. That legal interface is precisely why jurisdiction cannot be reduced to a map pin. ³

The practical question is neither “Do we trust Americans?” nor “Do we trust Europeans?”

It is: which actors have enforceable rights or practical capabilities to make an outcome happen, and what prevents them from doing so?

2. A promise can be meaningful without being absolute

A serious analysis must fairly describe what Microsoft has actually built and committed to.

In April 2025, Microsoft announced five European digital commitments, including European operational governance, additional capacity, data-protection undertakings and a promise to contest orders to suspend European cloud operations. Its 2026 progress update says the resilience commitment has been put into contracts with European governments and the Commission. These are meaningful commercial and legal provisions, not nothing. ⁴⁵

Microsoft also describes an EU Data Boundary for specified enterprise services. Its own documentation explains that the commitment covers defined data classes and services, with limited circumstances in which information may still be transferred outside the geographical boundary or remotely accessed. That nuance belongs beside the headline. ⁶

And in February 2026, Microsoft announced the worldwide availability of Azure Local disconnected operations and Microsoft 365 Local disconnected capability, with local AI models available to qualified customers. A truly disconnected architecture can change the operational risk of an external network shutdown. It is not intellectually defensible to treat an isolated installation as though it were necessarily identical to globally managed SaaS. ⁷⁸

A buyer should therefore distinguish at least three technical situations:

• Connected public cloud. Managed infrastructure with local residency and additional controls; continuing reliance on a provider’s wider cloud operations.
• Locally operated or partner-operated service. Different contractual and governance boundaries; exact underlying control plane, licensing, patching and access paths require inspection.
• Disconnected private deployment. A greater ability to continue specified workloads without cloud connectivity; software entitlements, update supply, replacement components, support, and long-term maintenance still need testing.

These are explanatory categories, not a classification or independent certification of every Microsoft product.

An absolute statement that Microsoft can never provide sovereign capabilities would be as careless as saying any Microsoft service with a European data centre must be sovereign.

The important question is which control, under which conditions, for how long.

3. The moment Europe stopped treating the word as one dimension

On 17 April 2026, the European Commission announced four sovereign-cloud contract awards that Union entities may use under a framework worth up to €180 million over six years. The four recipients included a Post Telecom–OVHcloud–CleverCloud partnership, STACKIT, Scaleway and a Proximus-led consortium using S3NS, Clarence and Mistral, including technology derived from Google Cloud. ⁹

The award is useful because it frustrates two simplistic narratives.

Europe has not decided that all sovereignty is achieved by excluding every American technology. Nor has it decided that a European street address is sufficient.

The Commission applied a Cloud Sovereignty Framework. In June 2026 it explained that this framework uses 48 defined criteria grouped under eight sovereignty objectives: strategic; legal and jurisdictional; data and AI; operational; supply chain; technological; security and compliance; and environmental sustainability. ¹⁰

The approach also distinguishes Sovereignty Effectiveness Assurance Levels, or SEAL. The Commission describes SEAL-2 as data sovereignty, SEAL-3 as a higher technological or resilience level, and SEAL-4 as full sovereignty under its definitions. The minimum required for its 2026 tender was SEAL-2; the three primarily European-technology bids reached SEAL-3, while the consortium using Google Cloud technology reached SEAL-2, according to the Commission. ⁹

The development matters. Procurement officials have an explicit vocabulary, gradations, and a documented way to ask for evidence.

But here is the distinction I want to preserve: a procurement framework measures a provider against specified criteria. It does not prove that every scenario beyond those criteria is impossible, or that an assessment made today cannot become stale after an acquisition, new regulation, or platform redesign.

A score is an aid to a decision.

It is not an exorcism of dependency.

4. The missing word is evidence

We already know that ownership, exitability and operational resilience matter. My earlier volumes The Sovereignty Gap, Open Is Not Sovereign, and The Exit Test examine those problems from different directions. ¹¹¹²¹³

This essay asks something narrower, and perhaps more uncomfortable.

How should a customer verify a supplier’s sovereignty claims before committing critical systems to that supplier?

I propose three steps. They apply to European, Swiss, American, public, and private suppliers alike.

Claim

Write the claim as an observable proposition, with its scope and duration. Not “our cloud is sovereign”. Instead: “For this service version and this data category, all decryption keys required to read customer data are generated and retained under customer-exclusive administration, with no standing provider access.” The example is a question to test, not an assertion about any named vendor.

A different claim might concern jurisdiction, operations, source availability, firmware, identity, networking, or subcontractor authority. Combining them under one adjective prevents meaningful verification.

Control

Identify who can override the proposed boundary.

Who can rotate or recover a key? Who can make a change to the control plane? Who can disable a subscription or licence? Who can shut down identity? Who can deny essential updates? Who can compel a transfer? Who controls the corporate structure of a nominally local operating company?

The fact that a vendor does not ordinarily do something is not the same as the vendor cannot do it.

And the fact that the vendor can do it does not imply abuse. It establishes an authority boundary that must be weighed against the threat model.

Evidence

Ask for the strongest evidence appropriate to the risk.

Some evidence is documentary: statutes, ownership filings, subprocessor registers, contract terms, independent audit scopes, design descriptions and published limitations.

Some must be technical: independently held keys, service behaviour in disconnected mode, recovery procedures, signed artefacts, customer audit logs, witnessed failover exercises, and validation of administrative access boundaries.

Some must be organisational: named decision authorities, renewal rights, separate administrators, documented escalation, costed continuity plans, and review cycles.

This is not a single checklist that fits every service. It is a demand to match the claimed property with a means of falsifying it.

The method’s standard is deliberately awkward: if the supplier became uncooperative tomorrow, which pieces of evidence would still be usable by the customer or an independent assessor?

That question is not an accusation. It is an architectural requirement.

5. The evidence must survive a change of circumstances

Consider a hospital’s document system, a municipal email platform, or an industrial control application.

A provider may honestly intend to operate a service for decades. A government may honestly intend never to order a disruption. A technical team may honestly intend never to alter its interfaces incompatibly.

None of those intentions constitutes a guarantee about the future.

An institution needs to know which properties are independently enforceable and which still rely on commercial and political continuity.

The distinction can be expressed through five procurement questions:

Where? Which data and processing functions are physically resident, and where do exceptions, support paths and metadata travel?

Who? Which entities can exercise corporate, legal or technical authority over the relevant layers?

How? Which actual mechanisms create the boundary—customer-held keys, control-plane separation, independent identity, disconnection, source access, or enforceable governance?

Prove it. What evidence can be inspected, by whom, how often, under which access rights, and with which limitations?

What changes? Which assumptions fail if the vendor is acquired, sanctioned, disconnected, compelled, bankrupt, or simply stops supplying a product?

These questions do not require a preference for local suppliers. A capable foreign supplier might satisfy a particular threat model better than an immature domestic offering. Geography should not conceal poor security, and sovereignty must not be confused with excellence in every engineering dimension.

The reverse is also true: superior features, reliability, compliance certificates or low prices do not settle questions of independence.

NIST’s supply-chain risk guidance addresses the visibility and control problems that arise when systems depend on organisations beyond their operator. It provides a useful discipline, while not certifying any particular sovereign-cloud claim. ¹⁴

6. Rights matter; rehearsal still matters

The EU Data Act contains measures designed to reduce contractual, technical and commercial barriers to switching between data-processing services. Its framework envisages removal of switching charges from 12 January 2027, subject to the regulation’s conditions and exceptions. ¹⁵

DORA, which applies to defined financial entities, requires exit strategies for ICT services supporting critical or important functions and calls for appropriate testing and periodic review. It does not apply indiscriminately to every European organisation. ¹⁶

Neither a right to switch nor a contract clause makes a system instantly portable. I explored that problem at length in The Exit Test. ¹¹

The new point is that the evidence of claimed control should exist throughout the vendor relationship, not be produced for the first time during an emergency.

For a critical service, procurement should define:

• a versioned inventory of sovereignty claims and their limitations;
• an accountable owner for each claim and evidence artefact;
• the circumstances under which the claim must be reassessed;
• independent assurance or witnessed exercises proportionate to risk;
• a documented treatment for unknowns and exceptions; and
• a board-level record of which dependencies were consciously accepted.

This is proposed governance practice, not a statement that European law universally prescribes these six items verbatim.

A robust organisation can knowingly accept non-sovereign elements. The failure is not always dependence. Sometimes it is the failure to know what kind of dependence was purchased.

7. Neither flags nor cynicism

There is a political danger in the sovereignty discussion.

A flag can become a substitute for technical analysis. An operator may be based in Europe yet depend on software, keys, identity, firmware or capital controlled elsewhere. A cloud product may be operated locally while important capabilities remain dependent on an external supplier.

But there is an equal danger in dismissing all contractual and engineering improvements as public relations. A disconnected workload, a locally controlled key, or a genuinely independent operating authority can reduce real risks. Those protections may be partial and still worth implementing.

We should also avoid turning an American jurisdictional question into the assumption that European states never compel disclosure. European suppliers operate under law as well. The task is not to select a nation imagined to have no power over data. It is to identify relevant lawful access pathways, conflicts of law, protections, and the customer’s control under the specific circumstances.

The strongest procurement language does not begin with a supplier’s nationality.

It begins with the question a system is meant to survive.

A multinational professional-services firm moving marketing documents has one threat model. A national emergency communications system has another. An archive holding personally sensitive material may have another again.

They need not all purchase the same sovereignty level. They do need to know which level they are claiming.

8. What survives the supplier?

A supplier’s promise may be genuine and legally enforceable within its scope. A contract may change incentives. An independent audit may improve assurance. A procurement score may make alternatives comparable. None should be discarded.

The mistake is treating any one of them as the final answer.

If we are serious about digital sovereignty, the relevant evidence must be strong enough to survive disagreement about the label.

Ask the architect what remains functional if connectivity disappears.

Ask the lawyer what happens when two jurisdictions disagree.

Ask the operator who holds the administrative authority.

Ask the security team what can be independently inspected.

Ask the buyer which failure scenario justified paying for these controls.

And ask all five to sign the same scoped claim.

Then the adjective starts to mean something.

A provider can promise resilience. It can promise to fight a demand. It can promise to maintain infrastructure. Those promises may matter very much.

But the most consequential properties of sovereignty are not promises to be admired. They are boundaries to be demonstrated.

Control cannot be promised into existence. It has to be shown.

Method and limitations

Research cutoff: 14 October 2026. Public sources only: no supplier tenant, contract, key inspection, disconnected-deployment exercise or independent SEAL test was available for this essay.

• The Senate testimony is about potential lawful compulsion and Microsoft’s stated procedures; it is not evidence of an actual unauthorised transfer involving the customers discussed.
• The French Senate hearing was held on 10 June 2025 according to the primary transcript; some secondary reporting uses a different date. Prefer the primary record.
• CLOUD Act legal exposure varies with the particular entity, architecture, access rights and circumstances; an independently operated fully disconnected installation cannot automatically be treated like an ordinary hyperscale cloud service.
• The EC’s published SEAL awards reflect application of its methodology and are not independent field tests conducted for this essay.
• EU bodies and Switzerland have different legal and procurement regimes; the EU framework can inform Swiss analysis but is not automatically Swiss law.
• “Claim–Control–Evidence” is an original editorial framework, not a recognised certification standard or a replacement for procurement/legal/security advice.

Sources