R-TF-030-001 Cyber Security Management Plan

Scope

This document contains the security risk management plan for the device. It covers the management all security-related risks during the lifecycle of the device, in design and development, and in maintenance. It also contains the provisions about relationships with the ISO 14971 safety risk management process, and IEC 62366-1 usability engineering process.

Reference documents

Standard and regulatory references

• ISO 14971:2019
• ISO 27005:2022
• IEC 81001-5-1
• IEC 62366-1 :2015
• IEC 62366-2 :2016
• Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions
• Cybersecurity for Networked Medical Devices Containing Off-the-Shelf (OTS) Software
• MITRE EMB3D: Evaluating Medical Device Bidirectional Boundary Defense

Terms and definitions

Term	Definition
Information security risk	Potential that a given threat will exploit vulnerabilities of an asset or group of assets, and thereby cause harm to the organization
Activity	Set of one or more interrelated or interacting tasks
Asset	Physical or digital entity that has value to an individual, an organization or a government
Attack	Attempt to destroy, expose, alter, disable, steal or gain unauthorized access to or make unauthorized use of an asset
Attack Funnel	An EMB3D concept used to model how an attack propagates through the security barriers
Availability	Property of being accessible and usable on demand by an authorized entity
Barrier	In the context of EMB3D, a point of defense or security control that separates assets from threats
Confidentiality	Property that information is not made available or disclosed to unauthorized individuals, entities, or processes
Control	a control refers to any measure, mechanism, or action implemented to prevent, detect, mitigate, or respond to security threats and vulnerabilities. These controls are designed to protect the confidentiality, integrity, and availability of information systems and data
CVSS Score	A numerical score representing the severity of a vulnerability. Used for risk evaluation, replacing RPN
Integrity	property of accuracy and completeness
ISAO	Information Sharing and Analysis Organizations
Process	Set of interrelated or interacting activities that uses inputs to deliver an intented result (outcome)
Security, Cyber security	state where information and systems are protected from unauthorized activities, 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 throughout the lifecycle
Task	single piece of work that needs to be done to achieve a specific goal
Threat	Potential for violation of security, which exists when there is a circumstance, capability, action, or event that could breach security and cause damage to confidentiality, integrity, availability of information assets
Vulnerability	Flaw or weakness in a system design, implementation, or operation and management that could be exploited to violate the system's security policy.
Weakness	Kind of deficiency

Conventions

Security risk and Cyber security risk are used indifferently in this document as synonyms of information security risk according to the definition above.

Responsibilities

Role	Responsibility
JD-007 Technology Manager	Overall security risk management process responsibility
JD-007 Technology Manager	Software security risks
JD-004 Quality Manager & PRRC	Interface with the safety risk management process
Security expert	Perform penetration testing

Risk management process

The risk management process is an iterative process, where the Analysis and Evaluation phases are adapted to the MITRE EMB3D/CVSS methodology.

Context establishment and threat modelling

• Define the assets

• Define the threats

• Define the Security Barriers

Risk assessment

• Identification of existing controls

• Identification of vulnerabilities

• Identification of consequences

Analysis

• Evaluation

• Risk treatment

• Risk acceptance

• Risk communication

Post-production monitoring and review

Context establishment and threat modelling

This phase allows to identify assets and threats based on the device description and specifications.

Establishing the context consists in defining the scope and boundaries, and describing the following items, as appropriate:

• The medical device (hardware, software, network).
• Its accesories,
• Its environment
• The processes involved in the lifecycle of the device:
  • Internal processes
  • Outsourced processes
  • Client/user processes
• The users and user profiles
  • Client users
  • Users of the manufacturer (e.g. support, maintenance, development)
• The level of education of users
• The use cases associated to the users and user profiles
• The types of data handled in the device
  • Medical data
  • Configuration data
  • Logs
• The software network interfaces and protocols
  • HTTP, TCP...
  • REST
• The data input/output streams
• The SOUP used in software
  • Maintained software
  • Supported software (see IEC 81001-5-1)
• The constraints affecting the device
  • On the device
  • On manufacturer processes
  • On user processes
  • Regulatory requirements: GDPR, HIPAA...
