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. An advisor 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. 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, the QMS standard most medical device manufacturers already run) 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 across its development lifecycle.

If you hold a 2022-version certificate, you might reasonably push back here. Annex A controls 8.25 to 8.31 cover the secure development life cycle, secure coding, security requirements, and security testing. They do, and they're worth implementing well. But they govern how your organisation develops systems in general. Applied diligently, they still produce no device-level evidence for your technical documentation: no threat model for the device, no security management of the third-party software components inside it, no link from security risk to patient harm through ISO 14971, and no post-market vulnerability monitoring plan for the product you're shipping. Your ISMS auditor checks that the controls operate; no notified body ever reads that audit as device evidence. ISO 27001 is the right standard for the organisation. It is not, on its own, the right standard for the device.

What the notified body looks at

GSPR 17.2 of the MDR requires software to be developed in accordance with the state of the art, taking information security into account. GSPR 17.4 requires manufacturers to set out minimum requirements for the operating environment: hardware, IT network characteristics, and IT security measures, including protection against unauthorised access. The IVDR carries equivalent requirements for IVD software in GSPR 16.

Because the MDR expects state of the art rather than naming standards, notified bodies have settled on IEC 81001-5-1:2021 for the cybersecurity lifecycle of health software. This isn't informal preference. Team-NB, the European association of notified bodies, names IEC 81001-5-1 as state of the art in its position paper on cybersecurity and expects manufacturers to adopt it, and MDCG 2019-16 sets out the underlying expectations for cybersecurity under the MDR and IVDR.

IEC 81001-5-1, briefly, for people who know ISO 27001

IEC 81001-5-1 is the one most teams aren't familiar with, so here is the orientation. Its full title is Health software and health IT systems safety, effectiveness and security, Part 5-1: Security, Activities in the product life cycle. The structure is the useful part: it is deliberately built on the IEC 62304 lifecycle, with the same activity model and the same SOUP concepts. IEC 62304 in its current form addresses cybersecurity only within the software requirements activity; IEC 81001-5-1 adds the security activities to each lifecycle phase you already run. If your team operates IEC 62304, this is not a new world to learn. It is security work bolted onto a process you already operate.

Those activities cover 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 things an ISO 27001 reader will want to know straight away.

Is it harmonised? Not yet. EN IEC 81001-5-1 is on the Commission's standardisation request, with formal harmonisation currently expected around 2028. Notified bodies are not waiting for it, and neither should you. Treat the eventual presumption of conformity as a future bonus, not the trigger to start.

Is there a certificate? No, and this is the bigger mental-model shift. ISO 27001 works the way you expect a management system standard to work: an accredited certification body, a three-year cycle, surveillance audits, a certificate you can hand to procurement. IEC 81001-5-1 has none of that. There is no certificate to hold. It is a process standard, and the evidence of conformity lives in your technical documentation under Annex II and III of the MDR, integrated with your ISO 13485 design and development controls. Your notified body assesses it during conformity assessment, the same way they assess your IEC 62304 lifecycle. The deliverable is a technical file that holds up, not a logo for the website.

Two audiences, two reviews

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.

Your customer's CISO, IT, and procurement teams check that doing business with you won't create information security risk for them. Their review matters most when your medical device has a manufacturer-hosted cloud or SaaS component, or when you process customer data on their behalf. For a fully embedded device with no cloud back-end and no manufacturer data processing, this review is much lighter.

When it does apply, they want to see how you handle their data, your access controls, your incident response, and your supplier and cloud assurance. ISO 27001 is the certification they recognise across Europe; SOC 2 plays this role in North America. This is the procurement review.

Both reviews are real. Failing either one stops you. The mistake I see most often is teams treating them as if they were the same review, and assuming a certification meant for one audience 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 include a security risk file linked to ISO 14971, a threat model with the security requirements and mitigations that flow from it, secure development controls (coding standards, review records, security testing), a current SBOM with vulnerability status against the components, and a vulnerability triage log. Build them once. Present them twice.

If you think in ISO 27001 Annex A controls, the bridge looks like this:

Secure development (A.8.25 to 8.31) maps to IEC 81001-5-1 development activities in clause 5: secure design, threat modelling, secure coding, and security testing. The shift is from organisational practice to device-level evidence in the technical documentation.

Supplier relationships (A.5.19 to 5.23) become security management of third-party software components, the SOUP and COTS inside your product, evidenced with an SBOM. The shift is from supplier contracts and assurance to component-level identification and vulnerability status.

Incident management (A.5.24 to 5.28) becomes post-market vulnerability monitoring, coordinated disclosure, and problem resolution in clauses 6 to 9. The shift is from incidents in your own estate to vulnerabilities in devices you've already shipped.

Technical artefacts travel cleanly. QMS documents take more work. ISO 13485 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: secure design and threat modelling for the device, secure coding and security testing for the device's software, 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 procurement reviews 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 activities (secure design, threat modelling, third-party component management, post-market vulnerability monitoring) 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 CE marking, you can sequence accordingly. IEC 81001-5-1 has to be in place for the conformity assessment that gets you certified. 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 certification triggers the next funding tranche and the cash to do it properly lands.

The bottom line

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

If you're already on ISO 27001, treat the IEC 81001-5-1 work as the second half of the same picture, not a separate compliance project.

The piece of that evidence most teams find hardest to keep current is the SBOM and the vulnerability status against it. That's the part Threat Detective handles. Sign up and see where your components stand in minutes, without the spreadsheet surgery.