An information security audit was requested for our medical devices — what are they looking for exactly?

One of the top items on that list will be a machine-readable SBOM in CycloneDX or SPDX format. If the gateway runs a Linux kernel, every open-source package version and its corresponding CVE scan output needs to be documented. If you didn't leave telnet open or use unencrypted HTTP on the gateway, you're halfway there.

Two years ago in a similar tender, we paid 11.500 EUR to an independent lab for a device penetration test and a B3S hospital standard compliance report. Once we attached that report to the tender file, the hospital IT team signed off on the 45-point checklist with barely any pushback.

Ask the hospital IT team if they are basing requirements on BSI IT-Grundschutz or the B3S Medizinische Versorgung profile. Most hospitals don't write checklists from scratch; they copy existing forms from federal standards. Knowing the exact framework makes answering them much easier.

Hospital IT teams usually don't understand the internal logic of medical software, so they treat it like a standard server. They might tell you to "install an antivirus on the device." You need to patiently explain why traditional antivirus software can't run on embedded devices and that you use hardware-level integrity checks (Secure Boot) instead.

We got caught in a similar audit back in 2021 during a university clinic tender. Our devices were top-notch, but our remote software update mechanism lacked cryptographic signature verification. The auditor flagged it under a single clause and suspended the contract for 5 months until we set up the signature infrastructure.

as long as you haven't left default credentials like "admin/admin" on the devices and you force a password change on first login, you've already cleared the primary hurdle auditors look at.

Information security is already an essential legal requirement under MDR Annex I, Section 17.2. Presenting the documentation to the auditor as integrated parts of your medical device technical file (Post-Market Surveillance and Risk Management) will demonstrate your corporate professionalism.

edit: I wrote something wrong above, sorry about that.

The 4 documents you need to submit right off the bat are: 1) An MDCG-compliant threat analysis report, 2) A network architecture document listing all open ports and services, 3) A vulnerability disclosure and patch management policy document, 4) Proof of hardware-level secure boot (Secure Boot) on the device.

Let me speak from the other side; I'm on the supplier side. Any unwritten clause becomes a point of disagreement later, as both sides remember it differently.

Of course, it varies if your situation is different.

I have a question. An untested backup is not a backup.

Good luck with that.

I didn't know that.

I agree with this. The biggest time-waster for us was not knowing who had the final say.

Just leaving this note, it might be useful.

Here's how it went for us. If permission and scope aren't in writing, don't start that test.

Proven by experience.

I disagree with you on this point. The answer varies greatly by industry; there is no one-size-fits-all rule.

An untested backup is not a backup.

I'm in the same situation that's why I'm asking. The real issue isn't the number but what it's based on.

I agree and I'd like to emphasize that. An automated scan report is not the same as a penetration test.

If you post the result here, it will help others too.

I've been down this road, let me tell you. Don't hesitate to ask; those who don't ask always pay more.

I'm writing this so you don't make the same mistake. The harder it is to reverse a decision, the slower you should make it.

This is my opinion, I'm not claiming it's absolute truth.