Courtesy translation. In case of any discrepancy, the Italian version of this document prevails.

Security and Data Protection

Version 0.3 · Last revision: 8 novembre 2026

Unsigned draft, published for consultation purposes. The company providing the service has a VAT number; the REA number will be added once registration with the Companies Register is complete. Until then this document cannot be signed.

Revision of 19 October 2026. Corrections were made, both in the code and on the machine, regarding encryption, machine access, backups, and development: in particular, the database is not encrypted at rest, and the off-site copy is not yet active. The other sections are undergoing line-by-line re-verification before the signing of the first contract.

This technical sheet describes the security measures, both technical and organisational, adopted by Fibonacci (hereinafter, "Fibonacci" or the "Processor") in the provision of the Fibonacci digital medical record SaaS software (hereinafter, the "Service" or "Fibonacci"). The document is provided pursuant to Article 32 of Regulation (EU) 2016/679 (hereinafter, "GDPR") and constitutes Annex A of the Data Processing Agreement (DPA) signed by the client physician as Data Controller. The measures described apply to the processing of special categories of data pursuant to Article 9 GDPR (health-related data) carried out on behalf of the Controller within the scope of the Service.

The document is published at https://fibonaccimedica.it/sicurezza (opens in a new tab) and is subject to periodic updates based on the technological evolution of the Service and the state of the art in cybersecurity. Significant technical changes are notified to client Controllers in the manner indicated at the end of this document.

1. Security Architecture

Fibonacci's security architecture is structured on three concentric levels, each implementing independent and complementary controls. The defence logic follows a defence-in-depth approach: the failure of a single level is not sufficient to compromise the confidentiality, integrity, or availability of clinical data.

1.1 Network Level (Perimeter)

The network perimeter is hosted on Aruba S.p.A.'s infrastructure, on an Italian network and therefore within the European Union. Inbound traffic passes exclusively through a Caddy reverse proxy that terminates TLS (versions 1.2 and 1.3) and applies the HTTP security headers described in Section 6. The application backend is not directly exposed to the public Internet: Docker containers communicate over a private network, and administrative access to the machine is only permitted with an SSH key, without password authentication (configuration verified on 19 October 2026).

No network intermediaries are interposed. The Service domain resolves directly to the address of the infrastructure described above: no content delivery networks, third-party reverse proxies, or third-party managed Web Application Firewalls are used, and there is no point at which an entity other than the Processor terminates the encrypted connection from the browser. This can be verified externally with a DNS query on the Service domain.

1.2 Application Level

At the application level, Fibonacci implements multi-factor authentication, hardened sessions, role-based access control (RBAC), and FHIR compartmentalisation per medical tenant. Each request is validated by server-side input sanitisation middleware, CSRF control, and rate limiting per user and per IP address. The application logic is written in strongly typed languages and follows secure development practices described in Section 7.

1.3 Data Level

At the data level, Fibonacci encrypts clinical photos in the browser with AES-256-GCM before upload; the key for each photo is protected by a studio key (Key Encryption Key, KEK) managed by the signing service and never delivered to the browser. Backups are encrypted before being written. ⚠️ As of this revision, the database is not encrypted at rest, neither at the disk level nor for individual fields: it is protected by machine access and studio separation. Every CRUD operation on clinical resources is logged in an immutable audit log in FHIR AuditEvent format, signed in a SHA-256 hash-chain (Section 4).

