What an EU hospital asks a device vendor for before it buys

The document, and why it matters to a manufacturer

In July 2026 ENISA published Procurement guidelines for the cybersecurity of hospitals and healthcare providers, a 69-page document intended to help hospitals integrate cybersecurity objectives into their procurement processes. It is written for the buyer. That is exactly why a manufacturer should read it: it is the question list, published in advance.

The guidelines organise controls into a general set plus three procurement phases, and assign each control a procurement type and a complexity level. Annex B explains the levels: “Level 1 is for basic, low-assurance products and services and is easily testable, while level 2 is for products and services handling critical processes and data.” Level 1 is the baseline, expected of everyone.

One of the procurement types is literally “Medical devices”, defined in Annex A to cover equipment such as infusion pumps, spirometry devices, medical lasers, endoscopy equipment and IVDs used on biological samples. Controls carrying that type are the ones a device vendor will be asked about by name.

GENERAL-11.01, the control that asks for your test

The baseline control that reaches every supplier, marked Level 1 and applying to all procurement service types, reads in full:

Confirm that security validation (e.g., penetration testing, audits, independent assessments) is performed on procured products or services before deployment. Ensure that the security of other service components is not compromised by new additions. When feasible, scan the external attack surface of both the general access to supplier and the specific solutions supplied, and perform own vulnerability scan of the internal components of the specific solutions supplied.ENISA, Procurement guidelines for the cybersecurity of hospitals and healthcare providers, July 2026, control GENERAL-11.01

Three things are worth noticing. The control names penetration testing first among the acceptable forms of security validation. It requires the validation to have happened before deployment, which puts it in the tender rather than in the first year of operation. And it does not say who performs it, which in practice means the buyer asks the supplier to evidence it, because the buyer has neither the device nor the source of truth about its interfaces.

The second half of the control is the part that surprises vendors. It asks the hospital, where feasible, to scan the external attack surface of the supplier itself, not only of the product supplied. A manufacturer’s own internet-facing estate becomes part of the procurement assessment.

The controls that name medical devices

Beyond the general control, several measures in Annex B carry the “Medical devices” procurement type. These are the specific questions.

ENISA procurement controls carrying the “Medical devices” type

Control	Level	What the buyer is told to confirm
GENERAL-03.08	1	That suppliers of medical equipment are evaluated for security posture as part of the supplier management programme
GENERAL-06.02	1	That medical device networks are isolated or on dedicated segments, preventing unauthorised access via general networks
PLAN-02.01	1	That procurement documentation lists the security and regulatory requirements relevant to medical devices, with the MDS2 form named as best practice to request from suppliers
PLAN-02.02	1	That bids include evidence of following accepted cybersecurity guidelines, regulations such as the MDR, and standards or certifications such as ISO 27001 and IEC 62304
SOURCE-04.01	1	That hardware is obtained directly from authorised manufacturers or certified distributors, to guarantee authenticity
SOURCE-04.02	1	That, for devices with software, software validation has been performed following IEC 62304
SOURCE-05.01	1	That suppliers follow secure development practices, with devices designed in line with the MDR and with hardware security features
SOURCE-06.01	1	That supplier contracts include clauses for timely vulnerability disclosure and patching
GENERAL-06.08	2	That remote maintenance access to medical devices is strictly controlled
SOURCE-04.04	2	That suppliers provide digital signatures or device certificates for critical equipment, for example first-boot firmware integrity

Read down the Level 1 column and the tender pack writes itself: an independent security validation, an MDS2 form, evidence of MDR conformity and of an IEC 62304 software lifecycle, a statement about hardware sourcing and authenticity, and contractual language on disclosure and patching. Nine of those ten controls are answered from documents a manufacturer already has to produce for its notified body.

The MDS2 form

PLAN-02.01 singles out one artifact: “Best practice is to request the MDS2 form from the device ICT system, product or service providers during procurement. The MDS2 provides a standardised security profile for the device and aids in risk assessment.” The manufacturer disclosure statement is a structured questionnaire covering the security characteristics of a device, and it is the closest thing the sector has to a common vocabulary between a vendor’s engineers and a hospital’s security team.

Two practical points. An MDS2 is a claim sheet, and a hospital that has read GENERAL-11.01 will compare it against your test evidence, so the two documents have to agree. And an MDS2 that has not been revised since the firmware changed is worse than none, because it makes a false statement in writing on a form the buyer expects to be current.

The gap between the file and the tender pack

A manufacturer with a complete Annex II technical file usually has all the substance and none of the packaging. The technical documentation is confidential, voluminous and organised for a conformity assessment. A hospital evaluator has a scoring matrix, a deadline and no right to see your file.

What closes the gap is a small, deliberately public set of documents derived from the same evidence.

