BSI C5 for international SaaS providers entering the German healthcare market

This page is for cloud and SaaS providers headquartered outside Germany, often with a SOC 2 report in hand, who want to serve the German healthcare market. The legal basis itself, meaning who Section 393 of the German Social Code Book V (SGB V) applies to, which attestation types apply when and what alternatives exist, is explained on the Section 393 SGB V page. Here we cover the questions specific to international providers. This is general information, not legal advice.

What C5 is, in one paragraph

C5 (Cloud Computing Compliance Criteria Catalogue) is the criteria catalogue of the German Federal Office for Information Security (BSI). The current version is C5:2026, available in English as version 1.0.1. An independent auditor tests your controls against it and issues a report; the BSI is not involved in the audit and keeps no list of attested services. There is no C5 certificate, only attestation reports of Type 1 (design at a point in time) or Type 2 (design and operating effectiveness over a period).

Legal entity and service: who is the provider in the report?

According to the BSI FAQ, a C5 attestation never covers a company as a whole, only specific cloud services in specified regions. So the first questions are which service is audited, in which region it runs, and which legal entity appears as the cloud service provider: the foreign parent, a European or a German subsidiary.

The catalogue’s general conditions (section 4) require disclosures that German customers read with exactly this in mind:

• GC-01: applicable law, jurisdiction, countries, regions and locations, including the country in which the ultimate parent is registered.
• GC-05: how investigation requests from government agencies are handled, including the number of requests and the countries they come from. The catalogue names the US CLOUD Act as an example of foreign law.

A German subsidiary does not hide the parent: customers will still see the ultimate parent and its country in the report. Our recommendation is to choose the legal entity so it fits your customer contracts and to settle this early with your legal team. Changing it later means a new system description. If customers also ask for sovereignty, such as effective control in the EU or operations staff who are EU citizens, the benchmark is the BSI’s C3A catalogue, which builds on C5.

Establishment in Germany and processing location

Section 393(2) SGB V reads, in our own translation (there is no official English version):

“Social data and health data may be processed by way of a cloud computing service only 1. in Germany, 2. in a member state of the European Union, or 3. in a state treated as equivalent under Section 35(7) of Book One or, where an adequacy decision pursuant to Article 45 of Regulation (EU) 2016/679 exists, in a third country, and provided that the data-processing entity has an establishment in Germany.”

For an international provider this leads to two work items:

1. Map every actual processing location, including backups, support, monitoring and subservice organisations. The system description has to state the location of processing and storage for each subservice organisation anyway; country level is sufficient. PSS-12 requires customer data and backups to be processed only in the contractually agreed region; the catalogue does not require you to offer several regions.
2. Clarify the establishment in Germany. The law ties it to the data-processing entity. Whether an existing sales subsidiary is enough, or which company is the data-processing entity, is not answered by the wording and needs legal advice.

For third countries, the wording only mentions an adequacy decision under Article 45 GDPR. For the US there is the adequacy decision on the EU-U.S. Data Privacy Framework (as of 1 November 2026); it covers only organisations certified under that framework. Whether such a decision remains in force and covers your case needs to be checked before relying on it. For support from abroad, a draft bill is under discussion that would change the rules for technically sealed maintenance access; see maintenance access under Section 393 SGB V.

What your SOC 2 report brings

A SOC 2 report does not replace a C5 attestation, but a lot of the groundwork carries over. The catalogue explicitly allows you to reuse a system description prepared for another standard, adapted to the C5 description criteria. It also recommends aligning SOC 2 and C5 audits because that is more efficient. The detailed comparison is on the C5 vs SOC 2 page.

The project: language, team and independent auditor

• Language. The catalogue exists in German (version 1.1.0) and English (version 1.0.1). The German version is newer, and one additional subcriterion has a different ID (EN AM-01.02AC, DE AM-02.01AC). Agree with your auditor and customers in which language the system description and the report will be written, and quote the catalogue only from the official version in that language.
• Auditor. The audit is performed under ISAE 3000 (Revised), the German IDW PS 860 or another national equivalent, by an independent auditor usually engaged by the provider. The catalogue also provides for auditors who are not public auditors, whereas the BSI FAQ states that only Wirtschaftsprüfer (German public auditors) can issue a C5 attestation. Ask your German customers which auditors they accept.
• Separation of advice and audit. Blackfort Technology prepares you for the audit; the attestation is issued by an independent auditor.

Example: a US remote monitoring provider

Fictitious example. A US company runs a platform that lets hospitals monitor patients’ readings at home. It has a SOC 2 Type 2 report for the US platform. For Germany it sets up a separate instance in a hyperscaler region in Germany and incorporates a German limited company (GmbH).

• Service and region: only the German instance is audited; the US platform stays outside the subject matter.
• Legal entity: the GmbH acts as the cloud service provider; GC-01 still names the US as the country of the ultimate parent, and GC-05 describes how US government requests are handled.
• Processing locations: support from the US with access to plaintext data would be a processing location in a third country. The European Commission’s adequacy decision on the EU-U.S. Data Privacy Framework (as of 1 November 2026) applies only to organisations certified under it. Whether it covers this case is assessed by the provider’s lawyers; until then the provider moves support for the German instance to an EU team.
• Subservice organisations: the hyperscaler is carved out and monitored, as is a notification service.
• Reuse: the SOC 2 system description is the starting point and is adapted to C5.

What needs a separate legal assessment

No attestation answers these questions. They belong with lawyers experienced in German healthcare and data protection law:

• whether your service falls under Section 393 SGB V and which company is the data-processing entity,
• whether your German establishment meets subsection 2,
• whether an adequacy decision exists for locations outside the EU and what it covers,
• data processing agreements, transfers and other duties under the GDPR and Book X of the Social Code,
• sector rules, for example whether your software is a medical device.

The BSI does not interpret Section 393 and refers questions to the Federal Ministry of Health.