1.4 Simplified Flow Diagram

                              TLS, no intermediaries
   [Physician's browser]  ----------------------------------->  [Caddy reverse proxy / Aruba IT]
                       (httpOnly Secure cookie)                     |
                                                                    |  private network
                                                                    v
                                                       [Fibonacci app container]
                                                                    |
                                       +----------------------------+----------------------------+
                                       |                            |                            |
                                       v                            v                            v
                              [PostgreSQL]              [AES-256 photo storage]         [Hash-chain audit log]
                                       |
                                       v
                                  [Daily encrypted backup (age)]

2. Encryption

Encryption is the primary measure to mitigate the risk of data exfiltration and unauthorised access. Fibonacci applies encryption in transit, encryption of clinical photos, and encryption of backups.

2.1 Key Management

Application encryption keys (Key Encryption Keys) are held server-side and are never exposed to the physician user's browser. Derivation of Data Encryption Keys (DEK) for individual records occurs in memory on the backend at the time of write or read operations. Keys are not included in backups in the same package as the encrypted data. KEK rotation is a documented procedure and re-encrypts existing data incrementally without service interruption.

2.2 Integrity

The GCM (Galois/Counter Mode) ensures both confidentiality and integrity. The auth-tag verifies that the payload has not been altered and rejects any attempt to manipulate the ciphertext. This property is particularly relevant for clinical photos, where the modification of a single bit would invalidate the evidentiary value of the data.

3. Access Control and Authentication

Digital identity is the primary attack surface of a cloud-based healthcare application. Fibonacci adopts multi-factor authentication, robust password hashing, hardened sessions, and data domain compartmentalisation based on role and FHIR.

3.1 Authentication

3.2 Session

User sessions are managed using httpOnly, Secure, and SameSite=Strict cookies. The httpOnly attribute prevents client-side JavaScript access to the cookie, reducing the impact of potential XSS vulnerabilities. The Secure attribute forces transmission only over TLS. The SameSite=Strict attribute mitigates cross-site request forgery and cross-site leak attack classes. The session token is subject to rotation: every privilege elevation (login, password change, MFA activation) issues a new identifier and invalidates the previous one.

3.3 RBAC and Compartmentalisation

Access to clinical resources is governed by an RBAC model with the following minimum roles:

Above the RBAC model operates FHIR compartmentalisation via Medplum AccessPolicy: each physician is isolated to their own patients, FHIR queries are filtered at the server level, and any cross-tenant read attempt returns a denial, logged in the audit log. Compartmentalisation is the primary measure to mitigate the risk of lateral movement and unauthorised access between distinct medical practices sharing the same instance.

4. Integrity and Traceability

For healthcare applications, data integrity is essential for its evidentiary and clinical value. Fibonacci implements an immutable audit log in FHIR AuditEvent format with cryptographic chaining of entries (hash-chain).

4.1 Audit Log

Every CRUD operation on FHIR resources (Patient, Encounter, Observation, Condition, MedicationStatement, DocumentReference, Consent, ImagingStudy, and similar) generates an AuditEvent entry containing:

• actor identifier (physician, role, session);
• high-resolution UTC timestamp;
• action type (create, read, update, delete, sign);
• reference to the resource involved;
• outcome (success, failure) and reason for any denial;
• source IP address and user agent.

4.2 Hash-Chain

Each audit entry incorporates the SHA-256 digest of the previous entry, constructing a hash chain similar to an append-only ledger. Any retroactive manipulation of an intermediate entry would break the chain and be detectable through deterministic verification of the log. The digest of the last entry can be exported as periodic integrity proof.

4.3 Access and Retention

The audit log is accessible to the Controller through the /audit section of the reserved area, with filters for actor, resource, and time window. Retention is ten years from the event, consistent with the obligation to retain medical documentation. Upon expiry, the record is securely deleted or anonymised according to the Controller's instructions.

5. Availability and Backup

Continuity of access to clinical data is a security property equal to confidentiality and integrity, and is specifically addressed in Article 32(1)(b) and (c) GDPR.

5.1 Off-Site Copy: Declared Limitation

⚠️ As of this revision, the backup resides on the same machine it protects. The system for replication with a third-party provider is installed and active (the scheduled job runs, and in the absence of a configured destination, it explicitly logs this), but the remote destination has not yet been purchased and configured. The full consequence must be stated: today, the loss of the hosting provider would result in the loss of the system and its backup together.

This limitation is declared here, and not in a footnote, because it is precisely the kind of information a Controller must know before entrusting data to a Processor, and because the off-site copy is specifically addressed in Article 32(1)(c) GDPR. The remote destination will be a provider different from the one hosting the primary infrastructure, and located in the European Union: a copy retained by the same provider is not an off-site copy.

This paragraph will be replaced by the description of the active measure once it is operational and verified.

5.2 Recovery Testing

A full recovery test is performed quarterly from the most recent backup, on a non-production instance, verifying the integrity of the restored data and the actual recovery time. The test outcome is recorded and retained as evidence pursuant to Article 32(1)(d) GDPR (procedure for regularly testing, assessing, and evaluating the effectiveness of technical and organisational measures).

6. Application Hardening

Fibonacci adopts a front-end and back-end hardening configuration aimed at reducing the attack surface of the most relevant OWASP Top 10 classes for web applications.

7. Secure Development (Secure SDLC)

Security is integrated into the software development lifecycle (Security by Design pursuant to Article 25 GDPR) through automated controls and human review at every code change.

Production secrets (keys, tokens, service passwords) are managed via the infrastructure's secret manager, are never present in the source code, and are rotated periodically or following any suspected exposure.

8. Incident Management and Data Breach

Fibonacci adopts a documented incident response procedure that defines roles, escalation thresholds, notification timelines, and communication methods with the Controller.

8.1 Notification to the Controller

In the event of a personal data breach pursuant to Article 4(12) GDPR involving data processed on behalf of the Controller, Fibonacci notifies the Controller of the event within 24 hours of discovery. This term is stricter than the minimum "without undue delay" term provided in Article 33(2) GDPR for the Processor, and aims to provide the Controller with ample margin relative to the 72 hours under Article 33(1) for their potential notification to the Supervisory Authority.

The notification to the Controller includes, to the extent available at the time of the initial communication:

• description of the nature of the breach;
• categories and approximate number of data subjects and records involved;
• likely consequences;
• technical and organisational measures taken or proposed for containment;
• operational contact point within Fibonacci.

Any missing information at the time of the first notification is transmitted to the Controller incrementally as soon as available, consistent with EDPB Guidelines 9/2022.

8.2 Escalation and Cooperation

The internal procedure provides for the immediate activation of an incident manager, isolation of the affected asset, preservation of forensic evidence, and opening of an incident log. Fibonacci actively cooperates with the Controller in assessing the risk to data subjects and in preparing any notification to the Authority or data subjects. Upon incident closure, a post-mortem is prepared and shared with the Controller, containing the timeline, root cause, remediation actions taken, and long-term corrective actions (lessons learned).

8.3 Register

All incidents, regardless of their final qualification as notifiable breaches, are recorded in the internal incident register, retained for audit and evidence purposes pursuant to Article 33(5) GDPR.

9. International Transfers

For the processing of patients' health data, Fibonacci does not carry out any transfers outside the European Union. The entire application stack, database, photo storage, and backups reside on Aruba S.p.A.'s infrastructure, on an Italian network.

9.1 Absence of Extra-European Intermediaries on the Data Path

The path that clinical data takes between the physician's browser and the database does not pass through any extra-European entity, and this is by design, not configuration: no content delivery networks, third-party reverse proxies, or third-party managed Web Application Firewalls are used. The Service domain resolves directly to the infrastructure's address, and the encrypted connection is terminated solely by the Processor's reverse proxy.

The difference from the common setup in the sector must be stated because it is why this section is brief: when an intermediary is present, the extra-EU transfer of network metadata exists and must be justified with Standard Contractual Clauses and supplementary measures. Here, there is no transfer, so no justification is needed. This can be verified by anyone, externally and without our consent, with a DNS query on the Service domain.

9.2 Residual Transfers and Their Scope

The only sub-processor in the supply chain with resilience replicas outside the European Union is the payment provider indicated in Annex B, which does not process patient data or any clinical data: the payment chain is segregated from the clinical chain, and reconciliation occurs via opaque identifiers. For this provider, the Standard Contractual Clauses under Implementing Decision (EU) 2021/914 apply.

9.3 Other Extra-EU Sub-Processors

Any other extra-EU sub-processors are authorised only with the Controller's consent as governed by the DPA and are subject to the same guarantees (SCCs, supplementary measures, transfer risk assessment).

10. Operational Continuity

⚠️ This section described a redundant architecture that the Service does not have. The previous version declared deployment across multiple availability zones, multiple reverse proxy instances behind health checks, and a streaming database replica with automatic promotion. None of this is operational: the Service runs on a single host, and declaring non-existent redundancy in a signed technical annex is precisely the kind of statement the Controller cannot verify independently and has the right not to be misled about.

Below is the actual state, distinguishing between what is active and what is planned.

11. Training and Governance

Technical security is only effective if accompanied by coherent organisational governance. Fibonacci integrates training obligations and defined responsibilities within its structure.

12. Certifications and Reference Standards

At present, Fibonacci is not ISO/IEC 27001 certified. Despite the lack of certification, Fibonacci voluntarily adopts the applicable controls from Annex A of ISO/IEC 27001:2022 as a reference framework for its security posture, particularly in the areas of organisational controls, people controls, physical controls, and technological controls. This reference does not constitute a declaration of certified compliance and should not be interpreted as a certification claim.

12.0 What is certified, and by whom: the distinction that matters

Certifications covering part of the Service belong to the infrastructure provider, not to Fibonacci. This distinction is stated here because it is the one a less scrupulous provider might omit, displaying their host's certification as if it were their own.

⚠️ What this means in practice: the fact that the data centre is ISO/IEC 27001 certified says something about the physical and organisational security of the server room, and nothing about the quality of Fibonacci's application code, its access control model, or its key management. Presenting the host's certification as a guarantee of one's own software is answering a different question from the one asked.

GDPR compliance, and in particular the principles of security by design and by default (Article 25 GDPR) and appropriate technical and organisational measures (Article 32 GDPR), is self-certified by the Processor based on internal documentation and retained process evidence.

Among the additional standards and guidelines considered in designing the measures described in this document, although not subject to certification, are:

• OWASP Top 10 2021 and OWASP Application Security Verification Standard (ASVS) for secure development and application hardening practices;
• NIST Special Publication 800-53 for the security control vocabulary;
• EDPB Guidelines 9/2022 on the notification of personal data breaches.

12.1 Certification Roadmap

Fibonacci has set the initiation of the ISO/IEC 27001 certification process as a goal upon reaching the first consolidated round of pilot Service clients. The progress of the roadmap is communicated transparently to client Controllers through periodic updates of this document and, where appropriate, through dedicated communications.

12.2 European Health Data Space: The Upcoming Obligation

Regulation (EU) 2025/327 establishes the European Health Data Space (EHDS) and sets out a harmonised framework for electronic health record systems. The regulation applies from 26 March 2027; for systems intended for the processing of priority categories of personal electronic health data under Article 14(1)(a), (b), and (c), the relevant provisions apply from 26 March 2029.

For an electronic health record system, the setup provided by the regulation entails: preparation of technical documentation (Article 37), an information sheet accompanying the system (Article 38), a EU declaration of conformity with the essential requirements of Annex II (Article 39), assessment of harmonised software components in a European digital testing environment (Article 40), affixing of the CE conformity marking (Article 41), and registration in the EU database of electronic health record systems (Article 49).

Fibonacci is not currently a CE-marked system under Chapter III of Regulation (EU) 2025/327, and does not claim to be. The marking cannot currently be affixed: the common specifications of the European digital testing environment and the European format for electronic health record exchange are delegated to implementing acts by the Commission.

What can be declared today is the product's status with respect to the requirements of Annex II that do not depend on such implementing acts:

13. Operational Contacts

Vulnerability reports are welcome and managed in line with responsible disclosure practices. Upon the reporter's request, an encrypted channel can be established using the security team's PGP key, provided on request. Fibonacci undertakes to provide an initial response to the reporter within a reasonable time from receipt, not to pursue legal action for reports made in good faith and within the indicated scope, and to publicly acknowledge the reporter's contribution unless anonymity is requested.

14. Last Revision

Last revision of this document: 8 novembre 2026.

This document is descriptive and updated to the current version of Fibonacci software. Significant technical changes to the security measures described herein are notified to client Controllers via email at the contact address provided in the Service Agreement, with reasonable notice prior to their entry into force. Version 0.3.