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

Security and Data Protection

Version 0.2 · Last revision: 16 agosto 2026

Unsigned draft, published for consultation purposes. The company header of this document is deliberately blank: the company providing the service is a yet-to-be-incorporated Ltd., and including the company details of the software developer would indicate an incorrect contractual counterparty. Company name, registered office, VAT number, REA number and contact details are filled in on the day of registration in the of companies; until then, the document cannot be signed and does not produce effects between the parties.

This technical sheet describes the security, technical, and organizational measures adopted by Fibonacci (hereinafter, "Fibonacci" or the "Processor") in providing the Fibonacci digital medical record SaaS software (hereinafter, the "Service" or "Fibonacci"). The document is issued pursuant to Article 32 of Regulation (EU) 2016/679 (hereinafter, "GDPR") and constitutes Annex A of the Data Processing Agreement (DPA) signed by the physician customer 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 customer Controllers as 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 defense logic follows a defense-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 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 hosts is permitted exclusively from authorized IP addresses via SSH key, without password authentication.

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 via 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-based compartmentalization per medical tenant. Each request is validated by server-side input sanitization 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 applies encryption on two axes: volume-level filesystem encryption for the entire PostgreSQL instance and AES-256 GCM application-level encryption for columns containing sensitive identifiers and photo files. Application encryption keys (Key Encryption Keys, KEK) are managed server-side and never transmitted to the physician user’s browser. 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 1.3, no intermediaries
   [Physician’s browser]  ----------------------------------->  [Caddy reverse proxy / Aruba IT]
                       (httpOnly Secure cookie)                     |
                                                                    |  private network
                                                                    v
                                                       [Fibonacci app container]
                                                                    |
                                       +----------------------------+----------------------------+
                                       |                            |                            |
                                       v                            v                            v
                              [Encrypted PostgreSQL]      [AES-256 encrypted photo storage]   [Hash-chain audit log]
                                       |
                                       v
                                  [Daily AES-256 encrypted backup]

2. Encryption

Encryption is the primary measure to mitigate the risk of data exfiltration and unauthorized access. Fibonacci applies encryption in transit, at-rest filesystem encryption, and application-level columnar and binary payload encryption.

2.1 Key Management

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

2.2 Integrity

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 compartmentalization based on role and FHIR.

3.1 Authentication

3.2 Session

User sessions are managed via 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 enforces 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 Compartmentalization

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

Above the RBAC model, FHIR compartmentalization operates 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. Compartmentalization is the primary measure to mitigate lateral movement risk and unauthorized access between distinct clinics 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 involved resource;
• 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 analogous to an append-only ledger. Any retroactive manipulation of an intermediate entry would break the chain and be detectable via 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 via 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 expiration, the record is securely deleted or anonymized according to the Controller’s instructions.

5. Availability and Backup

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

5.1 Off-Site Copy: Declared Limitation

⚠️ As of this revision, the backup copy resides on the same machine it protects. The system for replication to 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 consequence must be stated in full: today, the loss of the hosting provider would result in the loss of both the system and its backup.

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 by Article 32(1)(c) GDPR. The remote destination will be a provider different from the one hosting the primary infrastructure, and located within 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

Quarterly, a full recovery test is performed 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 organizational 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 defining 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 by 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 organizational 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, in line 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 involved 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 drafted 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 transfer 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-EU Intermediaries on the Data Path

The path that clinical data travels between the physician’s browser and the database does not pass through any extra-EU 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, no transfer exists, so no justification is needed. This can be verified by anyone, externally and without our consent, via a DNS query on the Service domain.

9.2 Residual Transfers and Their Scope

The only sub-processor in the chain with resilience replicas outside the European Union is the payment provider listed 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 authorized 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. Business Continuity

⚠️ This section previously described a redundant architecture that the Service does not have. The earlier version claimed deployment across multiple availability zones, multiple reverse proxy instances behind health checks, and streaming database replication 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 effective only if accompanied by coherent organizational 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 organizational, people, physical, and technological controls. This reference does not constitute a certified compliance declaration and should not be interpreted as a certification claim.

12.0 What is Certified, and by Whom: The Critical Distinction

Certifications covering part of the Service belong to the infrastructure provider, not 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 center is ISO/IEC 27001 certified says something about the physical and organizational 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 answers a different question than the one asked.

GDPR compliance, particularly the principles of security by design and by default (Article 25 GDPR) and appropriate technical and organizational 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, though 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 customers. The roadmap’s progress is communicated transparently to customer Controllers through periodic updates of this document and, where appropriate, dedicated communications.

12.2 European Health Data Space: The Upcoming Obligation

Regulation (EU) 2025/327 establishes the European Health Data Space (EHDS) and sets a harmonized framework for electronic health record systems. The regulation applies from 26 March 2027; for systems intended to process the 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 required by the regulation entails: drafting technical documentation (Article 37), a product information sheet accompanying the system (Article 38), a EU declaration of conformity with the essential requirements of Annex II (Article 39), assessment of harmonized software components in a European digital testing environment (Article 40), affixing 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 Commission implementing acts.

What can be declared today is the product’s status relative 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 request, a secure channel can be established using the security team’s PGP key. Fibonacci commits to providing 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: 16 agosto 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 customer Controllers via email at the contact address provided in the Service Agreement, with reasonable notice prior to their entry into force. Version 0.2.