Guide

NIS2 and DORA for Life Sciences IT: What Pharma, Medical Device and Health Sector Manufacturers Actually Have to Evidence

NIS2 — Directive (EU) 2022/2555 on measures for a high common level of cybersecurity across the Union — replaced the original 2016 NIS Directive on 18 October 2024 and pulled a much wider slice of the life sciences industry into formal cybersecurity supervision. Pharmaceutical manufacturers, medical device manufacturers, in-vitro diagnostic manufacturers, hospitals, laboratories and their critical IT/cloud/MSP suppliers are now either 'essential' or 'important' entities under Annexes I and II, with mandatory risk-management measures (Article 21), governance accountability at the management-body level (Article 20), and a hard 24-hour early-warning / 72-hour incident notification regime (Article 23) enforced by national competent authorities with administrative fines up to EUR 10 million or 2% of global turnover for essential entities. DORA — Regulation (EU) 2022/2554 on digital operational resilience for the financial sector — applies from 17 January 2025 and matters to life sciences in one specific but consequential way: any life sciences software vendor or platform classified as a 'critical ICT third-party service provider' to a financial entity (banks, insurers, asset managers buying healthcare/pharma data products) falls under direct ESA oversight and must meet DORA's contractual, testing and incident-reporting requirements. This guide breaks both regimes into the artefacts a national competent authority (BSI in Germany, ANSSI in France, NCSC-IE in Ireland, AGID/ACN in Italy, INCIBE in Spain) will actually inspect, the relationship to EU GMP Annex 11, ISO 27001 and the EU MDR/IVDR cybersecurity guidance (MDCG 2019-16), and a realistic readiness path. It is written for IT, security, quality and regulatory leaders at pharma manufacturers, MAHs, CDMOs, medical device companies, IVD manufacturers, clinical labs, hospital groups and the SaaS/cloud vendors that serve them.

Start free trial Free trial, no credit card, onboard in days, not months.

Are you in scope? Essential vs important entities in life sciences

NIS2 expands scope by sector (Annexes I and II) and by size (the size-cap rule: medium and large entities are automatically in scope, with smaller entities pulled in where they are sole providers, public administration, DNS/TLD, qualified trust service providers or designated as critical by a Member State). For life sciences, Annex I 'Sectors of high criticality' captures the health sector (healthcare providers, EU reference laboratories, R&D of medicinal products, manufacturers of basic pharmaceutical products and pharmaceutical preparations, manufacturers of medical devices considered critical during a public-health emergency under Regulation (EU) 2022/123) as essential entities. Annex II 'Other critical sectors' captures the wider manufacture of medical devices and in-vitro diagnostic medical devices, manufacture of chemicals and the production, processing and distribution of food as important entities. The practical difference: essential entities face proactive ex-ante supervision (planned inspections, security audits, ad-hoc audits) and higher fine ceilings (EUR 10m or 2% of global turnover); important entities face ex-post supervision (only triggered by evidence of non-compliance) and lower fine ceilings (EUR 7m or 1.4%). The recurring scope failure is a CDMO or contract testing lab assuming it sits below the radar because it manufactures on behalf of others — Member State transposition consistently treats the CDMO as the manufacturer for NIS2 purposes, and 'we just do tox studies' does not shield a 250-person GLP lab from Annex I health-sector designation.

Article 21 risk-management measures: the ten obligations

