IEC 62304 §9.1 problem reporting and ISO 13485 complaint handling processes already receiving and tracking product issues from multiple sources.
Published vulnerability intake channel (CVD policy), PSIRT-style tracking covering seven defined source categories including security researchers and audit log indicators.
Published CVD policy with intake channel and vulnerability tracking records from all source categories — security issues routed through complaint handling without a dedicated intake are a major gap.
Maps to
IEC 81001-5-1: §9.2 Receiving notifications about VULNERABILITIES
IEC 62304: §9.1 Prepare problem reports
Requirement text
Enable reporting of vulnerabilities to the manufacturer from internal and external entities or via complaint handling. Receive and track to closure reports from: a) security verification and validation testers, b) third-party component suppliers, c) product developers and testers, d) product users (integrators, operators, administrators, maintenance personnel), e) audit event log information, f) security researchers (vulnerability reporters), g) data and notifications about widespread vulnerabilities (per 6.2).
Why this clause exists
Manufacturers who have no formal mechanism for receiving vulnerability notifications from external parties — security researchers, operators, healthcare information sharing and analysis organizations — will systematically learn about vulnerabilities in their products later than organizations that have established intake channels. External vulnerability reporting is a complementary source of intelligence to the proactive monitoring required by clause 6.2.1: monitoring catches vulnerabilities in components by cross-referencing the SBOM; external notifications identify vulnerabilities that arise from the specific product implementation, integration, or deployment — vulnerabilities that only someone who has encountered the product in context might discover. IEC 81001-5-1:2021 clause 9.2 requires that the manufacturer establish a formal mechanism for receiving vulnerability notifications, which is the same requirement expressed in the coordinated vulnerability disclosure (CVD) policy referenced in clause 4.1.7 and explicitly expected by FDA premarket cybersecurity guidance. The two requirements are complementary: clause 4.1.7 defines the disclosure obligation outward to regulators and users; clause 9.2 defines the intake mechanism inward from external reporters.
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)
- No designated intake channel for vulnerability reports — Manufacturers have no published mechanism (security.txt, dedicated email, web form) for external parties to report vulnerabilities. Reports arrive through customer support where they are triaged as product complaints, not security issues, causing delays.