---
title: MDR Market Access and NIS-2: How Healthcare Rules Affect MedTech Sales
description: NIS-2 turns hospitals into essential entities. MedTech vendors now face cybersecurity questionnaires long before procurement signs a CE-marked device in.
authors: Tibor Zechmeister, Felix Lenhard
category: Quality Management Under MDR
primary_keyword: MDR market access NIS-2 healthcare
canonical_url: https://zechmeister-solutions.com/en/blog/mdr-market-access-nis-2-healthcare
source: zechmeister-solutions.com
license: All rights reserved. Content may be cited with attribution and a link to the canonical URL.
---

# MDR Market Access and NIS-2: How Healthcare Rules Affect MedTech Sales

*By Tibor Zechmeister (EU MDR Expert, Notified Body Lead Auditor) and Felix Lenhard.*

> **NIS-2 reclassifies most European hospitals as essential entities with binding cybersecurity obligations. That pressure flows straight to their suppliers. A CE-marked device is no longer enough on its own. Startups now meet a procurement questionnaire that asks for SBOMs, patch policies, incident reporting, and third-party security evidence before a purchase order is signed.**

**By Tibor Zechmeister and Felix Lenhard.**

## TL;DR
- NIS-2 is the EU Directive on measures for a high common level of cybersecurity across the Union. It places binding cybersecurity and incident reporting duties on operators in critical sectors, including healthcare.
- Most European hospitals of meaningful size are now essential entities under NIS-2. Their cybersecurity obligations cascade to suppliers through contracts and procurement questionnaires.
- MDR Annex I Sections 17.2 and 17.4 already require state-of-the-art software security and minimum IT security requirements. NIS-2 does not rewrite MDR, but it changes what hospital buyers expect to see on the evidence side.
- The deliverables that clear a hospital security review overlap almost entirely with the deliverables the notified body expects under MDR and EN IEC 81001-5-1:2022. Startups that build one well-organised evidence pack serve both audiences.
- In Tibor's notified body experience, the three questions that most often stop a startup at the hospital gate are SBOM maintenance, vulnerability response time, and incident reporting pathway.
- In Felix's coaching work, the founders who lose deals under NIS-2 pressure are usually the ones treating the hospital security questionnaire as a sales artefact rather than an output of the QMS.

## Why this matters (Hook)

A Class IIa imaging startup has a signed pilot with a 900-bed university hospital. CE mark is in place. The product works. The clinical champions love it. Then a form arrives from the hospital's information security office. It is 74 questions long. It asks for an SBOM in a machine-readable format, a documented vulnerability disclosure policy, a declared time-to-patch for critical CVEs, SOC 2 or ISO 27001 evidence, penetration test reports from the last 12 months, and a signed data processing agreement that references the hospital's NIS-2 obligations. The founders assumed CE would be sufficient. The deal sits for three months while they assemble answers.

This scene plays out across European healthcare because NIS-2 changed who is accountable for cybersecurity when a medical device is connected to a hospital network. In Tibor's audit work with notified bodies, the MDR evidence is usually in reasonable shape by the time a startup ships. What is missing is the packaging that a hospital CISO can read in one sitting. In Felix's coaching work with 44 medtech startups, the pattern is consistent: founders treat cybersecurity as a regulatory task for the notified body and discover too late that the commercial gate is a separate audience with different formatting expectations and the same underlying evidence.

## What MDR actually says (Surface)

MDR and NIS-2 operate on different objects. MDR regulates the device. NIS-2 regulates the operator of the network and information system. The startup sits at the intersection because its device runs on the operator's network and feeds data into the operator's clinical workflows.

**MDR Annex I Section 17.2.** For devices that incorporate software or for software that are devices in themselves, the software shall be developed and manufactured in accordance with the state of the art taking into account the principles of development life cycle, risk management, including information security, verification and validation.

**MDR Annex I Section 17.4.** Manufacturers shall set out minimum requirements concerning hardware, IT networks characteristics and IT security measures, including protection against unauthorised access, necessary to run the software as intended.

**MDR Annex I Section 23.4.** The information supplied with the device shall include, where relevant, minimum requirements concerning hardware, IT networks characteristics and IT security measures, including protection against unauthorised access, necessary to run the software as intended.

**EN IEC 81001-5-1:2022.** The current state-of-the-art standard for security activities across the health software product life cycle. It is the reference point a notified body uses to evaluate whether the security content of the technical documentation meets the GSPRs.

