NIS2 for MVZs and Practice Networks: Who Is Affected and What Needs to Be Done by When

Since December 6, 2025, the German NIS2 Implementation Act (NIS2UmsuCG) has been in force. For hospitals, cybersecurity as a mandatory discipline is nothing new — KRITIS hospitals have worked for years with the sector-specific security standard B3S, and larger clinics have ISMS and CISO functions. For outpatient structures, the situation is different: estimates from the draft bill for the NIS2UmsuCG assume that around 1,000 Medical Care Centers will fall directly within scope for the first time — and thus under a set of obligations that previously did not exist in this form.

This guide is intended for managing directors, IT managers, and data protection officers in MVZs and practice associations. The goal: clarity on whether your organization is affected, what the obligations actually mean, and which sequence makes sense for implementation — without turning the project into an 18-month ordeal.

A key point up front: NIS2 does not turn outpatient care centers into small hospitals. Most technical and organizational requirements are operationally easier to meet than in a KRITIS hospital. But: the ten-measure catalog under § 30 BSIG, the reporting obligations under § 32 BSIG, and the personal liability of management under § 38 BSIG remain unchanged. Anyone who is standing here in 2026 without preparation has both an operational and a legal problem.

Who is affected? Thresholds and classification

NIS2 distinguishes between two categories of obligated entities — both are relevant for MVZs and practice associations:

• Important entity: medium-sized company under the EU SME definition (50–249 employees, with turnover up to €50 million or a balance sheet total up to €43 million) in an NIS2 sector. Maximum fine: €7 million or 1.4% of global annual turnover, whichever is higher.

• Particularly important entity: large company (at least 250 employees or more than €50 million in turnover and more than €43 million in balance sheet total) in an NIS2 sector. Maximum fine: €10 million or 2%.

Concrete examples from MVZ practice:

• MVZ with three locations and 60 full-time staff plus 15 part-time staff: important entity. Employees are counted as heads — 75 people, clearly above the 50-person threshold.

• Practice network with 220 employees and €28 million in turnover: important entity — the employee threshold is in the middle range, and so is turnover.

• Hospital group with an MVZ subsidiary: Here it becomes more nuanced. If the MVZ is legally organized as its own GmbH, its own figures count. If it is an integrated part of an NIS2-obligated hospital, it is covered through the parent group.

• Large-practice MVZ with hospital-like structures (laboratory, imaging, operating suite): regardless of employee numbers, it may be classified as a “practice with data processing on a significant scale” — this definition comes from § 75b SGB V (now § 390 SGB V) and is a strong indicator for NIS2 classification.

Anyone unsure whether the classification applies should use the official BSI NIS2 affected-entity check. It guides you through the threshold logic and provides an initial assessment. In cases of doubt, legal clarification is advisable — the classification directly affects the amount of the fine and the intensity of supervision.

Important: self-classification is mandatory. Nobody will be contacted by the BSI and politely asked whether they are affected. Anyone who does not register themselves risks not only a fine in the event of a later incident — in the event itself, management is left without a documented shield against personal liability under § 38 BSIG.

§ 75b SGB V (§ 390 SGB V) and NIS2 — not either-or

The biggest misconception in advisory practice in 2026: “We already implemented the KBV IT security directive — that should be enough for NIS2.” It is not enough.

The IT security directive under § 75b SGB V (since October 2025 anchored in § 390 SGB V) has applied since January 1, 2021 to all contracted physician and contracted psychotherapist practices. It distinguishes three practice sizes — small, medium, and large practices — as well as special cases involving major medical devices and data processing on a significant scale. The directive is structured like an operational measures catalog: concrete technical and organizational measures by practice size, with sample text and checklists from the KBV.

NIS2 (implemented through the BSIG in its new version) is structured more generically. The law defines ten risk management areas (§ 30 BSIG), a three-stage reporting obligation (§ 32 BSIG), and personal duties of management (§ 38 BSIG). The law leaves the level of implementation detail to the organization — the standard is the state of the art.

In practice, three constellations arise for an MVZ subject to NIS2:

1. Identical requirements. Backup, antivirus protection, multi-factor authentication, network segmentation, access management — what the KBV directive already requires is also covered by NIS2. Anyone who has properly implemented § 75b/§ 390 SGB V already has 60 to 70 percent of the NIS2 baseline measures in place.

2. NIS2 gaps compared with the KBV directive. The KBV directive does not know a three-stage reporting system with 24-hour early warning. It does not establish personal management liability with a training obligation. It does not require BSI registration. It does not prescribe systematic supplier management. It does not define fines in the millions.

