Cloud or on-premise in hospitals: what IT security and liability law actually require

Why “cloud or on-premise” is the wrong first question

Summary: The choice “cloud versus on-premise” only describes where the servers are located. It says nothing about the level of security. As soon as patients are to complete a medical history form from home, every operating model involves a service that can be reached from the internet. The only relevant question is: who operates this service, with which controls — and how is this evidenced?

In conversations with hospital IT and legal departments, we regularly encounter a pattern: cloud hosting is treated as an exclusion criterion, while at the same time in-house solutions are proposed that create the same internet exposure — only without the controls that are audited and documented for an attested cloud service. One specific proposal that we have heard several times in this form: set up a computer in the hospital, place it in the DMZ and let patients access it from home (observation from medudoc conversations with hospitals, as of August 2026).

The motivation behind the proposal is understandable — the data should not leave the building. But it does not change the attack surface; it only moves it: from the hardened, monitored client environment of an attested service provider into the hospital’s own network. This article compares the technical options, places them in the context of current law and identifies where liability risks arise.

Which operating models are actually available for digital patient intake?

Summary: There are not two but five operating models of practical relevance. They differ less in where data is stored than in who is responsible for hardening, patch management, monitoring and providing evidence.

Model A is effectively ruled out for preoperative patient intake as soon as patients are to take part from home before their hospital stay — which is precisely the purpose of the process. That leaves B to E. And the real difference in this topic lies between B and C: not cloud versus on-premise, but controlled versus uncontrolled remote access.

What does German law say about cloud use with health data?

Summary: Since 2024, § 393 SGB V has expressly permitted healthcare providers, health and long-term care insurance funds and their processors to process social and health data by means of a cloud computing service. The provision is not an exception or a matter of tolerance, but a permissive provision with four conditions.

The provision was introduced by the Digital Act (Digital-Gesetz, DigiG). It requires, cumulatively:

1. Processing region: in Germany, in an EU member state, in a state treated as equivalent under § 35(7) SGB I or — where there is an adequacy decision under Art. 45 GDPR — in a third country (§ 393(2) SGB V).
2. Establishment: The data processing entity must have an establishment in Germany (§ 393(2) SGB V).
3. State of the art: Appropriate technical and organisational measures in line with the state of the art must have been taken to ensure information security (§ 393(3) no. 1 SGB V).
4. C5 attestation and customer obligations: A current C5 attestation of the data processing entity must be available, and the corresponding customer criteria contained in the audit report must have been implemented (§ 393(3) nos. 2 and 3 SGB V).

On the fourth point, paragraph 4 contains a staged approach: until June 30, 2025, a C5 Type 1 attestation sufficed, confirming that the controls were suitably designed as of a reference date. Since July 1, 2025, a current C5 Type 2 attestation has in principle been required, which additionally demonstrates the operating effectiveness of the controls over a reporting period. For information technology systems first placed on the market after June 30, 2025, a Type 1 attestation applies in the first 18 months after placing on the market, and a Type 2 attestation from the 19th month. Attestations or certificates under standards with a comparable or higher level of security are also permitted.

Important for the adequacy assessment: for licensed hospitals, § 393(5) SGB V expressly refers to § 391 SGB V. The standard for “appropriate” is therefore the same as for self-operation. The law does not privilege the cloud — it puts both models on the same footing and additionally requires external audit evidence for the cloud.

The key consequence: anyone who rejects cloud use on the grounds that the law prohibits it is arguing against the wording of a permissive provision. Anyone who rejects it because a specific vendor cannot present the C5 attestation is arguing correctly on the facts — and that is a different, verifiable objection.

What requirements does § 391 SGB V place on self-operated systems?

Summary: § 391 SGB V obliges hospitals to take appropriate organisational and technical precautions in line with the state of the art to avoid disruptions to the availability, integrity and confidentiality of their information technology systems, components or processes. This obligation applies regardless of whether a system is bought in or built in-house.

Three aspects of the provision are underestimated in practice:

• The adequacy standard is relative, not absolute. Under § 391(3) SGB V, precautions are appropriate if the effort required is not disproportionate to the consequences of a failure or to the protection requirements of the patient information processed. For health data — special categories under Art. 9 GDPR — the protection requirements are high. The reasonable effort rises accordingly.
• Security awareness is a mandatory component. § 391(2) SGB V expressly includes mandatory measures to raise employees’ security awareness among the precautions under paragraph 1.
• The industry-specific security standard is the simplest way to comply, not the only one. Under § 391(4) SGB V, hospitals can meet their obligations in particular by applying a B3S (industry-specific security standard) that the BSI has found to be suitable. “In particular” means that other routes are possible — but they must then be evidenced independently.

