ISO 14971 §7 risk control process: control selection, effectiveness verification, and secondary risk assessment within the risk management file.
Security control selection with secondary risk assessment (e.g., authentication timeouts affecting clinical workflows), adversarial verification, and residual risk coordination with the ISO 14971 risk-benefit evaluation.
Risk Management File entries for security controls with adversarial verification evidence — controls assumed to work without exploitation-based testing are a major finding.
Maps to
IEC 81001-5-1: §7.4 Controlling SECURITY risks
ISO 14971: §7 Risk control
IEC 62443-4-1: §SR-3
Requirement text
Determine whether security risk control measures are appropriate: select mitigations, determine whether mitigations create new risks, implement mitigations, and verify effectiveness. Document results. Handle residual risks in cooperation with the product risk management process.
Why this clause exists
Identifying and estimating security risks without a formal, structured process for controlling them produces a comprehensive threat register and no change in the actual security posture of the device. Security risk control requires selecting, implementing, and verifying controls — not just documenting threats — and doing so in a structured way that ensures controls are adequate for the estimated risk level. Defense-in-depth (clause 5.3.1) is the architectural expression of risk control; individual controls at each system layer implement the specific mitigations that the threat model requires. IEC 81001-5-1:2021 clause 7.4 requires a formal security risk control activity that produces documented controls for each identified threat, evaluates the residual risk after control application, and determines whether residual risk is acceptable. The residual risk documentation requirement is critical: it creates a record of conscious decisions about what security exposure the organization accepts, rather than allowing residual risk to be invisible in the security risk register. Organizations that control some threats but document no residual risk have either controlled every threat to zero — which is implausible — or have failed to complete the residual risk analysis.
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 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-122 on December 19, 2022 and references it as providing one acceptable framework for satisfying the cybersecurity requirements of Section 524B(b)(2), which requires manufacturers to design, develop, and maintain processes and procedures to provide a reasonable assurance that cyber devices and related systems are cybersecure.
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.
Common gaps (what we see in audits)
- Security controls not verified for effectiveness — Security risk controls are specified (encryption, authentication, access control) but their effectiveness is not verified through adversarial testing. Controls are assumed to work based on implementation rather than demonstrated through penetration testing and fuzzing.