NIS2 in Healthcare: Hospitals and Outpatient Care

Main article: NIS2 implementation in Germany — all obligations under the BSIG at a glance: scope, measures, reporting obligations and fines.

1. Who is affected?

In Germany, you are affected if your organisation falls under a type of entity in the health sector under Annex 1 BSIG and reaches the size thresholds of Section 28 BSIG — and, regardless of size, every operator of a critical installation (§ 28(1) sentence 1 no. 1 BSIG). Hospitals, medical care centres (MVZ), rehabilitation clinics and other providers of healthcare services are important entities if they employ at least 50 people or have an annual turnover and an annual balance sheet total of more than EUR 10 million each (§ 28(2) sentence 1 no. 3(a) and (b) BSIG). The two thresholds apply alternatively, not cumulatively — the number of employees alone is already sufficient; for the financial criterion, the annual balance sheet total matters alongside turnover. Long-term care facilities that support people who need help with routine, everyday tasks are not covered: according to the explanatory memorandum to the Act, they do not count as providers of healthcare services within the meaning of Annex 1 no. 4.1.1 BSIG (as also stated in the BSI's sector-specific NIS2 FAQ). Special case: KRITIS hospitals (>30k inpatient cases per year) in addition.

From 250 employees, an important entity becomes a particularly important entity. Healthcare providers are a type of entity under Annex 1 BSIG (sector 4 health, “providers of healthcare services within the meaning of Directive 2011/24/EU”). For Annex 1 types, the higher threshold therefore applies in addition: at least 250 employees or an annual turnover of more than EUR 50 million and additionally an annual balance sheet total of more than EUR 43 million — then a particularly important entity (§ 28(1) sentence 1 no. 4(a) and (b) BSIG). Operators of critical installations are particularly important entities in any event (§ 28(1) sentence 1 no. 1 BSIG). An entity is an important entity only if it is not already a particularly important entity (§ 28(2) sentence 2 BSIG). The classification determines the intensity of supervision and the range of fines.

Two points decide the classification of a provider in practice. First, on both tiers only the number of employees operates on its own — 250 for the particularly important entity, 50 for the important entity; turnover alone is never sufficient, because § 28(1) sentence 1 no. 4(b) and § 28(2) sentence 1 no. 3(b) BSIG require the annual balance sheet total in addition to turnover. Second, what matters is not the name of the organisation but its allocation to a type of entity under Annex 1 or Annex 2 BSIG; this has to be assessed for each legal entity, particularly in group structures with spun-off service, laboratory or IT companies. For calculating employee numbers, annual turnover and balance sheet total, Recommendation 2003/361/EC applies, with the exception of Art. 3(4) of its Annex (§ 28(4) BSIG); group membership may bring linked enterprises into the calculation. Practical recommendation: record the classification for each legal entity in writing — with the reference date, the underlying figures and the number of Section 28 BSIG relied on.

2. Dual regulation NIS2 plus KRITIS

Large hospitals are additionally covered as operators of critical installations (KRITIS, >30,000 fully inpatient cases per year under the BSI KRITIS Regulation). They must evidence implementation of the measures under Section 30 BSIG at the earliest 3 years after the first classification and every 3 years thereafter through security audits, reviews or certifications (§ 39(1) BSIG 2025 — the former 2-year cycle came from § 8a BSIG, old version).

The KRITIS status operates at three points, which must be handled separately. First, in the classification: anyone operating a critical installation is a particularly important entity regardless of size (§ 28(1) sentence 1 no. 1 BSIG) — employee numbers, turnover and balance sheet total then no longer matter, and the higher range of fines applies (section 9). Second, in the evidence: § 39(1) BSIG allows a security audit, a review or a certification as three equivalent routes; the results, including the security deficiencies identified, must be transmitted. Third, in the registration: for operators of critical installations, § 33(2) BSIG provides for a different route via § 8 of the German KRITIS Umbrella Act (KRITIS-Dachgesetz) (section 7).

An organisation below the KRITIS threshold is therefore not exempt from the measures, only from the periodic evidence procedure: the measures under Section 30 BSIG are owed by every particularly important and important entity.

3. Special sensitivity under Art. 9 GDPR

Patient data is health data and therefore a special category of personal data under Art. 9(1) GDPR — processing it is prohibited in principle and permissible only under the narrow exceptions of Art. 9(2) GDPR, for example explicit consent. Where a significant security incident is at the same time a personal data breach, it must be reported twice — to the joint reporting office of the BSI and the BBK and to the data protection supervisory authority (section 7). The classification as a special category gives rise to three further obligations, which run alongside the NIS2 obligations and are independent of them:

• Data protection impact assessment: where special categories of data under Art. 9 GDPR are processed on a large scale, a DPIA must be carried out in advance (Art. 35(1) and (3) GDPR) — for a hospital information system it must therefore be assessed and documented whether the large-scale processing threshold is reached.
• Data protection officer: one must be designated where the core activity consists of large-scale processing of special categories of data (Art. 37(1)(c) GDPR); in Germany the threshold of § 38(1) of the German Federal Data Protection Act (BDSG) is added, in Austria no additional numerical threshold applies (§ 5 of the Austrian Data Protection Act (DSG)). Details in the FAQ.
• Processing on behalf of a controller: for outsourced processing — hospital information system hosting, radiology archives, billing service providers — Art. 28 GDPR applies, with the minimum contractual content prescribed by law (section 5).

Supervision here is not exercised by the same authorities as under NIS2: in Germany, the data protection authorities competent under Land law supervise non-public bodies (§ 40(1) BDSG), in Austria the Austrian Data Protection Authority (Datenschutzbehörde) does so (§ 18(1) DSG). The double reporting situation in the event of an incident, with deadlines and addressees, is set out in section 7.

4. Specific measures

§ 30(2) BSIG does not contain a separate catalogue of measures for hospitals — the ten areas apply across sectors; what is sector-specific is not the catalogue but what it is applied to within the organisation: medical device cybersecurity, operating theatre IT, laboratory information systems, patient apps.

The measures should comply with the state of the art, take the relevant European and international standards into account, and must be based on an all-hazards approach (§ 30(2) sentence 1 BSIG); compliance must be documented (§ 30(1) BSIG). The ten areas of § 30(2) BSIG are: policies on risk analysis and information system security (no. 1), incident handling (no. 2), business continuity, including backup management, recovery and crisis management (no. 3), supply chain security (no. 4), security in acquisition, development and maintenance (no. 5), assessment of effectiveness (no. 6), cyber hygiene and training (no. 7), cryptography and encryption (no. 8), human resources security and access control (no. 9), and multi-factor authentication, continuous authentication and secured communications (no. 10).

Four of these areas are set out here for hospital operations; the other six are covered in the linked main article. For a hospital, no. 3 means restarting care delivery, not just a backup concept; in practice this includes a business continuity plan with RTO and RPO per process, backup following the 3-2-1 principle or equivalent, a tested recovery routine and a crisis management plan with internal and external communication. No. 5 concerns acquisition, development and maintenance — the area covering the procurement and remote maintenance of medical technology systems, in so far as they count among the organisation's IT systems; in practice this includes vulnerability management with a process for coordinated disclosure. No. 9 requires human resources security and access control; in practice this means an authorisation concept on a need-to-know basis, documented withdrawal on a change of ward and on departure, periodic review. No. 10 requires multi-factor authentication or continuous authentication; as a practical recommendation, it should be treated as the minimum standard for all administrator accounts and all external access routes (VPN, cloud), while for pure office use the scope is to be justified on a risk basis. Practical recommendation: record the four classes of installation named above in an asset inventory and note, for each class, who maintains it, through which access route and under which credentials — without this inventory, no. 5, no. 9 and no. 10 remain unverifiable. In Austria, the corresponding catalogue is set out in § 32(4)(a) to (j) NISG 2026 and applies from 1 October 2026.

5. Supplier audit specifics

Audit medical device manufacturers and cloud service providers for hospital information systems (HIS) as a priority (practical recommendation). The benchmark in Germany is § 30(2) no. 4 BSIG (supply chain security), in Austria from 1 October 2026 § 32(4)(d) NISG 2026; a frequent weak point in practice is the absence of cybersecurity clauses in supplier contracts (practical assessment, not an official evaluation).

Four building blocks belong in an organisation's supplier programme:

• Supplier assessment with risk classification — it determines who is examined in depth at all; the criterion with the greatest effect is access to care-relevant systems and the remote maintenance access route.
• Cybersecurity clauses in the standard contracts instead of individual negotiation for each procurement.
• Right to audit for critical suppliers — without a contractual basis, every review remains a request rather than a right.
• Incident reporting by the supplier to you, customarily within 24 hours. The 24-hour requirement follows from the contract, not from § 30(2) no. 4 BSIG; it is what first creates the basis for submitting your own 24-hour report on time (section 7).

A second, independent strand runs alongside for HIS hosting: in so far as the service provider processes patient data on behalf of the organisation, the organisation may only work with processors providing sufficient guarantees of appropriate technical and organisational measures, and must govern the cooperation through a contract under Art. 28(3) GDPR — covering the subject matter, duration, nature and purpose of the processing, the types of data, the categories of data subjects, and the obligations and rights of the controller. The supply chain obligation of § 30(2) no. 4 BSIG does not replace this contract, and the processing agreement does not replace the supply chain review. Practical recommendation: keep both strands in one supplier file per service provider, so that an inspection does not find two sets of records with different statuses side by side.

6. Austria: healthcare under the NISG 2026

The sections above describe the German legal position (BSIG 2025, BSI KRITIS Regulation, supervision by the BSI). In Austria, a separate framework applies from 1 October 2026 with the NISG 2026 (BGBl. I Nr. 94/2025): healthcare is likewise covered as a highly critical sector under Annex 1. The risk management measures follow § 32 NISG, reports of significant incidents (24 h / 72 h / 1 month) go to the competent CSIRT (§ 34 NISG), and registration under § 29 NISG is with the Cybersecurity Authority (Cybersicherheitsbehörde, Austria). There too, company size determines the class: Annex 1 entities operating a large enterprise (from 250 employees, or more than EUR 50 million annual turnover and more than EUR 43 million annual balance sheet total) are essential entities, while medium-sized enterprises (from 50 employees, or more than EUR 10 million turnover and more than EUR 10 million balance sheet total) are important entities (§ 24, § 25 NISG). The range of penalties matches the Directive: up to EUR 10 million or 2 % of worldwide annual turnover for essential entities, up to EUR 7 million or 1.4 % for important entities (§ 45(2) and (3) NISG); the administrative penalties are imposed by the district administrative authority. Data protection for health data (Art. 9 GDPR) applies identically across the EU; supervision in Austria is exercised by the Austrian Data Protection Authority (Datenschutzbehörde, DSB).

The timing is the key difference from Germany. The NISG 2026 was promulgated on 23 December 2025 and becomes applicable on 1 October 2026 — nine months after promulgation, on the first day of the following month (§ 51(1) and (2)). Only from that day do the risk management obligations of § 32 NISG 2026 apply; the subsequent deadlines for registration, self-declaration and evidence are set out in section 7. For an Austrian organisation this means: before that day, the NISG 2026 itself does not yet create any registration or reporting obligation; on its entry into force it replaces the NISG 2018 together with the NISV and the QuaSteV (§ 51(1) and (2)). The remaining preparation time is the difference compared with German organisations, for which the BSIG has already applied since 6 December 2025.

Two further differences are relevant for providers with organisations in both countries. First, the authority landscape: in Austria the competent body is the Federal Office for Cybersecurity (Cybersicherheitsbehörde, Austria), an authority directly subordinate to the Federal Minister of the Interior and based in Vienna (§ 3a(1) and (2), § 3b(3) NISG 2026); supervision and enforcement lie with it (§§ 38 and 39), whereas incident reports go to the competent sector-specific CSIRT, otherwise to the national CSIRT (§ 34(1)). Second, the logic of evidence: Austria requires a structured self-declaration from all essential and important entities and — upon request — evidence from an independent body (§ 33 NISG 2026), whereas in Germany the periodic evidence obligation of Section 39 BSIG primarily applies to operators of critical installations. Group structures with organisations in Germany and Austria register separately in both countries.

7. Deadlines, reporting channels and evidence at a glance (DE and AT)

The following overview contains statutory deadlines and obligations only — each row names the provision it follows from and the entities it applies to. Practical recommendations are not in this table but are marked as such in the running text and in section 10. The Austrian rows only take effect from 1 October 2026.

The reporting clock only starts running once the incident is significant. Under § 2 no. 11 BSIG, a security incident is significant if it has caused or is capable of causing severe operational disruption of services or financial loss for the entity, or if it has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage. Quantitative thresholds for this are set out in EU Implementing Regulation 2024/2690, but only for certain types of digital entity such as DNS service providers, cloud and data centre services or managed (security) service providers — not for healthcare entities. For all other entities, until a statutory instrument under § 56(5) BSIG is adopted, only the definition in § 2 no. 11 BSIG applies. In Austria, the substantively equivalent threshold is set out from 1 October 2026 in § 35(1) NISG 2026; there, the financial losses must also be severe.

8. Management: implementation, monitoring, training

The management of an organisation owes the risk management measures personally: it must implement the measures under Section 30 BSIG and monitor their implementation (§ 38(1) BSIG) — the responsibility for this lies with the management itself and cannot be delegated. If it breaches these duties, it is liable to its own organisation for culpably caused damage under the rules of the company law applicable to the legal form (§ 38(2) BSIG); under the BSIG itself, management is liable only subsidiarily, namely where the relevant company law contains no such liability rule (§ 38(2) sentence 2 BSIG). In addition there is its own training obligation: management must attend training regularly (§ 38(3) BSIG).

In Austria, from 1 October 2026 the management bodies must ensure and supervise compliance with the risk management measures under § 32 NISG 2026, and they must attend specifically designed cybersecurity training; corresponding training must be offered to employees regularly (§ 31(1) and (2) NISG 2026). § 31 NISG 2026 contains no express internal liability rule comparable to § 38(2) BSIG — that is the point at which the two legal systems differ, and at which a management briefing written for Germany does not fit the Austrian sister company word for word. Practical recommendation: minute the approval of the measures and attendance at the training; without minutes, the monitoring within the meaning of § 38(1) BSIG cannot be demonstrated in an inspection.

9. Range of fines and relationship to the GDPR

The range of fines depends on the classification: up to EUR 10 million against particularly important entities and up to EUR 7 million against important entities (§ 65(5) sentence 1 no. 1(a) and (b) BSIG). The turnover variant of 2 % or 1.4 % of worldwide total turnover only applies above a total turnover of EUR 500 million and only for the infringements designated in § 65(6) and (7) BSIG; total turnover here is the sum of all worldwide revenue of the undertaking to which the entity belongs in the financial year preceding the authority's decision (§ 65(8) BSIG). For most organisations this means: what matters is the fixed maximum amount, not the percentage.

The relationship to data protection law is no side issue here, because an attack on a hospital information system regularly triggers both regimes. A GDPR fine under Art. 83 GDPR may in principle be added — up to EUR 10 million or 2 % of worldwide annual turnover for infringements including those of Art. 25 to 39 GDPR, and up to EUR 20 million or 4 % for infringements of the processing principles and data subject rights, whichever amount is higher. However, where a data protection supervisory authority has already imposed a GDPR fine for the same conduct, an additional fine under the BSIG is excluded (§ 65(11) BSIG). For Austria, the range set out in section 6 applies from 1 October 2026, where in each case the higher amount is decisive; other contraventions are punishable by up to EUR 50,000 and, in the event of a repeat, up to EUR 100,000 (§ 45(4) NISG 2026).

10. Practical rhythms for hospitals

None of the following rows is a statutory deadline. They are throughout practical recommendations on how to pace the work; what is required are appropriate, proportionate and effective measures (§ 30(1) BSIG) or — from 1 October 2026 — appropriate and proportionate risk management measures (§ 32(1) NISG 2026), and the depth of implementation scales with the risk. The binding dates are set out solely in the table in section 7. The column "Relation to the area of obligation" names the German sources; the Austrian equivalents are set out in § 32(4)(a) to (j) NISG 2026 (section 4).