Since December 2025, NIS2 regulation has been added. The NIS2 Implementation and Cybersecurity Strengthening Act (NIS2UmsuCG) came into force on December 6, 2025 without a transition period and transfers the requirements into the BSI Act; the deadline for registration with the BSI expired on March 6, 2026. The health sector is covered, and the scope extends well below the previous KRITIS (critical infrastructure) thresholds. Particularly relevant for management bodies: the Act obliges them to approve risk management measures and to monitor their implementation, provides for personal liability in the event of a breach of duty and, in the case of serious infringements, allows the supervisory authority to temporarily exclude members of management from their function. Fines can reach €10 million or 2% of worldwide annual turnover.

In Austria, the timetable is different: the NISG 2026 was promulgated on December 23, 2025 (BGBl. I No. 94/2025) and comes into force on October 1, 2026, with a registration deadline at the end of 2026. Until then, the NISG 2018 continues to apply. As a non-EU state, Switzerland is not directly covered but is indirectly affected through supply chain requirements. The German special provisions §§ 391 and 393 SGB V have no direct equivalent in Austria and Switzerland — however, the obligation to take risk-appropriate measures under Art. 32 GDPR applies identically in Austria.

Is the “computer in the DMZ” a permissible alternative to the cloud?

Summary: In the form typically proposed: no — not because on-premise operation would be impermissible, but because the same requirements apply and are regularly not met in this variant. An end system in the DMZ that can be reached from the internet moves the attack surface into the hospital network without providing the controls that an attested service demonstrably maintains.

Measured against § 391 SGB V and Art. 32 GDPR, this construction regularly lacks:

• Identity and access control: A system that “anyone can reach from home” by definition has no reliable authentication of the person accessing it. Without reliable identification, neither the assignment of medical history data nor a subsequent consent can stand up as evidence.
• Segmentation and blast radius: A compromised system in the DMZ is a bridgehead in the hospital network. With a multi-client capable external service, a successful attack on the application does not end in the hospital information system (HIS).
• Patch and vulnerability management with response times: Internet-facing components need defined SLAs for critical vulnerabilities — in hours, not in maintenance windows.
• Continuous monitoring: Attacks on exposed systems run around the clock. Organisationally, 24/7 logging and analysis are hardly feasible for a single system.
• Providing evidence: There is no audit report, no attestation, no independent confirmation of effectiveness. This is exactly the evidence that is required in the event of a dispute (see next section).

Variant C — hardened, monitored remote access with a reverse proxy, web application firewall, MFA, segmentation, vulnerability management and a connection to a security operations centre (SOC) — is, by contrast, a legitimate and viable model. Legally, it is in no worse a position than a cloud service. It is simply not cheaper, not faster and not easier to evidence. Anyone who chooses it should do so as an operational decision, not out of a misunderstanding of the legal position.

What liability consequences arise — and are there already rulings on this?

Summary: To our knowledge, there is no published decision on the specific scenario of an “unhardened end system in the DMZ”. However, the standard can be derived from settled case law on Art. 32 GDPR — and this standard is unfavourable for operators, because the burden of proof lies with them.

1. The burden of proof lies with the controller (CJEU, judgment of December 14, 2023, C-340/21 — Natsionalna agentsia za prihodite). The Court ruled that unauthorised access by third parties does not in itself prove that the measures taken were inappropriate — the GDPR establishes a risk management system and does not promise freedom from risk. Conversely, however, in an action for damages under Art. 82 GDPR, the controller must set out and prove that its security measures were appropriate within the meaning of Art. 32 GDPR. Appropriateness must be assessed specifically by the national courts, taking into account the risks associated with the processing. An expert report may serve as evidence, but it is neither mandatory nor sufficient on its own.

In practice, this means that after an incident, the hospital must actively prove that its level of protection was appropriate to the risk. A hospital that can point to a C5 audit report and a certified ISMS is in a structurally different evidentiary position from one that has to defend a single system it set up itself.

2. Risk appropriateness is interpreted strictly (Schleswig-Holstein Higher Regional Court, judgment of December 18, 2024, 12 U 9/24). A trade business had sent a final invoice of around €15,000 by email with transport encryption only; attackers manipulated the bank details. The court awarded the recipient a claim for damages under Art. 82 GDPR in the amount of the claim for payment, which she was able to set off against the claim — as a result, the business was left with its unpaid invoice. Where the financial risk is high, only end-to-end encryption is appropriate, the court held; the technical and financial effort required for this could also be expected of a medium-sized business if it did not send by post. The line of reasoning is notable: the court requires foresight and proactive action against risks inherent in a digital process.