**MDCG 2019-16 Rev.1 "Guidance on Cybersecurity for medical devices".** The authoritative interpretation of how MDR cybersecurity requirements are expected to be implemented. It frames cybersecurity as an integrated lifecycle activity rather than a pre-market deliverable.

**NIS-2 Directive (EU) 2022/2555.** NIS-2 replaces the 2016 NIS Directive. It expands the scope of cybersecurity obligations to a broader set of essential and important entities, including large parts of the healthcare sector. Hospitals of material size are captured as essential entities. They must implement risk management measures, report significant incidents, and manage supply chain security. The directive is transposed into national law. Exact obligations, thresholds and deadlines vary by member state, so startups should confirm the applicable national transposition for every hospital they sell into. 

Plain language: MDR says the device must be secure and the documentation must carry the IT security baseline. NIS-2 says the hospital has to manage its supply chain security and report incidents. The hospital meets its NIS-2 obligation by pushing supplier assurance onto the medtech vendor in the form of a questionnaire.

## A worked example (Test)

Consider a 12-person startup selling a wearable cardiac monitor (Class IIa) to five European hospitals. The device has a companion app and a cloud backend. The cloud receives ECG snapshots and returns alerts to a clinician dashboard. The MDR technical documentation is complete. EN IEC 81001-5-1:2022 lifecycle activities are documented inside the EN 62304 process. Cybersecurity risks are integrated into the ISO 14971 risk file as required by MDCG 2019-16 Rev.1.

Procurement sends the hospital's vendor security assessment. The relevant sections are:

1. Software bill of materials, machine-readable.
2. Vulnerability disclosure policy with public contact.
3. Declared time-to-patch by severity (critical, high, medium, low).
4. Incident response plan and notification pathway, including the hospital's named security contact.
5. Penetration testing evidence from the last 12 months.
6. Third-party certifications (ISO 27001, SOC 2, HDS) if held.
7. Data flow diagram and data processing agreement aligned with GDPR.
8. Supplier security clauses accepted in the contract.

The startup can answer every single one of these from existing MDR deliverables, except items 6 and 8, which are either commercial or optional. The SBOM already exists inside the EN 62304 configuration item list. The vulnerability disclosure policy already exists inside the EN IEC 81001-5-1:2022 post-market security process. The time-to-patch is already declared in the post-market cybersecurity plan. The penetration testing evidence already exists because the notified body asked for it during the technical file review.

What usually goes wrong is not the evidence. It is the packaging. The SBOM lives in a developer spreadsheet nobody can export. The vulnerability policy is a single paragraph in a risk management SOP. The time-to-patch is documented as a process but never stated as a number. The notified body accepted all of this. The hospital CISO did not.

The fix is a one-page supplier security assurance pack, generated from the QMS, refreshed on release, and shipped alongside every commercial proposal. The pack references the MDR technical documentation without disclosing it.

## The Subtract to Ship playbook (Ship)

NIS-2 readiness is not a new project. It is a reorganisation of evidence that already exists under MDR. The Subtract to Ship approach is to build the thinnest possible artefact that answers the hospital CISO once and can be regenerated when the device version changes.

**Step 1. Single supplier security assurance pack.** One PDF. Five pages maximum. Pulled from the QMS, never hand-written. It contains: product name and version, MDR classification, SBOM reference and format, vulnerability disclosure contact and public URL, time-to-patch by severity, incident response contact, data flow summary, applicable standards (MDR, EN IEC 81001-5-1:2022, EN 62304, EN ISO 14971), and a statement of which third-party certifications apply.

**Step 2. SBOM as a live artefact.** The SBOM is maintained inside the EN 62304 configuration item list and exported on every release in a machine-readable format (CycloneDX or SPDX). If the SBOM is not machine-readable, expect hospital procurement delays.

**Step 3. Vulnerability disclosure policy with a public email.** This is cheap to create and essential under EN IEC 81001-5-1:2022 post-market activities. Hospitals check whether the contact resolves before they sign.

**Step 4. Time-to-patch as a declared number.** Critical vulnerabilities patched within a committed window. The number itself is a commercial decision, but an undefined window reads as unmanaged risk to a hospital CISO.

**Step 5. Incident response pathway that names the customer.** NIS-2 requires the hospital to report significant incidents. The startup must be reachable on a working phone and email during and outside business hours. The incident response process should name the customer as an explicit party to notify when the root cause is on the device side.

