Cloud security in Europe: Why control, compliance, and digital sovereignty matter

In this article, you'll read

• why cloud security in Europe is no longer just a matter of firewalls and encryption, but also of capacity, resilience, and control,
• which legal, organizational, and technical criteria a secure European cloud should meet
• and how companies can identify a secure European cloud solution.

Distrust of the cloud is longstanding and surprisingly persistent. According to the Fortinet Cloud Security Report 2025, 61% of organizations cite unresolved security and compliance concerns as the primary reason for limiting broader cloud adoption. Common questions include how legal requirements can be met consistently and how confidential data can be protected reliably. An even more striking finding is that 92 percent of respondents are concerned about the security of public cloud environments. This is not a niche issue. It represents a significant challenge for IT and security leaders.

These figures show that the old question, "Cloud: yes or no?" was settled long ago. Today, organizations rely on cloud platforms for business-critical applications, sensitive data, and increasingly, AI workloads. The real question is no longer whether to use the cloud, but under what conditions. Where is the data stored? Who can access it? Which legal jurisdiction governs the infrastructure?

What is especially notable is how the concept of security itself has evolved. For many years, security primarily meant protecting systems from cyberattacks. Today, it also encompasses resilience against outages and geopolitical disruption, transparent operating models, and control over data and workloads. The widespread adoption of generative AI is driving another shift. Data is flowing into AI models, computing capacity has become a strategic resource, and new governance challenges are emerging. As a result, security has become a prerequisite for digital sovereignty, not the other way around.

Political initiatives reinforce this shift. Through the proposed Cloud and AI Development Act, the European Union aims to accelerate investment in data centers and computing capacity across Europe while reducing strategic dependence on non-European providers. This article explains the criteria a secure European cloud should meet, which certifications provide meaningful assurance, and why digital sovereignty is becoming a central element of a sustainable cloud strategy.

Cloud security has evolved from a purely technical discipline into a board-level priority. Three developments are driving this shift: the cloud has become essential infrastructure, regulatory and geopolitical pressures are increasing, and AI is raising the demands on capacity and control. As a result, evaluating cloud security now involves more than assessing technical safeguards. It also means considering business continuity, operational resilience, and long-term control.

Cloud platforms provide the foundation for digital business models, data-driven decision-making, modern software development, and artificial intelligence. Unlike a decade ago, the cloud is no longer simply an efficiency tool. It is business-critical infrastructure. If it becomes unavailable, operations can quickly grind to a halt. As organizations become more dependent on the cloud, the criteria for evaluating it also change. Availability, recoverability, and operational control are no longer just IT performance metrics. They are business risks. That is why the focus is shifting toward how a secure European cloud is operated, not simply which features it provides.

With the proposed Cloud and AI Development Act, the European Union is, for the first time, explicitly treating digital infrastructure as a strategic and security-related priority. The initiative seeks to expand Europe's data center and computing capacity, encourage investment, and reduce dependence on a small number of non-European providers. For organizations, the broader message is more important than the legislative details. Cloud capacity made in Europe is becoming a strategic priority supported by public policy. As a result, organizations are likely to gain access to more alternatives and improve their negotiating position with global cloud providers.

Traditional cybersecurity measures, including identity management, encryption, and threat detection, remain essential, but they are no longer sufficient on their own. Organizations must now also answer questions that were once rarely considered part of security. Can sufficient GPU capacity be obtained quickly for AI workloads? Will the platform remain operational if a provider, supplier, or entire region experiences an outage? Can the organization maintain control if political or regulatory conditions change? Capacity, resilience, and sovereignty have therefore become fundamental elements of cloud security. Operating a secure cloud across the European Union now requires all three.

A secure European cloud is defined not by a single feature, but by the combination of legal jurisdiction, operating model, and verifiable control mechanisms. The location of the data centers is the most visible element, but it is far from the most important. The critical question is who ultimately controls the platform and how much of that control customers can independently verify.

A data center in Frankfurt or Berlin is a strong starting point, but it does not guarantee security. What matters is the legal jurisdiction that governs the cloud provider and who has the authority to compel access to customer data. Even when data is stored in Europe, a provider that is ultimately controlled by a parent company outside the EU may still be subject to extraterritorial access requirements. A European data center is therefore a necessary condition, but not a sufficient one. Only when combined with European operator control and clear governance does it constitute a truly secure European cloud.

