GP-030 Cyber Security Management

Purpose

Defining a standard and systematized approach in security risk management for all products in AI LABS, based on the established practices of the regulatory requirements, standards and guidelines for medical devices.

Scope

This procedure covers the comprehensive management of cybersecurity across the entire Total Product Lifecycle (TPLC) under the MDR (Medical Device Regulation), prioritizing patient safety.

I. Pre-Market (Secure Design) This phase ensures Security by Design and regulatory readiness:

• Design & Risk: Proactively integrate cybersecurity risks into the Risk Management (ISO 14971) system according to GP-013 Risk Management. This requires a Defense-in-Depth strategy and Threat Modeling to ensure Confidentiality, Integrity, and Availability (CIA).
• Planning & Testing: Mandatory establishment of a robust TPLC Cybersecurity Management Plan. Requires rigorous security testing (penetration testing and vulnerability scanning) before market entry.
• Documentation: Must provide minimum security requirements to the customer via labeling and promote the provision of a Software Bills Of Materials.

II. Post-Market (Monitoring & Response) This phase focuses on continuous vigilance and reactive measures:

• Vigilance & Remediation: Maintain an active Post-Market Surveillance (PMS) as described in the GP-007 PMS and Coordinated Vulnerability Disclosure (CVD) system to detect evolving threats. Remediation and updates must be managed commensurate with the risk to the patient.
• Incident Response: Must be prepared with detailed plans and policies to respond to cybersecurity incidents and report to applicable regulatory agencies as described in the GP-004 Vigilance System.

Responsibilities

Role	Responsibility
JD-007 Technology Manager	Application of the present procedure
JD-007 Technology Manager	Redaction of the Security Risk Management Plan
JD-007 Technology Manager	Redaction of the Security Risk Assessment Report
JD-004 Quality Manager & PRRC	Independent review of Risk Management File
JD-003 Design & Development Manager	Approbation for the implementation of the requirements determined from the cyber assessment in the product specification.

Inputs

This procedure is initiated and informed by the following inputs:

• The design of a new medical device or a modification to an existing one, managed through the design and development process (GP-012).
• Information gathered during post-market monitoring, including:
  • Security incidents and vulnerabilities related to AI LABS's products.
  • Vulnerabilities in third-party components used within the products.
  • New threat developments.
• Problem reports generated to document a potential cybersecurity issue.
• Specific elements for risk identification, such as assets, threats, and vulnerabilities.

Outputs

The outputs of this procedure are consolidated within the Cyber Security File[cite: 56], which includes the following documents:

• Software Bills Of Materials: A formal inventory of all software components and dependencies.
• Cyber Security Management Plan: Describes all security risk management activities for a device.
• Cyber Security Risk Matrix: A catalog of all identified security risks and their related controls.
• Cyber Security Assessment Report: Contains the threat model, risk assessment, architecture views, and traceability.
• Cyber Security Risk Testing Report: Describes the cybersecurity testing performed and the results.
• Compliant Incident Response Plan: A documented plan to respond to cybersecurity incidents in accordance with regulatory requirements.

Additional outputs include:

• Safety risks that originate from security risks are identified and created in the Risk File (GP-013).
• User-facing information, such as Instructions for Use, containing cybersecurity cautions and contact information for reporting vulnerabilities will be described in the User Manual.
• Response measures to address identified vulnerabilities, which may include user communications, patches, or product updates.

Development

Cybersecurity activities

Definition of context

Context elements specific to cyber security are recorded in the Cybersecurity Management Plan according to the relevant regulations and standards, including:

• IEC81001-5-1:2021
• ISO 14971: 2019
• ISO 13485:2016 - Medical devices — Quality management systems — Requirements for regulatory purposes, 4.2 Documentation requirements
• EN ISO 13485/A11:2021
• FDA Guide: Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions
• FDA Guide: Select Updates for the Premarket Cybersecurity Guidance (Section 524B of the FD&C Act)
• 21 CFR 820 Quality Management System
• 21 CFR 820.30 Design controls
• 21 CFR 820.180 General requirements
• 21 CFR 820.181 Device master record
• 21 CFR 820.184 Device history record
• Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on Medical Devices, Amending Directive 2001/83/EC, Regulation (EC) No 178/2002 and Regulation (EC) No 1223/2009 and repealing Council Directives 90/385/EEC and 93/42/EEC
• MDCG 2019-16 Guidance on Cybersecurity for medical devices
• MDCG 2023-6 Guidance on Software Updates for Medical Devices
• IMDRF: CYBER Principles and Practices for Medical Device Cybersecurity

Security risk management plan

All activities related to the security risk management process for medical devices are defined in the Cyber Security Management Plan.

The security management plan includes the following activities:

Analysis and Design Stage (Initial Cybersecurity Phases)

• Context and Threat Modeling: Defines the device scope and performs Threat Modeling, identifying all security threats and vulnerabilities that could impact the system.
• Risk Evaluation and Measurement: Evaluates the severity and likelihood of the cybersecurity threats, determining the Inherent Risk before any control measures are applied.
• Risk Treatment and Controls: Designs and implements specific countermeasures (security controls) to mitigate risks, prioritizing the "Secure by Design" approach.
• Security Testing: Plans and executes rigorous tests, such as Penetration Testing and vulnerability scans, to verify the effectiveness of the implemented security controls.
• Residual Risk Acceptance (End of Cyber Stage): Documents the risk that remains after the controls are applied and verified. This level of Cybersecurity Residual Risk marks the end of the cyber risk treatment phase and starts the safety risk assessment phase (patient risks) following the GP-013.

Final Stage and Feedback (Link to Clinical Risk and Post-Market)

Crucial Link with ISO 14971: The Cybersecurity Residual Risk becomes an input for the overall clinical risk analysis according to ISO 14971. At this point, the assessment evaluates whether the materialization of that residual risk could lead to a Harm Condition for the patient and whether that risk is acceptable within the device's Benefit-Risk balance.

Communication and Reporting

Generates the final Cyber Security Assessment Report for inclusion in the Technical File required by the MDR.

Post-Production Monitoring

Establishes the Post-Market Surveillance (PMS) process, defining the frequency for Threat Model review and the mechanism for continuous feedback from cybersecurity incidents (MDR Art. 87/88) and other vigilance findings.

Security risk catalog (Matrix)

The security risk catalog is managed in Cyber Security Risk Matrix and contains the security risks identified in the Cyber Security Assessment Report.

1. Identification of the security risk

For each identified security risk, the team will provide the following initial security risk information:

• Asset: patient data, company asset such as secrets, intellectual property, etc.
• Threat: Description of the threat leading associated adverse impacts affecting confidentiality, integrity, availability of assets.
• Vulnerability: Description of the flaw or weakness in a system's design, implementation, or operation and management such as access, use, disclosure, disruption, modification, or destruction to a degree that the related risks to violation of confidentiality, integrity, and availability are maintained at an acceptable level.
• Existing controls: Description of the measure, mechanism, or action implemented to prevent, detect, mitigate, or respond to security threats and vulnerabilities.
• Consequences: Description of the impacts affecting confidentiality, integrity, availability of assets.

2. Security risk assessment

Then the team evaluates the Initial Likelihood and Initial Severity values according to the ranking system desceribed in Cyber Security Risk Management Plan. The Initial Risk Priority Number (RPN) and Initial Risk Class are deduced then.

3. Security risk treatment

For each security risk, a risk treatment is identified and the corresponding software or regulatory requirements implementing the treatment are referenced. If new safety or security risks are introduced by the treatment, the risks are also referenced. The following fields are set:

• Decision or risk treatment: explains the controls or measures taken to mitigate the security risk.
• SRS issue identifier: list the software and regulatory requirements identifiers implementing the controls or measures.
• New risk: Indicates if a new safety or security risk is introduced by the decision treatment.

Then, the residual evaluation is performed. The team evaluates the Residual Likelihood and Residual Severity values according to the ranking system described in Cyber Security Risk Management Plan. The Residual Risk Priority Number (RPN) and Residual Risk Class are deduced then.

4. Safety risk creation (Patient risk)

The safety risk originating from the security risk after applying the decision/risk treatment is created when the compromise of the system's confidentiality, integrity, or availability causes the device to fail to achieve its intended purpose or its essential safety and performance requirements (GSPRs), leading directly or indirectly to a condition of harm to the patient.

Planning and design

Cybersecurity management is integrated into the general project planning for every product development, according to (GP-012). The subsequent design phase, also defined in the GP-012 procedure, takes into account identified cybersecurity risks and their associated control measures. It also considers compatibility and interoperability requirements, as well as defining requirements for cryptography and access management where applicable.

User information and communication

User-facing materials, including the Instructions for Use, must describe relevant cybersecurity cautions and messages. The effectiveness of these communications is verified as part of the usability process defined in (GP-025).

Additionally, the information provided must include a contact method for cybersecurity-related topics. This allows users to report a discovered IT flaw or vulnerability and to access security updates.

info

For more information about communication refer to (GP-021)

Cyber security file

All documentation related to the process of security risk management is maintained in the Cyber Security File, which contains the following:

• Software Bills Of Materials. The human readable and machine readable Software Bills of Materials (SBOM) for the medical device software. It contains the list of software components, their versions, licenses, and other relevant information.
• Cyber Security Management Plan. This is the Cybersecurity management plan. It describes the activities related to the security risk management process for medical devices such as threat modelling, security risk assessment based on a documented security risk ranking system, risk communication and post-market management.
• Cyber Security Risk Matrix. The list of the cybersecurity risk and their related risk controls.
• Cyber Security Assessment Report. This is the Cyber Security Assessment Report. It contains the threat model, the cybersecurity risk assessment, the assessment of unresolved anomalies, the architecture views and the cybersecurity risk traceability with software requirements and tests cases, and the cyber security controls.
• Cyber Security Risk Testing Report. This document describes the cybersecurity testing performed and the associated test reports. It also provides the cybersecurity risk traceability with software requirements and tests cases.
• Compliant Incident Response Plan. A documented plan to respond to cybersecurity incidents in accordance with regulatory requirements.

The Cyber Security File, is part of the Product Technical File for medical devices and will be updated and reviewed if needed.

Development

During the development phase, cybersecurity weaknesses are actively managed through the following activities:

• Analysis and resolution: Cybersecurity weaknesses are identified using methods such as functional analysis and source code analysis, and all identified weaknesses are resolved.
• Vulnerability Testing: In accordance with the (GP-012) procedure, the development or verification eam designs vulnerability tests. These tests, which are executed during the verification phase, check for known vulnerabilities, the introduction of malware, and the use of non-compliant input data.
• SBOM Maintenance: The Software Bills Of Materials is maintained and kept up to date, with a review occurring at least once a year.

Monitoring

Cybersecurity is monitored during the post-market phase in accordance with the (GP-007) Post-market surveillance procedure. The purpose of this monitoring is to keep IT security up to date based on new information.

All collected information and its associated risks are evaluated to determine if action is required. If applicable, a problem report is generated to document the issue.

Monitoring inputs

The monitoring process actively looks for information regarding:

• Security incidents directly linked to AI LABS's products.
• Security vulnerabilities linked to AI LABS's products.
• Security vulnerabilities linked to third-party components used in AI LABS's products.
• Threat developments, including those related to interoperability and compatibility.

Response measures

Based on the evaluation, measures to fix vulnerabilities and respond to incidents may include:

• Informing users about the identified risk and possible mitigation measures (GP-021).
• Implementing quick fixes.
• Performing server maintenance through the standard process (GP-018).
• Releasing product updates through the design and development process (GP-012).

Changes

Modifications, updates, patches and fixes of AI LABS's products are managed according to (GP-012) and (GP-023), they are carried out as quickly as possible when they impact cybersecurity

Communication

When the level of risk justifies it, communication measures are planned in case of a cybersecurity event. Communications may, but are not limited to:

• Disclosure of a computer vulnerability
• The occurrence of a computer attack
• Confirmation of an incident
• The availability of a patch or update

Data Protection and Privacy

info

This part is managed in the GP-050 Data Protection and GP-052 Data Privacy Impact Assessment (DPIA), and thus the outcome of the Data Protection and Privacy is also recorded in the same records generated during the Data Protection activities.

Data protection and privacy are paramount, especially when dealing with sensitive patient data. Ensuring that all data used and generated by the device is securely handled and stored is a critical aspect of model development. Employing privacy-preserving methods, such as data anonymization, adds an additional layer of security, helping to protect patient privacy and comply with regulatory requirements.

Associated documents

• [GP-007 Post-market surveillance]
• [GP-012 Design, redesign and development]
• [GP-013 Risk management]
• [GP-018 Infrastructure and facilities]
• [GP-021 Communications]
• [GP-025 Usability and Human Factors Engineering]
• Software Bills Of Materials
• Cyber Security Management Plan
• Cyber Security Risk Matrix
• Cyber Security Assessment Report
• Cyber Security Testing Report
• Compliant Incident Response Plan

Signature meaning

The signatures for the approval process of this document can be found in the verified commits at the repository for the QMS. As a reference, the team members who are expected to participate in this document and their roles in the approval process, as defined in Annex I Responsibility Matrix of the GP-001, are:

• Author: Team members involved
• Reviewer: JD-003, JD-004
• Approver: JD-001