C3A: what the BSI sovereignty criteria require and how they relate to C5

On 27 April 2026 the BSI published C3A, a set of criteria for assessing the sovereignty of a cloud service. This page explains what C3A is, how it is structured, what it asks of providers and how it relates to C5. For cloud and SaaS providers the last point matters most: C3A builds on C5.

What is C3A?

In the BSI’s words, C3A “provide a set of criteria for assessing whether a given set of cloud services allows for self-determined use within its respective risk context.” The catalogue is a guiding framework for transparency, and “The C3A Framework is not binding in itself” (C3A, section 1.1). The starting point is the shared responsibility model, which limits the decisions a cloud customer can take, including those affecting its sovereignty.

How does C3A relate to C5?

“C3A presupposes that the cloud service provider meets the C5 criteria, as they reflect the security aspect of the sovereignty definition” (C3A, section 1.2). C3A adopts the structure and objectives of the European Commission’s EU Cloud Sovereignty Framework (EU CSF) and leaves out two of its areas on purpose: SOV-7 Security & Compliance, already covered by C5:2026, IT-Grundschutz and the BSI high-availability benchmark (HA-Benchmark kompakt), and SOV-8 Environmental Sustainability, which is outside the BSI’s remit.

Portability is part of self-determined use as well, but it is not in C3A because C5:2026 covers it in the area Portability and Interoperability (PI) (BSI C3A page). For providers this means: the service has to meet the C5 criteria; in practice, a C5 attestation for the service is how this is evidenced.

Which sovereignty criteria are already in C5:2026?

C5:2026 lists “the technical implementation of sovereignty” among its new focus areas (section 1.1). Only PSS-12 is explicitly called “a prerequisite for technical service sovereignty”; the other links in this table are our own, based on criterion titles and content.

Our view: if PSS-12, GC-01, GC-05, INQ, CRY-18/19 and SSO-07 are in place and described in your system description, much of the evidence for a later C3A assessment already exists. What C3A adds is mainly about ownership, staffing and operations.

The six C3A sovereignty areas

Criteria, additional criteria and the EU-or-Germany choice

C3A distinguishes criteria, additional criteria and supplementary information (section 1.3). Additional criteria “raise the bar on existing requirements or expand the scope of autonomy”, and it is up to customers to request them. Many criteria come in two variants: C1 refers to the EU, C2 to Germany, for example for the registered office (SOV-1-02), effective control (SOV-1-03) or operating personnel (SOV-4-01). Data residence (SOV-3-01) does not follow this pattern: its five subcriteria C1 to C5 are separate requirements that differ by type of data (customer data, derived and account data, provider data) and location (EU or Germany), with C1 covering the customer’s ability to check where data is stored (C3A, section 2.3.1).

Several criteria carry a note that restrictions to Germany or the EU “should be justified” and that their implementation, for example in procurement, must be legally permissible. A profile made only of C2 variants is therefore not the default; the customer’s risk analysis decides.

Disconnect, staffing and source code: the most demanding requirements

In our assessment, three requirements change operations and organisation the most. All three are worded as MUST requirements. We only summarise them here; the exact wording is in the original (BSI, C3A v1.0, sections 2.4 and 2.6).

• Disconnect and reconnect (SOV-4-09, SOV-4-10). The provider must be able to cut all non-EU network connections without impairing the service. The catalogue asks for a documented process, tested at least once a year; SOV-4-10 covers reconnecting afterwards. In practice, dependencies on services outside the EU, such as update or licence checks, must be known and under control.
• Staffing (SOV-4-01). Staff with access to the operating infrastructure, customer support and management must be EU citizens with their main residence in the EU (variant C1) or in Germany (variant C2). For providers with support teams in third countries this is an organisational and staffing question that cannot be solved at short notice.
• Source code (SOV-6-01). The provider must keep a source code backup in the EU that is “not older than 24 hours” and contains at least five versions, so that it can run and develop the service without external dependencies, including build and deployment tooling and documentation.

For a SaaS provider on a hyperscaler platform, some of these requirements fall on the platform and some on the provider’s own operations. How to split responsibility and reflect it in the audit scope is covered on C5 scope.

How does a C3A assessment work?

Providers select the criteria their offering meets and “provide the relevant evidence through an audit”; customers use C3A to define their baseline level of sovereignty and, for audited services, assess whether the criteria they care about are met (section 1.4). The BSI intends to publish how C3A audits can be standardised and how reports can be used, comparable to C5. As of 1 November 2026 that guidance was not yet published.

Until then we recommend this sequence:

1. Derive the sovereignty need of the use case from your own risk analysis.
2. Select criteria, variants (EU or Germany) and additional criteria per area and document why.
3. Check the service’s C5 attestation, since C3A presupposes C5.
4. Request and evaluate the provider’s evidence for the selected criteria.
5. Close gaps by contract, for example data location, staffing and disconnect tests.
6. Anchor the requirements in specifications and procurement.

Example: a sovereignty profile for document management in public administration

Fictitious example, not a real client. A German state administration procures a cloud-based document management service for files containing personal data and derives this profile from its risk analysis:

The provider presents its C5 attestation and maps its evidence to each selected C3A criterion. Where it relies on a third-party platform, it needs that platform’s evidence as well; the C5 report lists each subservice organisation with company name, location of processing and storage and an assessment of dependency (C5:2026, section 3.4.6).

Publication status

Checked on 1 November 2026: C3A is available as version 1.0 of 27 April 2026, in English. A German version and the audit guideline have been announced but are not yet listed by the BSI. C5:2026 itself applies to Type 1 dates and Type 2 periods beginning on or after 1 June 2027, and earlier use is permitted (section 3.5 of C5:2026).

How we support providers of sovereign cloud services

C3A presupposes C5, so we start with a C5 gap analysis and, if useful, look at the sovereignty-related C5 criteria and the C3A criteria your customers ask for at the same time. Blackfort Technology does not issue attestations or audit opinions; an independent auditor does. Book an initial call to discuss your sovereignty requirements.