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 Predetermined Change Control Plan
    • GP-025 Usability and Human Factors Engineering
    • GP-027 Corporate Governance
    • GP-028 AI Development
    • GP-029 Software Delivery And Comissioning
    • GP-030 Cybersecurity Risk Management
      • Templates
        • T-030-001 Software Bills Of Materials
        • T-030-002 Cyber Security Risk Management Plan
        • T-024-003 Cyber Security Risk Matrix
        • T-024-004 Security Risk Assessment Report
        • T-025-005 Security Risk Testing Report
        • T-030-008 NIS2-Compliant Incident Response Plan
    • 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
  • Grants
  • Public tenders
  • Procedures
  • GP-030 Cybersecurity Risk Management
  • Templates
  • T-024-004 Security Risk Assessment Report

T-024-004 Security Risk Assessment Report

Scope​

This document covers the security risk assessment report of the medical device.

It contains:

  • The security risk analysis,
  • The security risk assessment report,
  • The security risk traceability matrixes with software requirements and test cases.

Terms and definitions​

TermDefinition
APIA set of rules and protocols that allows different software applications to communicate and interact with each other.
Health Care ProviderOrganization that delivers medical services to individuals
REST APIRepresentational State Transfer Application Programming Interface, a type of web service that allows communication between systems over HTTP.
Security Level (SL)It represents the degree to which a system or component can withstand threats and potential attacks.
Capability Security Level (CSL)It specifies the degree to which a component, such as a device, system or application, meets the security requirements necessary to resist certain threats
Transport Layer Security (TLS)A cryptographic protocol designed to provide secure communication over a computer network. It is widely used to secure communications over the internet.

Risk analysis​

Intended use​

The intended use is available in the Device description and specifications document.

Context of risk assessment​

info

The context of risk assessment is the environment in which the device operates, including the hardware, software, network, and any external systems it interacts with. This context helps to identify potential threats and vulnerabilities that could impact the security of the device.

Assets​

info

Provide a list of assets that are relevant to the device, including hardware, software, data, and any other components that are critical to its operation.

Actors​

info

Actors are individuals or entities that interact with the device, such as users, administrators, and external systems. Identifying actors helps to understand their roles and responsibilities in relation to the device's security.

Diagrams​

Connection diagrams​

The connection diagrams show how the system components are connected together and what are the type connections.

They are available in the section Global System Views of the document T-012-029 Software Architecture Description.

Data flow diagrams​

The data-flow diagrams show the data exchanged between the system components.

They are available in the section Global System Views of the document T-012-029 Software Architecture Description.

Threat model diagram​

info

The threat model diagram provides a visual representation of the potential threats to the system, including the assets, actors, and their interactions. It helps to identify vulnerabilities and assess the risk associated with each threat.

Multi-patient harm view​

The multi-Patient harm view is available in the section view Multi-Patient Harm View of the document T-012-029 Software Architecture Description.

Updatability / Patchability view​

The updatability/patchability view is available in the section Updatability / Patchability View of the document T-012-029 Software Architecture Description.

Security use case views​

The security use case views are available in the section Security Use Case Views of the document T-012-029 Software Architecture Description.

Threat analysis​

info

The threat analysis identifies potential threats to the system and assesses their impact and likelihood. It helps to prioritize security measures and allocate resources effectively.

Threats​

info

Threats are potential events or actions that could compromise the security of the device. They can be categorized into different types, such as external threats (e.g., hackers, malware) and internal threats (e.g., insider attacks, misconfigurations).

Capability Security Level (CSL)​

info

The Capability Security Level (CSL) is a measure of the security capabilities of a component or system. It indicates the level of protection against specific threats and vulnerabilities. The CSL is determined based on the security requirements and the effectiveness of the implemented security controls.

Security risk matrix​

The Security Risk Matrix is available in the document Cyber Security Risk Matrix.

Risk traceability matrixes​

Risks/Software Requirements/Test Cases​

The risk traceability matrix below contains the connections between the risk analysis, software requirements and test plan.

A risk is deemed mitigated when the test status is set to PASSED in the test report.

Security RiskSoftware or Regulatory requirementTest cases
Unique IDKeySummaryKeySummaryKeySummary

Controls category/Risks​

The risk traceability matrix below contains the connections between categories of risk controls and risk controls in the device

IdentifierCategoryRisk ControlComment

Overall assessment of residual security risks​

info

This section should provide a concise and comprehensive summary of the security posture of the product after all risk control measures have been applied. It should clearly articulate the findings from various security assessments and the rationale for the final risk classifications.

Key elements:

  1. Overall Security Posture: High-level statement on attack surface and security from assessments (e.g., penetration testing). Reference detailed reports.
  2. Vulnerabilities & Resolutions: List identified vulnerabilities (e.g., from pen testing, static analysis, SOUP/SBOM). Describe decisions and actions taken (e.g., addressed, upgraded, backlog) with rationale. State if new risks were found.
  3. Component & Code Quality: Summarize SOUP/SBOM analysis and static code analysis (e.g., SonarQube) findings. Confirm if issues impact prod
  4. Residual Risk Classification: State final risk status (e.g., "all acceptable," "X tolerable risks").
    • For Tolerable Risks: List each risk, its control measure, and justification for its sufficiency and tolerability.
  5. Risk Transfer & Responsibilities: Detail transferred risk controls and define responsibilities of manufacturer, healthcare organization, and users (e.g., secure device configuration, network security, IFU adherence).
  6. Safety Risk Link: Briefly state if safety risks linked to security are acceptable post-controls.

Analysis and decisions​

Penetration testing vulnerabilities​

This table provides a short analysis and the decision regarding each vulnerability identified during the penetration testing:

VulnerabilityAnalysisDecision

Risk communication​

Internal communication​

The Overall assessment section and Security Risk Matrix are communicated to the safety risk management team when there are new patient risks introduced by security risks.

The Security Risk Matrix is communicated to the usability engineering team when security risk mitigations may imply usability modifications.

User and institutions​

The Instructions for Use of the device informs the user that the security and cybersecurity policies of their institution should be followed.

Previous
T-024-003 Cyber Security Risk Matrix
Next
T-025-005 Security Risk Testing Report
  • Scope
  • Terms and definitions
  • Risk analysis
    • Intended use
    • Context of risk assessment
    • Assets
    • Actors
    • Diagrams
      • Connection diagrams
      • Data flow diagrams
      • Threat model diagram
      • Multi-patient harm view
      • Updatability / Patchability view
      • Security use case views
    • Threat analysis
    • Threats
    • Capability Security Level (CSL)
  • Security risk matrix
  • Risk traceability matrixes
    • Risks/Software Requirements/Test Cases
    • Controls category/Risks
  • Overall assessment of residual security risks
    • Analysis and decisions
      • Penetration testing vulnerabilities
    • Risk communication
      • Internal communication
      • User and institutions
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.)