Section 393 SGB V explained for cloud providers and their customers

This page covers the legal basis: who Section 393 SGB V applies to, which conditions and deadlines it sets, and what customers should check with a cloud vendor. There is no official English version of the provision; the wording below is our own rendering of the German text. This is general information, not legal advice. Whether and how the provision applies to you has to be assessed case by case.

Who Section 393 SGB V applies to

The provision addresses healthcare providers within the meaning of Chapter Four of SGB V, statutory health and long-term care insurers, and their respective data processors. Subsection 1 allows them to process social data and health data “also by way of a cloud computing service” if the conditions of subsections 2 to 4 are met. Chapter Four covers, among others, the relationships of the health insurers with physicians, dentists and psychotherapists, with hospitals and with pharmacies.

In our reading, a cloud vendor processing data for these organisations is often their processor; the conditions of subsections 2 to 4 then also apply to its processing. Section 384 sentence 1 no. 5 SGB V defines a cloud computing service as a digital service that enables on-demand administration and broad remote access to a scalable and elastic pool of shareable computing resources. In our reading, software run purely on premises is not a cloud computing service in this sense, so Section 393 does not apply to it.

Section 393 in its current form has applied since 1 July 2024: it was inserted by Article 2 no. 6 of the Digital Act (DigiG, Federal Law Gazette 2024 I no. 101), which brought that provision into force on that date under its Article 9(4); the BSI gives the same date. 1 July 2025 is the date from which a Type 2 attestation is generally required, not the date the provision entered into force.

For providers based outside Germany there is a separate page for international providers. If you run AI systems in the cloud, the BSI’s A5 audit architecture is also worth a look; it relies on a C5 attestation for the infrastructure but does not replace the requirements of Section 393.

The conditions at a glance

Subsection 8 states that Book X of the Social Code and the Federal Data Protection Act remain unaffected. A C5 attestation does not replace a data protection assessment; the BSI itself describes C5 as an information security standard, not a data protection standard.

Which attestation applies when: the deadlines in subsection 4

• Until 30 June 2025: a C5 Type 1 attestation.
• From 1 July 2025: a current C5 Type 2 attestation.
• New systems (since 1 January 2026): if an IT system is first placed on the market after 30 June 2025, a Type 1 attestation counts for the first 18 months, and a Type 2 attestation from month 19. This sentence was inserted by Article 3 no. 44 of the Act on Extending Powers and Reducing Bureaucracy in Nursing Care (Federal Law Gazette 2025 I no. 371) and has been in force since 1 January 2026 (Article 14(1)).
• Alternative: instead of a C5 attestation, an attestation or certificate under a standard ensuring a comparable or higher security level. The C5 Equivalence Ordinance (C5GleichwV) specifies these standards (see below).

Type 1 assesses the design of controls as of a specified date, Type 2 also their operating effectiveness over a period; see C5 Type 1 or Type 2. If you launch a new system, record the launch date and plan the Type 2 report backwards from month 19 (C5 audit process). The wording does not say what “first placed on the market” means for a new major release or a platform migration. Our view: do not count on a mere migration of existing software being treated as a new system.

Section 393 does not set a maximum age for an attestation. According to the BSI FAQ, a Type 2 attestation covers a past period of three to twelve months (a Type 1 attestation refers to a specified date), and audits are usually repeated every year.

Whose attestation counts: application and platform

The law asks for an attestation “of the data-processing entity” for the cloud systems and technology used. Section 384 SGB V does not define that term, and we have not found a definition elsewhere in SGB V. Its exact reach is not settled.

What can be said: according to the BSI FAQ, a C5 attestation always covers the audited cloud services in specified regions, never a provider as a whole. A hyperscaler’s attestation covers its own services such as compute, storage or managed databases. It says nothing about the controls of the application running on top, such as access rights, tenant separation, development and support. In our assessment, a vendor operating an application with health data should therefore plan for its own evidence for that service. We found no interpretation by the Federal Ministry of Health and no case law on this point (as of 1 November 2026); your case needs a legal assessment.

The platform attestation still helps, because your own attestation can treat the platform as a subservice organisation. How that works is covered on the C5 scope page. If a third party runs both the application and its operations and holds an attestation for that, its attestation may be sufficient; whether it really covers the service in use is shown by the subject matter described in the report.

Example (fictitious): a vendor of appointment software for dental practices runs its application in a hyperscaler region in Frankfurt. The hyperscaler holds a C5 Type 2 attestation for the services used; the software itself has not been audited. The website says “hosted in C5-attested data centres”. In our view this does not satisfy subsection 3 no. 2, because the service the practices use is the appointment software. The vendor therefore plans its own attestation for the application.

What the attestation has to cover

Section 393 refers to the “C5 basic criteria”, so additional criteria are not required for Section 393. The basic criteria are also the minimum scope of every C5 audit; the C5:2026 catalogue contains 168 criteria in 17 areas.

