Maps to
ISO 14971: §9.1
IEC 81001-5-1: §7.5
Requirement text
Monitor the effectiveness of risk controls by collecting and reviewing information during the post-release phase. Inform other activities and processes of identified issues, including for other products and revisions. Inform third parties if problems are found in third-party source code. Issues identified in the threat model of released health software shall be addressed per clauses 9.4 and 9.5.
What changed
IEC 81001-5-1:2021 is the first standalone cybersecurity standard purpose-built for health software and medical device software. Published in December 2021, it was adapted from IEC 62443-4-1 (industrial control systems security) to address the unique safety and regulatory context of medical devices — adding 64 health-specific requirements that account for patient safety, clinical workflows, and the manufacturer-HDO relationship.
The standard mirrors IEC 62304's lifecycle structure but adds security-specific activities at every phase — planning, development, testing, release, and maintenance. It requires security risk management to be integrated with ISO 14971 safety risk management, not treated as a separate IT concern. FDA formally recognized it as Consensus Standard #13-112 in December 2022 and references it as providing a framework for the Secure Product Development Framework (SPDF) required by Section 524B.
EU MDR harmonization was originally targeted for May 2024 but postponed to May 2028. Despite this delay, Notified Bodies and Competent Authorities universally recognize it as "state of the art" for health software cybersecurity under MDR GSPR Annex I, Section 17.2. Missing or inadequate cybersecurity documentation is already a top cause of Notified Body major non-conformities for SaMD. A December 2025 Interpretation Sheet (ISH1:2025) clarified software item classification into maintained, supported, and required software categories, affecting risk transfer and post-market obligations.
Atomic constraints
- •Effectiveness of risk controls SHALL be monitored during the post-release phase.
- •Information collection and review SHALL be performed to support monitoring.
- •Other activities and processes SHALL be informed of issues identified, including for other products and revisions.
- •Third parties SHALL be informed if problems are found in third-party source code.
- •Issues in the threat model of released health software SHALL be addressed per clauses 9.4 and 9.5.
Common gaps
Post-market monitoring of security controls absent
moderateAfter release, there is no process to monitor whether security controls remain effective as the threat landscape evolves. New attack techniques and vulnerability classes can render previously adequate controls insufficient.
Evidence signals
- •
FILE_EXISTS
Post.*Market.*Surveillance|Security.*Monitoring|Risk.*Control.*Effectiveness|Post.*Release.*Review
- •
CONTENT_MATCH
Does this document describe a process for monitoring the ongoing effectiveness of security risk controls after product release, including how findings are escalated to other products, revisions, or third-party suppliers?
Audit defense
Our Post-Market Surveillance Plan for [your product] (Doc ID: [your document ID]) includes a security risk control monitoring activity that reviews field data, vulnerability reports, and audit logs against the risk controls documented in the Risk Management File. Findings are fed back into the threat model review cycle and, where applicable, notified to third-party component suppliers.