With the C3A, the BSI has presented concrete test criteria for cloud sovereignty for the first time. What this means for regulated industries - and where the limit lies for US hyperscalers.
The German Federal Office for Information Security (BSI) has presented a proposal that many in the industry have been waiting for: the "Criteria Enabling Cloud Computing Autonomy", or C3A for short. For the first time, there is now a concrete, technically sound test catalog that no longer treats cloud sovereignty as a political buzzword, but defines it as a measurable requirements profile. The timing is no coincidence - the EU Commission intends to present the Cloud and AI Development Act (CAIDA) on May 27, and the BSI is positioning itself as the content provider for the European debate with the C3A.
Why is the previous C5 catalog no longer sufficient?
The BSI's Cloud Computing Compliance Criteria Catalogue (C5) has been the reference framework for information security in the cloud for years - and is now even enshrined in law, for example in the Social Code for Health IT. What the C5 covers is clear: encryption, access control, logging, incident management. What it does not cover is the question of who actually controls a cloud service in an emergency.
This is precisely where the BSI comes in with the C3A. "We are looking for technically viable solutions that formulate concrete conditions," says Thomas Caspers, Vice President of the BSI. Less diplomatically translated: The BSI wants to change the sovereignty debate from marketing promises to testable facts - before the EU Commission makes its own specifications with the CAIDA.
What exactly do the C3As check?
The C3As supplement the C5 with criteria that address three central sovereignty risks: Dependence on non-EU jurisdiction, lack of control over operations and personnel, and lack of decoupling capability. Some of the specific requirements defined by the BSI:
Disconnectability (SOV-4-09-C): What happens if a cloud service is disconnected from its non-European operator platform? According to the C3A, operations must continue - without any loss of availability, integrity, authenticity and confidentiality. It is not enough to claim this in theory: the operator must maintain a documented decoupling process and test it at least once a year. Anyone wishing to fulfill the extended criterion SOV-4-09-AC must share the results of these tests with the responsible IT security authority on request.
Personnel requirements (SOV-4-01-C1 / C2): The basic criterion SOV-4-01-C1 requires that all employees with logical or physical access to operating resources have EU citizenship and an EU residence. The stricter variant SOV-4-01-C2 further restricts this: Residence within the Federal Republic. The latter is aimed at high-security environments - security authorities, the German armed forces, secret protection.
Jurisdiction: Providers must not be subject to any non-EU jurisdiction. No CLOUD Act, no Foreign Intelligence Surveillance Act (FISA) Section 702, no extraterritorial disclosure obligations to third countries.
What the C3As are based on - and what practical experience is incorporated
The BSI did not design the C3A on the drawing board. Six of the eight criteria are based on preliminary work by the EU Commission's Directorate-General DIGIT, which was originally developed for the Commission's own IT infrastructure. In addition, there is the experience gained from specific sovereignty projects in recent years by the BSI and the French security authority ANSSI (Agence nationale de la sécurité des systèmes d'information).
Thomas Caspers is open about the lessons learned: "Using the AWS European Sovereign Cloud as an example, we have seen how many mechanisms play a role in keeping a cloud operational. However, it will not be possible to continue operating such offerings for years if they are completely decoupled." This is a remarkably clear statement from the BSI Vice President - and in fact a restriction of the promises of sovereignty that US hyperscalers such as Amazon Web Services (AWS), Microsoft and Google are currently making for their European "Sovereign Cloud" offerings.
Anyone who has followed the debate surrounding the AWS European Sovereign Cloud will be familiar with the pattern: promises of billions in investment, separate infrastructure, EU personnel in operations - but in the end, the question remains as to whether the parent company in the USA will have access or can deactivate the service.
Why the timing is strategic: CAIDA and the EU debate
The C3A publication is directly linked to the planned CAIDA. The EU Commission under Vice President Henna Virkkunen wants to use CAIDA to define clearer criteria for cloud sovereignty at European level. Observers expect an intensive lobbying and negotiation phase to begin after the draft is presented at the end of May - between member states, the European Parliament and industry.
The BSI is taking a deliberate approach with the C3As: Whoever sets the frame of reference before Brussels decides shapes the debate. If the C3A criteria are included in the annexes of EU regulations such as the Network and Information Security Directive 2 (NIS2) or the Cybersecurity Act, they would in fact be binding throughout Europe. Martin Bierwirth, Head of the Cloud Security Division at the BSI, puts it in perspective: The C3As are "not binding in themselves", but "could be declared minimum requirements in the context of legislation or tenders."
The EU Parliament has already set the political direction with its resolution on "European technological sovereignty and digital infrastructure" from January 2026 - including the call for a stronger European cloud infrastructure and open standards.
What do the C3As mean for organizations with sensitive data?
For authorities, critical infrastructure operators (KRITIS), hospitals, law firms and financial service providers, the burden of proof is shifting. Until now, the question was: "Is our cloud provider C5-certified?" In future, the question will be: "Does our cloud provider also meet the sovereignty requirements - and if so, to what level?"
Three consequences are emerging:
Firstly, "Sovereign Cloud" will no longer be enough as a label. Anyone who has to prove in procurement procedures or audits that their cloud service is actually operated in a sovereign manner will need verifiable evidence - disconnect tests, personnel certifications, proof of jurisdiction. The report by the Federal Ministry of the Interior (BMI) has already shown that the storage location alone is not a protective shield.
Secondly, providers are differentiated. The C3As create a scale for the first time. There are basic requirements - and there are stricter requirements for high-security environments. Not every organization needs SOV-4-01-C2, but every organization in regulated industries should know what level they need and what level their provider can deliver.
Thirdly, the pressure on US hyperscalers is increasing. Caspers' assessment that "completely decoupled" offerings on a US basis will not remain operational for years sends a signal: for the highest sovereignty levels of C3A, providers with a US parent company are coming under structural pressure. This concerns not only the CLOUD Act and the associated data access risk - but also the so-called kill switch risk: the possibility that services can be deactivated by export controls, sanctions or license servers from outside.
Where does SecureCloud stand in the C3A criteria?
As a German cloud provider without a US parent company, without third-country capital and without extraterritorial legal ties, SecureCloud GmbH is structurally positioned in such a way that the central C3A requirements are met architecturally:
The entire infrastructure is operated on its own hardware at noris network AG in Nuremberg - with certifications according to TSI Level 4, PCI DSS (Payment Card Industry Data Security Standard) and ISAE (International Standard on Assurance Engagements) 3402. SecureCloud is subject exclusively to German and European law. All employees with access to operating resources are resident in Germany. There is no disconnect scenario as defined by the C3A because SecureCloud does not use a non-European operator platform from which it would have to be disconnected.
There are also existing verifications: BSI C5 certification and ISO 27001 compliance - in other words, the very building blocks on which the C3A is based. For organizations that want to create the C3A test catalog, this is a starting point without structural reservations.
What companies should do now
The C3As are not yet legally binding. But experience with the C5 shows: What begins as a voluntary catalog can quickly become a procurement standard or a legal requirement. Those who position themselves early on can avoid retrofitting costs and tendering risks.
Three steps that make sense now: Check what level of C3A your organization actually needs in view of protection requirements and regulation. Ask your cloud provider specifically about disconnect capability, staff location and jurisdiction - not for labels, but for proof. And document the results: In upcoming NIS2 audits or Network and Information Security Directive 2 (DORA) audits, this could become a test point.
Conclusion
With the C3A, the BSI has presented a catalog that raises the sovereignty debate from the marketing level to the verification level. This is good news for organizations in regulated industries: for the first time, there is a technically sound reference framework for distinguishing between "sovereign" and "allegedly sovereign". For US hyperscalers, things are getting tighter - and for European providers who have implemented sovereignty architecturally instead of just promising it in the sales deck, things are getting clearer. The question is no longer whether cloud sovereignty is coming. The question is how quickly it will become mandatory.