For health software under MDR/IVDR, cybersecurity is no longer a late-project binder. The general safety and performance requirements in the MDR (and IVDR) require design and manufacture that take the state of the art into account, including risks related to unauthorised access.
This article shows how to fold IEC 81001-5-1:2021 (security activities in the health software product life cycle) into the SDLC and QMS, using MDCG 2019-16 Rev.1 as the EU interpretation aid for medical device cybersecurity.
Why IEC 81001-5-1 matters under MDR
IEC 81001-5-1 defines life-cycle processes, activities and tasks to strengthen cybersecurity of health software, in balance with safety and effectiveness as discussed in the ISO/IEC 81001 family. It is the operational security counterpart to the software life cycle (often IEC 62304) and risk management (ISO 14971).
MDCG 2019-16 helps manufacturers interpret Annex I cybersecurity expectations (secure design, documentation, information for users/healthcare providers, post-market surveillance). In audits, notified bodies look for life-cycle evidence, not only a tool checklist.
Caution: presumption of conformity from a harmonised standard depends on OJEU publication of the reference. Track the Commission page on harmonised standards and the OJEU status of the EN version you claim. Even without formal presumption, IEC 81001-5-1 is widely treated as state-of-the-art reference.
Fold cyber into the life cycle (not as an add-on)
Threats, risks and requirements
Model threats early, transfer security risks into the product risk file, and derive testable security requirements. Without that link, SBOMs and scans stay decorative.
SBOM and third-party components
Maintain a useful software bill of materials for vulnerability management, with supplier responsibilities and update criteria. Document patch decisions in change control.
Verification, release and post-market
Verify security controls as product requirements. Post-market, connect vulnerability watch, incident response and PMS: a critical flaw is a regulatory signal, not only an IT ticket.
Evidence to attach to the technical file
- IEC 81001-5-1 activity plans/reports (or a justified equivalent route).
- Traceability from threats → risks → requirements → tests → release.
- SBOM, vulnerability policy and patch evidence.
- Security information for deployers/healthcare providers (aligned with MDCG 2019-16).
- PMS/vigilance procedures that include cybersecurity incidents.
To industrialise this evidence in the product flow, combine CE marking, eQMS deployment and Qapsule.
FAQ
Is IEC 81001-5-1 mandatory under the MDR?
No standard is strictly “mandatory” under the MDR: you must demonstrate conformity with the GSPRs. In practice, IEC 81001-5-1 is the most expected life-cycle reference for health software cybersecurity. Check the OJEU harmonised status of the EN version you claim.
What does MDCG 2019-16 ask for?
It guides manufacturers on fulfilling Annex I cybersecurity expectations under MDR/IVDR: secure design, documentation, information to supply-chain actors, and post-market activities. It is not legally binding, but it strongly shapes assessment expectations.
Is an SBOM enough cyber evidence?
No. An SBOM is necessary but not sufficient. Link it to threat analysis, risk, testing, vulnerability management and post-market surveillance.
How do we avoid a cyber pack outside the QMS?
Embed security activities in existing design-control / SDLC SOPs, with the same reviews and records as clinical safety. Trace evidence in the eQMS instead of an isolated repository.
Where should we start on a SaMD already in development?
Run a gap analysis against IEC 81001-5-1 and MDCG 2019-16, prioritise gaps on the release critical path, then plan technical-file evidence. QARA PULSE can scope that targeted audit.
QARA PULSE article (May 2026), based on IEC 81001-5-1, MDCG 2019-16 and MDR/IVDR. Check OJEU harmonised-standard status and adapt to your product architecture.