Germany's GeDIG draft: what changes for C5, maintenance access and reporting duties in healthcare software

On 30 September 2026 the German federal government submitted the draft Act on Data and Digital Innovation in Healthcare (Gesetz für Daten und digitale Innovation im Gesundheitswesen) to the Bundestag as printed paper 21/8279. The Federal Ministry of Health uses the short name GeDIG. The first reading took place on 8 October and the public hearing in the Health Committee on 14 October 2026. The act has not been passed yet.

The draft is extensive, but four points matter most for information security. It clarifies when maintenance or support access falls under the cloud rules of Section 393 of the German Social Code, Book V (SGB V), and thus under the C5 requirement. It allows healthcare professionals working in hospitals to use personal devices to transmit medical and nursing data under certain conditions. It requires vendors of systems connected to the telematics infrastructure to report to gematik, with fines for violations. And it designates the Federal Office for Information Security (BSI) as market surveillance authority for EHR systems. This article explains these points. It is not legal advice, and every statement about future obligations depends on the outcome of the parliamentary process.

Context: Section 393 SGB V and what the draft changes

Starting point: C5 attestation for health data in the cloud

Section 393 SGB V sets the conditions under which healthcare providers, health and long-term care insurers and their processors may process social and health data in cloud services. Requirements include a permitted processing location, an establishment in Germany, state-of-the-art safeguards and a current C5 attestation of the processing entity. Since 1 July 2025, only a C5 Type 2 attestation generally counts as current; for systems first placed on the market after 30 June 2025, a Type 1 attestation is sufficient for the first 18 months. We described the practical implications in a separate article on Section 393 SGB V.

How maintenance and support should be treated was not expressly regulated. If a service provider accesses a cloud system to analyse a fault, does it process health data within the meaning of Section 393 itself, with all requirements on location, establishment and attestation? According to the explanatory memorandum, the draft is meant to provide legal certainty for established maintenance and support processes.

New: maintenance access with technically locked data

The draft adds a second sentence to Section 393(1). Access for maintenance and support does not count as cloud processing if state-of-the-art technical safeguards, in particular encryption, ensure that the data cannot be viewed or otherwise processed.

The memorandum draws the line precisely:

• Technical protection is what tips the balance. The exemption covers access for maintenance and support purposes; according to the memorandum, the only question is whether the data demonstrably remains technically inaccessible. Encryption is only sufficient if the accessing party has no means to decrypt. Purely organisational or contractual assurances are not enough.
• Other methods are possible. The memorandum names trusted execution environments, effective separation of the maintenance environment from production data, and tokenisation. The list is open.
• The exemption reaches only as far as the protection. For technically locked access, the requirements of subsections 2 to 4 (processing location, establishment in Germany, technical and organisational measures, C5 attestation) do not have to be met separately; they continue to apply to the cloud service itself. According to the memorandum, maintenance can therefore also be provided regardless of location. The provisions of Book X of the Social Code and of the Federal Data Protection Act remain unaffected (Section 393(8) SGB V), and the GDPR applies in any case. If the data is not kept locked throughout, Section 393 applies in full. The security logic based on the C5 attestation is expressly meant to remain.
• Moving to the cloud should not trigger a reassessment of maintenance. Migrating from on-premises to the cloud is not supposed to change the security assessment of established support and maintenance processes merely because the hosting model changes.

New: cloud use for certain billing entities

Under the amended Section 295a SGB V, entities commissioned to bill services under contracts pursuant to Sections 73b, 132e, 132f and 140a SGB V or outpatient emergency services of hospitals may in future use cloud services. The condition is that they meet the Section 393 requirements accordingly, including a C5 attestation. The previous general ban on subcontracting is replaced by the general rules on processing on behalf.

New: personal devices in hospitals

The new Section 363f SGB V creates a legal basis for healthcare professionals working in hospitals to use personal devices, such as their own smartphone, to transmit medical and nursing data. Use is subject to three conditions:

• Transmission runs through a secure TI transmission procedure with approved services and providers. Section 363a SGB V as amended names in particular the instant messaging service (TI-Messenger) and the secure e-mail service (KIM).
• gematik's framework conditions for content and use of the procedure are complied with.
• Appropriate state-of-the-art technical and organisational measures within the meaning of Art. 32 GDPR are in place for the use of personal devices.

Information security measures count as appropriate if the relevant requirements of the sector-specific security standard for IT security in hospital care under Section 391(4) SGB V, or equivalent requirements, are met. The draft provides no such presumption for the data protection side. The requirements for the devices themselves are set by the German Hospital Federation after consulting the BSI and the Federal Commissioner for Data Protection and Freedom of Information. The draft sets no deadline for this.

Vendors: reporting duties towards gematik and the BSI

For vendors of practice management and hospital information systems, the draft creates two lines of supervision.

