ISO/IEC 27001 is an organisational information security management system standard. EN IEC 81001-5-1:2022 is a product-level security lifecycle standard for health software. They cover different scopes. Neither replaces the other. For a medtech startup under MDR, EN IEC 81001-5-1:2022 is the standard the notified body assesses against. ISO 27001 is a commercial instrument with an organisational scope.

By Tibor Zechmeister and Felix Lenhard.

TL;DR

  • ISO/IEC 27001 defines requirements for an information security management system (ISMS). Its scope is organisational: how a company manages confidentiality, integrity and availability of information across people, processes and systems.
  • EN IEC 81001-5-1:2022 defines security activities across the health software product life cycle. Its scope is the product: how security is designed, built, verified, released, and maintained over the life of a health software item.
  • MDR requires state-of-the-art product security under Annex I Sections 17.2 and 17.4. EN IEC 81001-5-1:2022 is the current state-of-the-art reference for that requirement. ISO 27001 is not referenced in MDR.
  • A notified body reviewing a technical file looks for EN IEC 81001-5-1:2022 evidence, integrated into the EN 62304 software process and the ISO 14971 risk file in line with MDCG 2019-16 Rev.1.
  • ISO 27001 evidence (policies, Annex A controls, Statement of Applicability, internal audit, management review) does not substitute for product security evidence. It complements it.
  • The two standards share a few DNA fragments (risk-based thinking, documented controls, management review) but they are answering different questions and the overlap does not let one replace the other.

Why this matters (Hook)

Tibor has seen founders bring an ISO 27001 Statement of Applicability to a notified body audit and expect it to answer the cybersecurity portion of the technical file review. The auditor reads the SoA, closes the document, and asks the same question again: where is the EN IEC 81001-5-1:2022 evidence for this specific product. The meeting goes quiet. The founders realise that organisational controls on how the company manages its own laptops and cloud tenants are not the same thing as a secure development lifecycle for the device.

Felix has seen the mirror image. Founders bring a beautifully integrated EN IEC 81001-5-1:2022 lifecycle and a clean ISO 14971 risk file to a hospital procurement office, and the CISO asks for ISO 27001. The product evidence is exactly what the notified body wanted, and none of it answers "does the vendor company run an ISMS". The founders walk out thinking the CISO was unreasonable. The CISO walks out thinking the founders were evasive. Neither is true. They were asking about different layers.

The aim of this post is to flatten the confusion by comparing the two standards on scope, object, audience, and the deliverables that result.

What MDR actually says (Surface)

MDR does not name either standard. It defines the outcome and the standards name the means.

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

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

EN IEC 81001-5-1:2022 "Health software and health IT systems safety, effectiveness and security Part 5-1: Security". Specifies the life cycle requirements for security of health software and health IT systems. Aligns with IEC 62443-4-1 secure development lifecycle concepts and dovetails with EN 62304. Structured around planning, requirements, design, implementation, verification, validation, release, maintenance, and decommissioning of security activities. Harmonised under MDR for the relevant GSPRs.

MDCG 2019-16 Rev.1 "Guidance on Cybersecurity for medical devices". The authoritative interpretation of MDR cybersecurity expectations. Cybersecurity is expected to be integrated into the ISO 14971 risk management process and to follow a secure development lifecycle. EN IEC 81001-5-1:2022 is the standard that operationalises that expectation.

ISO/IEC 27001. Specifies the requirements for establishing, implementing, maintaining and continually improving an information security management system within the context of an organisation. Includes Annex A, a list of information security controls. ISO 27001 is certifiable against by an accredited certification body. It is not harmonised under MDR and does not appear in MDR Annex I.

Plain language: MDR asks for secure software. EN IEC 81001-5-1:2022 is the standard that describes what secure software development and maintenance looks like over the product lifecycle. ISO 27001 is the standard that describes how an organisation manages its information security as a management system. Both are useful. They answer different questions.

A worked example (Test)

Compare the two standards across seven dimensions for a Class IIa SaMD startup.

1. Scope. ISO 27001 scopes to the organisation or a defined business unit. Boundary is drawn around "the people, processes and systems that handle information X". EN IEC 81001-5-1:2022 scopes to a specific health software product or product family. Boundary is drawn around the software item under EN 62304.

2. Object of protection. ISO 27001 protects information assets: customer data, employee data, intellectual property, credentials, contracts. EN IEC 81001-5-1:2022 protects the health software itself and, by extension, the patients and users who depend on it. Patient safety is the explicit concern.

3. Audience. ISO 27001 is read by the customer procurement office, enterprise CISOs, and an accredited certification body. EN IEC 81001-5-1:2022 is read by the notified body assessing the MDR technical file. Same word "cybersecurity" on the envelope, different readers inside.

4. Core artefact. ISO 27001 produces a Statement of Applicability, an ISMS policy, a risk register for information security, and a set of operational controls mapped to Annex A. EN IEC 81001-5-1:2022 produces a security plan integrated into the software development plan, a threat model, security requirements, verification and validation evidence, an SBOM, and a post-market security process.

5. Relationship to safety. ISO 27001 has no direct patient safety dimension. EN IEC 81001-5-1:2022 is explicitly linked to patient safety through the ISO 14971 risk management process. A security threat that compromises patient data is also a clinical hazard in the risk file, which is the integration MDCG 2019-16 Rev.1 expects.

6. Certification model. ISO 27001 is certified by an accredited certification body against the ISO 27001 standard. The result is an ISO 27001 certificate. EN IEC 81001-5-1:2022 is not certified by an accredited body in the same way. Conformity is demonstrated as part of the MDR technical file, reviewed by the notified body as evidence that the GSPRs on security are met.

