GP-018 Infrastructure and facilities

info

This procedure is developed in accordance with ISO 13485:2016, specifically:

• 6.3 Infrastructure — Document requirements for infrastructure (hardware, software, supporting services) and maintenance activities.
• 6.4 Work environment — Document requirements for the work environment needed to achieve conformity to product requirements.

Procedure flowchart

Purpose

To define the methodology for the acquisition, maintenance and incident control of the company's facilities and devices, in accordance with the requirements established by the organisation.

Scope

All company facilities and devices, including physical hardware and cloud resources.

Responsibilities

JD-001 and JD-003

• To approve the acquisition of new facilities and devices and their corresponding infrastructure control plan.

JD-004

• To ensure that the acquisition, risk assessment and control plan creation process follows the methodology established in this procedure.
• To verify that all maintenance activities are being carried out and to record any non-conformities that may affect the proper functioning of the processes.

JD-005

• To coordinate the maintenance tasks of each infrastructure element and generate the corresponding records.
• To coordinate the correction and documentation of detected incidents according to the defined plan.

JD-007

• To perform the activities described in this procedure and record the corresponding evidence.

Inputs

• Requirements for the new infrastructure element.

Outputs

• The new physical device or AWS resource.
• T-018-001 Infrastructure list and control plan
• T-018-002 Infrastructure and facilities incidents log
• T-018-004 Backup verification record

Development

info

As defined and validated in the R-002-007 Process validation card 2023-005, top management decided to implement remote work for all employees. The infrastructure and facilities described in this procedure have been designed accordingly.

Infrastructure identification

The company's facilities and equipment are identified with an alphanumerical code and registered in the T-018-001 Infrastructure list and control plan. This record maintains a list of all infrastructure elements, including their location and intended use within the established processes.

The company handles two types of infrastructure elements:

• Physical devices — Laptops and mobile devices.
• Cloud resources — Services provided by AWS.

Each element is associated with its corresponding access control policy and risk assessment, as detailed in the sections below.

Work environment

Since all employees work remotely, the work environment is defined by the physical devices and connectivity available to each team member. The following minimum requirements must be met.

note

Because the company's product is a Software as a Medical Device (SaMD), there is no physical contact between personnel and the product. Consequently, the requirements of ISO 13485:2016 clause 6.4.2 (Contamination control) are not applicable to this organisation and are excluded from this procedure.

Minimum hardware requirements

The laptops of company staff must have at least the following specifications:

Characteristic	Requirement
Microprocessor	Intel® Core™ i5 / M1 (MacBook)
RAM	8 GB
Hard disk	256 GB (SSD)
Video graphics	Intel® UHD Graphics 620, Integrated
Display	13-inch display

Any equipment that does not meet these specifications must be validated for use by JD-003.

Connectivity requirements

Each remote worker must have an internet connection of at least 50 Mb/s. The hiring and maintenance of this connection is the responsibility of the remote worker.

Infrastructure access control

Access to all company resources is governed by a minimum access policy: each user is granted only the permissions strictly necessary to perform their authorised activities. The specific procedures for granting and controlling access are described below.

Physical devices

Each physical device is currently assigned to a single team member — there are no shared devices. For management purposes, each device must have (where possible) two accounts:

• A user account belonging to the assigned team member, with the minimum permissions necessary for their work.
• An administration account for device management, including the management of user accounts.

AWS resources

The company uses several AWS resources for its activities. Unlike physical devices, these resources may be accessed by multiple team members. Cloud resources fall into the following categories.

AWS console users

Team members who require access to the AWS console have a user account within the company's AWS account. Each user belongs to one of the following groups:

• Administrators — Full access to all resources defined within the AWS account.
• Developers — Access to a subset of resources required for their tasks.

Every AWS account has the following security controls enabled by default:

• AWS CloudTrail — Records all API calls and management actions, enabling operational and risk auditing, governance and compliance monitoring.
• Multi-factor authentication (MFA) — Requires a second authentication factor in addition to the password, providing an extra layer of identity verification.

Resources managed through remote access

For resources that team members access remotely (e.g. EC2 instances), the process for granting access is described in SP-018-001 Remote infrastructure control access policy.

Access to these resources is logged by the operating system. For example, on Linux instances, authentication logs are stored in /var/log/auth.log.

Resources managed from the AWS console

Resources such as Lambda functions, ECR repositories, ECS services, S3 buckets, RDS databases and API Gateways are managed directly through the AWS Management Console (or via the AWS CLI/SDK). Access to these resources is controlled through IAM policies attached to the user groups defined above.

The process for creating, configuring and decommissioning these resources is described in SP-018-002 AWS console-managed resources procedure.

Information and data safety

Device security

All managed Mac devices have disk encryption (FileVault 2) enabled. Access to all computer systems is controlled through username and password authentication, which must provide verification of the user's identity.

