Is ISO 27001 enough for medical device cybersecurity?.

Since the MDR came into force, ISO 27001 has become common advice for medical device manufacturers thinking about cybersecurity. Your QA/RA consultant recommends it. Your customer's procurement team may ask about it on their vendor questionnaire. Investors expect it. It is a sensible place to start.

The catch is that the MDR doesn't name ISO 27001, or any cybersecurity standard, at all. It requires manufacturers to apply the state of the art. For cybersecurity, notified bodies have settled on a different stack as state of the art, with IEC 81001-5-1 at the centre of it. ISO 27001 satisfies your customer. IEC 81001-5-1 satisfies your notified body. Many teams discover this late.

What ISO 27001 covers (and what it doesn't)

ISO 27001 is an information security management system standard. It sits alongside the QMS you already operate (ISO 13485) and tells the organisation how to manage information security risk through an ISMS, with controls drawn from Annex A covering access, cryptography, supplier relationships, secure development, change management, incident response, and continuity.

The key word is organisational. ISO 27001 governs how your company protects information, systems, and data. It does not, on its own, tell you how to do cybersecurity engineering on a regulated medical device through its development lifecycle. There is no clause that mandates a software bill of materials (SBOM). There is no clause that defines post-market vulnerability monitoring of third-party software components inside the device you're shipping. ISO 27001 is the right standard for the organisation. It is not the right only standard for the device.

What the notified body looks at

GSPR 17.2 of the MDR requires manufacturers to consider information security. GSPR 17.4 sets minimum IT security expectations. Because the MDR expects state of the art rather than naming standards, notified bodies have settled on IEC 62304 (with the recently published cybersecurity amendments) for the software lifecycle, ISO 14971 for risk management including security-related risk that can lead to patient harm, and IEC 81001-5-1:2021 for the cybersecurity lifecycle of health software.

IEC 81001-5-1 is the one most teams aren't aware of yet. It covers secure design, threat modelling, secure coding, security testing, identification and security management of third-party software components (SOUP and COTS in IEC 62304 language), post-market vulnerability monitoring, coordinated disclosure, and security maintenance. The standard itself doesn't reference an SBOM by name, but SBOMs are the industry-standard way teams evidence the third-party component clauses, and they're directly mandated by adjacent regimes such as FDA premarket cybersecurity guidance and the EU Cyber Resilience Act.

Two audiences, two gates

The cleanest way to think about this is to ask who is reading your evidence.

The notified body is checking that your medical device is safe and performant. They want a recognised cybersecurity engineering process applied to the device itself, security-related risk treated through ISO 14971, and a plan for post-market vulnerability monitoring of the components inside it. This is the conformity assessment gate.

Your customer's CISO, IT, and procurement teams check that doing business with you won't create information security risk for them. This gate matters most when your medical device has a manufacturer-hosted cloud or SaaS component, or when you process customer data on their behalf. In those cases, they want to see how you handle their data, your access controls, your incident response, and your supplier and cloud assurance. For a fully embedded device with no cloud back-end, the gate is much smaller. ISO 27001 is the certification they recognise across Europe; SOC 2 plays this role in North America. This is the commercial gate.

Both gates are real. Failing either one stops you. The mistake I see most often is teams treating these gates as if they were the same gate, and assuming a certification meant for one will satisfy the other.

Where the two overlap

The good news is that ISO 27001 and IEC 81001-5-1 share a meaningful amount of underlying evidence. Supplier and third-party component management, secure development, change control, incident handling, and document control all overlap. The artefacts most teams produce to evidence both at once are a current SBOM with vulnerability status against the components, a vulnerability triage log, and a security risk file linked to ISO 14971. Build them once. Present them twice.

Technical artefacts travel cleanly. QMS documents take more work. ISO 13485 (the QMS standard most medical device manufacturers already run) and ISO 27001 use different terminology for what is often the same underlying activity. ISO 13485 has design controls, the device master record, complaints, and CAPA. ISO 27001 has Statement of Applicability, asset registers, incidents, and nonconformities. A single set of QMS documents can serve both auditor types, but it usually needs careful drafting, clear cross-references, or a small terminology appendix to be readable on both sides.

Where the two standards don't overlap, the gap is usually on the product side: third-party software component management (typically evidenced via an SBOM), security-related risk against ISO 14971, post-market vulnerability monitoring, and coordinated disclosure. An ISMS audit report won't substitute for evidence against those clauses.

What to do now

If you've already started on ISO 27001, don't stop. It's useful evidence for the commercial gate and it brings discipline to your information security operations. Just don't let it stand in for product cybersecurity.

If you're working with a QA/RA consultant on your ISMS, or you're a consultant supporting a manufacturer, the most useful next conversation is how the IEC 81001-5-1 clauses, especially post-market vulnerability monitoring of SOUP and COTS components, will be evidenced in the technical file alongside the ISMS. That mapping tends to surface the practical work quickly, on both sides.

If your funding milestones are tied to clearance, you can sequence accordingly. IEC 81001-5-1 has to be in place for the conformity assessment that gets you cleared. ISO 27001 mainly bites later, once you start selling into hospitals and health systems whose procurement teams want to see it. Many startups focus on IEC 81001-5-1 first and begin the ISO 27001 work after clearance triggers the next funding tranche and the cash to do it properly lands.

The bottom line

ISO 27001 is the right standard for the customer-facing gate. IEC 81001-5-1 is the right standard for the notified-body-facing gate. If you're selling a medical device into Europe, you'll need to satisfy both. Treating them as a shared evidence stack with two audiences, rather than two separate compliance programmes, leads to a leaner, more defensible posture.