IEC 81001-5-1: where to start when you already have 100k lines of code

Your notified body has just asked for your compliance with IEC 81001-5-1. Your product already exists, it is CE-marked or nearly so, and no one on the team has ever written a line of “threat model” in their life. This article describes a realistic catch-up plan — the one I apply with my clients — without rewriting the product or freezing the roadmap.

What is IEC 81001-5-1?

Definition: IEC 81001-5-1:2021 is the standard that specifies the cybersecurity activities to be built into the life cycle of health software — from design to end of life — to ensure the product’s safety, effectiveness and security. It is designed as a “security” mirror of IEC 62304: where 62304 structures software development, 81001-5-1 injects the security activities into it (threat analysis, vulnerability management, security testing, incident response).

Concretely, it covers eight processes: security management, security requirements specification, secure design, implementation, security verification and validation, management of security-related defects, update management, and documentation/user guidance.

Why are notified bodies asking for it now?

The MDR has required since 2017 (Annex I, requirements 17.2 and 17.4) that software be developed according to the state of the art in information security. The problem: “state of the art” was not defined. The MDCG 2019-16 guidance on cybersecurity set the expectations, then IEC 81001-5-1 was published in late 2021 and progressively harmonised as the reference. As a result, since 2024 most notified bodies cite it explicitly in their question lists, and in 2026 a SaMD file without a documented 81001-5-1 strategy almost systematically comes back with a nonconformity.

You do not need to rewrite your code. You need to prove that you know what it contains and what can go wrong.

The standard in fact explicitly foresees this case in its annex dedicated to legacy software: you are not required to have developed the product under 81001-5-1, but to run a documented catch-up through a gap analysis.

The 5-step catch-up plan

Step 1 — Inventory: generate your SBOM

You cannot secure what you do not know. Start with an exhaustive SBOM (Software Bill of Materials):

• Generate a CycloneDX-format SBOM from your lockfiles (package-lock.json, poetry.lock, go.sum…) — tools such as cyclonedx-cli, Syft or Trivy do it in one command.
• Include transitive dependencies, Docker base images, runtimes.
• Reconcile this SBOM with your SOUP list in the 62304 sense: every SOUP component must have its functional requirements and known anomalies documented.

Budget one to two days for a first clean SBOM. It is the best effort-to-value ratio in the whole plan.

Step 2 — Threat model: half a day, not a month

A threat model is not a thesis, but it does follow a precise method, the risk matrix. For a typical SaMD (app + API + database):

1. Draw the data-flow diagram: actors, components, trust boundaries.
2. Run each flow through STRIDE (spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege).
3. Prioritise: which threats have a patient impact or affect health data?
4. Link each retained threat to an existing control or to a ticket.

Do it in a workshop with the tech lead and a quality person. Half a day is enough for a first usable — and auditable — version.

Step 3 — Vulnerability management: a process, not a tool

The notified body wants to see a living process:

• Monitoring: automatic scan of the SBOM against vulnerability databases (Dependabot, Renovate, Trivy, OSV) on every build and at least weekly.
• Triage: a written rule stating who assesses, within what deadline, and how you decide whether a CVE is exploitable in your context of use.
• Link to risk: any exploitable vulnerability with a patient impact enters the ISO 14971 risk management file.
• Trace: every decision (fix, accept, not applicable) is justified and archived.

Step 4 — Proportionate security testing

You don’t need a red team. The expected baseline:

Document the results and, above all, how findings are handled: a pentest report without an action plan is evidence against you, not proof.

Step 5 — Document the activities, not novels

81001-5-1 asks for records, not literature. A 10-page security plan that references your real tools beats an 80-page binder copied from a template. Minimum content: roles and responsibilities, vulnerability management process, threat model, test results, update and end-of-life policy, and the legacy gap analysis that justifies your catch-up.

Five steps for eight processes: does that cover it?

It is the question any attentive reader asks, and the honest answer is no, not entirely — and deliberately so. A catch-up plan handles what can be caught up on a product that is already written. Two of the standard’s processes escape that exercise by nature: they cannot be retrofitted, they apply to what you build next.

The two rows marked “not retrofittable” are the ones that worry teams most, and they should not. Nobody will ask you to prove that code written in 2022 came out of a secure design process you did not have. What is expected is that your gap analysis records them honestly and commits to what follows: from when your design reviews carry security, from which version your code reviews cover it.

That is exactly what the legacy gap analysis is for. It is not an admission of weakness, it is the document that turns a shortfall into a trajectory — and it is the first thing a notified body opens.

The classic mistakes

• Buying a template and filling it in without executing it. Auditors now ask for evidence of execution: show a triaged-CVE ticket, not a theoretical procedure.
• Treating the SBOM as a one-off deliverable. It must be regenerated on every release, automatically.
• Confusing safety and security. ISO 14971 covers patient risk; 81001-5-1 covers intentional threat. The two files must cross-reference each other.
• Making quality carry everything. Without the tech lead in the loop, the threat model will be wrong and the developers won’t follow.

How does it fit with IEC 62304 and the MDR?

Remember the chain: the MDR requires security according to the state of the art → IEC 81001-5-1 defines the security activities that constitute that state of the art → IEC 62304 provides the life cycle into which those activities fit. If your 62304 documentation is clean, 81001-5-1 grafts onto it: same reviews, same releases, same records, with an added security dimension. If it isn’t, start there — that’s the subject of another article.

In practice, for a team of 5 to 10 developers with an existing product, this catch-up runs over two to three months alongside the roadmap. The key is to start with the inventory: everything else follows from it.

FAQ

Is IEC 81001-5-1 mandatory?

Not in the sense that a law names it. What is enforceable are requirements 17.2 and 17.4 of MDR Annex I, which mandate development according to the state of the art in information security without saying which one. IEC 81001-5-1 is the standard that defines that state of the art, and the MDCG 2019-16 guidance cites it as a means of compliance. In practice the distinction is academic: a notified body will ask for your 81001-5-1 strategy, and a file with nothing documented comes back with a non-conformity.

How is it different from IEC 62304?

They address different risks. IEC 62304 structures the software life cycle and covers failure — what breaks on its own. IEC 81001-5-1 adds the security activities and covers intentional threat — what an adversary causes. They neither replace nor duplicate each other: 81001-5-1 grafts onto the 62304 life cycle, with the same reviews and the same records. If your 62304 documentation is not clean, that is where to start.

Does it apply to software that already exists?

Yes, and the standard explicitly provides for that case in its annex on legacy software. You are not asked to have developed the product under 81001-5-1 — absurd for a device already on the market — but to run a documented catch-up through a gap analysis. That document is what justifies your trajectory: it records what is missing and commits to a plan. Without it, your catch-up looks like scattered activity; with it, it is a process.