Hospital security is decided in the tender: ENISA rewrites its procurement guidelines

The moment everything is decided, with nobody from security in the room

When a hospital makes the news for a cyber-attack, the reconstruction always starts from the same point: the day of the incident. The ransomware, the systems down, the postponed procedures, the return to paper.

There is another, far quieter moment at which that incident was made likely or unlikely: the day the tender was written. The security posture of a hospital information system is largely set when the clinical management software, the reporting platform, the diagnostic machine that will stay in service for a decade and the remote maintenance service are bought. If security does not appear in that document, or appears as a generic clause, no later configuration fully recovers it.

That is exactly where the document ENISA published on 22 July 2026 intervenes.

What the guidelines contain

The Procurement guidelines for the cybersecurity of hospitals and healthcare providers are a new iteration — not a document born today — prepared by ENISA with the support of the NIS Cooperation Group, the EU Health ISAC and the European Commission.

As the agency describes it, the content runs along four axes:

1. 01
   Every phase of the procurement cycle

   from defining the need to managing the contract
2. 02
   Requirements for suppliers

   what they must guarantee and what information they must provide
3. 03
   Critical categories

   where security considerations weigh most
4. 04
   Practical checklist

   measures linked to specific threats per procurement type

That last element is the most useful for whoever actually has to write the tender: a checklist of cybersecurity measures tailored to healthcare procurement, in which each measure is linked to a specific threat for that type of supply. Not a one-size-fits-all list of good intentions, but a pairing between what you buy and what you are defending against.

The guidelines are aligned with the relevant EU regulatory frameworks: the NIS2 Directive, the medical device regulations, the GDPR and the European health data space regulation. That detail looks bureaucratic and is not: it means requirements an organisation puts into a tender can be traced back to obligations it already has, rather than reading as negotiable preferences.

The document is deliberately written for a broad audience: from senior technical professionals in healthcare to IT teams. In many hospitals the people who actually draft tenders are not security experts — and that is the problem the document is trying to solve.

The EUR 6 million, and what it buys

Alongside the guidelines, ENISA announced a contribution agreement with the European Commission worth EUR 6 million, running for three years, to build the health sector's support mechanism.

The centrepiece is the proposed European Cybersecurity Support Centre: a mechanism intended to provide tailored guidance, tools and services to healthcare providers across Europe. ENISA is responsible for developing that mechanism's service catalogue, drawing on the earlier ENISA Cybersecurity Support Action. The catalogue currently clusters actions under four headings: preparedness, detection, response and governance.

The agreement also covers repackaging and expanding the current service offer, creating harmonised approaches, reusing established methodology and procurement strategy, and building the offer in consultation with relevant stakeholder groups.

Why this is national security news, not procurement news

Health is a sector of high criticality under Annex I of the NIS2 Directive, and it is the sector where the cost of an attack is not measured in revenue. What makes purchasing so decisive is structural: a hospital does not freely choose its own risk level.

A company that considers a supplier insecure can change it. A hospital that has bought a linear accelerator, a PACS or a monitoring system faces ten or fifteen years of service life, a maintenance contract that often includes vendor remote access, and a clinical constraint that makes powering the device down for an out-of-window update unthinkable. Decisions taken at tender stage therefore become very long-term security debt, in a context where replacement is not a realistic option.

Hence the logic of the European intervention: if the lever is procurement, then procurement is where a common position is needed, because twenty-seven health systems writing twenty-seven different requirements have no negotiating power over suppliers. A harmonised requirement, by contrast, changes what the market considers sellable.

What an organisation can do today, waiting for nothing

Open the document before the next tender, not after. The guidelines are published and downloadable: the checklist is the part to bring to the table where the specification gets written.

Review existing contracts on the most expensive point: supplier access. Remote maintenance is, in healthcare, one of the most recurrent and least governed vectors. Which supplier gets in, under which identity, with what logging, and who reads it.

Recognise this as governance material, not just technical material. Under NIS2, risk management decisions are the responsibility of management bodies. A security requirement omitted from a tender is a risk decision that has been taken, even when nobody framed it as one.

A note on what this article is not: it is not the assessment of an attack. It is an explainer on an official document just published, with the facts drawn from ENISA's own pages. The topic returns to the public agenda on 7 October 2026 in Nicosia, at the 11th ENISA eHealth Security Conference, where the Action Plan and medical device security are among the scheduled items.