3. KBV requirements that NIS2 does not have at this level of detail. The specific requirements for the telematics infrastructure, major medical devices, and patient data protection are formulated more concretely in the KBV directive. Anyone setting up an NIS2 compliance project should not throw the KBV directive overboard — but should maintain both sets of rules in parallel.

The pragmatic consequence: a shared information security policy as an umbrella, an operational measures catalog based on § 75b/§ 390 SGB V, and an NIS2-specific supplemental document for the gaps (reporting, supply chain, management training proof, registration).

The ten obligations under § 30 BSIG — translated for MVZs

§ 30 BSIG lists ten mandatory risk management areas. In MVZ terms:

1. Risk analysis and security concept. Which systems process which data? Where are the critical points? A one-page risk register with 15 to 25 risks is enough to start.

2. Handling security incidents. Who is alerted when? Who decides on system segmentation? Which authorities are informed? A two-page incident response plan is mandatory.

3. Business continuity. If the practice management system or the connector fails — how does patient care continue? Manual forms, emergency phone list, alternative findings routes.

4. Supply chain security. Which IT service providers have access to patient data? Connector provider, practice management system vendor, MFA maintenance company. A processor agreement under Art. 28 GDPR is mandatory, supplemented by concrete security agreements and a minimum level of audit rights.

5. Security in acquisition, development, and maintenance. Patch management, vulnerability handling, secure configuration of new purchases. This is where many MVZs have their biggest gap — nobody feels structurally responsible.

6. Assessment of the effectiveness of measures. Does what you have put in place actually work? Quarterly internal reviews, annual review of critical systems.

7. Cyber hygiene and training. Phishing awareness is explicitly anchored here. Staff must be trained regularly, and the training must be documented. Art. 21(2)(g) of the NIS2 Directive expressly requires this.

8. Cryptography. Encryption in transit (TLS), at rest (hard drives, backups), and in email communication involving patient data. KIM and the ePA include parts of this, but not the full range.

9. Personnel security, access control, and asset management. Who has access to which systems? Are permissions removed when employees leave? Is there a complete inventory of the systems in use?

10. Multi-factor authentication and secured voice and video connections. MFA for all administrative accounts and remote access is the single most effective measure. Full stop.

In practice, points 1, 2, 5, and 7 are the most common weaknesses — this is where the implementation focus should lie.

Specific risks in MVZ structures

MVZs face a different threat landscape than pure acute-care hospitals. Four recurring patterns:

Telematics infrastructure as an attack vector. KIM, the ePA, e-prescriptions, and electronic sick notes run through connectors and gematik components. These are usually certified — but the local access to them (practice management system workstations, smart cards, eHBA) is not automatically. A successful phishing attack on an MFA employee can lead to manipulated e-prescriptions or unauthorized access to the ePA.

Distributed locations with central IT. Practice associations with three or more locations often operate a central server infrastructure — VPN connections, shared Active Directory, shared backup strategy. If the central server is compromised, all locations are affected. This is not hypothetical — the cyberattack on the MVZ Tirschenreuth/Kemnath in autumn 2025 followed exactly this pattern and led to the temporary closure of both locations.

High staff turnover, many devices. In outpatient care, nurses, medical assistants, and physicians change more often than in hospital structures. Onboarding and offboarding are often not systematized from an IT perspective — former employees retain system access for weeks or months. Tablets, smartphones, and mobile devices further expand the attack surface.

Billing as a financial target. Outpatient structures are attractive for targeted CEO fraud attacks and manipulated invoices — the flow of funds is easier to hijack than in a hospital. A medium-sized MVZ chain with five locations quickly processes seven-figure monthly reimbursements.

Reporting under § 32 BSIG — 24/72/30 in practice

§ 32 BSIG sets out a three-stage reporting obligation:

• Initial report within 24 hours of becoming aware of the significant security incident: brief description of the incident, affected systems, suspected origin.

• Assessment report within 72 hours: detailed evaluation of the impacts, measures taken, classification of severity.

• Final report after one month: full review, cause, consequences, lessons learned, and adjustments to the security concept.

The report is submitted via the BSI reporting portal, which is accessed through the My Company Account (MUK). Both registration and incident reports are handled there.

Operationally, this means three preparation points for an MVZ:

1. Set up the MUK account before the first incident. Anyone who still has to organize login credentials in a crisis loses hours. Access should be stored with management and the IT lead, with a clearly defined backup contact.

2. Document the escalation chain. Who triggers the report in the event of an incident should be clear in advance. Typical chain: IT leadership recognizes it → management decides → the data protection officer checks the GDPR reporting obligation in parallel.