Section 384 sentence 1 no. 6 defines a current C5 attestation as the positive audit result against the catalogue “in its currently valid version” (our translation). In our reading, C5:2026 therefore applies once the catalogue requires it for the engagement in question: for Type 1 dates on or after 1 June 2027 and for Type 2 periods beginning on or after that date. The catalogue permits earlier use of C5:2026. A Type 2 period starting earlier and ending later should, according to the catalogue, cover only the C5:2020 criteria. The Federal Ministry of Health has not published its interpretation. The transition rules themselves are in section 3.5 of C5:2026.

Subsection 3 no. 3 also puts the customer on the hook: the “complementary customer criteria contained in the audit report” (our translation) must be implemented. The German wording uses the name of a part of the catalogue. The catalogue itself lists complementary customer criteria for selected C5 criteria, expressly not as an exhaustive list; they indicate where customers may have cooperation obligations (section 2.1). They are distinct from the “complementary customer controls”, also called complementary user entity controls (CUEC), that the vendor assumes when designing its controls and lists in its system description (section 3.4.5.1 no. 7), such as managing the customer’s own user accounts. According to the catalogue, the complementary customer criteria help identify these CUEC; they are not the same thing.

Section 393 does not say how the statutory term relates to the CUEC in the report, and we found no official interpretation (as of 1 November 2026). Our reading, expressly not an official interpretation: because the law refers to the audit report and the report contains the CUEC, customers should cover both, the CUEC from the report and the complementary customer criteria for the audited C5 criteria. The auditor states in the report that the criteria can only be met if the CUEC are effective. Each of these obligations needs an owner at the customer and evidence that it has been implemented.

Without a C5 attestation: the C5 Equivalence Ordinance

The C5 Equivalence Ordinance (C5GleichwV) of 19 March 2025 applies retroactively from 1 July 2024. It accepts evidence under ISO/IEC 27001, ISO 27001 based on IT-Grundschutz or the Cloud Controls Matrix 4.0, each combined with a remediation plan for the cloud service. The plan and the certificate have to be provided to customers and supervisory authorities without delay on request. The plan has four required parts, with up to twelve months for closing the gaps and 18 and 24 months for documenting steps towards a Type 1 and a Type 2 attestation, each counted from the milestone plan (Section 1(2) of the C5 Equivalence Ordinance).

Publication of attested systems (subsection 7)

On application, the Competence Centre for Interoperability in Healthcare publishes information on attested cloud systems and technology on its platform under Section 385(1) sentence 2 no. 5 SGB V. The application must include a “checklist of the complementary customer criteria” (our translation), so by its wording a checklist of the customer criteria, not of the CUEC. The law sets no format. Our recommendation: build the list along the complementary customer criteria for the audited C5 criteria and name the matching CUEC from the system description in each row, so customers can work through it. The BSI itself keeps no list of attested services and does not review reports.

Checklist for practices, hospitals and insurers

These questions help customers assess what a cloud vendor says about Section 393. Vendors can use the same list to prepare the documents customers will ask for.

1. Which service does the attestation cover? The application we use, or only the infrastructure underneath? In which regions?
2. Which type and period? Type 1 with a specified date or Type 2 with a period; when does it end, when is the next report due, who was the auditor?
3. New system? When was the service first placed on the market, and what is the plan for Type 2 from month 19?
4. No C5 attestation? Is there evidence under the C5 Equivalence Ordinance, with certificate and remediation plan, and will we receive both on request?
5. What is carved out? Which subservice organisations are excluded, and do they have their own reports?
6. What are our obligations? Which complementary user entity controls (CUEC) does the report rely on, which complementary customer criteria does the catalogue list for the audited criteria, and how do we implement both?
7. Where is the data processed? All locations including backups, support and subservice organisations; does the data-processing entity have an establishment in Germany?
8. What does the report say? According to the BSI, an unqualified opinion does not mean there were no deviations. Which deviations were reported and what was done?
9. What does the contract secure? Do we receive current and future reports, and what applies if a follow-up report is late?

A marketing line such as “C5-certified data centre” answers none of these questions. According to the BSI there are no C5 certificates, only attestations.

What this page does not settle

Whether your company is a processor under Section 393, whether your data is health data and which locations and set-ups are permissible depends on the facts. The BSI does not interpret Section 393 and refers to the Federal Ministry of Health. Have your case assessed by a qualified lawyer. A draft bill that would change the rules for maintenance and support access has not been passed yet; see maintenance access under Section 393 SGB V.

How we support healthcare cloud providers

In a C5 readiness assessment we compare your service with the C5 basic criteria that Section 393 refers to, prepare the customer obligations from CUEC and complementary customer criteria, and plan the route to a Type 2 attestation. Blackfort Technology does not issue attestations and does not give legal advice; an independent auditor issues the attestation.