3. There is a counter-position (OLG Karlsruhe, judgment of July 27, 2023, 19 U 83/22). In a comparable B2B case, the Higher Regional Court of Karlsruhe came to a different result: the absence of certain measures does not automatically lead to liability; what matters are the legitimate security expectations of the respective business dealings. These diverging decisions have not yet been resolved by the highest court. For health data, the stricter line is likely to be more relevant, because the security expectations placed on a hospital are measurably higher than those placed on a trade business — but this cannot currently be supported by a relevant decision.

4. Personal responsibility of management. Irrespective of civil liability, the NIS2UmsuCG addresses management directly: approval and monitoring of risk management measures, personal liability in the event of a breach of duty and, in extreme cases, a temporary ban from office. The decision to operate an internet-facing system without hardening and without providing evidence is therefore no longer a purely IT decision.

5. The operational risk reference case. According to consistent reports, the ransomware incident at University Hospital Düsseldorf in September 2020 began via a vulnerability in a Citrix gateway that had been known since December 2019 (CVE-2019-19781); the BSI had repeatedly warned that systems could have been compromised even before the patches were applied. Around 30 servers were encrypted, and emergency care had to be suspended. For context, in all honesty: the public prosecutor’s office discontinued the investigation into causing death owing to a lack of causation — the case does not prove a liability judgment. It proves something else, and that is enough: that the perimeter component enabling remote access is the gateway for attacks, and that operating it requires continuous, specialised attention.

Note: medudoc does not provide legal advice. This account does not replace an assessment of the individual case by your legal department or your data protection officer. Case law on Art. 32 GDPR is evolving; the decisions cited here are decisions of regional courts or CJEU preliminary rulings, not a clarification by the highest German court.

Does medical confidentiality under § 203 StGB prohibit the use of external service providers?

Summary: No. Since the reform of § 203 of the German Criminal Code (StGB) in 2017, persons bound by professional secrecy may disclose secrets to “other contributing persons” insofar as this is necessary for their work. IT service providers and data centres fall under this term. The permission is, however, tied to obligations that must be implemented by contract.

The key requirements: disclosure must be limited to what is necessary for the commissioned work. The contributing persons must be selected carefully and formally obliged to maintain confidentiality — including any subcontractors involved. Anyone who fails to impose this obligation may themselves be liable to prosecution under § 203(4) StGB.

Two clarifications that are often missing from the discussion: § 203 StGB addresses professions, not institutions — it is the treating physicians who are bound, not the hospital as a legal entity. And a data processing agreement alone does not resolve the criminal law question; it is the basis under data protection law, not under criminal law. Both must be regulated. Both can be regulated. No prohibition can be derived from § 203 StGB.

How can hospitals assess a vendor reliably?

Summary: The assessment should not start with the hosting model but with the evidence. A vendor that can present the following documents demonstrably meets the requirements of § 393 SGB V. A vendor that cannot present them should be viewed critically, regardless of the operating model.

Two practical notes: first, a Type 1 attestation is not a Type 2 attestation — the difference between suitable design as of a reference date and operating effectiveness over a period is the real substance of the audit. Second, the C5 audit only applies to the attested scope of services; the scope belongs in every assessment.

How medudoc works — and where the limits lie

Summary: medudoc is operated as a cloud-native platform. Data is stored in Germany, and the AI models used are operated exclusively within the EU. In relation to the hospital, medudoc acts as a processor; the hospital remains the controller within the meaning of Art. 4(7) GDPR.

The regulatory status in detail:

• ISO/IEC 27001:2022 — certified since April 2026, valid until March 2029.
• BSI C5 — Type 1 successfully completed as of the reference date May 8, 2026; Type 2 in the observation period until October 2026. Until the Type 2 audit report is available, medudoc deliberately does not use the wording “C5 certified”.
• MDR — medudoc is not a medical device. The final medical decision always remains with the physician; the platform solely structures information for the physician’s assessment.

What medudoc does not provide belongs in the same account: complete operation in the hospital’s data centre without a connection to the medudoc platform is not part of the service model. Hospitals for which pure self-operation is a given for strategic reasons are not the right fit for us — we would rather say so beforehand than afterwards. Nor does an attestation replace the hospital’s own obligations: the corresponding customer criteria from the C5 audit report must be implemented by the hospital, and responsibility under the GDPR remains with it.

Technically, medudoc connects to existing hospital information system (HIS) and patient portal landscapes via FHIR interfaces; you can find an overview under integrations and interfaces. The pillar page on the digital preoperative workflow describes how the platform fits into the clinical process. You can find security-related information and contact options for responsible disclosure under security information, and the medical editorial process behind the content under quality standards. We provide certificates and audit reports in the medudoc Trust Center.