NIS2 for healthcare providers: scope, cost and readiness

Does NIS2 apply to healthcare providers, pharma and medical devices?

NIS2 reaches the health sector entities listed in Annex I that meet the size test. Entities above the medium-sized enterprise ceilings are essential, and most other in-scope entities in the sector are important. The sector list covers healthcare providers, EU reference laboratories, medicinal product research and development, manufacturers of basic pharmaceutical products, and manufacturers of medical devices that are critical during a public health emergency. If a regulator, a customer or a contract now points to NIS2, the first task is to map each legal entity in your group against those categories rather than against the sector name alone.

Scope depends on three things at once: the sector category, the size of the entity, and whether it provides services or carries out activities in the Union. A hospital group, a contract research organization and a device maker can each land in a different status, and a subsidiary may be assessed separately from its parent. Because the classification drives which supervisor applies and how strict supervision will be, ask for a written scope analysis before anyone estimates cost or timeline. Confirm with your national competent authority or your national transposition law how your Member State applies these rules, since NIS2 binds entities through national law.

NIS2 creates no certificate of compliance. No one can issue you a NIS2 certificate, and an implementation partner cannot either. National authorities supervise compliance through inspections, audits, scans and information requests, and an independent auditor or assessor may be engaged to test specific controls. The organization owns its controls and the decisions behind them, while an implementation partner can prepare systems, configurations and evidence. Your board or management body remains accountable for approving the measures, so plan that sign-off as part of the program from the start.

Which health sector entities NIS2 covers

NIS2 lists five health sector categories in Annex I, and each one has its own entry test. Some are covered by activity alone, while others depend on size, so the first step is to match your activities to the right category and then confirm with your national authority how your national law applies.

Healthcare providers

This category covers entities that provide healthcare services to patients, such as hospitals and clinics, as defined in the Directive and national law. Whether an organization counts as a healthcare provider depends on the services it actually delivers, not only its name or legal form. Check each site and service line separately, since a group may operate some facilities that fall in scope and others that do not. Confirm with your national authority how it reads the definition for outpatient, diagnostic and specialist services.

EU reference laboratories

EU reference laboratories are designated laboratories that support public health work across the Union. They are listed in Annex I because disruption to their testing and analysis can affect health responses across several Member States. Designation is a formal status, so the first question is whether your laboratory holds it. Confirm the designation with the relevant authority and check whether the Member State applies the category to laboratories at the national level as well.

Medicinal product research and development

This category covers organizations that carry out research and development of medicinal products, from early development through to the regulatory submissions that follow. Research sponsors, contract research organizations and biotech companies can all fall within it, depending on their activities. Map which of your systems hold trial data, clinical records or regulatory submissions, because those systems usually drive your risk assessment. Ask your national authority whether a purely contract-based role falls within the category.

Basic pharmaceutical products manufacturing

This category covers manufacturers of basic pharmaceutical products classified under NACE Rev. 2 division 21. The NACE code is a statistical classification, so confirm that your main or secondary activity falls under division 21 by checking your registered business activities. Production control systems, quality management systems and batch records are the systems that most often need to be covered by your measures. Confirm with your national authority how it applies the size thresholds to your group structure.

Critical medical device manufacturers

This category covers manufacturers of medical devices that are regarded as critical during a public health emergency. The list of critical devices is determined through the Annex I criteria and national or EU designation, so a device maker does not fall in scope simply because it makes medical equipment. Confirm with your national authority and the relevant health authority whether any of your products are designated as critical. Keep a current list of those products and the production systems behind them, since that list defines the scope of your risk assessment.

What the size ceiling changes: essential versus important status

For a healthcare provider, pharma manufacturer or medical device maker in Annex I, the first question is whether the entity exceeds the medium-sized enterprise ceilings in Commission Recommendation 2003/361/EC. If it does, Article 3(1)(a) of NIS2 makes it an essential entity. Other in-scope Annex I entities are generally important entities, unless another Article 3(1) category, such as a designation by a Member State, makes them essential. The test uses the headcount and financial thresholds of the Recommendation, so the answer depends on the whole enterprise and its linked enterprises, not only the subsidiary that runs the clinic, laboratory or production site. Group-level headcount and turnover should be confirmed with counsel before any classification decision is recorded.