Password management

All users have access to the Passbolt password manager. They receive security training on its use and are strongly encouraged to use it for all credentials. Each user has access to their own private vault and to shared vaults where applicable.

Documents and source code

Documents are stored on Google Drive. Source code is managed through GitHub and Bitbucket using Git version control. We rely on their backup procedures to ensure data integrity.

The use of these platforms also enables local back-up of source code on each developer's machine.

Email

The company's email is managed through Google Workspace (Gmail). Key policies include:

• Emails moved to trash are permanently deleted after 30 days.
• All email accounts are personal with non-shared credentials. Administrators cannot access employees' emails.
• Generic addresses (e.g. contact@…) are implemented as groups to which individual users are added.
• A second authentication factor is mandatory for Google accounts. This second factor is stored in Passbolt.

Anti-virus protection

No antivirus software is enforced on computers or servers. Downloads from Google Drive are tested for viruses by the platform.

Email spoofing protections are enforced via SPF, DKIM and DMARC.

Data backup and restoration

Physical devices

All company work is carried out using cloud-based tools. Documents, spreadsheets and other files are created and stored in Google Drive, ensuring they are automatically saved and versioned. Source code and related assets are managed through GitHub and Bitbucket repositories.

As a result, no critical data resides exclusively on a physical device. The only data at risk of loss is work that has not yet been committed to a repository or saved to Google Drive (e.g. uncommitted local code changes). Team members are responsible for committing and pushing their work regularly to minimise this risk.

AWS resources

The following backup mechanisms are in place for the company's AWS infrastructure:

Resource	Backup mechanism	Recovery capability
S3	Versioning enabled on all buckets	Any previous version of an object can be restored at any time
RDS	Automated backups with point-in-time recovery	Database can be restored to any point within the last 5 minutes
EBS	Daily automated snapshots	Volumes can be restored from the most recent daily snapshot

JD-007 is responsible for verifying that these backup mechanisms remain active and correctly configured as part of the maintenance tasks defined in the infrastructure control plan. Any failure in backup processes shall be documented as an incident in accordance with the incidents control plan defined in this procedure.

In addition to continuous monitoring, a formal verification of all backup mechanisms is conducted every 3 months. During this review, JD-007 checks that every applicable resource has its corresponding backup mechanism enabled (S3 versioning, RDS automated backups and EBS snapshots). The results are documented in the T-018-004 Backup verification record, which lists each resource together with the evidence of its backup status. This quarterly review shall be scheduled in the Quality Calendar and conducted in January, April, July, and October of each year.

Operational resiliency and monitoring

The organisation applies the following measures to ensure the operational resiliency and continuous monitoring of its AWS infrastructure.

Data durability

All S3 buckets used for storing application data, backups or audit logs have versioning enabled. This ensures that previous versions of objects are retained and can be recovered in the event of accidental deletion or overwriting.

Metrics and monitoring

The core AWS services — EC2 instances, RDS databases and ECS clusters — push operational metrics to Amazon CloudWatch. The key metrics monitored include:

Service	Metrics
EC2	CPU utilisation, network traffic, disk I/O
RDS	CPU utilisation, free storage, database connections
ECS	CPU and memory utilisation, running task count

Alerting

CloudWatch Alarms are configured on the core services to detect deviations from normal operation and potential failures. These alarms cover, at a minimum:

• High CPU or memory utilisation thresholds.
• Low available storage on RDS instances.
• Unexpected drops in running ECS task count.
• Elevated error rates or latency in API endpoints.

In addition, custom CloudWatch Synthetics canaries are implemented for the most critical services. These canaries periodically execute automated checks that simulate end-user interactions, enabling early detection of availability or performance degradation before it impacts users.

When an alarm or canary failure is triggered, a notification is sent to the responsible team members. Any incident detected through these mechanisms shall be documented in accordance with the incidents control plan defined in this procedure and, where applicable, handled as a non-conformity per GP-006.

Infrastructure risk analysis

JD-005 is responsible for analysing the criticality of failure modes for each infrastructure element. The risk analysis follows the methodology defined in GP-013 Risk management.

For infrastructure elements, the probability values represent the likelihood that the equipment or infrastructure may fall out of control if the planned control actions are not carried out. The severity values represent the impact on the final product. Based on the risk level established in the T-013-002 Risk Management Record, an appropriate level of control is applied.

The risk analysis recorded in the T-013-002 Risk Management Record must be updated whenever the specifications initially evaluated change, regardless of the risk level previously assigned.

Infrastructure control plan

The T-018-001 Infrastructure list and control plan contains information about the maintenance and incident control tasks planned for each element. When corrective maintenance actions are taken, their status is updated in the list, and relevant evidence (delivery notes, contracts, intervention reports, invoices, etc.) is stored in the appropriate location. Unsatisfactory results shall be handled in accordance with GP-006 Non-conformity. Corrective and preventive actions.

