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

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.