Maintenance and support access under Section 393 SGB V: current law and the GeDIG draft

This page separates two things: what Section 393 SGB V says about maintenance and support today, and what the GeDIG draft bill would change. The provision as a whole, including location, establishment, attestation and deadlines, is covered on the Section 393 SGB V page. Quotes from the draft are our own translation; there is no official English version. This is general information, not legal advice, and the draft may still change.

What applies today

In its current version, Section 393(1) has a single sentence: healthcare providers, statutory health and long-term care insurers and their processors may process social and health data by way of a cloud computing service if subsections 2 to 4 are met. There is no specific rule for maintenance, support or troubleshooting (wording checked on 1 November 2026).

In our view, access to a cloud system with health data, for instance by a support team with admin rights or an external remote maintenance provider, has to meet Section 393 in full to the extent that it is processing: processing location, establishment in Germany, technical and organisational measures and a current C5 attestation. Whether a particular access counts as processing under Section 393 is not answered by the wording and needs a case-by-case assessment.

What the GeDIG draft would change

On 30 September 2026 the Federal Government submitted the draft Act on Data and Digital Innovation in Healthcare (Bundestag printed paper 21/8279; abbreviated GeDIG by the Federal Ministry of Health). Article 1 no. 100 would replace Section 393(1). Sentence 1 would stay the same in substance, with “Auftragsverarbeiter” (processors, the GDPR term) replacing “Auftragsdatenverarbeiter”; a new sentence 2 would read (our translation):

“Access for maintenance and support purposes shall not be deemed processing under sentence 1 if technical safeguards in line with the state of the art, in particular encryption, ensure that the data cannot be viewed or otherwise processed in the course of such access.”

The explanatory memorandum to no. 100 (pages 187 f.) describes sentence 1 as unchanged and sets out the intent of the new sentence 2:

• Technical protection is the trigger. What counts is solely the technically demonstrated inaccessibility of the data; the purpose of the access is not enough on its own.
• Encryption only without keys. Encryption is sufficient only if the accessing party has no means of decryption. Purely organisational or contractual assurances are not enough.
• Technology-neutral. Trusted execution environments, effective separation of the maintenance environment from production data, and tokenisation are named; the list is open.
• Effect. Subsections 2 to 4 would not have to be met separately for such sealed access. The memorandum explicitly mentions maintenance and support regardless of location.
• Limit. The exemption reaches only as far as the technical protection. If the data is not consistently sealed, Section 393 applies in full. The security logic based on the C5 attestation remains fully intact; subsection 8 is unaffected.
• Cloud migration. Moving existing systems from on-premises to the cloud should not, by itself, change the assessment of established maintenance processes.

Current law and draft compared

Where the bill stands

• Cabinet decision on 15 July 2026, first round of deliberations in the Bundesrat on 25 September 2026 (Federal Ministry of Health).
• Printed paper 21/8279 dated 30 September 2026, published as an advance version to be replaced by an edited version.
• First reading in the Bundestag on 8 October 2026 and referral to the Committee on Health; public hearing on 14 October 2026 (Bundestag).
• The ministry lists the bill as ongoing. When we checked on 1 November 2026, we found no final vote of the Bundestag.

Under Article 16(1) of the draft, the act would generally enter into force on the day after promulgation, with no separate date for no. 100. Until then, Section 393 applies in its current version.

Example: two support routes at one vendor

Fictitious example. A hospital software vendor runs its service in a data centre in Germany. Second-level support is provided by a contractor outside the EU.

• Route A: the contractor logs into the production database with admin rights and can read records. The data is accessible, so in our view, today and under the draft, this access has to meet Section 393 in full, including the location rules in subsection 2.
• Route B: the contractor works in a separate maintenance environment with tokenised copies. Keys and the token vault sit in a key store managed only by the vendor in Germany; the contractor has no technical access to it. Under the draft, the new exemption could apply, provided the vendor can show the protection holds throughout.

Data protection rules, for example on transfers to third countries, still have to be assessed separately in both cases.

What this means for the C5 attestation

The exemption would take individual access routes out of Section 393, but it would not replace the attestation for the cloud service. In our view, maintenance and support routes stay within the subject matter of the C5 audit, because they touch controls the auditor looks at anyway: privileged access in the IAM area, key management in the CRY area (C5:2026 includes, for example, CRY-18 on external key management systems), separation of environments under DEV-12 where a maintenance environment is to be kept apart from production data (plus tenant separation under OPS-30 and OPS-31 for shared resources), and the monitoring of external support providers as subservice organisations.

What you can prepare now

1. Map access routes: who accesses systems with health data, for what purpose and from where, and whether the data is technically reachable on each route.
2. Document key custody: where keys are, who manages them, and how it is technically enforced that maintenance staff cannot use them.
3. Separate the maintenance environment: troubleshoot with tokenised or synthetic data where possible.
4. Collect evidence: keep configurations, logs and approvals so they are available for the whole Type 2 period.
5. Do not rely on contracts alone: under the memorandum, a confidentiality promise would not replace technical protection.

A C5 readiness assessment shows where your access routes, key custody and evidence stand against the C5 criteria today.

Other links between the draft and Section 393

Under Article 1 no. 24, the requirements of Section 393 would apply accordingly to billing centres under Section 295a SGB V that use cloud services; the memorandum names location, establishment in Germany and a C5 attestation. The draft also contains further rules for healthcare software, for example on private devices in hospitals, reporting duties towards gematik and BSI market surveillance of EHR systems; they are not covered here.