---
title: Hospital IT Requirements and Your Medical Device
description: Hospital IT requirements medical device: MDS2, HIMSS, network diagrams, SBOM, and vulnerability process. Prepare the pack before the procurement meeting.
authors: Tibor Zechmeister, Felix Lenhard
category: Cybersecurity & Data Protection
primary_keyword: hospital IT requirements medical device
canonical_url: https://zechmeister-solutions.com/en/blog/hospital-it-requirements-medical-device
source: zechmeister-solutions.com
license: All rights reserved. Content may be cited with attribution and a link to the canonical URL.
---

# Hospital IT Requirements and Your Medical Device

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

> **Hospital procurement teams ask for a standard cybersecurity pack: a completed security questionnaire (commonly MDS2 or a HIMSS-style equivalent), a network architecture diagram, a current SBOM, and a vulnerability management process. A MedTech startup that walks into the procurement meeting with that pack already built shortens the sales cycle by a quarter. A startup that improvises gets filtered out.**

**By Tibor Zechmeister and Felix Lenhard.**

## TL;DR
- Hospital IT and procurement teams ask standard questions because they are filtering vendors against internal information security policies. The questions are predictable.
- The four items that almost every hospital pack requires are a completed security questionnaire, a network and data flow diagram, an SBOM, and a vulnerability management process description.
- MDS2 (the Manufacturer Disclosure Statement for Medical Device Security) is the most widely recognised questionnaire template globally. European hospitals often use local variants or HIMSS-derived forms. 
- The MDR side of this is Annex I Sections 17.2, 17.4, and 23.4. The hospital side of this is internal ISMS policy, often ISO 27001-flavoured. The two sides overlap but are not identical.
- In Tibor's audit experience, the cleanest startups treat the hospital pack as a by-product of the EN IEC 81001-5-1:2022 engineering artefacts. Nothing new is written for procurement. Everything is a view of documents that already exist.
- Felix has watched deals slip a full quarter because the founder discovered the procurement questionnaire on the day of the meeting.

## Why this matters (Hook)

A Series A MedTech with a CE-marked Class IIa software device lands a pilot with a German university hospital. The clinical champion is sold. The medical director is sold. The meeting with hospital IT is scheduled for three weeks later. The hospital sends a cybersecurity questionnaire ahead of the meeting. The founder opens it and discovers 180 questions about network architecture, authentication, SBOM, vulnerability management, and end-of-support policy. The founder has most of the information but not in any form a hospital can consume. The meeting is rescheduled. Then rescheduled again. Three months later the pilot starts.

Tibor has seen the mirror image on the regulatory side. A notified body audit for the same class of device asks for the same information in a different format. The engineering work overlaps almost completely. The failure is that the work produced outputs that spoke only to the notified body and had to be rewritten for every hospital.

Felix has watched the funding consequence. An investor asks for the sales pipeline. The pipeline shows five hospitals in procurement. The founder cannot commit to when the first deal closes because each hospital is running a different questionnaire. The pipeline goes into the "slipping" column.

The good news is that this is fixable before the first procurement meeting, not after.

## What MDR actually says (Surface)

MDR does not prescribe the format of a hospital cybersecurity questionnaire. It does require the manufacturer to do the underlying work that feeds any such questionnaire.

**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.

**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.

**Annex I Section 23.4.** The information supplied with the device shall include the minimum IT requirements and security measures necessary to run the software as intended.

MDCG 2019-16 Rev.1 is the authoritative interpretation. It explicitly contemplates information exchange between manufacturer and operator, which in hospital language is the procurement conversation. EN IEC 81001-5-1:2022 covers the engineering activities that produce the evidence hospitals will ask to see.

On the hospital side, the questionnaire is driven by the hospital's own information security management system, which in most European hospitals follows ISO 27001 patterns. The questionnaire is not a regulatory document in the MDR sense. It is a procurement filter. Failing the filter does not make the device non-compliant. It makes the device unsold.

## A worked example (Test)

A cloud-connected Class IIb ICU monitoring system is in the final stage of procurement at a Dutch academic hospital. The hospital sends a standard vendor cybersecurity pack request. The manufacturer has a prepared pack ready.

**1. Completed security questionnaire.** The manufacturer maintains a master answer set for the MDS2 questionnaire and a local Dutch variant derived from it. Each question has a verified answer with an internal reference to the controlling document or test record. When the hospital's form arrives, filling it in takes half a day rather than two weeks.

**2. Network architecture and data flow diagram.** The manufacturer provides two diagrams. The first shows the device and its components inside the hospital network with clear VLAN boundaries, required ports, required outbound connections, and where patient data is stored. The second shows the end-to-end data flow from sensor to cloud backend to clinician dashboard, with the processing location of each personal data element.

**3. Software bill of materials (SBOM).** The manufacturer supplies an SBOM in a machine-readable format (CycloneDX or SPDX), including every third-party library, every SOUP component, and the current version of each. The SBOM is dated and the manufacturer commits to refreshing it on every release. Tibor's view on this is that the SBOM is not a new document. It is what the EN 62304 configuration item list should already contain.

**4. Vulnerability management process.** The manufacturer supplies a short document describing how new vulnerabilities are monitored (CVE feeds plus the SBOM), how severity is assessed, how patches are developed, how patches reach deployed devices, and what the communication channel to the hospital is. The document references the post-market surveillance plan and the change control process so the hospital can see the loop is closed.