A secure European cloud should ensure that data processing, storage, and administration take place entirely within the European legal jurisdiction. This requirement should apply not only to production data, but also to metadata, backups, logs, and administrative processes. When these secondary data flows are processed outside Europe, they can create compliance gaps that are often overlooked during audits. A platform that is consistently operated and managed within the EU legal jurisdiction reduces regulatory complexity and lowers the risk of exposure to non-European legal claims.

Security depends on clearly defined and verifiable responsibilities. Organizations should be able to confirm who operates the platform, who has administrative access, and how privileged access is controlled, restricted, monitored, and fully logged. One factor that is often underestimated is the role of local operations teams. When operations, support, and administration are handled by personnel within the EU, and administrative access from outside the EU is not permitted, the risk of extraterritorial influence is significantly reduced. This level of operational sovereignty is increasingly expected by cloud customers.

Cloud providers almost always depend on a supply chain that includes hardware vendors, connectivity providers, software components, and, in some cases, subcontractors responsible for specific platform functions. Transparent supply chains and clearly defined responsibilities, including disclosure of subcontractors and their locations, are therefore essential for trust, compliance, and effective risk management. In regulated industries, this has long been a requirement. In the financial sector, for example, the Digital Operational Resilience Act (DORA) requires organizations to maintain a register of their ICT third-party providers, including subcontractors that support critical or important functions. Meeting this obligation depends on providers supplying complete and accurate information about their own subcontractor chains. At this point, supply chain transparency becomes more than a trust-building measure. It becomes a regulatory documentation requirement.

Digital sovereignty is often reduced to the idea of "keeping data in Europe," but that definition is too narrow. True sovereignty is an organization's long-term ability to retain control over its data, applications, and operations, both today and in the future, including during provider migrations or changes in political or legal conditions. Security and sovereignty are closely connected. Without strong security, there can be no sovereignty. Without meaningful control, security remains little more than a promise.

It is helpful to think of sovereignty as comprising several dimensions: data sovereignty, operational sovereignty (covering operations and personnel), and technological sovereignty (covering portability and independence from individual vendors or supply chains). As the discussion around digital sovereignty continues to evolve, additional dimensions are increasingly being considered, including legal sovereignty, assurance sovereignty, supply chain sovereignty, geopolitical sovereignty, and network sovereignty.

Data residency, which defines where data is stored, is only the starting point. Data sovereignty goes further. It includes control over who can access data, under what conditions, how data flows are tracked, and how access controls are enforced technically. In practice, this means defined storage locations, transparent and fully logged data flows, customer-controlled encryption, and the assurance that even the cloud provider cannot access unencrypted data without authorization. Only this combination of measures transforms data residency into genuine data sovereignty.

In addition to data location, the provider's operating structure plays a key role in determining sovereignty. Organizations should be able to identify which legal entity operates the platform, understand its ownership structure, and assess whether it is subject to extraterritorial legislation. A provider headquartered in Europe and operating under European control, with clearly defined governance, audit rights, and accountability, offers structural advantages over a European subsidiary of a non-European parent company. This distinction highlights the difference between providers that treat sovereignty as a legal and organizational principle and those that limit it to technical security features.

International dependencies create both legal and operational risks, and these risks extend beyond the possibility of government access to data outside Europe. The supply chain also matters. Hardware, firmware, and critical software components are often sourced from third countries. Export controls, trade restrictions, embargoes, or supply disruptions can directly affect the availability of computing capacity, particularly GPUs needed for AI workloads. Assessing third-country dependencies therefore requires evaluating both potential access to data and the resilience of technology supply chains. Community-driven technologies such as OpenStack can help reduce these dependencies.

Exit capability is not a convenience feature. It is a fundamental requirement for sovereign cloud adoption. Organizations that cannot migrate their data and workloads to another provider within a reasonable timeframe and at a reasonable cost cannot be considered truly sovereign, regardless of how many security features the platform offers. A robust exit strategy should therefore be part of every cloud strategy from the outset. It should include open standards and APIs, documented data formats, clearly defined migration processes, and regularly tested migration and repatriation procedures. Regulation reinforces this requirement. BaFin, for example, explicitly requires documented exit strategies for critical outsourcing arrangements.