• A test attestation. A one-page statement from the testing party naming the device and firmware version, the test window, the scope, the methods and the fact that remediation was verified. Not the report, which contains findings you cannot circulate, but a document a buyer can put in a file.
• A current MDS2. Revised with the firmware, not with the sales cycle.
• A vulnerability disclosure and patching statement. SOURCE-06.01 asks for contract clauses; having your standard clause ready avoids a legal review on every tender.
• A minimum IT requirements sheet. You already publish this under MDR point 17.4 in the instructions for use. Extracting it into a standalone page answers most of the hospital’s network and segmentation questions in one document.
• An SBOM you are willing to share, or a statement of the terms on which you will. Increasingly asked for; better answered with a policy than with a negotiation.

None of these is new work. All of them are the same evidence, re-cut for a reader who is not a notified body.

Where a manufacturer sits under NIS2

Procurement is not the only reason a hospital raises cybersecurity with a supplier. Both parties are in scope of Directive (EU) 2022/2555, and most commentary gets the manufacturer’s position backwards.

Annex II of the directive, “other critical sectors”, point 5 “Manufacturing”, sub-point (a) covers “Manufacture of medical devices and in vitro diagnostic medical devices”, defined as entities manufacturing medical devices under Regulation (EU) 2017/745 and IVDs under Regulation (EU) 2017/746, “with the exception of entities manufacturing medical devices referred to in Annex I, point 5, fifth indent, of this Directive”. That exception points at makers of devices considered critical during a public health emergency, who sit in Annex I instead.

So an ordinary device or IVD manufacturer is an Annex II entity, and Annex II entities are important entities rather than essential ones. Hospitals above the size thresholds are Annex I entities and can be essential. The difference is not cosmetic: supervision of essential entities is proactive, while important entities are supervised ex post, on evidence of non-compliance.

Two of the Article 21(2) measures land directly on a product security programme: “(d) supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers” and “(e) security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure”. Point (f), “policies and procedures to assess the effectiveness of cybersecurity risk-management measures”, is the one an auditor reads as a testing programme.

Article 21(1) frames all of it as measures taking into account “the state-of-the-art and, where applicable, relevant European and international standards”, which is the same phrase that governs MDR Annex I point 17.2. The two regimes ask for the same posture from different directions: one about the product, one about the company that makes it.

Why hospitals are asking now

The sector data explains the change in tone. ENISA’s health sector page records that in its 2023 threat landscape report for health, covering publicly reported incidents from January 2021 to March 2023, ransomware accounted for 54% of attacks, and that 53% of the analysed incidents affected healthcare providers, in particular hospitals. For the health-related incidents analysed in the ENISA Threat Landscape 2024, 45% related to ransomware and 28% were data breaches. ENISA also notes that health has been the most affected sector for four years in a row, 2020 to 2023, in significant NIS incidents reported by Member States through its CIRAS system.

The same page records the policy response: an EU action plan for the cybersecurity of hospitals and healthcare providers proposed in January 2025, under which ENISA is to establish a pan-European Cybersecurity Support Centre for the sector, with tasks including guidance on procurement, a regulatory mapping tool, detection capabilities, an early warning service and incident response playbooks. The July 2026 procurement guidelines are the first substantial deliverable of that programme to reach a vendor’s desk.

Answering the questions before they are asked

The most efficient response to a published question list is to answer it in the bid rather than in the clarification round. A short structure that works.

• Open with the independent validation: who tested, when, against which firmware version, and the fact that remediation was verified. This answers GENERAL-11.01 in the first paragraph a scorer reads.
• Attach the current MDS2 and say when it was last revised and against which build.
• State the MDR or IVDR conformity position and the software lifecycle standard applied, which covers PLAN-02.02 and SOURCE-04.02.
• Give the minimum IT requirements as a standalone sheet, including whatever the device needs from network segmentation. GENERAL-06.02 asks the hospital to isolate device networks; being explicit about what you assume saves an argument at commissioning.
• Include the vulnerability disclosure and patching commitment in the form of the clause you are willing to sign, for SOURCE-06.01.
• Describe remote maintenance access and its controls, for GENERAL-06.08, even where the tender is at Level 1 and does not ask.
• Say how firmware authenticity is protected, for SOURCE-04.01 and SOURCE-04.04.

Seven items, all derived from documents that already exist. A vendor that can hand these over on the day the tender opens is answering from its technical file; a vendor that cannot is scheduling a penetration test with a deadline set by someone else.

What this does not mean

Two clarifications, because procurement guidance is easy to over-read. ENISA controls do not create a legal obligation on a manufacturer, and no hospital is required to apply them. Their weight comes from being written down and public: an evaluator who wants to justify a security question now has a citation, and a competitor who can answer it has an advantage.

And a procurement pack is not a substitute for the conformity file. GENERAL-11.01 asks for evidence that security validation happened; MDR Annex I point 17.2 and Annex II section 6 decide whether the device may be placed on the market at all. Passing a tender proves nothing about the first, and a complete technical file proves nothing about the second until it is re-cut for a buyer who will never see it.