• Constraints regarding emergency access to the device for patient safety, bypassing security measures.

Define the assets

An asset is anything of value for the manufacturer or for the end-user. Assets can be:

• Hardware,
• Software,
• Data,
• SW Services in interface with the device,
• SW development platform,
• Other supporting services,
• Other tangible or intangible assets.

Knowing the assets contributes to identify the magnitude of the consequences of an attack.

Define the threats

A threat is anything—whether human, natural, accidental, or deliberate—that could potentially damage one or more assets. Examples include:

• Criminal organizations and advanced persistent threats.
• Inexperienced or malicious users (e.g., patients, caregivers, disgruntled employees).
• Natural events.

Threats are identified based on the established context and are formally documented in a threat model. This model can be described using appropriate methods such as data flow diagrams (DFDs), use cases, or various architectural diagrams (hardware, system, software).

The threat modeling process must account for specific constraints, such as provisions for emergency access that bypass standard security measures. Furthermore, any elements excluded from the scope of this risk management plan must be clearly identified and justified.

Define the Security Barriers

Security barriers are points of defense or security controls that separate assets from threats. They can be physical, technical, or administrative measures implemented to protect assets from potential threats.

Risk assessment

Based on the threat model documented in the previous step, the risks shall be identified, analyzed and evaluated according to the objectives of the risk management process and the ranking system for security risk analysis.

A preliminary risk assessment, together with the threat modelling, may be documented at the beginning of the design project, or before design (e.g. in feasability / mock-up, etc.) and reviewed in the design input data.

Identification of existing controls

All existing and planned controls must be identified. These can be internal to the manufacturer’s organization or exist within external environments, such as those of a healthcare provider or a datacenter service supplier.

Following identification, each control shall be assessed to determine if it is effective, sufficient, and justified.

Identification of vulnerabilities

• Weaknesses may come from design decisions, anticipated misuse of the device, organizations, processes, etc.
• Vulnerabilities can be found in catalogs like:
  • MITRE Common Vulnerabilities and Exposures List
  • CISA Known Exploited Vulnerabilities
  • NIST National Vulnerability Database

Identification of consequences

The analysis shall identify all potential consequences of a security breach. This includes assessing the impact on assets by evaluating any loss of confidentiality, integrity, and availability. Furthermore, all potential consequences for patient safety must be separately identified.

Assets, threats, vulnerabilities, existing controls and consequences shall be recorded in the R-TF-030-004 Cyber Security Risk Matrix.

Analysis

The risk analysis is performed with the use of the ranking system described in the section Ranking system for security risk analysis of this document, and with the data collected in the previous steps:

• The identification of the consequences on assets allow to determine the impact magnitude of the risk,
• The identification of threats, vulnerabilities, and incident scenarios allow to determine the likelihood of a risk.

For each incident scenario, probability of ocurrence, severity, other criteria and RPN are recorded in the R-TF-030-004 Cyber Security Risk Matrix.

Evaluation

The CVSS scores are compared against risk acceptance criteria described in section Ranking system for security risk analysis of this document.

For each incident scenario: risk acceptance class and decision are recorded in the R-TF-030-004 Cyber Security Risk Matrix.

Risk treatment

The term “risk treatment” is used in ISO 27005. Note that the meaning of “risk treatment” is broader than “risk control” or “risk mitigation” commonly used in medical device industry.

For information, risk treatment options are:

• Mitigate (thus risk control): take action to reduce the likelihood that the threat will materialize.
• Eliminate (kind of inherent security by design): simply remove the feature or component that is causing the threat.
• Transfer (kind of information to users): shift responsability to another entity such as the consumer or the integrator of the device.
• Accept (thus, need of information to users): do not mitigate, eliminate or transfer the risk because none of those options are acceptable given business requirements or constraints.

info

Important: Risk transfer and risk acceptance strategies are NOT allowed for security risks that have a potential impact on patient safety. When a security risk could affect patient safety (according to ISO 14971), it must be mitigated or eliminated in the Safaty risk Matrix as described in the GP-013- it cannot be transferred to users or simply accepted.

Risk controls shall be sought in this order of precedence (see AAMI SW96):