Maintenance plan

The maintenance plan for each resource listed in T-018-001 Infrastructure list and control plan must include:

• The access control for the resource, specifying the users or groups that have access to it, or the owner in the case of a physical device.
• The location of the access records generated for the resource. This location must be a file within the resource itself or an S3 bucket. Only administrators shall have access to these audit logs.
• A set of records documenting each maintenance task carried out on the device, including the type of action and the completion date.

Maintenance tasks for physical devices

Task	Code	Max. periodicity
Installation of security updates	PD-MT-001	1 month
Execution of Windows Defender Scan (only Windows devices)	PD-MT-003	1 month
Review of installed applications	PD-MT-004	6 months
Check disk encryption is enabled	PD-MT-005	1 year
Hardware check / Memory RAM / Free space available	PD-MT-006	1 year

Maintenance tasks for cloud instances

Task	Code	Max. periodicity
Installation of security updates	CI-MT-001	1 month
Hardware check / Memory RAM / Free space available	CI-MT-002	1 month
Manual review of access logs	CI-MT-003	1 month
Manual review of performance metrics	CI-MT-004	1 month

Maintenance tasks for self-managed resources

Task	Code	Max. periodicity
Manual review of access logs	SMR-MT-001	1 month
Manual review of performance metrics	SMR-MT-002	1 month

JD-004 is responsible for verifying that all maintenance activities are being carried out in accordance with the T-013-002 Risk Management Record, and for recording any non-conformities that may affect the proper functioning of the processes.

Incidents control plan

The incidents control plan comprises the list of possible incidents related to each infrastructure element together with the record of all incidents that have occurred.

Each incident must include the following information:

• Code, with the format I-XXXX, where XXXX is an incremental numeric identifier starting from I-0001.
• The date and person reporting the incident.
• A description of the incident.
• A record of the actions taken to resolve it.
• The date the incident was resolved.

The incident log follows the structure below:

Incident code	Reported by	Description	Actions required	Reported date	Solved at
I-XXXX

Audit log monitoring and review

In addition to the maintenance tasks defined above, a formal periodic review of audit logs is conducted to ensure the security and integrity of the infrastructure. This review process is essential for detecting unauthorised access attempts, security anomalies and verifying compliance.

Scope of audit log review

The audit log review covers the following log sources:

Log source	Location	Description
AWS CloudTrail	AWS Console / S3 bucket	Records all API calls and management actions in AWS
Application logs	S3 bucket / CloudWatch	Application-level events and errors
Database logs	RDS / CloudWatch	Database access and query logs
Linux auth logs	/var/log/auth.log	Authentication events for Linux instances

Review frequency and responsibility

Activity	Responsible	Frequency
Comprehensive audit log review	JD-004 / JD-005	Semi-annual (every 6 months)
Security alert triage	JD-007	As alerts are generated
Incident-triggered review	JD-004	As needed

The semi-annual comprehensive review shall be scheduled in the Quality Calendar and conducted in January and July of each year.

Review process

The audit log review process consists of the following steps:

1. Log collection: Gather logs from all sources listed above for the review period.
2. Anomaly detection: Identify unusual patterns such as:
   • Failed authentication attempts
   • Access from unusual locations or IP addresses
   • Unauthorised resource access attempts
   • Unusual API call patterns
   • Privilege escalation attempts
3. Compliance verification: Verify that access controls are being enforced according to SP-018-001 Remote infrastructure control access policy.
4. Findings documentation: Document any findings, anomalies or security concerns in the T-018-003 Audit Log Review Record.
5. Action determination: For any significant findings:
   • Minor findings: Document and monitor.
   • Significant findings: Raise a non-conformity per GP-006.
   • Critical findings: Immediate escalation to JD-001 / JD-003.

Documentation requirements

Each semi-annual review must be documented using the T-018-003 Audit Log Review Record, which captures:

• Review period and date.
• Reviewer identification.
• Log sources reviewed.
• Summary of findings.
• Actions taken or recommended.
• Sign-off by responsible personnel.

Associated records

• GP-006 Non-conformity. Corrective and preventive actions
• GP-013 Risk management
• R-002-007 Process validation card 2023-005
• SP-018-001 Remote infrastructure control access policy
• SP-018-002 AWS console-managed resources procedure
• T-013-002 Risk Management Record
• T-018-001 Infrastructure list and control plan
• T-018-002 Infrastructure and facilities incidents log
• T-018-003 Audit Log Review Record
• T-018-004 Backup verification record

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 Design & Development Manager, JD-004 Quality Manager & PRRC
• Approver: JD-001 General Manager