**5. End-of-support policy.** A defensible number or policy, consistent with the IFU and the post-market surveillance plan.

**6. Third-party evidence.** The pack includes a sanitised penetration test report or summary and, where available, any ISO 27001 or SOC 2 certification of the backend. Third-party evidence is not required by MDR but is routinely asked for by hospital IT.

With that pack prepared in advance, the procurement meeting becomes a conversation about integration, not a scramble to find documents.

## The Subtract to Ship playbook (Ship)

**Step 1. Build the pack once, not per hospital.** The canonical pack lives in a dedicated folder. Each item has an owner and a review cadence. When a hospital asks, the founder assembles the pack in hours, not weeks.

**Step 2. Treat MDS2 as the master form.** Answering MDS2 thoroughly prepares the manufacturer for almost every European hospital variant. Most local forms are subsets or reorganisations of the same questions. 

**Step 3. Make the SBOM machine-readable and keep it current.** An SBOM in a PDF is a starting point but hospital IT teams increasingly want CycloneDX or SPDX output that can be ingested into their own vulnerability tooling. A stale SBOM is worse than a missing one because it gives false confidence.

**Step 4. Write the vulnerability management process in plain language.** Hospital IT does not want a copy of the internal QMS procedure. They want a one or two page description that states the monitoring source, the triage path, the patch cadence, and the notification channel. The underlying QMS procedure exists. What the hospital sees is the summary.

**Step 5. Diagram the network the way a hospital IT engineer thinks.** Not the way the development team thinks. VLANs, ports, outbound endpoints, data flow, data location, authentication method. If the diagram does not show these items, it will be rejected.

**Step 6. Prepare a one-page Q&A for the non-obvious questions.** What happens when the hospital network goes down. What happens when the cloud backend is unreachable. What happens when a clinician forgets their password. What happens when the SBOM surfaces a CVE in a widely-used library. Having answers ready signals maturity.

**Step 7. Bring the regulatory lead and the technical lead to the meeting.** Procurement meetings often bounce between regulatory and technical questions. A founder answering alone loses credibility faster than a two-person team that can switch cleanly.

## Reality Check

1. Is there a single folder that holds the canonical hospital cybersecurity pack, or does every sales cycle start from scratch.
2. Can the team produce a completed MDS2 or MDS2-equivalent response in less than one working day.
3. Is the SBOM current, machine-readable, and aligned with the EN 62304 configuration item list.
4. Does the network and data flow diagram match what a hospital IT engineer would draw, not what a developer would draw.
5. Is the vulnerability management process described in a short document hospital IT can read without internal QMS context.
6. Is the end-of-support policy defensible and consistent with the IFU and the post-market surveillance plan.
7. Has a sanitised penetration test summary been prepared for external sharing.
8. Are the regulatory and technical leads both on the procurement call, or is the founder carrying it alone.

## Frequently Asked Questions

**Is MDS2 legally required in Europe.**
MDS2 is not an MDR requirement. It is a procurement convention. Hospitals use it because it maps well to their internal ISMS. 

**What if the hospital uses its own questionnaire.**
Most local questionnaires overlap heavily with MDS2. A well-maintained master answer set translates quickly. The effort is translation, not fresh writing.

**Does the SBOM need to be shared publicly.**
No. Most hospitals accept an SBOM under a confidentiality agreement. The manufacturer is not required to publish the SBOM on the website.

**What if the backend is hosted by a cloud provider.**
The hospital will ask for evidence of the provider's security posture. ISO 27001 certification of the relevant service region and a data processing agreement are the usual artefacts. The manufacturer remains accountable under MDR and under data protection law.

**How does this interact with the notified body.**
The notified body cares about MDR Annex I compliance. The hospital cares about operational integration. The same engineering work serves both audiences with different output formats.

**What is the single fastest win.**
Build the canonical pack before the first procurement meeting. In Felix's experience, this single move has moved deal closures forward by a full quarter.

## Related reading
- [Cybersecurity Risk Management for Medical Devices Under MDR](/blog/cybersecurity-risk-management-mdr). how the underlying risk file feeds the hospital pack.
- [Cybersecurity Labeling for Medical Devices](/blog/cybersecurity-labeling-medical-devices). the IFU side of the same information.
- [SBOM for Medical Devices](/blog/sbom-medical-devices-mdr). how to build and maintain a usable SBOM.
- [Hospital Procurement MedTech Strategy](/blog/hospital-procurement-medtech-strategy). the broader procurement playbook for startups selling to hospitals.

## Sources
1. Regulation (EU) 2017/745 on medical devices, consolidated text. Annex I Sections 17.2, 17.4, 23.4.
2. MDCG 2019-16 Rev.1 (December 2019, Rev.1 July 2020). Guidance on cybersecurity for medical devices.
3. EN IEC 81001-5-1:2022. Health software and health IT systems safety, effectiveness and security. Security activities in the product life cycle.
4. EN 62304:2006+A1:2015. Medical device software. Software life cycle processes.

---

*This post is part of the [Cybersecurity & Data Protection](https://zechmeister-solutions.com/en/blog/category/cybersecurity) 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).*