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 recognized it as Consensus Standard 13-122 (date of entry December 19, 2022). FDA's February 2026 cybersecurity guidance, Section V, lists IEC 81001-5-1 among the "possible frameworks to consider" for secure product development, and FDA's recognition record for the standard notes that conformance "may not satisfy all the cybersecurity requirements outlined in Section 524B of FD&C Act".
EU MDR harmonization was originally targeted for May 2024 but postponed to May 2028.
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.