• Inherent security by design.
  • Example: Design change in hardware or software, documented in a HRS or SRS
• Inherent security by manufacturing process.
  • Example: Documented process step making use of state-of-the-art security feature, e.g.,use of digital signature to verify the authenticity and integrity of a software installation bundle
• Protective threat mitigation measures added into the medical device.
  • Example: Hardware or software mitigation added to the device, e.g., delivering the device with a firewall
• Protective threat mitigation measures added to the manufacturing process.
  • Example: Documented process step making use of less effective security feature (Compared to inherent security by manufacturing process), e.g., ensuring software authenticity by organizational measure, testing software after install
• Security risk disclosure (i.e., providing needed security information to users) and/or security risk transfer to users.
  • Example: Secure operations guidelines or warnings about secure use of the device, for example, reminder in the Secure operations guidelines to activate security windows updates by default-
• Where appropriate, security training to users.
  • Example: Training to users is deemed poorly effective

Risk control should be carried out to decrease the CVSS score of the residual risk As Low As Reasonably Practicable (ALARP), with economic considerations. If the risk has an impact on patient safety, the risk treatment (risk control) shall be carried out with acceptance criteria related to patient safety.

The security vulnerabilities or impacts on patient safety arising from risk treatment shall also be assessed.

For each incident scenario: the risk treatment plan is recorded in the Security risk assessment report.

Risk acceptance

The reevaluation of the risk is performed with the use of the ranking system described in section Ranking system for security risk analysis of this document and with the risk treatment plan.

A security risk may be deemed accepted even if it doesn't match the risk acceptance criteria of section Ranking system for security risk analysis of this document, with a justification based on the risk/benefit ratio, to override the acceptance criteria.

For each incident scenario: the risk acceptance and justification as appropriate are recorded in the R-TF-030-004 Cyber Security Risk Matrix.

Risk communication

The [R-TF-030-003 cyber Security Assessment Report] and the [R-TF-030-004 Cyber Security Risk Matrix]:

• are communicated internally to the design team,
• shall be agenda items of the design and validation reviews of the software development plan.

Parts of the security risk assessment report may also be communicated externally to service providers or suppliers, as appropriate. When a supplier requires knowledge of the security risk assessment report, it should be determined if this supplier shall be placed in the list of critical suppliers.

Post-production monitoring and review

The Cyber security File is sistematically reviewed and updated, especially when:

• The product is modified
• The context changes
• Assets, threats, vulnerabilities change
• Analysis of data of post marketing surveillance triggers a reevaluation (internal defects, customer requests, maintenance, vigilance bulletins, security incidents, field information from any source).

The review of post-marketing data is performed annually. Reviews and updates to any risk will be documented, approved, and included within the Cyber security File. This review should include an evaluation of the relevance of the ranking system and the need to update it upon business or regulatory context.

Ranking system for security risk analysis

This section describes how cybersecurity risks are evaluated using the MITRE framework and CVSS (Common Vulnerability Scoring System) methodology:

MITRE Framework Integration

The risk assessment process leverages the following MITRE resources:

• CVE (Common Vulnerabilities and Exposures): Standardized identifiers for known vulnerabilities
• CWE (Common Weakness Enumeration): Classification system for software weaknesses and vulnerabilities
• CVSS (Common Vulnerability Scoring System): Industry-standard method for assessing the severity of vulnerabilities

CVSS Scoring Methodology

The CVSS score is calculated based on three metric groups:

Base Metrics

Base metrics represent the intrinsic characteristics of a vulnerability that are constant over time and across user environments:

• Attack Vector (AV): Network, Adjacent, Local, or Physical
• Attack Complexity (AC): Low or High
• Privileges Required (PR): None, Low, or High
• User Interaction (UI): None or Required
• Scope (S): Unchanged or Changed
• Confidentiality Impact (C): None, Low, or High
• Integrity Impact (I): None, Low, or High
• Availability Impact (A): None, Low, or High

Temporal Metrics (Optional)

Temporal metrics reflect characteristics that may change over time:

• Exploit Code Maturity: Unproven, Proof-of-Concept, Functional, High
• Remediation Level: Official Fix, Temporary Fix, Workaround, Unavailable
• Report Confidence: Unknown, Reasonable, Confirmed