Responsibility cannot be outsourced to the cloud. Even when organizations entrust their data and applications to a cloud provider, they remain accountable to regulators, customers, and data subjects. For this reason, being subject to European law is more than a compliance consideration. It determines how easily an organization can demonstrate that it meets its legal and regulatory obligations.

The GDPR establishes legally binding, EU-wide requirements for processing personal data, covering everything from lawful processing and purpose limitation to data subject rights and breach notification. For cloud services, this means providers acting as data processors must clearly document where and how personal data is processed and actively support customers in meeting their compliance and documentation obligations. A cloud platform that not only claims GDPR compliance but demonstrates it through contractual commitments, technical safeguards, and independently auditable evidence can significantly reduce an organization's compliance burden.

Even when using cloud services, organizations remain the data controllers under the GDPR. As a result, a comprehensive Data Processing Agreement (DPA) is essential. It should clearly define instructions for processing, technical and organizational safeguards, subcontractor arrangements, and procedures for responding to data subject requests. Documentation must also withstand regulatory scrutiny. DPAs, records of processing activities, certifications, and audit reports should all be complete, current, and readily available. Providers that offer standardized, up-to-date documentation reduce the need for customers to assemble this evidence themselves.

Assessing international data transfers remains one of the greatest challenges in modern cloud strategies. Organizations need to know which data leaves Europe, what access rights authorities in third countries may have, and the legal basis for any international transfers. Following the Schrems decisions, and despite the EU-U.S. Data Privacy Framework, this area continues to present legal uncertainty. A secure European cloud minimizes these risks by avoiding transfers to third countries whenever possible. Data that remains within Europe is not subject to foreign government access regimes.

Organizations often manage data protection, cybersecurity, and digital sovereignty separately through different functions, including data protection officers, CISOs, and IT strategy teams. In practice, however, these areas are closely connected. A data protection breach is often the result of a security incident, while inadequate operational control can undermine both security and compliance. Effective protection requires these three perspectives to work together. Encryption strengthens security, customer-controlled encryption keys reinforce sovereignty, and documented processing supports data protection. A secure European cloud distinguishes itself by integrating all three rather than treating them as separate concerns.

Trust is valuable, but independent verification provides greater assurance. Because customers rarely have direct visibility into a provider's internal operations, audits, certifications, and independent testing play a critical role. It is also important to understand what different forms of assurance actually demonstrate, since not every certification or compliance mark provides the same level of confidence. Independent oversight bodies, including the European Supervisory Authorities (ESAs), also contribute to confidence in Europe's cloud ecosystem through their regulatory oversight.

Independent audits and certifications allow organizations to evaluate a provider's security posture using objective criteria rather than relying solely on marketing claims. The scope of an assessment is just as important as the assessment itself. Organizations should verify which services, geographic regions, and time periods are covered. A certification that applies to only part of a provider's services offers only limited assurance. Organizations may also perform or commission their own security assessments. Reputable cloud providers regularly conduct independent penetration tests and, upon request, make reports or executive summaries available to customers.

The Cloud Computing Compliance Criteria Catalogue (C5), developed by the German Federal Office for Information Security (BSI), has become one of the leading cloud security frameworks in German-speaking markets. Strictly speaking, C5 is not a certification. Instead, it provides the basis for an independent audit performed under internationally recognized assurance standards. A Type 2 attestation offers particularly strong assurance because it confirms not only that security controls have been designed appropriately, but also that they have operated effectively over an extended period. A current C5 Type 2 attestation covering the provider's full range of services is therefore one of the strongest indicators of a secure cloud platform in Europe.

