ISO 13485 design review process and IEC 62304 requirements review covering functional requirement quality criteria.
Multi-disciplinary security requirements review with four required disciplines, documented reviewer independence level, and explicit testability verification per each requirement.
Review record with all four disciplines represented and independence level documented — single-team reviews without security advisor participation are a routine finding.
Maps to
IEC 81001-5-1: §5.2.2 SECURITY requirements review
Requirement text
The manufacturer shall establish an activity (or activities) for ensuring that security requirements: a) implement product requirements including those relating to risk control; b) do not contradict one another; c) are expressed in terms that avoid ambiguity; and d) are stated in terms that permit establishment of test criteria and performance of tests. The manufacturer shall document the level of independence of the reviewers. Each of the following representative disciplines shall participate: architects/developers, testers, cross-functional/clinical experts, and security advisors.
Why this clause exists
Security requirements review is the first formal verification gate in the security lifecycle and the most cost-effective place to catch deficiencies: a missing authentication requirement identified during requirements review costs hours to address; the same deficiency discovered during penetration testing costs days to remediate and weeks to re-test. Organizations that treat security requirements review as a rubber-stamp sign-off — or that skip it entirely — systematically ship products with security gaps that trace back to requirements-phase omissions. IEC 81001-5-1:2021 clause 5.2.2 requires a formal review of security requirements before development proceeds, ensuring that the requirements are consistent, complete relative to the threat model, and verifiable. The review must be performed by personnel with appropriate security expertise — a constraint that prevents the review from being absorbed into a functional design review conducted by engineers without security training. FDA premarket guidance explicitly expects evidence of requirements review with qualified reviewers in cybersecurity documentation packages.
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 requirements reviewed by same team that wrote them — Security requirements are reviewed internally by the same development team without independent security review. Requirements may be technically sound but miss threat scenarios that only a security specialist would identify.