In the early years of cloud computing, architectural discussions revolved mainly around cost, scalability and operational agility. The question of which country, which data center and which legal jurisdiction held the…
In the early years of cloud computing, architectural discussions revolved mainly around cost, scalability and operational agility. The question of which country, which data center and which legal jurisdiction held the data was usually treated as a matter for contract language rather than for infrastructure teams. That separation no longer holds. Stricter rules on cross-border flows of personal data, combined with enterprises running several cloud providers alongside on-premises infrastructure, have turned data sovereignty into a direct architectural design problem.
Hybrid cloud architectures sit at the center of this shift. Running sensitive workloads in an on-premises data center and elastic workloads in the public cloud is a technically sound split. Yet every log line, every backup copy and every support session that moves between these two worlds reopens the question of where the data resides and whose jurisdiction it falls under. In this article we examine data sovereignty together with its legal framework, and then look at how these requirements can be translated into engineering controls enforceable at the infrastructure level.
This article provides an architectural framework and is not a substitute for legal advice. Specific transfer scenarios should be assessed together with the organization's legal and compliance functions.
Three concepts that are often used interchangeably in data sovereignty discussions actually lead to different engineering requirements.
Data residency means storing data physically within a specific geographic region. It usually stems from the organization's own preference or from a customer contract. Its technical counterpart is restricting storage and processing resources to specific cloud regions.
Data localization means keeping certain categories of data within national borders because the law requires it. It differs from residency in that it rests on a legal obligation rather than a preference. Some sector-specific regulations explicitly require certain data to remain in the country.
Data sovereignty is the principle that data is subject to the laws of the country in which it is located. The critical point is that physical location alone is not enough. The law that governs the service provider processing the data is also decisive. The US CLOUD Act, enacted in 2018, for example, allows data under the control of US-based service providers to be disclosed to US authorities under certain conditions, even when it is stored abroad. So even when data sits in a European region, the sovereignty question has to be re-evaluated in light of the provider's structure.
This distinction matters architecturally: residency can be achieved with a configuration setting, while sovereignty requires deeper decisions on key management, access control and provider selection.
Article 9 of Turkey's Personal Data Protection Law No. 6698 (KVKK), which governs transfers abroad, was amended by Law No. 7499, and the new provisions entered into force on 1 June 2024. Under the new structure, transfers rely first on an adequacy decision. Where no adequacy decision exists, appropriate safeguards come into play, such as standard contracts announced by the Board, binding corporate rules, or a written undertaking approved by the Board. Notifying the Authority after standard contracts are signed is also among the obligations set out.
From an engineering perspective, the implication is clear: it must be traceable which data is transferred to which recipient and on which legal basis. In an architecture that cannot maintain a transfer inventory, compliance remains at the level of a declaration.
Articles 44 to 49 of the GDPR govern transfers outside the European Economic Area. The Court of Justice of the European Union's Schrems II ruling (C-311/18) of July 2020 invalidated the EU-US Privacy Shield framework and made it necessary, for transfers based on standard contractual clauses, to separately assess the legal environment of the recipient country. In practice this assessment is known as a Transfer Impact Assessment (TIA). The EU-US Data Privacy Framework adequacy decision adopted in July 2023 created a new basis for transfers to certified recipients.
The most significant architectural consequence of the post-Schrems II era is that technical safeguards are now expected alongside contractual ones. Who controls the encryption keys, and whether data is processed in clear text on the recipient side, have become decisive factors in assessing a transfer.
The area most often overlooked in compliance audits is the set of data copies that exist outside the primary database. A service drawn as a single box in an architecture diagram produces multiple copies of data at runtime.
Application logs, error tracking systems and APM tools can unintentionally carry personal data such as request bodies, user identifiers or email addresses. While the primary database stays in the country, this telemetry may be flowing to a SaaS observability platform abroad.
Disaster recovery strategies by nature encourage geographic distribution. However, a backup replicated to a region in another country is, legally speaking, a transfer. The choice of DR region should therefore be based not only on latency and resilience criteria but also on the legal basis for the transfer.
"Follow-the-sun" support models delivered from different time zones, or a provider's engineers abroad accessing the production environment, can constitute a transfer through remote access even when the data is not physically moved.
The common answer for all three areas is to build the data flow inventory not only at the application level but also at the platform level.
Data sovereignty requirements cannot be sustained while they live only in procedure documents. Infrastructure has to be re-checked with every change. The goal should therefore be controls that are enforced and verified automatically.
Every control starts with classifying the data. Classes such as personal data, special categories of personal data, trade secrets and public data should be defined, and storage resources, queues and data warehouse tables should be tagged with these classes. For an untagged resource, there is no way to determine which rule applies.
Major cloud providers offer mechanisms that restrict, at the organization level, the regions in which resources can be created: Service Control Policies on AWS, Azure Policy on Azure, and Organization Policy with resource location constraints on Google Cloud are examples. These restrictions stop a developer from creating storage in the wrong region for testing purposes before it ever reaches the application layer.
Infrastructure defined as Infrastructure as Code can be checked by policy engines before deployment. Tools such as Open Policy Agent (OPA) automatically enforce rules in the CI/CD pipeline, such as "a storage resource tagged as personal data may only be created in permitted regions" or "a database without a specified encryption key cannot be deployed." Compliance then stops being an audit performed after deployment and becomes a precondition of deployment.
Encryption is the mechanism that determines who can read data, regardless of where it is stored. That is why the real control point in data sovereignty is the encryption keys rather than the data itself.
In the Bring Your Own Key (BYOK) model, the organization imports a key it generated into the cloud provider's key management service. The key's lifecycle is under the organization's control, but the key resides in the provider's infrastructure while in use. In Hold Your Own Key (HYOK) or external key manager models, the key stays in a hardware security module (HSM) under the organization's own control, and the provider has to call this external system for every decryption operation.
HYOK provides a stronger guarantee in terms of sovereignty, because the organization can render data stored in the cloud unreadable by revoking key access. In return, every cryptographic operation becomes dependent on an external system. When the key manager is unreachable, every workload that depends on it stops as well. HYOK should therefore be applied selectively to the most sensitive data classes rather than to all data.
The country in which keys are held matters as much as the location of the data. Key management privileges and data access privileges should also be held by different roles. A structure in which the same administrator can access both the data and the keys weakens the meaning of the technical safeguard.
The most effective principle of a compliance architecture is that data which does not need to cross the border never does.
The GDPR defines pseudonymisation as processing personal data in such a way that it can no longer be attributed to a specific data subject without the use of additional information. In a tokenization approach, sensitive fields are replaced with meaningless references that map to values stored in a token vault inside the country. Analytics or AI workloads abroad work only with tokens, while the mapping table never crosses the border.
There is an important limitation here: pseudonymised data remains personal data as long as re-identification is possible. The technique does not remove obligations, but it significantly reduces transfer risk and the impact of a potential breach.
In log and telemetry pipelines, masking personal data fields at the source is the most reliable approach. When masking rules are applied centrally in the log collection layer rather than scattered across application code, newly added services are covered automatically.
Compliance is not a certificate obtained on a given date but a state that must be continuously verified. Since infrastructure changes every day, compliance must be provable every day as well.
Who accessed which data, from which region and under which authorization should be kept in immutable (append-only) records. In an audit, these records are the primary evidence that the transfer inventory and access policies are actually enforced.
Rules enforced before deployment through Policy as Code must also be verified periodically in the running environment. A manual change made through the console creates drift between the IaC definition and the actual state. Automatically detecting this drift prevents compliance from eroding over time.
For every data flow, the source, destination country, recipient, data class and legal basis should be kept in a single inventory. Standard contract notifications under KVKK and transfer impact assessments under the GDPR can only be managed consistently when this inventory is up to date.
Hybrid cloud architectures promise organizations both flexibility and control. The data sovereignty side of that promise, however, does not materialize by itself. The location of data can be set with a region setting; which jurisdiction the data falls under only becomes meaningful when key management, the access model, provider selection and all data flows are addressed together.
A sustainable compliance architecture is built on classified data, policies defined as code, keys under the organization's control and continuously verified records. Once this structure is in place, regulatory changes require updating policies rather than redesigning the infrastructure each time. Organizations that make data sovereignty a native property of their architecture keep both legal risk and operational uncertainty at a manageable level in an environment where regulations keep changing.