Article 21(2) lists ten cybersecurity risk-management measures every in-scope entity must implement on an 'all-hazards' basis, proportionate to risk: (a) policies on risk analysis and information system security, (b) incident handling, (c) business continuity (backup management, disaster recovery, crisis management), (d) supply chain security (including security-related aspects concerning the relationships between the entity and its direct suppliers), (e) security in network and information systems acquisition, development and maintenance (including vulnerability handling and disclosure), (f) policies and procedures to assess the effectiveness of cybersecurity measures, (g) basic cyber hygiene practices and cybersecurity training, (h) policies and procedures regarding the use of cryptography and, where appropriate, encryption, (i) human resources security, access control policies and asset management, and (j) the use of multi-factor authentication or continuous authentication solutions, secured voice/video/text communications and secured emergency communication systems. The Commission Implementing Regulation (EU) 2024/2690 of 17 October 2024 fleshes these out for the digital infrastructure sub-sectors but is widely used as the de facto benchmark in audits across all NIS2 sectors. The recurring failure mode is treating ISO 27001 certification as automatic Article 21 compliance — the ten obligations overlap heavily with Annex A controls but Article 21(d) (supply chain security) and Article 21(j) (MFA) are explicitly broader than the corresponding ISO controls, and an authority will ask for evidence against the directive text, not the standard.

Article 20 management-body accountability and training

