Explains how manufacturers meet the cybersecurity-related general safety and performance requirements (GSPRs) in Annex I of the MDR (2017/745) and IVDR (2017/746) across the full device lifecycle, for medical devices and IVDs that include programmable electronic systems or software -- SaMD, embedded software, mobile apps, networked devices, and systems relying on hospital networks or cloud services. Its central principle is that "security is part of safety and risk management," and it distinguishes between (1) built-in security capabilities -- authentication, authorization, integrity protection, logging, backup/recovery, and secure update mechanisms -- and (2) security information that must be documented, covering the operating environment, configuration, accounts, network controls, updates and residual risk. Pre-market expectations include linking threat analysis to the safety risk management file, applying defence-in-depth controls (least privilege, strong identity management, protected communications, audit logging), and defining testable operating-environment requirements. Post-market expectations include active monitoring of vulnerability sources (databases, researcher reports, supplier notices, threat intelligence), risk assessment, coordinated disclosure, security updates and communication to users. The guidance frames cybersecurity as a shared responsibility between manufacturer and healthcare provider, while stressing that a manufacturer cannot transfer its own design and regulatory obligations to the hospital or user, and aligns with IMDRF's international guidance on medical device cybersecurity.

Sets out how manufacturers determine the level of clinical evidence needed for medical device software (MDSW) under the MDR (2017/745) and IVDR (2017/746), built around three components: (1) valid clinical association / scientific validity -- whether the software's output is meaningfully linked, per accepted medical knowledge or peer-reviewed literature, to the targeted clinical or physiological state; (2) technical/analytical performance -- whether the software accurately, reliably and precisely generates the intended output from its input data; and (3) clinical performance -- whether the software yields a clinically relevant result in line with its intended purpose. The required evidence level scales with device classification: MDR Class III and implantable devices generally require clinical investigation data (subject to the Article 61(4)-(6)/(10) exceptions), while IVDR generally requires performance studies regardless of class, unless an alternative evidentiary route is justified. Clinical evaluation is treated as part of the quality management system and as an iterative, ongoing process across the software's lifecycle, supported by Post-Market Clinical Follow-up (PMCF) / Post-Market Performance Follow-up (PMPF) to keep the evidence current. Annex II gives six worked examples -- covering a sleep-quality analyser, an image segmentation tool, a semi-quantitative IVD calprotectin detector, embedded device-driving software, an insulin-pump companion app, and closed-loop ventilator CO2-control software -- illustrating when MDSW can be evaluated independently versus when it must be evaluated jointly with the hardware it drives or influences.