C3A: How cloud sovereignty becomes measurable
Estimated reading time: 19 minutes
How sovereign is our cloud? For a long time, the answer depended on assurances: providers promised sovereignty, but those promises could hardly be verified. With the Cloud Sovereignty Framework, the European Commission created a first framework for this in October 2025. Since April 2026, there has been a German specification: with the C3A, the German Federal Office for Information Security (BSI) has published a criteria catalog that makes cloud sovereignty verifiable.
The C3A are neither a law nor a certification, but a question grid: 30 criteria areas across six domains that let you ask a cloud provider precise questions. In this guide, you will learn what the C3A catalog contains, how it relates to the C5, and how to tailor it to your own use case in five steps.
C3A: The key facts at a glance
- C3A stands for "Criteria enabling Cloud Computing Autonomy". The catalog was published by the BSI; version 1.0 has been available since April 27, 2026.
- While the C5 checks whether a cloud service is operated securely, the C3A check whether you can use it autonomously. Meeting the C5 criteria is a prerequisite.
- The catalog comprises 30 criteria areas in six sovereignty domains. They range from the provider's ownership structure to the question of who can compile security updates in an emergency.
- For cloud customers, the criteria make sovereignty verifiable. You can see which properties a service actually has, compare offerings, and make risk-based decisions on that basis.
- For cloud providers, the C3A serve as a list of requirements. It shows which sovereignty properties an offering already meets and where adjustments are needed.
- Software vendors with a SaaS offering are cloud providers themselves. Many criteria are architecture questions that can be applied directly to your own product.
- The C3A are voluntary and have no regulatory effect. There is no certification, and so far no standardized audit procedure either.
What is C3A?
C3A is short for "Criteria enabling Cloud Computing Autonomy". The catalog is published by the German Federal Office for Information Security (BSI). The first version (1.0) of the C3A was released on April 27, 2026, and is so far available in English only.
The catalog's guiding question is: Can a specific set of cloud services be used autonomously in the respective risk context? To answer it, the BSI breaks down the concept of digital sovereignty into 30 verifiable criteria areas across six sovereignty domains.
For cloud customers, the benefit lies in transparency. The criteria let you see which sovereignty properties a service actually has. For cloud providers, in turn, the C3A form a list of requirements whose fulfillment they can demonstrate, for example through a self-declaration.
The C3A catalog is a diagnostic tool, not a protective shield. It doesn't eliminate dependencies – it makes them nameable and negotiable.
Why the BSI published the C3A
Using a cloud service means handing over decisions. That limits your room for maneuver, including on points that affect your sovereignty: where data is processed, who has administrative access to it, which updates are installed and when. The provider decides all of this, not you. That is exactly how the shared responsibility model is built. Whether a provider gives you the desired degree of self-determination is largely up to the provider. For you to assess this and make risk-based decisions, you need generally accepted, objective and verifiable criteria for self-determination. The C3A provide this criteria catalog and serve as a guiding framework for action.
The topic is gaining relevance due to a comparatively new type of threat: cyber dominance. Since early 2025, the BSI has classified it as the third form of cyber aggression, alongside cyber crime (financially motivated attacks) and cyber conflict (state-directed attacks). It refers to influence exerted through digital products that give manufacturers access to information and control over systems. What makes it special: there is no external attacker. The access is not an exploited vulnerability but an intended function of the product. In the cloud, this weighs particularly heavily: the provider owns the infrastructure, defines functions, controls availability and, if self-protection is insufficient, can even view customer data.
This growing dependency is a driver for companies to expand their digital sovereignty. That is shown by the results of the Lünendonk study "Digital Sovereignty – From Risk to Resilience" (in German), in which MaibornWolff took part. 154 IT and business decision-makers from the DACH region were surveyed. For 95 percent of respondents, reducing excessive dependencies in the IT supply chain is a strong or very strong driver; for 94 percent, it is strengthening resilience in crisis situations.
C3A and C5: How the two catalogs work together
The C5 (Cloud Computing Compliance Criteria Catalogue) answers the question of whether a cloud service is operated in a technically secure way. This is about cloud security. Specifically, it examines criteria such as encryption, access control, logging and incident management. The C3A catalog goes one step further and assesses whether you can also use the service autonomously in the respective risk context.
The two catalogs do not compete; they build on each other: meeting the C5 criteria is a prerequisite for applying the C3A. Security is the foundation, sovereignty the evaluation dimension built on top of it. Without fulfilled C5 criteria, a C3A assessment therefore makes no sense.
For the C5, there is an established attestation procedure through which providers can have their conformity audited and confirmed. For the C3A, such a guideline has so far only been announced: the BSI plans to publish it in a next step, and the verification procedure is to be based on the C5 attestation processes.
The six sovereignty domains of the C3A in detail
In structure and objectives, the C3A are based on the European Cloud Sovereignty Framework (EU CSF). The BSI deliberately leaves out two of its eight areas. Security and compliance (SOV-7) are already covered by the C5:2026, IT-Grundschutz and the HV-Benchmark kompakt. Environmental sustainability (SOV-8) does not fall within the BSI's remit.
That leaves six domains, SOV-1 to SOV-6, across which 30 criteria areas are distributed. The catalog's focus is on operational sovereignty: this domain (SOV-4) alone accounts for one third of the criteria areas.
The catalog distinguishes two levels of requirements:
- Criteria (C) are the actual requirements. They describe specific conditions for autonomous use.
- Additional Criteria (AC) raise existing requirements or extend their scope. Whether you demand them depends on your sovereignty needs.
Good to know: Many criteria come in two variants. C1 describes the EU level, C2 the stricter Germany level. An example: for SOV-1-01 on jurisdiction, C1 requires the provider to be subject to EU law, while C2 requires German law.
| ID | Area | Key question |
|---|---|---|
| SOV-1 | Strategic independence | Who holds ownership and decision-making power over the cloud provider? |
| SOV-2 | Legal framework | Which legal system applies to the provider, and which laws does it have to obey? |
| SOV-3 | Data control | Who manages the cryptographic keys and can therefore access the data? |
| SOV-4 | Operational autonomy | Do operations continue even if the connection to the provider or parent company is cut? |
| SOV-5 | Supply chain | Where do the hardware components used come from, and how transparent is their origin? |
| SOV-6 | Technological control | Can updates and security patches be installed without the original manufacturer? |
SOV-1 Strategic sovereignty
The focus here is not on technology but on ownership structures and legal jurisdictions. The provider must operate under EU or German law, including contract design and dispute resolution. Its registered headquarters must be located in the EU or in Germany. Subcontractors also need to be based in the EU or in Germany.
The provider must be controlled by European or German companies. The C3A catalog looks at actual influence: can companies from outside the EU directly or indirectly influence or determine key strategic, financial or operational decisions?
The provider must keep these arrangements transparent for you and report changes to them 90 days in advance, insofar as they may affect the promised sovereignty properties.
SOV-2 Legal sovereignty
A provider can be based in Germany and still be subject to foreign law. The catalog therefore requires an annual review: Which laws outside the EU have a direct impact on its cloud services? Anything that affects the availability of the services or the confidentiality and integrity of your data is relevant. The provider must assess the resulting risks in a structured way.
On top of this come audit rights. The provider must document procedures that allow the competent cybersecurity authority to verify compliance with the criteria. Where possible, the authority should first draw on existing evidence such as a C5 report or a SOC 2 Type 2 report.
If an EU member state declares a state of defense, the provider must enable it to take over cloud operations, insofar as legally possible. As a rule, this means that documentation, source code and administration tools are available in transferable form.
SOV-3 Data sovereignty
SOV-3 governs two things: where your data is processed and who can read it. Regarding location, the catalog requires traceability. To this end, the provider must offer service options in which individual data classes are processed exclusively in the EU or in Germany.
When it comes to access, three technical requirements apply:
- External key management: Your keys are generated and remain outside the provider's environment. Important: for IaaS and PaaS, the provider must enable the integration of external key management; for SaaS, it is only an additional criterion (AC).
- Your own identity provider: Authentication and authorizations run through your system, connected via established standards. The additional criteria also require open, non-proprietary standards. In addition, the provider must support an authentication model that does not require your accounts to be created or copied in its own directory.
- Client-side encryption: The private key remains with you alone, outside the cloud.
The provider must also enable you to log, retain and view administrative and data access to your customer data. These logs must show the time and identity of the access, as well as the context, insofar as the service captures it.
SOV-4 Operational sovereignty
Operations are where sovereignty either holds or fails. That is why one third of all criteria areas are located here. The most important ones include:
- Personnel: Anyone who has access to the infrastructure, provides support or manages the company must be an EU citizen with their main residence in the EU or in Germany.
- Administrative access: It runs via access paths within the EU. Access from outside must be technically restricted. Only narrowly defined exceptions remain permitted, which must also be approved and monitored.
- Connectivity: The service needs at least two independent connectivity providers, one of which must be from the EU. If one fails, the other must maintain the agreed service levels.
- Security Operations Center: Operated in the EU or in Germany, even in the event of a disconnection.
- Updates: They are received in a secured network zone, checked for known vulnerabilities and released in a controlled manner. A vulnerability counts as known if it is listed in the EUVD or the CVE program.
- Data flows: Transfers to third parties are logged, documented and shown in a data flow diagram. An affiliated company within the same group also counts as a third party.
- Disconnect: The provider must be able to cut all connections to non-EU networks without compromising availability, integrity, authenticity and confidentiality. This must be tested annually.
The counterpart to the disconnect is the reconnect: after up to 90 days of separation, the provider must be able to restore connections and catch up on missed updates. The procedure for installing these updates must also be tested.
SOV-5 Supply chain sovereignty
SOV-5 focuses on suppliers. For each cloud service, the provider must document which software and hardware it uses, which third-party cloud services it needs to deliver the service and which countries its suppliers come from. It must present these lists to customers on request. The provider should record the software components used in a software bill of materials (SBOM); a procedure of comparable quality is also permitted.
In addition, there must be documented processes for export restrictions and supply failures. Capacity management must also take place in the EU or in Germany. The additional criteria in this area go one step further: they require the provider to identify critical dependencies and design its architecture so that components can be replaced. If this is not technically or operationally feasible, the provider must inform you.
SOV-6 Technological sovereignty
What happens if a supplier fails? SOV-6 requires the provider to be able to continue working. To do so, it must keep the source code of its services in the EU. The backup may be no more than 24 hours old and must be available in at least five versions. This also includes all infrastructure-as-code scripts and deployment toolchains, as well as documentation enabling independent further development.
Contingency strategies are required in case third parties drop out. The C3A catalog names three possible approaches: alternative suppliers, in-house troubleshooting or compensating security measures. In addition, the provider's own staff need access to development tools and environments. In case this access is lost, the provider must have documented emergency procedures.
The additional criterion also requires a specific capability: the provider must be able to compile, test and roll out security patches itself in an emergency, with its own specialist staff and its own build environment.
Arrange a free initial consultation with our cloud experts.
Is the C3A criteria catalog mandatory?
No, the C3A criteria catalog is not mandatory. The BSI itself describes the C3A as a voluntary framework for action without regulatory effect. This also means that claims such as "C3A-compliant" are not technically tenable. There is no certification and currently not even a published audit procedure. Anyone who sells or buys the catalog as proof anyway creates a false sense of security.
However, the BSI C3A are useful even without legal force. The value of the C3A catalog lies in the fact that it makes dependencies nameable in a structured way for the first time – by data class, operational function and supply chain tier. A vague sense of unease turns into 30 concrete questions you can ask a provider. Whether and to what extent you are willing to accept a possible residual risk is up to you. It remains your business decision, but thanks to the C3A, you can rely on evidence rather than assurances for the first time.
C3A in practice: How to proceed as a cloud customer
The C3A is not a catalog that a cloud service has to meet as a whole. The BSI explicitly intends you to apply it to your own usage scenario. You identify the criteria that are relevant to your use case and derive the target sovereignty level from them. At the same time, the C3A catalog supports your risk assessment. It shows you where you stand with your current setup and how large the gap to this target level is.
Step 1: Define the use case and data classes
Don't start with the catalog, start with the workload. Which service is used, for which processes, in which service model (IaaS, PaaS, SaaS)? The service model helps determine how much you can influence at all.
Then determine which data classes are involved. The C3A catalog distinguishes four:
- Customer data: what you enter into the service or generate via its interfaces, including credentials
- Derived service data: what results from your usage – logs of access and functions, number and identity of users, configurations
- Provider data: operational data of the service such as utilization, resource allocation, failure rates
- Account data: contract, payment and contact information for administering the service
This distinction later determines your requirements profile, as the catalog grades the data residency criteria by class.
Step 2: Clarify protection needs and risk context
Now for the crucial question: What would be the impact of losing control over this service? Don't just think about data leakage, but also about shutdown, price changes or a forced cloud migration. At the same time, check the regulatory requirements: NIS2, KRITIS obligations or industry-specific regulations raise the required level.
The result is a statement on how much sovereignty this use case needs. An internal test environment, for example, requires a different sovereignty level than a specialist application processing personal data.
Step 3: Select criteria and additional criteria
In this step, you translate your protection needs into concrete requirements. Go through the six domains one by one and check for each criteria area whether it is relevant to your use case at all.
Also decide where the EU level (C1) is sufficient and where you require the stricter Germany level (C2). Add specific additional criteria, such as external key management for a SaaS service.
In the end, you have an individual requirements profile. It is your benchmark when selecting providers and a building block of your cloud strategy. Avoid the reflex of demanding the maximum everywhere: a blanket maximum target level makes procurement more expensive and excludes providers without any significant risk behind it.
Step 4: Assess providers and request evidence
Make the requirements profile the basis of every conversation with providers and every tender. In public procurement, it becomes a suitability or award criterion. Review existing evidence – above all the C5 audit report with its information on jurisdiction, data locations and disclosure powers.
In addition, specifically request what the C3A catalog requires, for example: the list of software and hardware components used, including countries of origin, the list of external services, information on key management and the result of the annual disconnect test. Insist on evidence rather than vague assurances.
Step 5: Document the results and review them regularly
An assessment that nobody can look up helps nobody. Met and unmet criteria should be recorded in writing. Everything providers assure you of in conversations should also be reflected in the final contract.
For every open gap, weigh up whether you want to close it or consciously accept the risk. Two questions help you decide: How likely is the scenario, and what damage (e.g. costs, reputational damage, outages) would occur if it happened?
Some gaps cannot be closed completely but can be mitigated through your cloud architecture. A multi-cloud strategy, for example, distributes critical workloads and thus reduces the consequences of an outage or shutdown.
Important: sovereignty is not a one-off finding. Request the current C5 audit report and the result of the disconnect test every year and, where possible, keep an eye on changes of ownership and new subcontractors.
What the C3A mean for cloud providers
For cloud providers, the C3A criteria are above all an indicator of which sovereignty requirements are likely to gain importance. The BSI also points out that the criteria could in future be declared minimum requirements by legislation or in tenders.
Cloud customers can already use the C3A today to determine their own sovereignty level and measure providers against it. For public-sector clients, proof of sovereignty could become part of bidder evaluation in the future.
A development similar to that of the C5 catalog is conceivable. It also started out as voluntary, then became a procurement standard and is now even enshrined in law in the healthcare sector.
With the C3A, a provider's sovereignty level becomes a verifiable selling point. Especially for public authorities, KRITIS operators and companies with increased protection needs, the catalog is a useful tool for selecting providers. Those who can say early on which criteria they meet stand out from competitors who continue to work only with the vague label "sovereign cloud".
Providers should therefore run the comparison now: Which criteria do we already meet, and where is action needed?
C3A in product development: What software vendors and development teams should check
Formally, the C3A assess cloud services. But anyone who offers their software as SaaS is a cloud provider themselves. That is why, at the latest in tenders from public authorities or KRITIS operators, the questions from the catalog also land on software vendors' desks.
What's more, many C3A criteria concern not the organization but the architecture. They can be applied directly to your own product, whether it is already on the market or still in development. This applies, for example, to the following areas:
- Keys and identities (SOV-3): Can external key management be integrated? Can customers use their own identity provider?
- Disconnect (SOV-4): What happens if US services drop out, such as container registries, auth providers or LLM APIs? Does your product keep running or does it come to a standstill?
- Supply chain (SOV-5): Is there an SBOM? Are critical components encapsulated so that you can replace them?
- Source code and build (SOV-6): Are the repository and build pipeline located in the EU? Can you build and roll out a security patch yourself in an emergency?
Answering these questions at the architecture level means following a sovereignty by design approach. An architecture review shows whether your product is set up this way. In it, we examine your system from the C3A perspective, whether you develop it yourself or together with us. This shows you which criteria it already meets and where you should make adjustments.
Conclusion: The C3A make sovereignty verifiable
The C3A deliver what was missing until now: a common benchmark. Instead of debating the "sovereign cloud", it becomes measurable on the basis of 30 concrete criteria areas. The C3A catalog is therefore a tool for structured assessment, not a compliance checkbox. Based on your use case, data classes and protection needs, you define a requirements profile, measure your provider against it and prioritize the gaps by risk.
Important: The C3A only assess sovereignty, not security. So always use the C5 catalog as well when assessing providers. And because ownership structures, subcontractors and legal situations can change, the result is not a one-off finding and should be reviewed annually.
Not sure where your cloud architecture stands today? This is exactly where MaibornWolff's cloud consulting comes in. We have been helping companies move to the cloud for more than twelve years, and we consider sovereignty from the very beginning. In the Cloud Readiness Check, we analyze your IT landscape and use it to develop a target picture and roadmap for your cloud strategy. As a vendor-independent partner with certifications from STACKIT, Azure and AWS, we advise you neutrally: your requirements determine the platform, not our partnerships.
Book a free consultation with our cloud experts here.
FAQ: Frequently asked questions about C3A
What does the abbreviation C3A stand for?
C3A stands for "Criteria enabling Cloud Computing Autonomy". The criteria catalog was published by the German Federal Office for Information Security (BSI); version 1.0 was released on April 27, 2026.
What is the difference between C3A and C5?
The two catalogs ask different questions. The C5 checks whether a cloud service is operated securely. The C3A check whether you can use it autonomously, i.e. who retains control in the background. Security is the foundation: applying the C3A presupposes that the provider meets the C5 criteria. In practice, this means: ask for the C5 attestation and check with the provider whether the C3A criteria relevant to you are met.
Is there a C3A certification?
No. The C3A are voluntary and have no regulatory effect. There is no certification, and so far no standardized audit procedure either. The BSI has announced a guideline for this. If a provider advertises itself as "C3A-certified" or "C3A-compliant", there is no verified statement behind it.
Which domains do the C3A cover?
The C3A catalog comprises six domains with a total of 30 criteria areas:
- SOV-1 Strategic sovereignty: ownership structure, headquarters, jurisdiction
- SOV-2 Legal sovereignty: non-European laws, audit rights, state of defense
- SOV-3 Data sovereignty: processing location, key management, access logs
- SOV-4 Operational sovereignty: personnel, administrative access, updates, disconnect
- SOV-5 Supply chain sovereignty: origin of software and hardware, SBOM, supply failures
- SOV-6 Technological sovereignty: source code retention, contingency strategies, own build capability
The focus is on SOV-4: one third of all criteria areas relate to operational sovereignty.
Is the C3A available in German?
Not yet. The BSI announced the German version for the end of the second quarter of 2026. As of September 2026, the BSI website still only offers the English PDF version for download.
Do the hyperscalers meet the C3A criteria?
Some of the criteria they cannot meet at all. The market-leading hyperscalers are US corporations, whereas the C3A require EU ownership control and headquarters in the EU (SOV-1). Added to this are operating staff with EU citizenship and EU residence (SOV-4), retention of source code in the EU (SOV-6) and the annual disconnect test: anyone who permanently depends on a connection to a manufacturer outside the EU for updates will not pass it.
The major providers now have European sovereignty offerings that can meet individual criteria. The model is decisive:
If the hyperscaler operates its own EU region, for example through a European subsidiary, the provider still belongs to a group outside the EU. SOV-1 takes this influence into account, even if it is only indirect.
In the partner model, by contrast, the provider belongs to a European company: Delos Cloud, for example, is a subsidiary of SAP and is based on Azure. Here, the hyperscaler Microsoft is only a technology supplier, not the owner or operator. Updates are checked before they are installed. A dependency remains nonetheless: without new updates from Microsoft, the service can only continue to operate to a limited extent.
Whether a hyperscaler is still an option for you depends on your requirements profile. You select the criteria your use case requires. For many workloads, these services remain a viable option. The C3A simply make visible which dependencies you are taking on.
Christian Leinweber is Head of Department in the DevOps&CloudNative division at MaibornWolff, with many years of experience in distributed system architectures, including the design and integration of application landscapes. His passion is the introduction of cloud native systems into structures where not only applications scale, but also the people who build them.