Environmental Metrics (Optional)

Environmental metrics represent characteristics relevant to a specific user's environment:

• Modified Base Metrics: Adjusted based on local environment
• Confidentiality/Integrity/Availability Requirements: Low, Medium, High

CVSS Score Interpretation

CVSS scores range from 0.0 to 10.0, with higher scores indicating greater severity:

CVSS Score Range	Severity Rating	Risk Level
0.0	None	Informational
0.1 - 3.9	Low	Acceptable
4.0 - 6.9	Medium	Tolerable
7.0 - 8.9	High	Unacceptable
9.0 - 10.0	Critical	Unacceptable

Risk Acceptability Criteria

Risk acceptability is determined based on the CVSS score and the EMB3D threat model analysis:

• Acceptable (CVSS 0.1-3.9): Risks can be accepted with documentation
• Tolerable (CVSS 4.0-6.9): Risks require mitigation controls; residual risk must be justified and documented
• Unacceptable (CVSS 7.0-10.0): Risks must be mitigated before release; cannot be accepted unless risk/benefit analysis demonstrates clear patient benefit outweighing the risk

CWE Classification

All identified vulnerabilities are classified using CWE categories to ensure comprehensive understanding and appropriate remediation:

• CWE-20: Improper Input Validation
• CWE-79: Cross-site Scripting (XSS)
• CWE-89: SQL Injection
• CWE-200: Exposure of Sensitive Information
• CWE-264: Permissions, Privileges, and Access Controls
• CWE-287: Improper Authentication
• CWE-352: Cross-Site Request Forgery (CSRF)
• And other relevant CWE categories as applicable

Documentation Requirements

For each identified vulnerability, the following shall be documented:

• CVE identifier (if applicable)
• CWE classification
• CVSS Base Score
• CVSS Temporal Score (if temporal metrics are used)
• CVSS Environmental Score (if environmental metrics are used)
• Impact on confidentiality, integrity, and availability
• Proposed mitigation factors
• Residual risk after mitigation

Communication

Communication with Safety risk management team

Communication with the Safety risk management team shall be performed in a timely manner when:

• A security risk has a potential impact on safety
• Security controls may affect safety
• A security incident may affect safety

In case of security incident, which may affect safety, the information shall be immediately reported to the person in charge of medical device reporting.

If a security risk has a potential impact on safety, the safety risk management team shall be informed to perform the safety risk assessment and the metodology used is decribed in the GP-013 Safety Risk Management Process.

Security testing

Security testing is conducted throughout the device lifecycle, including during design modifications and after market release, to verify and validate the effectiveness of security controls. These activities may be performed by internal teams or third-party security experts. The design and development process is centralized in the GP-012 Software Development Process but if any change affects security, the security risk management process must be updated accordingly.

Verification and traceability

All cybersecurity-related requirements are tested according to the organization's established verification and validation (V&V) processes as described in the GP-012 Software Development Process. To ensure full traceability, each security requirement must be linked to a specific test case within the corresponding unit or integration test plan. The execution of these tests provides the supporting evidence needed to confirm that security functionality is implemented correctly.

Overall residual security risk acceptability

Overall residual security risk acceptability is based on the following items:

• The intended context of use and threat model
• Design considerations pertaining to security risks and unclosed weaknesses (can be backed by architecture design charts, design reviews, and traceability matrixes b/w mitigation actions and HW/SW requirements specifications)
• The acceptability level of each residual risk based on CVSS scores
• The presence of unresolved anomalies with possible security consequences
• The presence of unclosed vulnerabilities (especially vulnerabilities in COTS/SOUP, and vulnerabilities identified lately in the design, like in pen tests)
• The impact (or absence of impact) of security risks or their mitigation on safety risks or usability
• When some security risks are tolerable or non-acceptable, the security risk vs clinical benefit ratio

CVSS Acceptance Criteria

A residual security risk is considered acceptable when the CVSS score after implementation of mitigation measures is less than 7.0. This threshold ensures that only Low (0.1-3.9) and Medium (4.0-6.9) severity vulnerabilities remain in the final product.