The status drives the supervision model and the fine ceiling. Essential entities face *ex ante* supervision, meaning authorities can check compliance before an incident occurs, while important entities face *ex post* supervision, which is triggered by evidence that they failed their duties. For infringements of Article 21 or Article 23, essential entities can be fined a maximum of at least EUR 10 000 000 or at least 2% of total worldwide annual turnover in the preceding financial year, whichever is higher. The fine ceiling for important entities is set in national law under Article 34, so the national transposition text for each Member State where the group operates should be checked. A hospital group, for example, may be essential in one country and treated under different national rules elsewhere (illustrative).

The size status changes how exposed the organization is to supervision, but it does not change the work. Article 21 risk-management measures and Article 23 reporting duties apply in full to both categories, including the business impact analysis for continuity planning and the 24-hour early warning. Management should therefore not plan a lighter program for an important entity. The practical decisions are to record the classification with a documented basis, confirm the group headcount and turnover figures each financial year, and ask counsel to confirm how any linked enterprises are counted. Re-test the status whenever an acquisition, disposal or reorganization changes the group.

How the incident reporting clock runs for a health sector entity

This sequence shows how a health sector entity moves from first awareness of a significant incident to the early warning, notification and final report that Article 23 requires, so the reporting duties are met under pressure. Each step names the output that proves the step was done.

Record the moment of awareness
The clock starts when the entity becomes aware of a significant incident, so the first step is to log that moment precisely. The incident coordinator, usually a member of the security operations or response team, records the date, time and source of the first signal, whether it came from a monitoring alert, a clinician report, a supplier or a regulator. Keep the log in a tamper-evident system so the start time can be defended later. The output is a timestamped incident record that every later deadline is calculated from.
Assess whether the incident is significant
Before any report is due, the response team decides whether the incident meets the significance criteria. For health sector entities, check the thresholds in the Article 23 text and in your national transposition law, and document the reasoning against the impact on service availability, patient care, medicine supply or medical device safety. The output is a signed significance assessment held by the incident coordinator and reviewed by the legal or compliance lead. Where the assessment is uncertain, record the uncertainty and the reason for escalating it.
Submit the early warning within 24 hours
Article 23(4)(a) requires an early warning without undue delay and in any event within 24 hours of becoming aware of a significant incident. The compliance lead submits it to the CSIRT or competent authority named in the national law, using the channel and format that authority specifies. The early warning can be brief and should state whether the incident is suspected of being caused by unlawful or malicious acts and whether it could have cross-border effects. The output is a submission receipt stored with the incident record.
Notify the authority and update the assessment
After the early warning, the notification follows under Article 23. It updates the authority with an initial assessment of the incident, including its severity and impact, and any indicators of compromise the team has identified. Confirm the due date for this notification against the Article 23 text and your national transposition law, not against this page. The output is a notification record showing what was reported, when, and by whom, plus an updated impact analysis.
Inform affected service recipients
Where the incident is likely to adversely affect the provision of the entity's services, Article 23 expects the entity to inform the affected service recipients without undue delay. For a hospital, clinic, laboratory or manufacturer, these recipients may include patients' treating organizations, purchasers, pharmacies or hospitals that rely on a device or supply. The communications lead prepares notices that describe the impact and the protective steps users can take, and approval comes from the management body or a delegated officer. The output is a dated log of each notice, its recipients and its content.
Deliver the final report
Once the incident is handled, Article 23 requires a final report. Confirm the deadline for it against the Article 23 text and your national law. The report should set out the root cause, the severity and duration, the measures taken and any cross-border impact. The incident coordinator drafts it from the incident record and the legal lead reviews it before submission. The output is a filed final report and a closure note linking the report to the original timestamps.
Build the clock into the response plan
The reporting clock only works if the people and channels are ready before an incident happens. Write the steps above into the incident response plan, name a deputy for each role, pre-register the reporting channels, and keep contact details for the CSIRT and competent authority current. Test the sequence in an exercise that includes a clinical or supply impact, so that gaps in timing and decision rights surface early. The output is a tested runbook with named owners and a dated exercise report.

Why one incident can trigger NIS2 and GDPR notifications at once

A single cyber incident affecting patient records, clinical systems or trial data can create two separate reporting duties at the same time. Under NIS2, an entity must submit an early warning without undue delay and in any event within 24 hours of becoming aware of a significant incident, as set out in Article 23(4)(a). Under Article 33 of the GDPR, a controller must notify the data protection authority of a personal data breach, and the GDPR clock runs on its own terms. The two notifications go to different authorities, ask for different content and are judged against different thresholds, so an organization cannot treat one as a substitute for the other. The reporting interplay is a matter for the organization's own counsel and data protection officer to interpret for its circumstances. This section describes the operational preparation that makes both notifications possible on time.

