Maps to
IEC 81001-5-1: §5.5.1
Requirement text
The manufacturer shall establish an implementation activity (or activities) following secure coding standards (5.5.1). The manufacturer shall establish an activity (or activities) to ensure that implementation reviews identify, characterize and feed into the problem resolution process all security-related issues including: a) security requirements not adequately addressed by the implementation; b) secure coding standards used and any deviations documented (e.g., banned functions, failure to apply least privilege); c) Static Code Analysis (SCA) of source code using the secure coding standard; d) review of implementation traceability to the security capabilities defined in 5.3 and 5.4; and e) examination of threats and their ability to exploit implementation interfaces, trust boundaries, and assets.
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
- •Implementation must follow the secure coding standards established in 5.1.3.
- •Implementation reviews must be conducted and feed into the problem resolution process.
- •Security requirements not addressed by the implementation must be identified.
- •Secure coding standard usage must be documented, including any deviations (banned functions, least privilege failures).
- •Static Code Analysis (SCA) must be performed using the secure coding standard.
- •Traceability from implementation to security capabilities in 5.3 and 5.4 must be reviewed.
- •Threats and their ability to exploit implementation-level interfaces, trust boundaries, and assets must be examined.
Common gaps
No static analysis or code review for security vulnerabilities
majorCode reviews focus on functionality without systematic review for security vulnerabilities. SAST tools are not integrated into CI/CD or are configured with default rulesets not tuned to the secure coding standard.
Evidence signals
- •
FILE_EXISTS
Code.*Review|Implementation.*Review|Static.*Analysis|SCA|Secure.*Coding.*Review
- •
CONTENT_MATCH
Does this document describe code review or implementation review activities confirming secure coding standards were followed, static code analysis was performed, deviations were documented, and implementation is traceable to security capabilities?
Audit defense
The Implementation Review records and SCA reports for [your product] (Doc ID: [your document ID]) demonstrate that all implementation activities followed the secure coding standard, deviations were documented and justified, static analysis was performed, and findings were fed into the problem resolution process.