The European Cybersecurity Certification Scheme for Cloud Services (EUCS), established under the EU Cybersecurity Act, is intended to create a common European framework for assessing cloud security and digital sovereignty. It is important to distinguish the framework from a certification. Unlike ISO/IEC 27001 certification or a C5 attestation, EUCS is not currently a certification that providers can obtain. It is the certification scheme itself, which is still being finalized. In particular, the proposed sovereignty requirements have been the subject of extensive debate. EUCS is therefore best understood as an emerging European reference framework. Until it is fully implemented, organizations should base security assessments on established evidence such as C5 attestations and ISO/IEC 27001 certification.

Internationally recognized standards provide additional assurance. ISO/IEC 27001 certifies that an organization operates an effective information security management system (ISMS) and is recognized worldwide. SOC 2 reports (Type I and Type II) assess the effectiveness of controls against the Trust Services Criteria and are widely used, particularly in North America. Industry-specific certifications also play an important role in sectors such as healthcare, financial services, and government. Ultimately, the strength of a provider's security assurance depends not on the number of certifications displayed, but on the relevance, scope, currency, and depth of the assessments supporting them.

Legal and organizational safeguards establish the framework, but technology must enforce them. The following elements are best understood not as an architectural blueprint, but as the security and control layers a platform needs to turn governance requirements into practical protections. Equally important is how these capabilities are delivered. Rather than requiring organizations to build and maintain them internally, a modern cloud platform should provide them as managed services. Management and security services are a key differentiator. For example, T Cloud Public offers integrated services such as Identity and Access Management (IAM), the Log Tank Service, and the Host Security Service, while also allowing customers to integrate selected third-party services where appropriate.

Identities have become the new security perimeter. Today, most attacks begin with compromised credentials rather than breached firewalls. A modern Identity and Access Management (IAM) solution ensures that only authorized users and services can access systems and data. It should enforce core security principles, including multi-factor authentication, role-based access control based on the principle of least privilege, separation of duties, and dedicated management and monitoring of privileged accounts through Privileged Access Management (PAM). When delivered as a managed platform service, IAM enables these controls to be applied consistently across all workloads.

Encryption is essential, but it is only one component of a comprehensive security strategy. Data should be encrypted both in transit and at rest. The greatest increase in sovereignty comes from control over encryption keys. Key management services that support Bring Your Own Key (BYOK) or Hold Your Own Key (HYOK) allow customers to retain control of their cryptographic keys. Ideally, this prevents even the cloud provider from accessing unencrypted data. Confidential Computing extends this protection further by using hardware-based Trusted Execution Environments (TEEs) to secure data while it is being processed in memory, addressing one of the last remaining gaps in traditional encryption approaches.

Public cloud environments allow multiple customers to share the same physical infrastructure. Effective tenant isolation must ensure that one customer cannot access another's data or resources at the compute, network, or storage layer. Common approaches include isolated virtual private clouds (VPCs), microsegmentation, dedicated encryption keys for each tenant, and, for highly sensitive workloads, dedicated infrastructure or even dedicated hardware. For organizations with stringent compliance requirements, the ability to demonstrate effective isolation is often a key factor when selecting a cloud platform.

Organizations can respond only to threats they can detect. Comprehensive monitoring and tamper-resistant logging therefore form the foundation of effective threat detection and are required by many regulatory frameworks. Rather than developing these capabilities internally, organizations can rely on platform-provided management and security services. This is another important differentiator. For example, T Cloud Public provides centralized log collection, storage, and analysis through its Log Tank Service, workload protection and monitoring through the Host Security Service, and activity tracking through services such as Cloud Eye and Cloud Trace to support comprehensive audit trails. Together, these services consolidate distributed operational data into a unified security view, enabling faster and more structured incident response.

Security extends beyond preventing attacks. It also includes the ability to recover quickly from outages, ransomware incidents, or other disruptions. An effective resilience strategy defines clear Recovery Point Objectives (RPOs), specifying the maximum acceptable data loss, and Recovery Time Objectives (RTOs), defining how quickly services must be restored. Key elements include regularly tested backups, immutable and logically isolated backup copies to protect against ransomware, and replication across multiple availability zones or regions. Recovery procedures should also be tested regularly. A disaster recovery plan that exists only on paper provides limited value during an actual incident.

