Why Data Residency Alone Does Not Make a Sovereign Cloud

Short answer: Sovereign cloud is less about where your data sits and more about which legal regime governs the control plane, the encryption keys and the operations team that manage it. Even if the server is in Türkiye, when identity management, security policy and scaling decisions flow to a parent region abroad, only your data plane has been localized. The most practical test of any sovereignty claim is the disconnection scenario: if the link to the parent region goes down, can you still operate and intervene in your own infrastructure?

Why sovereign cloud is on the agenda right now

2026 is the year the sovereign cloud debate moved from marketing slogan to concrete frameworks. On 15 January 2026, AWS launched the AWS European Sovereign Cloud in Brandenburg, Germany: an investment of more than 7.8 billion euros, operated exclusively by EU residents, with a commitment to run indefinitely even if connectivity to the rest of the world is cut. When a hyperscaler sells a "keeps running even when disconnected" guarantee through a separate legal entity, it is the clearest signal yet that sovereignty has become a negotiable customer requirement.

The European Commission, for its part, published its Cloud Sovereignty Framework on 1 June 2026, making that requirement measurable, and in April 2026 concluded a 180 million euro sovereign cloud procurement built on it. The agenda in Türkiye is moving in the same direction: the 2026-2030 AI Vision presented around GITEX AI Türkiye on 9-10 September 2026 set a target of 1 GW of data center capacity by 2030 and at least 10 billion dollars of private investment. Local providers are also positioning for this market with September announcements of sovereign control planes and sovereign AI architectures.

The practical consequence for an IT decision maker is simple: over the coming quarters you will see the word "sovereign" in every vendor deck. The purpose of this article is to make clear which questions to ask when you do.

Data plane localization versus real sovereignty

Cloud infrastructure has two distinct layers. The data plane is where your workloads actually run and your data sits. The control plane is where resources are created, identity and access are managed, security policies are distributed, encryption keys are handled, and monitoring and scaling decisions are made. The same distinction is now at the center of the debate in Türkiye: the server may be in Türkiye, but if those decisions flow to a parent region abroad, the only thing that has been localized is the data plane.

Two scenarios show this is not an abstract legal debate. The first is the sanctions and access scenario: the company operating the control plane is subject to the court orders and sanction regimes of its own jurisdiction, and the physical location of your data does not remove that obligation. The second is the operational scenario: if, when the link to the parent region drops, you cannot start a new virtual machine, revoke an access key or change a security policy, then at the moment of an outage the management of your infrastructure is effectively out of your hands. The fact that AWS announced indefinite disconnected operation in its European Sovereign Cloud as a capability requiring dedicated engineering is an admission that standard cloud architecture does not have it.

What the EU's 48-criterion framework actually measures

The European Commission's framework turns sovereignty from a single yes-or-no question into 48 criteria across eight categories: strategic, legal and jurisdictional, data and AI, operational, supply chain, technological, security and compliance, and environmental sustainability. The result is summarized in assurance levels called SEAL: SEAL-2 represents data sovereignty, SEAL-3 technological autonomy and SEAL-4 full sovereignty. The Commission recommends the framework not only for its own procurement but for use by any organization, public or private. In parallel, the draft Cloud and AI Development Act published in June 2026 aims to make similar tiers mandatory in public procurement.

For an organization in Türkiye, the value of this framework is not one-to-one adoption but inheriting the question set. A vendor claiming "sovereign cloud" can now be evaluated not through a marketing page but by demanding concrete evidence in each of the eight categories. Which country holds jurisdiction, where the operations staff sit, which critical components in the supply chain depend on whom, who holds key management: each of these is now a measurable criterion.

What Turkish regulation already requires

Sovereign cloud may look like a new concept for Türkiye, yet sectoral regulation has been enforcing a de facto residency regime for years. Data localization provisions in Turkish law cover a wide area:

Banking regulation requires banks to keep their primary and secondary systems inside the country; a similar obligation applies to payment and electronic money institutions.
Electronic communications providers must store traffic and location data domestically; capital markets and insurance rules also impose in-country system requirements.
Public institutions are obliged, under Presidential Circular 2019/12 and the Information and Communication Security Guide, to keep critical information and data in secure environments inside the country.
On the personal data side, Article 9 of the KVKK, amended in 2024, eased cross-border transfers through instruments such as standard contractual clauses; that easing, however, did not remove the sectoral residency obligations above.

The picture is this: the personal data transfer regime is softening while sectoral and public-sector residency requirements stay in place. Your obligations are therefore spread across different regimes per workload, not concentrated in a single law. We covered the contractual and liability chain dimension of this in our article on supply chain security and KVKK liability.

Not every workload needs the same level of sovereignty

The most expensive mistake in the sovereignty debate is the "make everything sovereign" reflex. Full sovereignty carries a real price in both capacity and cost: the Turkish data center market stood at 715 million dollars in 2025, with 21 active data centers in Istanbul, still far below global hyperscale, and construction costs of 9-10 million dollars per megawatt mean capacity will not grow overnight.

The realistic approach is to tier workloads by their sovereignty requirement:

Systems that regulation explicitly keeps in-country: banking primary and secondary systems, payment infrastructure, critical public data. No debate here; residency and an auditable control plane are mandatory.
Systems where access or outage risk directly hits business continuity: production environments, identity infrastructure, backup and disaster recovery. The critical question here is not location but whether management capability survives a disconnection.
Workloads heavy in personal data but without a sectoral mandate: manageable through KVKK transfer instruments; sovereignty here is a risk appetite decision rather than an obligation.
General-purpose SaaS and collaboration tools: for most organizations full sovereignty does not pay for itself here; data classification and an exit plan provide adequate maturity.

Seven questions to ask your vendor

When you sit through a "sovereign cloud" presentation, insist on clear answers to these:

Where does the control plane run, physically and legally, and which country's jurisdiction applies to it?
Who generates, stores and can access the encryption keys? Is there a customer-held key option?
Which operations keep working when connectivity to the parent region or abroad is lost? Has this scenario ever been tested, and can the test report be seen?
Where are the operations staff with access to the infrastructure employed, and under which legal regime?
Which critical components in the supply chain depend on third-country licenses or support?
If a foreign court or authority demands data, how does the process work and when is the customer informed?
If the contract ends, in what format, within what time and at what cost do you get your data and configuration back?

If several of these draw a "we will have to check" response, what you are looking at is not a sovereignty solution but a localized hosting service. Both are legitimate products; just know which one you are buying.

Conclusion: start from your inventory, not from the label

A sovereign cloud decision is a classification exercise before it is a vendor selection. First, build your workload and data inventory: which system falls under which regulation, and for which one does an outage stop the business within hours. Then place each workload into the tiers above and demand full sovereignty only where it is required. Finally, take the seven-question list into vendor meetings and get the answers written into the contract.

In most organizations the output of this exercise will be a hybrid picture: some workloads in-country with an auditable control plane, some in global clouds under transfer instruments, some in your own data center. Sovereignty is not a label but the sum of decisions made per workload; and organizations that do not make those decisions today will be answering these questions on someone else's schedule in the next audit and procurement cycle.