Vulnerabilities with CVSS scores of 7.0 or higher after mitigation are considered unacceptable and require additional controls or risk transfer/acceptance justification based on risk/benefit analysis.

Safety Risk Conversion Process

Once a security risk has been determined to be acceptable from a cybersecurity perspective (CVSS < 7.0), it shall be analyzed to determine if it could potentially impact patient safety:

1. Safety Impact Assessment: Each accepted cybersecurity risk shall be evaluated to determine if it could lead to a hazardous situation or harm to patients, users, or other persons.

2. Risk Transformation: If the security risk is determined to have a potential safety impact:

   • The security risk shall be transformed into a safety risk
   • A safety risk assessment shall be performed according to ISO 14971 and documented in the Safety Risk Management File (following GP-013 Safety Risk Management Process)
   • A unique Safety Risk ID shall be assigned

3. Cross-Reference Documentation: In the R-TF-030-004 Cyber Security Risk Matrix:

   • The original cybersecurity risk entry shall be maintained
   • The Safety Risk ID shall be recorded in the cybersecurity risk matrix to establish traceability
   • The safety risk assessment conclusion shall be referenced

4. Dual Management: Risks with both cybersecurity and safety implications shall be managed under both risk management processes:

   • Cybersecurity controls address the vulnerability exploitation
   • Safety controls address the potential harm to patients
   • Both risk management files shall cross-reference each other

This process ensures that all potential safety implications of cybersecurity vulnerabilities are properly identified, assessed, and controlled according to the appropriate regulatory framework.

The overall security risk acceptability discussion should be recorded in the R-TF-030-003 Security Assessment Report.

Post-market management

Review, analysis and decision

The following activities are performed annually when devices are placed on the market:

• Review production and post-production information related to security,
• Analyze information to identify the need to update the threat model, reassess security risks and potential safety impact:
  • On the device subject of information,
  • On other devices in our product portfolio,
  • On COTS/SOUP used with these devices,
  • On third party systems interfaced with these devices, as appropriate.

And, if needed:

• Update the threat model,
• Perform the security risk reassessment,
• Communicate to the safety team potential safety impact,
• Trigger the coordinated vulnerability disclosure process,
• Decide to release a security patch or minor update on device software,
• Communicate the issue(s) to third party systems owners.

The reassessment shall include (but not limited to):

• The relevance of the threat model,
• The effectiveness of existing security controls,
• The acceptable level of pre-market residual vulnerabilities,
• New or revised vulnerabilities or weaknesses.

Customers

Customer may report product security concerns according to the described in GP-014 Feedback and complaints either because of a security incident or from testing and monitoring conducted at their own facilities.

Security researchers

Security researchers may report vulnerabilities to AI LABS via public-facing channels. When such reports are received, the product security incident must be formally documented and assessed in accordance with the GP-017 Technical assistance service. Prompt notification to the appropriate cross-functional team is required to ensure timely evaluation and response.

CISA Known Exploited Vulnerability Catalog

On a recurring basis—at least once a month—the CISA Known Exploited Vulnerabilities (KEV) database shall be reviewed for any new vulnerabilities that could affect the device. It will be accessed to this website https://www.cisa.gov/known-exploited-vulnerabilities-catalog and examined the catalog for newly listed vulnerabilities relevant to the components used in the solution. If a relevant new vulnerability is identified, the Incident Response Plan must be initiated, beginning with the initial evaluation and triage of the vulnerability.

Information Sharing and Analysis Organizations (ISAO)

ISAOs play a crucial role in the sharing of threat intelligence and vulnerabilities among organizations. AI LABS participates in ISAO initiatives to stay informed about emerging threats and vulnerabilities that could impact the device.

National Vulnerability Database (NVD)

The NVD is a comprehensive repository of known vulnerabilities. AI LABS regularly monitors the NVD for vulnerabilities that may affect the device, ensuring that any relevant vulnerabilities are addressed promptly.

Post market surveillance methods

The following internal processes are used to collect security issues:

• CAPA system (see GP-004 Corrective and Preventive Action),
• SOUP security issues,
• Servicing or maintenance reports by product support team,
• Cybersecurity metrics
• Security incident reports (see GP-017 Technical assistance service),