Preparation starts with one incident register that records every event once, with fields that serve both regimes: the time the entity became aware, the systems and data categories affected, whether health or trial data is involved, the number of data subjects where known, and the decisions taken. Health entities should agree shared classification criteria before an incident happens, so that the security team, the clinical or research leads and the privacy team use the same test for what is significant under NIS2 and what is a personal data breach under the GDPR. Each notification also needs a named owner with authority to send it, a deputy, and a documented handoff so that the NIS2 early warning does not wait for the full GDPR assessment. Confirm with the relevant national competent authority and CSIRT which reporting channel and template apply in your Member State.

The third step is a review of which systems hold health data. Clinical information systems, laboratory information management systems, pharmacovigilance databases, clinical trial platforms, device telemetry back ends and the identity systems that control access to them all need to be listed, mapped to their owners and tagged with the data categories they process. Without that inventory, an entity cannot tell quickly whether an incident touches personal data, and it cannot decide what its NIS2 report should describe. Ask your managed security or SOC provider, if you use one, to confirm in writing how it will pass incident details to your named owners within the NIS2 timelines, so that the reporting duties are assigned in the contract as well as in your playbook.

What the all-hazards measures mean for hospitals, labs and plants

NIS2 does not limit cyber risk management to attacks on software. Recital 79 asks entities to plan for physical and infrastructure events as well, and the implementing regulation ties continuity requirements to a business impact analysis. The cards below cover what this means for a hospital, a laboratory or a plant, and where the organization's own decisions end and the partner's preparation work begins.

Physical and infrastructure hazards

Recital 79 lists events such as theft, fire, flood, telecommunication or power failures and unauthorized physical access. For a hospital, that means the server room, the clinical network closets, the cold chain for vaccines and the laboratory analyzers all count as risk sources. Check whether each site's hazard register covers its own building, utilities and carrier links, not only the central data center.

Business impact analysis

The implementing regulation requires entities to carry out a business impact analysis and derive continuity requirements for network and information systems from it. In practice, the analysis ranks clinical, laboratory and production processes by how quickly their outage harms patients, samples, batches or safety. Ask the partner to show how each system is linked to a process owner and a tolerable outage period.

Continuity requirements for systems

Continuity requirements translate the impact analysis into concrete system needs: backup frequency, recovery order, redundant power and alternative communication paths. A laboratory information system, for example, may need an offline fallback for sample tracking during an outage. Confirm with the organization which systems have a documented recovery target, who approved it and when it was last tested.

Backup and recovery testing

A backup that has never been restored does not show continuity. Restore tests should cover at least one clinical or laboratory system end to end, including the configuration, identity and network steps needed to bring it back in service. Record who ran each test, what failed and what changed afterward, because these records are what a supervisor will ask to see.

Access control at physical sites

Unauthorized physical access is named in Recital 79, so badge systems, visitor logs and locked cabinets for network equipment belong in the risk assessment. Medical device closets and pharmaceutical production control rooms often sit outside IT's direct control. Check that facilities, IT and the security function share one access policy and one review cycle.

Ownership and partner role

The organization owns its continuity decisions, risk acceptance and sign-off on the business impact analysis. An implementation partner can prepare the asset inventory, draft the continuity requirements, configure backup and failover systems, and set up test scripts and evidence folders. Any statement about compliance comes from the organization's own assessment and, where required, an independent auditor, not from the partner.

Who does what: your team, an implementation partner and the assessor

Under NIS2 the management body of an essential or important entity must approve the Article 21 cybersecurity risk-management measures and oversee their implementation. Accountability cannot be handed to an outside party. The compliance lead turns those decisions into an owned control set, assigns named control owners and decides how significant incidents are classified and reported within the 24-hour early warning, 72-hour notification and one-month final report windows.

Approval and oversight: Record management body approval of the risk-management measures, the risk treatment decisions and any accepted residual risk.
Control ownership: Assign an owner to each control, including the business impact analysis outputs that set continuity requirements for network and information systems.
Incident decisions: Decide whether an incident is significant, who signs each report and who informs service recipients.
Training and budget: Ensure management body members complete the cybersecurity training the directive requires and that funding matches the measures.
Supplier decisions: Keep the decision to appoint, retain or exit a managed service or security provider, and approve the contract terms.

What to check: that every control in your register has a named internal owner who can explain it to a supervisor without the partner present.

What a NIS2 program in health costs and who is paid for each part

This table separates the cost of a NIS2 program for healthcare providers, pharma and medical device entities into its components, showing who is paid for each, whether the cost is one-time or recurring, and what moves it up or down. Use it to structure requests for written, scoped quotes and to decide which parts to buy in and which to keep internal.