7. What the notified body does with each. In Tibor's audit experience, a notified body accepts EN IEC 81001-5-1:2022 lifecycle evidence directly as conformity evidence for the relevant GSPRs. An ISO 27001 certificate is accepted as context but does not close any non-conformity on product security. The reverse is also true: an EN IEC 81001-5-1:2022 lifecycle does not close an enterprise customer's ISO 27001 question on its own.

The practical consequence: a startup that builds EN IEC 81001-5-1:2022 evidence in a disciplined way will not satisfy ISO 27001, and a company that holds ISO 27001 certification will not satisfy MDR product security expectations. The two are additive.

The Subtract to Ship playbook (Ship)

The Subtract to Ship approach is to pick the standard that the current binding audience requires, build it well, and add the second standard only when the business case is specific. For most early-stage medtech startups under MDR, the sequence is simple.

Step 1. EN IEC 81001-5-1:2022 first. It is the standard the notified body audits against. Without it, the CE mark is at risk. With it, the startup has a defensible product security story.

Step 2. Integrate EN IEC 81001-5-1:2022 into the existing EN 62304 software lifecycle. Do not create a parallel security process. The security plan lives inside the software development plan. Threat modelling feeds the ISO 14971 risk file. SBOM maintenance lives in the EN 62304 configuration item list.

Step 3. Build a supplier security assurance pack. A five-page PDF that answers enterprise procurement from existing QMS artefacts. This buys time and often closes hospital deals without ISO 27001.

Step 4. Watch for the ISO 27001 trigger. Named enterprise customer. Written procurement gate. Signed revenue on the line. Until this trigger fires, ISO 27001 is a distraction.

Step 5. When ISO 27001 is triggered, reuse the ISO 13485 QMS aggressively. The overlap between ISO 13485 and ISO 27001 Annex A is substantial. Document control, records, training, internal audit, management review, corrective action and supplier control are already in place for the medical device QMS. A good ISO 27001 implementer will plug into these instead of duplicating them.

Step 6. Scope the ISO 27001 certificate tightly. Only the business unit that touches the product. Only the processes that are relevant. An over-scoped ISMS is expensive to maintain and adds operational weight the startup cannot carry.

Step 7. Do not mix the two deliverables in front of the wrong audience. When the notified body asks for EN IEC 81001-5-1:2022 evidence, the answer is the software security plan, threat model, security requirements, verification and validation reports, SBOM and post-market security process. When the hospital CISO asks for an ISMS, the answer is the ISO 27001 certificate or an equivalent. Do not hand a Statement of Applicability to the notified body or a threat model to the CISO and expect the other audience's question to be answered.

Reality Check

  1. Is it clear inside the startup which audience is asking when a "cybersecurity" question arrives, and does the answer change accordingly?
  2. Does the EN IEC 81001-5-1:2022 evidence live inside the EN 62304 software lifecycle, or is it a parallel tab nobody reconciles with the risk file?
  3. Does the ISO 14971 risk file actually contain threats from the threat model as hazards with probability, severity and controls?
  4. Is the SBOM machine-readable and generated on every release?
  5. Is ISO 27001 being considered because a named customer requires it, or because it "looks serious"?
  6. If ISO 27001 is in scope, is it sized to the business unit that touches the product, or to the whole company?
  7. Does the team have a reusable one-page map showing which standard answers which question, so the wrong document is not sent to the wrong audience?

Frequently Asked Questions

Which standard does the notified body care about? EN IEC 81001-5-1:2022. It is the current state-of-the-art standard for health software security lifecycle activities. MDCG 2019-16 Rev.1 operationalises MDR Annex I Section 17 cybersecurity expectations against this standard.

Does ISO 27001 help with MDR in any way? Indirectly. A mature ISMS makes it easier to run internal processes securely, which supports the organisational side of a secure development lifecycle. It does not substitute for product-level lifecycle evidence.

Can a startup skip EN IEC 81001-5-1:2022 and only do ISO 27001? No. EN IEC 81001-5-1:2022 evidence is what the notified body assesses against the MDR GSPRs on security. Skipping it puts the CE mark at risk.

Can a startup skip ISO 27001 and only do EN IEC 81001-5-1:2022? Yes, until an enterprise customer specifies ISO 27001 as a procurement gate and the deal value justifies the cost. Most early-stage MDR startups do not need ISO 27001 on day one.

Is there a harmonised ISMS standard for medical devices? Not specifically. The closest cross-reference is EN IEC 81001-5-1:2022 for product security and MDCG 2019-16 Rev.1 for MDR interpretation. ISO 27001 remains a horizontal information security standard.

What about IEC 62443 for industrial security? IEC 62443 concepts, especially IEC 62443-4-1 on secure product development, have influenced EN IEC 81001-5-1:2022. For medical devices under MDR, EN IEC 81001-5-1:2022 is the direct reference. IEC 62443 appears more often in industrial and operational technology contexts than in medtech technical files.

Sources

  1. Regulation (EU) 2017/745 on medical devices, consolidated text. Annex I Sections 17.2, 17.4.
  2. MDCG 2019-16 Rev.1 "Guidance on Cybersecurity for medical devices", July 2020.
  3. EN IEC 81001-5-1:2022 "Health software and health IT systems safety, effectiveness and security Part 5-1: Security".
  4. EN 62304:2006+A1:2015 "Medical device software Software life cycle processes".
  5. EN ISO 14971:2019+A11:2021 "Medical devices Application of risk management to medical devices".
  6. ISO/IEC 27001 "Information security, cybersecurity and privacy protection Information security management systems Requirements".