The report of the periodic security risk testing should be recorded in R-TF-030-005 Security Risk Testing Report.

Coordinated vulnerability disclosure

AI LABS's coordinated vulnerability disclosure process is composed of 4 steps:

1. Receive the vulnerability report
2. Identify the vulnerability
3. Communicate to the submitter the findings and outcome of his vulnerability report
4. Report the vulnerability to customers, ISAO and FDA

complete

AI LABS's policy and procedure for Coordinated Vulnerability Disclosure for AI LABS is published on ...

Receive the cybersecurity issue from the submitter

A report concerning a vulnerability is received via e-mail. E-mail reports are received at support@legit.health.

As explained in the AI LABS policy and procedure, the report should contain the following information:

• Contact information of the submitter (e.g., name, address, phone number)
• Date and method of discovery
• Description of potential vulnerability
• Product name
• Version number
• Configuration details
• Steps to reproduce
• Tools and methods
• Exploitation code
• Privileges required
• Results or impact

The support team is responsible for:

• Creating a security support request in Github to track the vulnerability report
• Sending a confirmation of receipt of the report to the submitter within 48 working hours
  • This is not a confirmation of the validity of the leak by confirmation of the start of the investigation
• Notifying the CTO about the security support request so that the CTO can start the identification of the vulnerability

Identify the vulnerability

The CTO and his team try to verify the suspected vulnerability based on the information provided in the security support request. They create a dedicated task as an Github issue in order to trace all the performed verifications. The CTO and his team perform their verification based on the available sources of information listed in Threat monitoring section. The verification phase leads to determine the legitimacy and seriousness to the reported vulnerability.

If the reported vulnerability is legitimate, the exploitability and severity of patient harm are assessed in order to determine if the risk is controlled (acceptable) or uncontrolled (unacceptable):

• If the risk is uncontrolled, an Out-of-Cycle Patch Cycle is engaged
• If the risk is controlled, the patch will be integrated in a Regular Patch Cycle

The verification may also identify remediation actions that may include complete solutions to remove the cybersecurity vulnerability from the device or compensating controls that adequately mitigate the risk.

The verification may also lead to the following outcome that terminates the investigation:

• Double reporting: The problem is as previously reported and is already being handled via a Coordinated Vulnerability Disclosure procedure, via some other incident handling procedure, via scheduled maintenance, or is already remedied.
• Out-of-date: The vulnerability is only present in a version of the device that is no longer supported by the organisation.
• Non-security vulnerability: The reported vulnerability has no implications for data or patient security or is no capable of abuse using existing techniques.
• Third party vulnerability: The vulnerability is present in the product or service of a third party. In consultation with the submitter, contact may be made with the third party.

Finally, the verification could may lead to a Can not reproduce situation: It has not been possible to reproduce the vulnerability based on the report information.

Communicate to the submitter the findings and outcome of his vulnerability report

Once the verification of the vulnerability is completed, the support team informs the submitter of the findings depending on the verification outcome:

• The support team informs the submitter why the investigation has been terminated and the actions he/she may take based on the reason of termination (known remediations, update the version of the device, etc.).
• The support team informs the submitter that more information (evidence) is required by AI LABS to prove this is a patient and/or security problem
• The support team informs the submitter that the validity of its report and the next steps in the investigation or about the remediation development plan

The remediation development plan is started from this step.

Report the vulnerability to customers, ISAO and FDA

If the vulnerability leads to an uncontrolled risk and there is no known serious adverse event, AI LABS communicates the vulnerability no later than 30 days after learning of the vulnerability to:

• the customers by email
• the ISAO by email: Health-ISAC

The communication:

• describes the vulnerability including the impact assessment according to AI LABS's understanding of the report
• explains AI LABS's effort to address the risk of patient harm as quick as possible
• describes the interim compensating controls, if any
• explains the remedation development plan to bring the residual risk to an acceptable level

In the case there is a known serious adverse event or AI LABS was unable to communicate about the uncontrolled risk before 30 days the AI LABS will report the vulnerability to the FDA according to 21 CFR part 806.