**Step 6. Do not over-certify early.** ISO 27001 and SOC 2 are commercially useful, but they are organisational, not product, evidence. A pre-revenue startup should not burn runway on ISO 27001 until a named enterprise customer has it as a gating requirement. Felix has seen founders spend 150 thousand euros on ISO 27001 to close a deal that was never going to close on security grounds in the first place.

**Step 7. Re-use, do not recreate.** Every answer to a hospital security questionnaire should map to an existing QMS document. If the answer requires writing something new, the process behind it is missing, not the documentation.

## Reality Check

1. Does a hospital CISO receive one packaged document from the startup, or does the CISO receive hunted-together fragments from the sales team?
2. Is the SBOM machine-readable and generated automatically on release, or is it a spreadsheet that drifts between versions?
3. Is the time-to-patch for critical vulnerabilities declared as a number with a signed-off owner?
4. Is there a working vulnerability disclosure email that routes to a human within one business day?
5. Is the incident response plan explicit about which customers are notified and how?
6. Has anyone on the team read the NIS-2 transposition law for the member state where the first commercial customers sit?
7. Does the commercial pipeline track "security review" as a stage the same way it tracks legal review?

## Frequently Asked Questions

**Does NIS-2 apply to the startup directly or only to the hospital?**
NIS-2 applies to the operator of the network and information system, which is the hospital. The startup is not the regulated entity. The obligations land on the startup through contracts and the hospital's supply chain security duties. Functionally, the effect is the same as direct regulation in the procurement process.

**Is ISO 27001 required for NIS-2?**
No. NIS-2 does not mandate ISO 27001. It requires risk-based cybersecurity measures and supply chain security. ISO 27001 is one way to evidence an ISMS. It is useful for enterprise sales motion and unnecessary for early-stage MDR compliance on its own.

**Does MDR already cover what NIS-2 asks for on the product side?**
For product-level security, largely yes. MDR Annex I Section 17, EN IEC 81001-5-1:2022, EN 62304 and MDCG 2019-16 Rev.1 cover development lifecycle, risk management, SBOM hygiene, verification, validation and post-market vulnerability handling. NIS-2 adds organisational security duties on the operator side that cascade to suppliers through procurement.

**Can a Class I device skip this?**
No. Hospital procurement applies the same supplier security questionnaire regardless of device class if the device touches the hospital network. Class I devices with network connectivity face the same questionnaire.

**How early should a startup build the supplier security assurance pack?**
Before the first paid pilot. The pack is lightweight if the MDR evidence is in place, and it removes the most common commercial friction in the sales cycle.

**What happens if the startup refuses or delays the questionnaire?**
The deal stalls and the clinical champion loses political capital inside the hospital. In Felix's coaching cases, more than one deal has been lost not on price or clinical value but on a security questionnaire the founder treated as optional.

## Related reading
- [Cybersecurity Risk Management for Medical Devices Under MDR](/blog/cybersecurity-risk-management-mdr) explains how security risks integrate into the ISO 14971 risk file the notified body reads.
- [Hospital Procurement for MedTech Startups](/blog/hospital-procurement-medtech-strategy) covers the commercial structure a founder navigates once the security gate opens.
- [SBOM for Medical Devices Under MDR](/blog/sbom-medical-devices-mdr) explains how the EN 62304 configuration item list becomes a hospital-ready SBOM.
- [FDA Cybersecurity Section 524B](/blog/fda-cybersecurity-section-524b) compares the US pre-market cybersecurity regime for vendors selling into both markets.

## Sources
1. Regulation (EU) 2017/745 on medical devices, consolidated text. Annex I Sections 17.2, 17.4, 23.4.
2. Directive (EU) 2022/2555 on measures for a high common level of cybersecurity across the Union (NIS-2).
3. MDCG 2019-16 Rev.1 "Guidance on Cybersecurity for medical devices", July 2020.
4. EN IEC 81001-5-1:2022 "Health software and health IT systems safety, effectiveness and security Part 5-1: Security".
5. EN 62304:2006+A1:2015 "Medical device software Software life cycle processes".

---

*This post is part of the [Quality Management Under MDR](https://zechmeister-solutions.com/en/blog/category/quality-management) cluster in the [Subtract to Ship: MDR Blog](https://zechmeister-solutions.com/en/blog). For EU MDR certification consulting, see [zechmeister-solutions.com](https://zechmeister-solutions.com).*