Cost component	Who is paid	One-time or recurring	What drives it up or down
Readiness scoping and gap analysis	Implementation partner or consultant, sometimes an internal team	One-time, repeated when scope changes	Number of sites, clinical and research systems in scope, and how many legal entities the group contains
Technical implementation and hardening of self-hosted platforms	Implementation partner, plus internal platform engineers	One-time build, with later upgrades	Number of self-hosted systems, integration with existing clinical and lab systems, and hosting model
Business impact analysis and continuity work	Internal risk and clinical operations staff, often supported by a consultant	One-time, reviewed each year	Number of critical services such as patient care, laboratory and manufacturing lines, and dependencies on suppliers
Incident response plan and reporting exercises	Internal incident response team, plus a partner if exercises are outsourced	Plan is one-time; exercises recur	Number of reporting paths (NIS2, GDPR and any sector rules), and how often exercises run
Evidence collection and documentation	Internal compliance and security staff, supported by a partner	Recurring, as evidence must stay current	Degree of automation in logging and ticketing, and how well policies map to the measures
Internal staff time and management training	Internal payroll, plus training providers if bought externally	Recurring	Size of the management body, staff turnover, and whether training is delivered in-house
Independent assessment or audit where the authority or customer requires one	Independent auditor or assessor, chosen by the entity or required by the customer	Recurring at each assessment cycle	Whether your national authority or a contract requires a third-party check, and the assessment scope agreed in advance
Ongoing support or testing retainers	Implementation partner or security testing provider under a retainer	Recurring	Frequency of testing, upgrade cadence of self-hosted platforms, and response times agreed in the contract

What makes a health sector program cost more or take longer

Health sector NIS2 programs vary widely in effort because the organization's footprint, clinical systems and dependencies differ. The six drivers below shape how much inventory, testing and evidence work the readiness project must absorb, so scope them in writing before comparing quotes.

Number of sites

Each hospital, laboratory and manufacturing plant adds its own network segments, local administrators, physical access controls and backup arrangements. Effort grows with the count of distinct sites and with how much each one differs from the others. Ask for a site register that lists location, function, systems hosted and who administers them, and agree which sites are in the assessed scope. A single standard build for all sites usually reduces the number of configurations that must be documented and tested.

Clinical, laboratory and manufacturing systems

Electronic health records, laboratory information systems, batch record and quality systems each carry different availability needs and different owners. The count and type of these systems determine how many business impact analyses, recovery plans and access reviews are required. Confirm which systems support patient care or product release, because those usually set the continuity requirements that the business impact analysis must derive.

Medical device and connected equipment inventory

Imaging devices, infusion pumps, analyzers and other connected equipment often run vendor-managed operating systems that cannot receive standard patches on the organization's schedule. Each device needs an owner, a network position, a record of its vendor support status and a compensating control where patching is limited. Inventory quality often decides the timeline, so ask whether the asset list comes from network discovery or from procurement records.

Third-party and cloud dependencies

Hosted laboratory platforms, cloud storage for imaging, managed network services and vendor remote access all extend the organization's attack surface and its supplier obligations. Each dependency needs a contract clause covering security, incident notification and access control, plus evidence that the supplier meets the same measures. Start with a list of every supplier with access to clinical or production systems, then mark which ones lack a contractual security schedule.

Maturity of existing evidence

An organization with current asset registers, change records, access reviews and tested backups can point assessors to real artifacts within days of starting. Where policies exist but logs, test results or approval records do not, the work shifts to producing evidence over a sustained period. Review the last internal audit, the most recent restore test and the access review record to judge how much evidence must be built rather than collected.

Group-level entities in scope

When a healthcare group, pharmaceutical holding or device manufacturer has several legal entities, each one that meets the size and sector tests may need its own measures, reporting duties and management oversight. Shared services such as a group security operations center can reduce duplication, but the contracts and responsibility split must be documented per entity. Ask early which legal entities fall under NIS2 and whether one group policy can be applied to each of them.

Questions health organizations ask before NIS2 readiness work starts

Is every hospital or clinic automatically an essential entity under NIS2?

No. Healthcare providers are in the health sector under Annex I, but whether a given hospital or clinic is in scope, and whether it is essential or important, depends on its size and its legal form. Entities that exceed the medium-sized enterprise ceilings in Recommendation 2003/361/EC are the ones the size cap captures, and Article 3 then decides between essential and important status. Smaller providers may fall outside scope unless another rule in Article 2 or Article 3 applies, and national transposition law can add detail. Start from the written scope: confirm the legal entity, headcount, turnover and balance sheet figures, then check the classification with counsel or your national competent authority. The NIS2 Article 3 text is the natural starting point.