gematik: Under the new Section 329(2) SGB V, providers and manufacturers of systems with interfaces to the telematics infrastructure (TI), Germany's national health data network, must report significant disruptions to gematik without delay and take remedial action without delay. Significant means in particular disruptions that impair or may impair the integrity, authenticity, confidentiality, functionality or operational stability of the TI. gematik may demand information on causes and countermeasures, block systems from TI access and, under Section 333(3), issue binding instructions to remedy security deficiencies identified by gematik or the BSI. For these vendors, violations of the duty to report, the duty to take remedial action, the duty to provide information or such instructions become subject to fines under Section 397(2a) SGB V as amended. Under the unchanged Section 397(3) SGB V, fines can reach EUR 300,000; the BSI remains the fining authority. The memorandum cites faulty implementations in practice management systems that can cause outages, for example of e-prescriptions.

BSI: Under the new Section 383b SGB V, the BSI becomes market surveillance authority under Regulation (EU) 2025/327 on the European Health Data Space (EHDS). The regulation treats EHR systems as products. An EHR system is software that stores, transmits, imports, exports, converts, edits or displays health data in the priority categories and that the manufacturer intends for patient care or patient access. Manufacturers need technical documentation, an EU declaration of conformity, CE marking and registration. Serious incidents must be reported no later than three days after becoming aware of them; NIS2 reporting duties remain unaffected. Where an EHR system is also a product with digital elements under the Cyber Resilience Act, the manufacturer demonstrates the CRA essential requirements through the EHDS conformity assessment procedure and draws up a single set of technical documentation (Art. 104 EHDS).

Who is affected, and from when

Cloud and SaaS providers handling health data are mainly affected by the new maintenance rule. Two simplified examples, which do not replace an assessment of the individual case:

• A support team can log in to the customer database with administrator rights to analyse a fault and read records. The data is accessible. According to the memorandum, Section 393 then applies in full, including processing location, establishment and C5 attestation for this access.
• The support team works in a separate maintenance environment and sees only encrypted or tokenised data, with the keys held exclusively by the operator of the production system. The new exemption may then apply, according to the memorandum regardless of location. Data protection requirements, for example for transfers to third countries, remain unaffected. The provider must be able to show that this protection holds throughout.

Billing service providers within the scope of Section 295a may use cloud services in future but need the same evidence as healthcare providers under Section 393, including a C5 attestation.

Hospitals that want to allow personal devices must ensure that the conditions of Section 363f are met. For information security, the draft sets a benchmark: measures that meet the sector-specific security standard or equivalent requirements count as appropriate. Data protection measures under Art. 32 GDPR have to be defined separately. The provision covers only the secure TI transmission procedures with approved services and providers; it does not cover transmission via consumer messaging apps.

Vendors of practice and hospital software will be subject to gematik's operational oversight and, where their products are EHR systems, to BSI market surveillance. Depending on size and activity, NIS2 obligations may come on top. That makes three reporting duties with their own channels, thresholds and deadlines.

On timing: the GeDIG is generally to enter into force on the day after promulgation; when that will be depends on the further procedure. The EHDS applies generally from 26 March 2027. Its manufacturer obligations for EHR systems are staggered: from 26 March 2029 for systems intended to process patient summaries, e-prescriptions and e-dispensations, and from 26 March 2031 for medical imaging, test and laboratory results, and discharge reports. For EHR systems offered as a service or manufactured and used within a healthcare institution itself (Art. 26(2) EHDS), Chapter III applies uniformly from 26 March 2031.

Readiness: what can be prepared now

The final text is not settled. Some preparation does not depend on it. In our view, six steps make sense:

1. Map maintenance and support paths. List who accesses cloud systems with health data and for what purpose: own teams, service providers, subcontractors, locations. Record for each path whether the data is technically accessible.
2. Evidence key control. The new exemption only applies if the accessing party cannot decrypt. Document where the keys are, who manages them and how this is technically enforced. According to the memorandum, a contract alone is not enough.
3. Align C5 attestation and maintenance concept. Check whether your C5 attestation covers the maintenance and support processes that remain under Section 393, and whether the customer criteria from the audit report are implemented. Billing service providers within the scope of Section 295a should plan now how to obtain a C5 attestation.
4. Prepare for personal devices in hospitals. Determine which workflows would benefit from personal devices, check your safeguards for such devices against the sector-specific security standard and define the measures under Art. 32 GDPR together with your data protection officer. Set out the rules in a policy and update it once the German Hospital Federation has defined the device requirements.
5. Build one reporting process for several recipients. Vendors should detect, assess and report disruptions, vulnerabilities and incidents in a single workflow: to gematik, to market surveillance and, where applicable, under NIS2. The workflow belongs in the ISMS, with clear responsibilities and rehearsed deadlines.
6. Classify products and set up documentation. Determine which products count as EHR systems, which data categories they process and whether you offer them as a service. This decides whether 2029 or 2031 applies to you. If a product also falls under the Cyber Resilience Act, the technical documentation for both regulations can be built together.

Blackfort Technology supports these steps: with C5 consulting from readiness analysis to preparing the attestation, with Cyber Resilience Act consulting to prepare conformity assessment and technical documentation, and as external information security officer when building an ISMS with rehearsed incident handling and the policies it needs, for example on personal devices. More at www.blackfort-tec.de.