Article 20 makes the management body of an essential or important entity directly accountable for approving the cybersecurity risk-management measures, overseeing their implementation and being personally liable for infringements. This is a step-change from the original NIS Directive and from ISO 27001 — accountability sits with named directors, not 'the organisation'. Article 20(2) further requires members of the management body to follow training on cybersecurity and to offer similar training to their employees on a regular basis, so that they gain sufficient knowledge and skills to identify risks and assess cybersecurity risk-management practices. Several Member State transpositions (Germany's NIS2UmsuCG, Belgium's NIS2 law of 26 April 2024, Ireland's NIS2 Bill) make management-body training non-delegable — a CISO or CIO cannot complete it on behalf of the CEO. The recurring failure mode is recording training attendance for the CISO and head of IT, but having no training record for the CEO, CFO or the non-executive directors of the board — the first item an authority requests on a planned inspection visit.

Article 23 incident reporting: the 24/72/30-day clock

Article 23 imposes a three-stage reporting clock to the national CSIRT / competent authority for any 'significant incident' (one that has caused or is capable of causing severe operational disruption of the services or financial loss to the entity concerned, or has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage): an early warning within 24 hours of becoming aware, an incident notification within 72 hours with an initial assessment including severity, impact and (where available) indicators of compromise, and a final report within one month of the incident notification with a detailed description, the type of threat or root cause, the mitigation measures applied and (where applicable) the cross-border impact. The threshold for 'significant' is set by Commission Implementing Regulation (EU) 2024/2690 for digital infrastructure and by the competent authority for other sectors — most authorities have published draft thresholds (number of affected users, downtime in hours, financial loss in EUR). The 24-hour clock starts at 'becoming aware', not at confirmation, and the recurring failure mode is debating internally whether something is significant for the first 18 hours and then missing the early-warning deadline. Where the incident is caused by an unlawful or malicious act, the entity must also notify recipients of its services that are potentially affected by any significant cyber threat, of any measures or remedies they can take in response. NIS2 reporting does not replace GDPR Article 33 (72 hours to the supervisory authority) or MDR/IVDR vigilance reporting under Article 87 MDR / Article 82 IVDR — a single ransomware incident at a medical device manufacturer can trigger all three.

Article 21(d) supply chain security and ICT third-party risk

Article 21(d) requires entities to address supply chain security including 'security-related aspects concerning the relationships between each entity and its direct suppliers or service providers', and Article 22 empowers the Cooperation Group (in coordination with the Commission and ENISA) to carry out coordinated security risk assessments of critical supply chains (the first round, on 5G, was carried out under NIS1 in 2019; the cloud and managed-services round under NIS2 is ongoing). For life sciences, the practical effect is that EU GMP Annex 11 §3 supplier requirements and the ISO 13485 §7.4 purchasing-control evidence now have a parallel cybersecurity dimension: every ICT supplier (cloud hoster, MES vendor, eQMS vendor, contract IT operator, MSP, MSSP) must be risk-assessed for cybersecurity, the contract must include security clauses, and the entity must have evidence of ongoing supplier monitoring. DORA Article 28-30, although applying to financial entities, sets the benchmark for the contractual clauses every authority now expects to see (data location, sub-outsourcing, audit rights, exit strategy, incident notification, service-level agreements with security KPIs). The recurring failure mode is relying on a supplier's ISO 27001 certificate as the sole evidence — Article 21(d) requires a documented risk assessment of the supplier-specific cyber risk profile, not a recital of the supplier's certifications.

DORA: when life sciences SaaS becomes a regulated CTPP

DORA — Regulation (EU) 2022/2554 — applies from 17 January 2025 to financial entities (credit institutions, payment institutions, investment firms, insurance undertakings, crypto-asset service providers, central securities depositories and many others listed in Article 2). Most life sciences companies are not financial entities and are not directly in scope. The relevance to life sciences is Chapter V (Articles 28-44) on managing ICT third-party risk and, in particular, the designation regime for Critical ICT Third-Party Service Providers (CTPPs) under Articles 31-44. A life sciences SaaS vendor that supplies a data product, analytics platform, document management system or AI service to a critical mass of financial entities can be designated as a CTPP by the Lead Overseer (one of the three ESAs) under the criteria in the Commission Delegated Regulation (EU) 2024/1502: systemic impact, criticality of the services, degree of substitutability and number of Member States in which services are provided. A CTPP is then subject to direct ESA oversight — including the right to require information, conduct general investigations, perform on-site inspections, issue recommendations and impose periodic penalty payments. The contractual requirements in Article 30 (full content of the ICT services contract, data location, sub-outsourcing chain, service-level descriptions, exit strategy, audit and access rights) are routinely written into pharma-to-financial-sector data licensing contracts even where the vendor is not yet designated, because the financial entity is required by Article 28(1)(a) to verify them before contracting.

How NIS2 stacks on Annex 11, GAMP 5 and MDCG 2019-16

NIS2 does not replace any existing GxP or device-cybersecurity obligation — it sits on top. For a pharmaceutical manufacturer the practical layering is: EU GMP Annex 11 governs computerised systems used in GxP processes (validation, audit trails, access control, change control); ISO 27001 / ISO 27002 are voluntary frameworks commonly used to demonstrate the management-system side; NIS2 is now the mandatory legal floor for the cybersecurity risk-management measures (Article 21) regardless of whether the system is GxP or not. For a medical device manufacturer add IEC 81001-5-1 (security activities in the device lifecycle), AAMI TIR57, MDCG 2019-16 (cybersecurity guidance for the EU MDR/IVDR), the FDA premarket cybersecurity guidance (September 2023) and the post-market cybersecurity guidance. The recurring failure mode is duplicating evidence packs — one for the Annex 11 inspection, one for the MDR notified body, one for the NIS2 authority. The Article 21 obligations and the Annex 11 / IEC 81001-5-1 controls overlap by roughly 70%; mapping them once into a single control framework (e.g. via the IEC 62443-derived mappings in MDCG 2019-16 Appendix III) avoids the audit-fatigue tax and the evidence-drift risk.

Registration, jurisdiction and the NIS2 entity registry

Article 27 of NIS2 requires Member States to maintain a registry of essential and important entities by 17 January 2025 and to forward the aggregated information to ENISA. Article 26 sets the jurisdiction rule: an entity falls under the Member State where it has its main establishment in the EU (the place where decisions related to the cybersecurity risk-management measures are predominantly taken; or, if that cannot be determined, the place where cybersecurity operations are carried out; or, if neither, the place with the largest number of employees). For pan-European life sciences groups this is a deliberate decision — the lead authority depends on it — and the entity must register actively with the national competent authority (BSI's MELANI portal in Germany, ANSSI's MonEspaceNIS2 in France, NCSC-IE's portal in Ireland). Sector-specific registration deadlines vary: digital infrastructure entities had to register name, address, contact details and Member States of service provision by 17 January 2025 under Article 27(2); other sectors followed the national transposition timetable. The recurring failure mode is silently relying on the original NIS1 registration without confirming the entity is correctly classified under NIS2 — many entities classified as 'operators of essential services' under NIS1 are now important entities under NIS2 (or vice versa), and the registration must be re-validated.

Sanctions, personal liability and the supervision regime

Article 32 (essential entities) and Article 33 (important entities) set out the supervisory and enforcement powers of national competent authorities. For essential entities these include on-site inspections, off-site supervision (including random checks), regular and targeted security audits carried out by an independent body or the authority, ad-hoc audits, security scans, requests for information, access to data, documents and any information necessary for the authority to perform its supervisory tasks, and requests for evidence of implementation of cybersecurity policies. For important entities the same powers apply ex-post (where there is evidence, indication or information that the entity is not complying). Article 34 sets the administrative fines: at least EUR 10 million or 2% of total worldwide annual turnover for essential entities, and at least EUR 7 million or 1.4% for important entities, whichever is higher. Article 32(5) goes further than any previous EU cyber regime: the authority may suspend, temporarily, a certification or authorisation concerning part or all of the relevant services or activities provided by an essential entity, and may prohibit, temporarily, any natural person discharging managerial responsibilities at chief executive officer or legal representative level in that essential entity, from exercising managerial functions. The recurring failure mode is treating NIS2 as another tick-box exercise — it is the first EU cyber regime where individual directors can be temporarily banned from management roles for non-compliance, and the supervision regime is built to make that meaningful.

Where this lives in V5 Ultimate

The clauses above aren't theoretical — every one maps to a shipped module and an industry profile. Jump to the parts of the product that turn this guide into evidence on a Monday morning.

Industries this hits hardest

Pharmaceutical Medical Devices Radiopharmaceuticals Veterinary Pharma Blood & Tissue

Frequently asked

We are a US pharma company with a German manufacturing subsidiary. Does NIS2 apply to us?

NIS2 applies to the German subsidiary if it meets the sector + size test (manufacture of basic pharmaceutical products and pharmaceutical preparations under Annex I, with at least 50 employees or EUR 10m turnover/balance sheet). The US parent is not directly in scope, but Article 26(3) requires non-EU entities offering services within the Union in any of the Annex I/II sectors to designate an EU representative in one of the Member States where the services are offered — relevant if the US parent operates a cloud or SaaS service that EU customers use. The German subsidiary's lead authority is BSI (the Bundesamt für Sicherheit in der Informationstechnik) under the NIS2UmsuCG transposition.

We are a CDMO contract-manufacturing for a sponsor. Who is the NIS2 obligated entity — us or the sponsor?

Both, in respect of their own information systems. The CDMO is in scope as a manufacturer of pharmaceutical preparations under Annex I if it meets the size test, regardless of who owns the marketing authorisation. The sponsor / MAH is in scope as an essential entity in respect of its own systems (the regulatory dossier, pharmacovigilance system, distribution system). The CDMO contract must address Article 21(d) supply-chain obligations from the sponsor's side (security clauses, audit rights, incident notification) — most sponsors are now adding NIS2-aligned annexes to their quality agreements during the 2024-2025 contract refresh cycle.

Does NIS2 require ISO 27001 certification?

No. Article 21 is technology-neutral and certification-neutral — entities choose their own technical and organisational measures, proportionate to risk. ISO 27001 is the most common framework used to demonstrate the management-system side of Article 21 and many Member State authorities accept it as strong evidence, but it is not mandatory and it is not sufficient on its own (Article 21(d) supply-chain and Article 21(j) MFA obligations go beyond ISO 27001 Annex A as written). Smaller important entities frequently demonstrate compliance via the BSI IT-Grundschutz Kompendium, the ANSSI Guide d'hygiène informatique, or sector-specific frameworks like the FDA premarket cybersecurity guidance for medical device makers.

What is the practical difference between the 24-hour early warning and the 72-hour incident notification?

The 24-hour early warning (Article 23(4)(a)) is a short flag to the CSIRT or competent authority that a significant incident has occurred, indicating whether it is suspected to be caused by unlawful or malicious acts and whether it could have a cross-border impact. It is intentionally lightweight — the entity is not expected to have completed root-cause analysis. The 72-hour incident notification (Article 23(4)(b)) is the substantive notification with an initial assessment including the severity and impact and, where available, the indicators of compromise. The final report at the 30-day mark (Article 23(4)(d)) closes the loop with the type of threat or root cause and the mitigation measures applied. The clock for all three starts at 'becoming aware', which most authorities interpret as the point at which the entity has reasonable grounds to suspect a significant incident has occurred — not the point of confirmation.

We supply analytics software to several EU banks. Are we automatically subject to DORA?

Not automatically. DORA applies directly to the financial entities (the banks). They are required by Article 28 to verify the ICT third-party risk of their contracts with you — and that pushes DORA-aligned contractual clauses, security testing requirements and reporting commitments into your contract whether or not you are designated. You become directly subject to ESA oversight only if you are formally designated as a Critical ICT Third-Party Service Provider (CTPP) by the Lead Overseer under Articles 31-44, using the criteria in Commission Delegated Regulation (EU) 2024/1502 — systemic impact, criticality, substitutability, and number of Member States served. The first round of CTPP designations is expected during 2025; the threshold has been calibrated to capture the major hyperscalers and a small number of sector-specific SaaS vendors.

How does NIS2 interact with the EU MDR cybersecurity expectations and MDCG 2019-16?

The two are complementary. EU MDR Annex I §17.2 (and IVDR Annex I §16.2) requires medical device software to be developed and manufactured in accordance with the state of the art including secure-by-design principles, with MDCG 2019-16 as the recognised guidance. That obligation sits on the product. NIS2 sits on the manufacturer as an entity — its corporate IT, its development environment, its production network, its incident response. A medical device manufacturer that has full MDR/MDCG 2019-16 evidence for its product but no Article 21 risk-management measures for its corporate systems is non-compliant with NIS2. Several Member States have explicitly clarified in their NIS2 transposition Q&A that MDCG 2019-16 conformity does not exempt the manufacturer from Article 21 — the two regimes have different scopes.

What is the registration deadline and what information must we submit?

Article 27(4) required Member States to ensure essential and important entities submitted name, address, up-to-date contact details (including email addresses, IP ranges and telephone numbers), the relevant sector and subsector from Annexes I/II, and (where applicable) the Member States in which they provide services in scope of the Directive by 17 April 2025. Sector-specific registration deadlines (Article 27(2) for digital infrastructure entities) were earlier — 17 January 2025. Submission is via the national portal designated by each Member State's competent authority. Late registration is itself a breach subject to administrative fines under Article 34, and several authorities (Ireland's NCSC, Italy's ACN) have already published guidance that they will treat unregistered entities as a supervisory priority during 2025-2026.

Do we need to keep separate evidence packs for NIS2, Annex 11 and ISO 27001?

You do not have to and you should not — the underlying controls overlap heavily. The practical pattern is a single control framework that maps each control to the obligations it satisfies: Article 21 sub-obligation, Annex 11 clause, ISO 27001 Annex A control, MDCG 2019-16 expectation, IEC 81001-5-1 activity. Evidence is collected once and surfaced into the audit pack appropriate to the inspector in the room — the GMP inspector sees the Annex 11 view, the NIS2 authority sees the Article 21 view, the ISO 27001 certification auditor sees the Annex A view. The mapping work is the one-time investment; the ongoing evidence collection cost falls dramatically after it.

See it on your shop floor.

Free trial, no credit card, onboard in days, not months.

Start free trial See pricing →Browse all resources →