Does a pharmaceutical manufacturer need NIS2 coverage if it is outside NACE division 21?

It can. The health sector in Annex I covers manufacturers of basic pharmaceutical products under NACE Rev. 2 division 21, but it also covers medicinal product research and development and manufacturers of medical devices critical during a public health emergency. A company whose main activity sits in another NACE division may still fall under one of these categories if it carries out the relevant research, development or device manufacturing. The test is the activity the entity actually performs, combined with the size rules. Map each legal entity against the Annex I wording, document the reasoning, and keep it current as product lines change.

How long does NIS2 readiness work take for a health organization?

The duration depends on the scope, the number of entities and sites, how many systems and suppliers are involved, and how mature the existing security management is. No fixed timeline applies across organizations. Work usually runs through scoping, a gap analysis against Article 21 and Implementing Regulation (EU) 2024/2690, remediation, evidence collection and testing of the incident reporting process. Ask any implementation partner for a written schedule tied to deliverables, and check the national transposition status in your Member State, since local rules can change obligations. Fixed-scope engagements agree scope, deliverables and timelines in writing before work starts.

What does a NIS2 program need from our internal staff?

It needs named owners and steady access to people who run the systems. Management must approve and oversee the Article 21 measures under Article 20, so executives need time for briefings and training. Clinical engineering, medical device owners, IT operations, identity administrators, facilities and procurement all supply facts that the risk assessment, business impact analysis and continuity plans depend on. Expect interviews, asset inventories, access reviews and walkthroughs of incident handling. Ask any provider to list these roles in the written scope so that your staff time is planned rather than discovered mid-project.

Can our organization run NIS2 readiness on its own?

Yes, in principle, if it has the skills and capacity. The organization owns its controls and remains responsible for compliance. Many teams keep governance, risk decisions and supervisor contact in-house and bring in outside help for technical build, hardening, testing or documentation. An implementation partner prepares systems and evidence but does not issue audit reports or certificates. Decide which parts you will keep, which you will outsource, and who signs off, then write that split into the scope before work starts.

Does NIS2 require a certificate for healthcare organizations?

No. NIS2 creates no certificate of compliance. National competent authorities oversee compliance through inspections, security audits, security scans, information requests and administrative fines, as set out in Articles 32 to 34. Some organizations choose an external standard to structure their evidence, and ENISA's June 2025 technical guidance maps evidence to frameworks such as ISO/IEC 27001:2022. Any certification is a separate decision made by the organization, and only an independent certification body can issue one.

How do NIS2 and GDPR breach reporting differ for one incident?

They run on different clocks and go to different authorities. NIS2 requires an early warning without undue delay and in any event within 24 hours of becoming aware of a significant incident, under Article 23(4)(a), reported to the CSIRT or competent authority. GDPR Article 33 requires notification of a personal data breach to the data protection authority, and patient data incidents often trigger both. One incident can therefore require two separate filings with different content and deadlines. Build a single incident process that assigns one owner, records the timeline and prepares both notifications from the same facts.

How DeployOpen works on this

DeployOpen is a Chainscore Labs company that plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For health sector organizations, we prepare the systems, controls and evidence that a national competent authority may ask for under NIS2, while the organization keeps ownership of its controls and the independent auditor or assessor issues any report.

How we scope

The written scope lists which healthcare, pharma, research or device entities and systems are included, agreed before work starts.
We confirm with you whether your entity type is essential or important and which national transposition law applies.
Engagements are fixed-scope, with deliverables and timelines set out in writing before any work begins.

How we build

We map the self-hosted open-source platforms in scope, such as clinical, laboratory or device data systems, to the Article 21 measures.
We run a business impact analysis for network and information systems and derive continuity requirements from it.
We test backup, recovery and incident handling in your environment and record the results as evidence.

How we hand over

You receive documented configurations, runbooks, policies and evidence records that your management body can review and approve.
Each incident reporting step, including the 24-hour early warning, is documented with a sample workflow you can run in exercises.
Where a single incident may also trigger GDPR breach notification, we document how both reporting paths are coordinated.

How we support

Ongoing support, upgrades and continuous security testing are available as retainers after handover.
We can prepare evidence packs for an inspection or information request, while your organization answers the authority.
Quotes follow from the written scope, so you can ask for the items, assumptions and exclusions to be listed explicitly.