Timelines to develop and release patches

There are 2 timelines identified:

1. A vulnerability leading to an uncontrolled risk, the Out-of-Cycle Patch Cycle is engaged.
2. A vulnerability leading to a controlled risk, the Regular Patch Cycle is engaged.

Both are described below.

Regular Patch Cycle (Planned Updates)

The device will follow a regular patch cycle every 6 months, in which AI LABS will release cumulative security updates and software improvements. This schedule balances the need for timely security updates with operation feasibility, minimizing disruption to users.

Out-of-Cycle Patch Cycle (Emergency Updates)

In the event of identifying an uncontrolled risk, an out-of-cycle security patch will be released within 7 to 60 days, depending on the severity and complexity of the issue. This rapid response is crucial for maintaining the security and safety of the device in a dynamic threat environment.

The 7-day window is reserved for vulnerabilities with known exploits in the wild or that could severely impact device functionality, while the 60-day window is for vulnerabilities that require more complex testing and validation to ensure the patch does not introduce new risks.

Emergency patchs will be treated as high priority changes and will expedite the review and approval process.

Software development process (changes implementation)

All security related changes will be subject to the organization's established change control process (outlined in GP-023 Change control management). The urgency and complexity of the change will determine the appropriate way to declare change control depending on the required resolution time described above.

• Regular Patch Cycle
  • Integration into Software Roadmap: regular patch will be included in the overall software roadmap
  • Existing Change Control: regular patch cycle will be included in existing Change Control record accordingly to the roadmap
• Out-of-Cycle Patch Cycle
  • Existing Change Control : if the closure time of the current change control is compatible with the required resolution time, the emergency patch could be incorporated as a new change within the existing record
  • New Change Control: if the existing change control is nearing completion or if the emergency patch requires a significant deviation from the original plan, a new change control record will be created
  • Prioritization: emergency patches will be treated as high-priority

Once a change control is approved, the software development team will follow the software development plan to implement the changes (as outlined in T-012-023 Software Development Plan). This includes design, risk assessments, development, verification and validation. It's important to mention that any patch, whether regular or emergency, will undergo rigorous testing to ensure it doesn't introduce new vulnerabilities or impact device functionality.

Release and Commissioning

We deploy all updates to our servers using the Semantic Versioning (SemVer) standard. The version number is formatted as $MAJOR.MINOR.PATCH$.

• $MAJOR$ ($X$): Incremented for incompatible API changes (breaking changes).
• $MINOR$ ($Y$): Incremented for new, backward-compatible functionality.
• $PATCH$ ($Z$): Incremented for backward-compatible bug fixes.

Our API endpoints are versioned using the $MAJOR$ and $MINOR$ numbers, like so: https://api.example.com/vX.Y/

Patch Releases ($X.Y.Z -> X.Y.Z+1$)

This is the standard method for deploying urgent, out-of-cycle, and regular security fixes that are fully backward-compatible and require no changes to the API contract.

• Description: Patches are for critical security updates and bug fixes that are applied directly to the existing codebase without altering its external behavior.
• Impact: No client-side action is required.
• Reasoning: The update is applied to the active API endpoint (e.g., api/v1.2/). All client integrations pointing to this version automatically benefit from the security fix without any modification or downtime.

Minor Releases ($X.Y.Z -> X.Y+1.0$)

This method is used when a security fix necessitates adding new, backward-compatible functionality or altering the API contract in a non-breaking way.

• Description: A minor release is required when the resolution for a vulnerability involves, for example, adding a new, more secure endpoint or enriching an existing one with new security-related fields.
• Impact: Client action is required to adopt the security enhancements.
• Reasoning: The enhanced, more secure version is deployed as a new API endpoint (e.g., api/v1.3/). To receive the security benefits, clients must update their integration to target this new endpoint. The previous endpoint (e.g., api/v1.2/) will remain operational for a transition period but will not contain the security improvements of the new version.

Communication

In the case of releasing a patched version to mitigate an uncontrolled risk, an email is sent to the customers to confirm the vulnerability previously identified has been fixed in the upcoming version.

In other case, for regular patch, the communication will follow the common process as stated in the GP-021 Communications.

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