Modern applications depend heavily on third-party software components, including open-source libraries, container images, and automated CI/CD pipelines. As a result, attackers increasingly target the software supply chain. Effective software supply chain security includes maintaining a Software Bill of Materials (SBOM), continuously scanning for vulnerabilities, verifying digitally signed software artifacts, and securing build pipelines. For secure cloud infrastructure in Europe, supply chain transparency also includes understanding where critical components originate so organizations can identify dependencies and evaluate potential risks related to trade restrictions or supply disruptions.

AI does not fundamentally change security requirements, but it amplifies them in several important areas. Three characteristics distinguish AI workloads from traditional applications. They process large volumes of often highly sensitive data, require scarce and expensive GPU resources, and introduce new governance requirements for models and their use. These factors define the additional capabilities a secure European cloud should provide for AI workloads.

General statements about AI security are rarely helpful. Instead, organizations should focus on the specific points where sensitive data enters AI workflows. Three common examples stand out. First, training and fine-tuning datasets may contain proprietary information, trade secrets, or personal data. Second, prompts and contextual information entered during day-to-day use may include confidential internal documents. Third, retrieval-augmented generation (RAG) systems often access large portions of an organization's knowledge base or document repositories. In each case, the same security requirements apply as for any other sensitive data. The difference is the scale of the data and the new ways in which it is processed and accessed. Understanding where this information is processed and who can access it is therefore a legitimate security concern.

Security and compliance requirements for computing infrastructure are well established. Generative AI changes the picture by dramatically increasing demand for GPU resources and making their availability a strategic concern. GPUs are expensive, scarce, and subject to supply chain constraints and export controls. Organizations that depend on a small number of non-European suppliers face both supply risks and sovereignty concerns. At the same time, GPU-based AI workloads require the same security controls as other sensitive workloads, including strong access controls, tenant isolation, and comprehensive logging. The challenge is therefore not that compliance suddenly becomes more important. Rather, it is the combination of growing demand, limited GPU availability, and increasingly sensitive data flows.

AI governance is often framed as a need for "explainability," but that concept is difficult to define and verify in practice. More practical governance focuses on operational controls. Organizations should be able to determine who can access each model and its associated training data, track the origin and movement of data throughout the model lifecycle, maintain audit logs showing who accessed which models and when, and identify the exact model version used at any point in time. These controls can be implemented and verified technically. Unlike broad demands for explainability, they provide concrete, auditable governance. A secure European cloud should make these capabilities available as integrated platform services.

Sovereign AI refers to AI environments in which organizations retain control over their data, governance, and compliance obligations throughout the AI lifecycle. Achieving this requires infrastructure that combines the characteristics discussed throughout this article: operation under European legal jurisdiction, controlled access to GPU resources, customer-controlled encryption keys, and comprehensive governance capabilities. For many organizations, particularly those operating in regulated industries or the public sector, a secure European cloud is therefore a prerequisite for deploying AI with sensitive data. Sovereign AI is not a standalone product. It is the outcome of building AI on a platform designed around the principles of digital sovereignty.

In principle, every organization benefits from greater control and verifiable security. For some sectors, however, a secure European cloud is more than a strategic advantage. It is a necessity, driven by regulatory requirements, the sensitivity of the data they process, or the need to protect intellectual property.

Government agencies and public institutions face particularly stringent requirements for data protection, transparency, and digital sovereignty. They are also under growing political pressure to ensure that citizens' data remains under European control. Initiatives such as national government cloud strategies and the broader goal of sovereign public-sector cloud platforms make cloud selection a strategic decision. Compliance alone is not enough. Organizations must also be able to demonstrate independence from non-European legal access rights.

Healthcare data is among the most sensitive categories of information and is subject to strict legal and regulatory requirements, including the GDPR, medical confidentiality obligations, and sector-specific rules for healthcare providers and research institutions. At the same time, electronic health records, telemedicine, and AI-assisted diagnostics are accelerating digital transformation. A secure European cloud provides the foundation for balancing both priorities: protecting sensitive health data while enabling modern, data-driven healthcare.

Banks, insurance companies, and other regulated organizations must demonstrate robust security, compliance, and risk management. Since early 2025, the Digital Operational Resilience Act (DORA) has introduced mandatory requirements for ICT risk management, registers of ICT third-party providers, documented exit strategies, and threat-led penetration testing. A secure European cloud solution with a transparent supply chain, independently verified security controls, and proven exit capabilities can significantly simplify compliance with these obligations.

