Since July 2025, German hospitals and medical practices can only process health data in cloud services that hold a C5 Type 2 attestation. The new C5:2026 catalogue raises the bar again, and by June 2027 it will be the only version that counts. This is what it means for the software vendors selling to them.

If you run a Berlin health SaaS that sells to hospitals, MVZs or private practices, cloud security used to be one line in a procurement questionnaire. It is now a hard stop. Procurement asks, “Can you send us your C5 attestation?”, and many product teams answer, “Our cloud provider has one.” Under German law, that answer no longer gets you through the door.

What § 393 SGB V actually requires from healthcare software vendors

The Digital Act (DigiG) of 2024 added § 393 to the German Social Code (SGB V). It allows healthcare providers and statutory health insurers to process health and social data in the cloud, but only under strict conditions. The data has to be stored in Germany, the EU/EEA, or a country with an adequacy decision. The provider needs an establishment in Germany. Technical and organisational measures must reflect the state of the art. The specific cloud service needs a current C5 attestation from the BSI’s Cloud Computing Compliance Criteria Catalogue. Until 30 June 2025 a Type 1 attestation was enough. Since 1 July 2025, a Type 2 is required.

On paper, the obligation sits with the hospital, the practice or the insurer. In practice, it travels down the supply chain to anyone who processes that data for them, and that includes your SaaS product.

The hyperscaler’s attestation covers the hyperscaler’s infrastructure. It says nothing about your application, your access model or your deployment pipeline.

If your clinical workflow tool runs on AWS Frankfurt, Azure Germany West Central or STACKIT, those providers hold their own C5 attestations. Those attestations end where your responsibility starts: who can access production, how code changes reach it, how long you keep logs, which third-party APIs see patient data. A SaaS vendor processing health data on third-party infrastructure needs its own attestation, with a clearly defined scope for its service.

C5 Type 1 vs Type 2: why the difference shapes your roadmap

Teams often treat the two attestation types as two levels of the same exam. They aren’t. A Type 1 attestation confirms that your controls are suitably designed at a single point in time. A Type 2 attestation confirms that those controls actually operated effectively over an observation period, usually several months.

This has a direct consequence: you cannot cram for a Type 2. The auditor will ask for evidence that already exists, such as quarterly access reviews, a traceable change history from ticket to deployment, incident records, vulnerability scan results and supplier assessments. If those artefacts only start to exist the week the auditor arrives, the observation period starts that week too.

There was a temporary bridge. The C5 equivalence regulation, adopted after it became clear there weren’t enough auditors, let organisations combine an ISO/IEC 27001 certificate with a documented gap plan towards C5. It was designed as a transition towards a Type 1 attestation, not as a lasting alternative to a Type 2. If your current answer to hospital customers relies on that bridge, treat it as borrowed time.

C5:2026: what the new catalogue changes for your cloud architecture

In spring 2026, the BSI published C5:2026, the first major revision since C5:2020. The numbers show how far the scope has grown. Basic criteria rise from 121 to 168, broken down into 462 sub-criteria, and additional criteria go from 55 to 89. Only the basic criteria are mandatory for § 393 SGB V, but those are the ones that grew.

The content changes matter more than the count. C5:2026 explicitly covers modern cloud architectures and container management, and it brings in NIS-2-related requirements. For a typical health SaaS stack, that turns into very concrete engineering questions. How is your Kubernetes cluster configured and hardened, and can you prove it? Where do your container images come from, and who can push to the registry? How are secrets managed and rotated? Which subprocessors, such as an LLM API, an analytics tool or a transactional email service, receive health data, and how do you assess them?

The transition timeline is tight:

  • Until 28 February 2027: audits can still be done fully under C5:2020.
  • 28 February to 31 May 2027: C5:2020 can still be used, but the system description has to document the planned changes towards C5:2026.
  • Type 2 reporting periods starting from 1 June 2027: only C5:2026 applies.

Existing C5:2020 attestations don’t become invalid overnight, but your next renewal will be measured against the new catalogue.

One more development is worth watching. In April 2026 the BSI published C3A (Criteria enabling Cloud Computing Autonomy), which assesses digital sovereignty on top of C5. It isn’t legally binding yet, but it already appears as a qualification or award criterion in public tenders. If your customers include public hospital groups, expect the question.

Where healthcare product teams usually get stuck?

Here is a pattern we see repeatedly in German and Austrian digital health projects. Picture a Series A team in Berlin: twelve engineers, a clinical documentation tool, running on AWS in eu-central-1. A university hospital likes the product and asks for the C5 attestation. The gap analysis then shows what is missing.

Production access goes through a few shared admin accounts. Merging to main means deploying, with no documented approval step that an auditor could trace. Application logs are kept for 14 days because that was the default. Part of the infrastructure was set up by clicking through the console during the MVP phase and never moved into code. And a feature built last quarter sends free-text clinical notes to a third-party LLM API that isn’t on the documented subprocessor list.

None of these issues is exotic, and none of them is a legal problem. Each one is an engineering task: introduce role-based access with just-in-time elevation, add approval gates and audit trails to the CI/CD pipeline, define log retention and centralise logs, move infrastructure into Terraform, and put every data flow on an inventory. A team that builds this way from the start mostly collects evidence for a C5 audit. A team that didn’t has to reconstruct it, which is exactly what makes a Type 2 slow and expensive.

The lesson matches what we’ve learned building regulated software for clients such as mySugr and Selfapy: compliance is a property of how a product is built and operated, not a document produced at the end.

A realistic path to C5:2026 before June 2027

The most useful exercise is to count backwards. Say you want a Type 2 attestation under C5:2026 in the second half of 2027, when hospital customers renew contracts and start asking for it. The observation period, often around six months, then has to begin in early 2027. That means your controls need to be running, not planned, by the end of 2026. And that means the gap analysis should happen now.

Practically, start by scoping: define exactly which service, which environments and which data flows the attestation will cover. A tight, well-defined scope is cheaper to audit and easier to defend. Next, run a gap analysis against the C5:2026 basic criteria, not C5:2020. Otherwise you’ll fix the old catalogue and audit against the new one. Then close the gaps where they live, which is usually in infrastructure-as-code, the deployment pipeline, identity and access management, and logging, rather than in policy documents. Finally, talk to auditors early. The shortage that led to the equivalence regulation hasn’t disappeared, and the spring of 2027 will be busy.

Doing this in the right order also pays off beyond C5. The same controls support the security requirements for DiGA under BSI TR-03161, the NIS-2 obligations many health organisations now face, and the security questionnaires of every enterprise customer in the DACH region.

The takeaway: treat C5 as an architecture requirement, not a certificate

For health SaaS vendors in Berlin and across Germany, C5 is becoming the entry ticket to the provider market, and C5:2026 is the version that will be checked. Teams that treat it as a certificate to buy at the end will spend 2027 reconstructing evidence. Teams that treat it as an architectural requirement will mostly find their audit is already underway.

If you’re mapping your stack against C5:2026, or planning a product for German hospitals and want compliance built in from the first sprint, we’re happy to compare notes. Let’s talk. You can also read more about what’s actually different in healthcare software development in the DACH region.

Sources: