Skip to main content
QMSQMS
QMS
  • Welcome to your QMS
  • Quality Manual
  • Procedures
    • GP-001 Control of documents
    • GP-002 Quality planning
    • GP-003 Audits
    • GP-004 Vigilance system
    • GP-005 Human Resources and Training
    • GP-006 Non-conformity, Corrective and Preventive actions
    • GP-007 Post-market surveillance
    • GP-008 Product requirements
    • GP-009 Sales
    • GP-010 Purchases and suppliers evaluation
    • GP-011 Provision of service
    • GP-012 Design, redesign and development
    • GP-013 Risk management
    • GP-014 Feedback and complaints
    • GP-015 Clinical evaluation
    • GP-016 Traceability and identification
    • GP-017 Technical assistance service
    • GP-018 Infrastructure and facilities
    • GP-019 Software validation plan
    • GP-020 QMS Data analysis
    • GP-021 Communications
    • GP-022 Document translation
    • GP-023 Change control management
    • GP-024 Cybersecurity Risk Management
      • Templates
      • GP-024 Deprecated Cybersecurity
    • GP-025 Usability and Human Factors Engineering
    • GP-027 Corporate Governance
    • GP-028 AI Development
    • GP-029 Software Delivery And Comissioning
    • GP-050 Data Protection
    • GP-051 Security violations
    • GP-052 Data Privacy Impact Assessment (DPIA)
    • GP-100 Business Continuity (BCP) and Disaster Recovery plans (DRP)
    • GP-101 Information security
    • GP-200 Remote Data Acquisition in Clinical Investigations
    • GP-026 Market-specific product requirements
    • GP-110 Esquema Nacional de Seguridad
  • Records
  • Legit.Health Plus Version 1.1.0.0
  • Legit.Health Plus Version 1.1.0.1
  • Licenses and accreditations
  • Applicable Standards and Regulations
  • Public tenders
  • Procedures
  • GP-024 Cybersecurity Risk Management

GP-024 Cybersecurity Risk 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 applies to the Design and Development and Distribution departments participating in the life cycle of medical devices in AI LABS. This procedure also applies to all medical devices placed on the market under the name of AI LABS. It does consider "only" security risks.

Responsibilities​

RoleResponsibility
JD-007 Technology ManagerApplication of the present procedure
JD-007 Technology ManagerRedaction of the Security Risk Management Plan
JD-007 Technology ManagerRedaction of the Security Risk Assessment Report
JD-004 Quality Manager & PRRCIndependent review of Risk Management File
JD-003 Design & Development ManagerApprobation 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:

  • T-024-001 Software Bills Of Materials (SBOM): A formal inventory of all software components and dependencies.
  • T-024-002 Cyber Security Risk Management Plan: Describes all security risk management activities for a device.
  • T-024-003 Cyber Security Risk Matrix: A catalog of all identified security risks and their related controls.
  • T-024-004 Security Risk Assessment Report: Contains the threat model, risk assessment, architecture views, and traceability.
  • T-025-005 Security Risk Testing Report: Describes the cybersecurity testing performed and the results.

Additional outputs include:

  • Safety risks that originate from security risks are identified and created.
  • User-facing information, such as Instructions for Use, containing cybersecurity cautions and contact information for reporting vulnerabilities.
  • Response measures to address identified vulnerabilities, which may include user communications, patches, or product updates.

Development​

Reference documents​

  • 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

Terms and definitions​

  • Regulatory requirements: Regulatory requirements are rules that AI LABS must follow. Means all applicable laws, rules, regulations, orders, requirements, guidelines, interpretations, directives, etc.
  • Software Bill of Materials (SBOM): A formal inventory of software components and dependencies, information about those components, and their hierarchical relationships.

Cybersecurity risk management activities​

Definition of context​

Context elements specific to cyber security are recorded in the GP-024 Cybersecurity Risk Management file folder.

Security risk management plan​

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

The security risk management plan includes the following activities:

  1. Establish the medical device context and perform a threat modelling
  2. Assess the security risk
  3. Treat the security risk
  4. Security risk acceptance evaluation
  5. Security testing
  6. Communicate the security risk assessment report
  7. Perform the post-production monitoring and review

Security risk catalog​

The security risk catalog is managed in T-024-003 Cyber Security Risk Matrix and contains the security risks identified in the security risk assessment.

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 T-024-002 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.
  • New risk issue key: list the safety or security risk identifier of the new risks.

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

4. Safety risk creation​

The safety risk originating from the security risk after appliying the decision/risk treatment is created when the following initial values:

  • Hazard category: Cyber security
  • Summary: A summary of the root or cause, hazardous situation, harm fields
  • Root cause and sequence of events: security risk's Threat field value.
  • Hazardous situation: security risk's Consequences field value.
  • Harm: security risk's Safety risk field value.

Planning and design​

Cybersecurity management is integrated into the general project planning for every product development, according to GP-012 Design, redesign and development. 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 Usability and Human Factors Engineering.

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 Communications

Cyber security file​

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

  • T-024-001 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.
  • T-024-002 Cyber Security Risk 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.
  • T-024-003 Cyber Security Risk Matrix. The list of the cybersecurity risk and their related risk controls.
  • T-024-004 Security Risk Assessment Report. This is the Security Risk 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.
  • T-025-005 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.

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 Design, redesign and development procedure, the development or verification team 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 T-024-001 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 Communications).
  • Implementing quick fixes.
  • Performing server maintenance through the standard process (GP-018 Infrastructure and facilities).
  • Releasing product updates through the design and development process (GP-012 Design, redesign and development).

Changes​

Modifications, updates, patches and fixes of AI LABS's products are managed according to GP-012 Design, redesign and development, 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

Relationships with other risk management processes​

The safety risk management team may be separate from the security risk management team and the usability engineering team. Or they may be in a single team. In any cases, communication is required between safety, usability, and security.

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
  • T-024-001 Software Bills Of Materials
  • T-024-002 Cyber Security Risk Management Plan
  • T-024-003 Cyber Security Risk Matrix
  • T-024-004 Security Risk Assessment Report
  • T-024-005 Security Risk Testing Report
Previous
T-023-001 Change control
Next
T-024-001 Software Bills Of Materials
  • Purpose
  • Scope
  • Responsibilities
  • Inputs
  • Outputs
  • Development
    • Reference documents
    • Terms and definitions
    • Cybersecurity risk management activities
      • Definition of context
      • Security risk management plan
      • Security risk catalog
        • 1. Identification of the security risk
        • 2. Security risk assessment
        • 3. Security risk treatment
        • 4. Safety risk creation
      • Planning and design
      • User information and communication
      • Cyber security file
    • Development
    • Monitoring
      • Monitoring inputs
      • Response measures
    • Changes
    • Communication
    • Relationships with other risk management processes
  • Associated documents
All the information contained in this QMS is confidential. The recipient agrees not to transmit or reproduce the information, neither by himself nor by third parties, through whichever means, without obtaining the prior written permission of Legit.Health (AI LABS GROUP S.L.)