Organizations that operate critical infrastructure face increasingly demanding cybersecurity and resilience requirements. The NIS2 Directive significantly expands the range of organizations covered and strengthens obligations related to risk management, incident reporting, and supply chain security. National implementing legislation further defines these requirements. For affected organizations, selecting a demonstrably secure, resilient cloud platform that operates under European law becomes a key component of regulatory compliance.

Even outside heavily regulated industries, protecting intellectual property, research data, engineering designs, and AI models is becoming increasingly important. For research-intensive organizations, design files, testing data, proprietary algorithms, and trained AI models often represent core business assets. Unauthorized disclosure could have serious commercial consequences. A secure European cloud infrastructure that combines data sovereignty with controlled AI capabilities can therefore become a significant competitive advantage.

The discussion is often presented as a choice between European cloud providers and global hyperscalers. In practice, that oversimplifies how most organizations operate. The objective is not to choose one over the other, but to match each workload with the platform that best meets its technical, regulatory, and business requirements. As sovereignty considerations become more important, cloud architecture decisions increasingly depend on workload characteristics rather than provider size.

Global cloud providers offer substantial advantages, including worldwide infrastructure, extensive service portfolios, rapid innovation, and virtually unlimited scalability. These strengths make them well suited to globally distributed applications, less regulated workloads, and organizations seeking to deploy new services quickly. These advantages are well established and should be recognized in any balanced assessment.

For highly sensitive workloads, additional questions become critical. Which legal jurisdiction governs the provider? Who can require administrative access to customer data? Will services remain available during geopolitical or regulatory disruptions? Technical security alone is no longer sufficient. Organizations also need structural control over where and how critical workloads operate. This is where the distinction becomes clear between providers that view sovereignty as a legal and organizational principle and those that focus primarily on technical security capabilities.

European cloud providers often concentrate on the areas where sovereignty matters most: data protection, regulatory compliance, data residency, European ownership and operation, and locally based operations teams. Many can contractually guarantee that cloud operations and administration remain entirely within the European Union while providing transparency throughout their supply chains. Ultimately, what makes a European cloud both secure and sovereign is not any single security feature. It is the combination of European legal jurisdiction, operational governance, and independently verifiable control mechanisms.

Most organizations now use multiple cloud platforms to balance innovation, flexibility, and regulatory compliance. A common strategy is to assign workloads according to their level of sensitivity. Highly regulated or business-critical workloads remain in a sovereign European cloud, while less sensitive or globally distributed applications run on global hyperscale platforms. The success of this approach depends on portability. Open standards and well-defined interfaces help ensure that multicloud strategies increase flexibility rather than creating a new form of vendor lock-in.

Terms such as “sovereign” and “secure” are often used loosely, leading to assumptions that can create a false sense of security. Four misconceptions are particularly common.

One of the most common assumptions is that servers located in Germany are automatically secure. In reality, location alone says little about operator control, administrative access, encryption, or operational governance. A European data center operated by a subsidiary of a non-European parent company may still be subject to foreign legal access requirements. Data residency is an important prerequisite, but it is not sufficient on its own.

GDPR compliance focuses on protecting personal data. While this is essential, it represents only one aspect of cloud security. The GDPR does not address issues such as operational resilience, ransomware protection, software supply chain security, or digital sovereignty. A service may fully comply with the GDPR while still having significant operational or security weaknesses. Data protection and cloud security overlap, but they are not the same.

Operating workloads in an internal or regional data center does not automatically create digital sovereignty. What matters is who controls the environment, who manages the encryption keys, who has administrative access, and where operational responsibilities reside. Sovereignty results from legal authority, organizational governance, and operational control, not simply from the physical location of servers.

The assumption that private clouds are inherently more secure rarely reflects reality. A poorly maintained private cloud running outdated software with limited security resources may be significantly more vulnerable than a professionally managed public cloud supported by certified security processes, continuous monitoring, and automated patch management. Ultimately, security depends on architecture, operational processes, governance, and ongoing investment, not on the deployment model itself.