3. Keep templates for the three reports ready. The 24-hour initial report often happens in crisis mode. A prepared text module, into which only case-specific details are inserted, saves time and reduces errors.

Important: the NIS2 report does not replace the GDPR reporting obligation under Art. 33 GDPR in the event of patient data loss. In classic ransomware incidents, both reporting paths must be activated at the same time — the BSI portal under § 32 BSIG and the competent data protection authority under the GDPR.

§ 38 BSIG — the personal liability of management

Perhaps the most uncomfortable part of NIS2: management is personally liable for implementing and complying with the risk management measures. The BSIG expressly anchors in § 38:

• Management must monitor the implementation of the § 30 measures.

• Management must regularly participate in cybersecurity training.

• In the event of a breach of duty, management is personally liable for damages.

The law leaves open what format and frequency “regularly” means. A proven approach is an annual documented training session with agenda and attendance proof, supplemented by written quarterly reports on the security situation.

In MVZ structures with multiple managing directors, the obligation applies to all of them. Delegation “to IT” is not legally possible — operational responsibility can be transferred, but not the supervisory and monitoring duty.

8-week roadmap for a typical MVZ

In practice, the following sequence has proven effective — more compact than the hospital roadmap, because outpatient structures are usually less complex and less often operate several hundred care-critical systems in parallel.

Weeks 1 to 2: inventory assessment. Scope clarification (which locations, which subsidiaries, which practice areas), asset inventory (servers, workstations, connectors, mobile devices), supplier mapping (practice management system vendor, IT service provider, cloud provider). A simple Excel sheet is enough — completeness is what matters.

Weeks 3 to 4: quick wins. MFA on all administrative accounts (Active Directory, practice management system, backup system, VPN, RDP, Microsoft 365). Check backup strategy against 3-2-1, with at least one copy offline or immutable. Phishing awareness kickoff for the entire workforce — a short kickoff format with documentation.

Weeks 5 to 6: build documentation. Information security policy as a shared umbrella for § 75b/§ 390 SGB V and NIS2. Risk register with 15 to 25 risks. Emergency plan of two pages. Supplier register with processor-agreement status and risk assessment. Incident response flowchart with escalation chain and reporting templates.

Week 7: management training. Documented session on the cybersecurity situation, introduction to the duties under § 38 BSIG, overview of the security concept. Include agenda and attendee list in the file.

Week 8: registration with the BSI. Via the My Company Account (MUK), with master data, classification, and 24/7 contact point. With good preparation, the portal process takes 30 to 60 minutes.

After that: no project phase is ever “finished.” Quarterly updates to the risk register and emergency plan, annual phishing simulation, tabletop exercise at least once a year, and external assessment of measures every two years.

Common pitfalls

“Our IT service provider handles everything.” That is not a NIS2-compliant answer. Responsibility cannot be outsourced — the service provider implements measures, but supervision, risk assessment, and management liability remain with the MVZ.

“We’ll wait and see whether the BSI checks.” Fines do not only apply after BSI audits, but in incidents without documented protective measures. And in the event of an incident, the 24/72/30-hour deadlines are unforgiving.

“Phishing simulation? The works council won’t go along with that.” Correct — and the same applies in MVZ structures. But with a clean works agreement that clearly regulates anonymization, purpose limitation, and the prohibition of using the results for personnel measures, co-determination is not a blocker but an accelerator.

“We’ll do the documentation first, then the measures.” Backwards. Documentation grows out of lived practice — implement measures, document as you go, then condense them into a quarterly structure.

Conclusion

NIS2 for MVZs and practice networks is no longer optional in 2026, but mandatory. Operational implementation is feasible — eight weeks are enough for a solid basic framework, if scope, prioritization, and resource allocation are right from the start.

The biggest levers: MFA on all administrative accounts, a documented emergency plan, a well-thought-out supplier list, and annual management training with proof. Much of the rest follows from the already implemented KBV IT security directive under § 75b/§ 390 SGB V.

Where things typically get stuck: supplier management (often completely disorganized), awareness programs (rarely run systematically), and reporting with 24-hour logic (in very few cases set up). This is exactly where managed services for Phishing Simulation, Awareness Training, Vulnerability Management, and Incident Detection & Response come in — they provide the operational building blocks required by § 30 BSIG without MVZs having to build their own security team.

At Entropy CS, we support MVZs and practice networks with exactly these managed services — the operational pillars of NIS2-compliant security work. Our free risk assessment takes 30 minutes and provides an honest snapshot of your organization — including concrete next steps.