Traducción de cortesía. En caso de discrepancia, prevalece la versión italiana de este documento.

Seguridad y protección de los datos

Versión 0.3 · Última revisión: 8 novembre 2026

Borrador no firmado, publicado con fines de consulta. La sociedad que presta el servicio tiene número de IVA; el número REA se añadirá cuando se complete la inscripción en el registro mercantil. Hasta entonces, este documento no se puede firmar.

Revisión del 19 de octubre de 2026. Se han corregido, sobre el código y sobre el servidor, las partes relativas al cifrado, el acceso al servidor, las copias de seguridad y el desarrollo: en particular, la base de datos no está cifrada en reposo y la copia externa todavía no está activa. Las demás secciones se están volviendo a verificar línea por línea antes de la firma del primer contrato.

La presente ficha técnica describe las medidas de seguridad, técnicas y organizativas, adoptadas por Fibonacci (en adelante, "Fibonacci" o el "Encargado") en la prestación del software SaaS de historia clínica digital Fibonacci (en adelante, el "Servicio" o "Fibonacci"). El documento se emite de conformidad con el artículo 32 del Reglamento (UE) 2016/679 (en adelante, "GDPR") y constituye el Anexo A del Acuerdo de Tratamiento de Datos (DPA) suscrito por el médico cliente en calidad de Responsable del tratamiento. Las medidas descritas se aplican al tratamiento de categorías especiales de datos conforme al art. 9 GDPR (datos relativos a la salud) efectuado por cuenta del Responsable en el marco del Servicio.

El documento está publicado en https://fibonaccimedica.it/sicurezza (se abre en una nueva pestaña) y se actualiza periódicamente en función de la evolución tecnológica del Servicio y del estado de la técnica en materia de seguridad informática. Las modificaciones técnicas significativas se notifican a los Responsables clientes según las modalidades indicadas al final de este documento.

1. Arquitectura de la seguridad

La arquitectura de seguridad de Fibonacci se estructura en tres niveles concéntricos, cada uno de los cuales implementa controles independientes y complementarios. La lógica de defensa es la de la profundidad (defense in depth): el fallo de un solo nivel no basta para comprometer la confidencialidad, la integridad o la disponibilidad de los datos clínicos.

1.1 Nivel de red (perímetro)

El perímetro de red está alojado en la infraestructura de Aruba S.p.A., en red italiana y, por tanto, dentro de la Unión Europea. El tráfico entrante pasa exclusivamente por un reverse proxy Caddy que termina TLS (versiones 1.2 y 1.3) y aplica las cabeceras de seguridad HTTP descritas en la sección 6. El backend de la aplicación no está expuesto directamente a Internet: los contenedores Docker se comunican en una red privada, y el acceso administrativo a la máquina solo se permite con clave SSH, sin autenticación por contraseña (configuración verificada el 19 de octubre de 2026).

No se interpone ningún intermediario de red. El dominio del Servicio resuelve directamente a la dirección de la infraestructura descrita arriba: no se utilizan redes de distribución de contenidos, proxies inversos de terceros ni Web Application Firewall gestionados por terceros, y no existe ningún punto en el que un sujeto distinto del Responsable del tratamiento termine la conexión cifrada procedente del navegador. Esta circunstancia se puede comprobar desde el exterior con una consulta DNS sobre el dominio del Servicio.

1.2 Nivel de aplicación

En el nivel de aplicación, Fibonacci implementa autenticación multifactor, sesión reforzada (hardened), control de accesos basado en roles (RBAC) y compartimentación FHIR por tenant médico. Cada solicitud es validada por un middleware de saneamiento de la entrada en el servidor, control CSRF y rate limiting por usuario y por dirección IP. La lógica de la aplicación está escrita en lenguajes de tipado fuerte y sigue las prácticas de desarrollo seguro descritas en la sección 7.

1.3 Nivel del dato

En el nivel del dato, Fibonacci cifra las fotos clínicas en el navegador con AES-256-GCM antes de la carga; la clave de cada foto está protegida por una clave por consulta (Key Encryption Key, KEK) gestionada por el servicio de firma y nunca entregada al navegador. Las copias de seguridad se cifran antes de escribirse. ⚠️ En la fecha de esta revisión, la base de datos no está cifrada en reposo, ni a nivel de disco ni por campos individuales: está protegida por el acceso a la máquina y por la separación por consulta. Cada operación CRUD sobre los recursos clínicos queda registrada en un audit log inmutable en formato FHIR AuditEvent, firmado en hash-chain SHA-256 (sección 4).

1.4 Diagrama de flujo simplificado

                              TLS, senza intermediari
   [Browser medico]  ----------------------------------->  [Caddy reverse proxy / Aruba IT]
                       (cookie httpOnly Secure)                     |
                                                                    |  rete privata
                                                                    v
                                                       [Container app Fibonacci]
                                                                    |
                                       +----------------------------+----------------------------+
                                       |                            |                            |
                                       v                            v                            v
                              [PostgreSQL]              [Storage foto AES-256]         [Audit log hash-chain]
                                       |
                                       v
                                  [Backup giornaliero cifrato (age)]  

2. Cifrado

El cifrado es la principal medida de mitigación del riesgo de exfiltración y de acceso no autorizado a los datos. Fibonacci aplica cifrado en tránsito, cifrado de las fotos clínicas y cifrado de las copias de seguridad.

2.1 Gestión de las claves

Las claves de cifrado de la aplicación (Key Encryption Keys) se conservan en el servidor y nunca se exponen al navegador del médico usuario. La derivación de las Data Encryption Keys (DEK) para cada registro se realiza en memoria en el backend en el momento de la operación de escritura o lectura. Las claves no se incluyen en los backups dentro del mismo paquete que los datos cifrados. La rotación de las KEK es un procedimiento documentado y vuelve a cifrar de forma incremental los datos existentes sin interrumpir el servicio.

2.2 Integridad

El modo GCM (Galois/Counter Mode) garantiza simultáneamente confidencialidad e integridad. El auth-tag verifica que el payload no haya sido alterado y rechaza cualquier intento de manipulación del ciphertext. Esta propiedad es especialmente relevante para las fotos clínicas, donde la modificación de un solo bit invalidaría el valor probatorio del dato.

3. Control de accesos y autenticación

La identidad digital es la principal superficie de ataque de una aplicación sanitaria en la nube. Fibonacci adopta autenticación multifactor, hashing robusto de las contraseñas, sesión reforzada y compartimentación del dominio de datos por rol y por FHIR.

3.1 Autenticación

3.2 Sesión

Las sesiones de usuario se gestionan mediante cookies httpOnly, Secure y SameSite=Strict. El atributo httpOnly impide el acceso a la cookie desde JavaScript en el cliente, lo que reduce el impacto de posibles vulnerabilidades XSS. El atributo Secure fuerza la transmisión únicamente sobre TLS. El atributo SameSite=Strict mitiga las clases de ataque de tipo cross-site request forgery y cross-site leak. El token de sesión está sujeto a rotación: cada elevación de privilegios (inicio de sesión, cambio de contraseña, activación de la MFA) emite un nuevo identificador e invalida el anterior.

3.3 RBAC y compartimentación

El acceso a los recursos clínicos está regulado por un modelo RBAC con los siguientes roles mínimos:

Sobre el modelo RBAC opera la compartimentación FHIR mediante AccessPolicy de Medplum: cada médico queda aislado en sus propios pacientes, las consultas FHIR se filtran en el servidor y el intento de lectura cross-tenant devuelve una denegación, registrada en el audit log. La compartimentación es la principal medida de mitigación del riesgo de movimiento lateral y de acceso no autorizado entre consultas clínicas distintas que comparten la misma instancia.

4. Integridad y trazabilidad

Para las aplicaciones sanitarias, la integridad del dato es esencial para su valor probatorio y clínico. Fibonacci implementa un registro de auditoría (audit log) inmutable en formato FHIR AuditEvent con encadenamiento criptográfico de las entradas (hash-chain).

4.1 Registro de auditoría

Cada operación CRUD sobre los recursos FHIR (Patient, Encounter, Observation, Condition, MedicationStatement, DocumentReference, Consent, ImagingStudy y análogos) genera una entrada AuditEvent que contiene:

• identificador del actor (médico, rol, sesión);
• marca de tiempo (timestamp) UTC de alta resolución;
• tipo de acción (create, read, update, delete, sign);
• referencia al recurso implicado;
• resultado (success, failure) y motivo de la eventual denegación;
• dirección IP de origen y user agent.

4.2 Hash-chain

Cada entrada de auditoría incorpora el digest SHA-256 de la entrada anterior, construyendo una cadena de hashes análoga a un registro append-only. Cualquier manipulación retroactiva de una entrada intermedia provocaría la rotura de la cadena y sería detectable mediante una verificación determinista del registro. El digest de la última entrada se puede exportar como prueba de integridad periódica.

4.3 Acceso y conservación

El registro de auditoría es accesible para el titular del trattamento a través de la sección /audit del área reservada, con filtros por actor, recurso y ventana temporal. La conservación es de diez años desde el evento, en coherencia con la obligación de conservar la documentación sanitaria. Al vencer ese plazo, el registro se elimina de forma segura o se anonimiza según las instrucciones del titular del tratamiento.

5. Disponibilidad y copias de seguridad

La continuidad de acceso a los datos clínicos es una propiedad de seguridad al igual que la confidencialidad y la integridad, y es objeto específico del art. 32, apartado 1, letras b) y c) del GDPR.

5.1 Copia fuera de las instalaciones: límite declarado

⚠️ A la fecha de esta revisión, la copia de seguridad reside en la misma máquina que protege. El sistema de réplica en un proveedor externo está instalado y activo (la tarea programada se ejecuta y, a falta de un destino configurado, lo registra de forma explícita en sus propios logs), pero el destino remoto aún no ha sido contratado ni configurado. La consecuencia debe decirse por completo: hoy la pérdida del proveedor de alojamiento supondría la pérdida del sistema y de su copia a la vez.

El límite se declara aquí, y no en una nota a pie de página, porque es precisamente el tipo de información que un responsable del tratamiento debe conocer antes de confiar datos a un encargado del tratamiento, y porque la copia fuera de las instalaciones es objeto específico del art. 32, apartado 1, letra c) del GDPR. El destino remoto será un proveedor distinto del que aloja la infraestructura primaria, y estará situado en la Unión Europea: una copia conservada por el mismo proveedor no es una copia fuera de las instalaciones.

El presente apartado será sustituido por la descripción de la medida activa cuando esta esté en funcionamiento y verificada.

5.2 Prueba de restauración

Con periodicidad trimestral se realiza una prueba de restauración completa a partir de la copia de seguridad más reciente, en una instancia que no sea de producción, verificando la integridad del dato restaurado y el tiempo efectivo de recuperación. El resultado de la prueba se registra y se conserva como evidencia, conforme al art. 32, apartado 1, letra d) del GDPR (proceso de verificación, evaluación y valoración regulares de la eficacia de las medidas técnicas y organizativas).

6. Hardening de la aplicación

Fibonacci adopta una configuración de hardening del front-end y del back-end orientada a reducir la superficie de ataque de las clases del OWASP Top 10 más relevantes para aplicaciones web.

7. Desarrollo seguro (Secure SDLC)

La seguridad está integrada en el ciclo de desarrollo del software (Security by Design conforme al art. 25 GDPR) mediante controles automáticos y revisión humana en cada modificación del código.

Los secretos de producción (claves, tokens, contraseñas de servicio) se gestionan mediante el secret manager de la infraestructura, nunca están presentes en el código fuente y se rotan periódicamente o tras cualquier sospecha de exposición.

Corrección: en la fila de Test E2E debe decir «creación de la historia clínica», no «cartella».

8. Gestión de incidentes y brechas de seguridad de datos

Fibonacci adopta un procedimiento documentado de respuesta a incidentes (incident response) que define funciones, umbrales de escalado, plazos de notificación y modalidades de comunicación con el Titular.

8.1 Notificación al Titular

En caso de violación de datos personales en el sentido del art. 4, n. 12 GDPR que afecte a datos tratados por cuenta del Titular, Fibonacci notifica el evento al Titular en un plazo máximo de 24 horas desde su detección. Este plazo es más estricto que el plazo mínimo de «sin dilación indebida» previsto por el art. 33, apdo. 2 GDPR para el Encargado, y tiene como finalidad ofrecer al Titular un margen amplio respecto a las 72 horas del art. 33, apdo. 1, para su eventual notificación a la Autoridad de control.

La notificación al Titular incluye, en la medida en que esté disponible en el momento de la comunicación inicial:

• descripción de la naturaleza de la violación;
• categorías y número aproximado de interesados y de registros afectados;
• consecuencias probables;
• medidas técnicas y organizativas adoptadas o propuestas para la contención;
• punto de contacto operativo dentro de Fibonacci.

La información que falte en el momento de la primera notificación se transmite al Titular de forma incremental, tan pronto como esté disponible, de conformidad con las Directrices 9/2022 del CEPD.

8.2 Escalado y cooperación

El procedimiento interno prevé la activación inmediata de un incident manager, el aislamiento del activo afectado, la conservación de las evidencias forenses y la apertura de un registro de incidente. Fibonacci coopera activamente con el Titular en la evaluación del riesgo para los interesados y en la preparación de la eventual notificación a la Autoridad o a los interesados. Al cierre del incidente se elabora un post-mortem compartido con el Titular, que contiene la cronología, la causa raíz, las acciones de remedio aplicadas y las acciones correctivas a largo plazo (lessons learned).

8.3 Registro

Todos los incidentes, con independencia de su calificación final como violación notificable, se anotan en el registro interno de incidentes, que se conserva a efectos de auditoría y como prueba conforme al art. 33, apdo. 5 GDPR.

9. Transferencias internacionales

Para el tratamiento de los datos sanitarios de los pacientes, Fibonacci no efectúa ninguna transferencia fuera de la Unión Europea. Toda la pila aplicativa, la base de datos, el almacenamiento de las fotos y las copias de seguridad residen en la infraestructura de Aruba S.p.A., sobre red italiana.

9.1 Ausencia de intermediarios extracomunitarios en el recorrido del dato

El recorrido que el dato clínico realiza entre el navegador del médico y la base de datos no atraviesa ningún sujeto extracomunitario, y no lo atraviesa por construcción y no por configuración: no se emplea ninguna red de distribución de contenidos, ningún proxy inverso de terceros ni ningún Web Application Firewall gestionado por terceros. El dominio del Servicio resuelve directamente a la dirección de la infraestructura, y la conexión cifrada la termina únicamente el reverse proxy del Encargado del tratamiento.

La diferencia respecto al planteamiento habitual en el sector hay que explicarla, porque es la razón por la que este apartado es breve: cuando hay un intermediario, la transferencia extra-UE de los metadatos de red existe y debe justificarse con Cláusulas Contractuales Tipo y medidas complementarias. Aquí no existe la transferencia, por lo que no hace falta justificarla. Cualquiera puede comprobar esta circunstancia desde el exterior y sin nuestro consentimiento, con una consulta DNS sobre el dominio del Servicio.

9.2 Transferencias residuales y su perímetro

El único subencargado de la cadena con réplicas de resiliencia fuera de la Unión Europea es el proveedor de pagos indicado en el Anexo B, que no trata datos de los pacientes ni datos clínicos de ningún tipo: la cadena de pagos está separada de la clínica y la conciliación se realiza mediante un identificador opaco. Para dicho proveedor rigen las Cláusulas Contractuales Tipo a las que se refiere la Decisión de Ejecución (UE) 2021/914.

9.3 Otros subencargados extra-UE

Los eventuales otros subencargados extra-UE se autorizan exclusivamente con el consentimiento del Responsable del tratamiento según lo dispuesto en el DPA y están sujetos a las mismas garantías (CCT, medidas complementarias, evaluación del riesgo de transferencia).

10. Continuidad operativa

⚠️ Esta sección describía una arquitectura redundante que el Servicio no tiene. La versión anterior declaraba distribución en múltiples zonas de disponibilidad, varias instancias de reverse proxy detrás de health check y una réplica en streaming de la base de datos con promoción automática. Nada de esto está en producción: el Servicio funciona en un solo host, y declarar una redundancia inexistente en un anexo técnico suscrito es exactamente el tipo de afirmación que el titular del trattamento no puede verificar por sí solo y respecto a la cual tiene derecho a no ser engañado.

A continuación se expone el estado real, distinguiendo entre lo que está activo y lo que está previsto.

11. Formación y gobernanza

La seguridad técnica solo es eficaz si va acompañada de una gobernanza organizativa coherente. Fibonacci integra obligaciones formativas y responsabilidades definidas dentro de su propia estructura.

12. Certificaciones y estándares de referencia

En la actualidad Fibonacci no está certificada ISO/IEC 27001. Aun sin certificación, Fibonacci adopta voluntariamente los controles aplicables del Anexo A de la norma ISO/IEC 27001:2022 como marco de referencia para su postura de seguridad, en particular en las áreas de controles organizativos, controles de las personas, controles físicos y controles tecnológicos. Esta referencia no constituye una declaración de conformidad certificada y no debe entenderse como una afirmación de certificación.

12.0 Qué está certificado y quién lo ha certificado: la distinción que importa

Las certificaciones que cubren una parte del Servicio pertenecen al proveedor de la infraestructura, no a Fibonacci. La distinción se declara aquí porque es la que un proveedor poco escrupuloso omite, exhibiendo el sello de su anfitrión como si fuera propio.

⚠️ Qué significa esto en concreto: que el centro de datos esté certificado ISO/IEC 27001 dice algo sobre la seguridad física y organizativa de la sala de máquinas, y nada sobre la calidad del código de la aplicación de Fibonacci, sobre su modelo de control de accesos o sobre su gestión de claves. Quien presenta la certificación de su anfitrión como garantía sobre su propio software está respondiendo a una pregunta distinta de la que se le ha hecho.

La conformidad con el GDPR, y en particular con los principios de seguridad desde el diseño y por defecto (art. 25 GDPR) y con las medidas técnicas y organizativas adecuadas (art. 32 GDPR), es autocertificada por el Encargado del tratamiento sobre la base de la documentación interna y de las evidencias de proceso conservadas.

Entre los estándares y directrices adicionales considerados en el diseño de las medidas descritas en este documento, aunque no sean objeto de certificación, se encuentran:

• OWASP Top 10 2021 y OWASP Application Security Verification Standard (ASVS) para las prácticas de desarrollo seguro y de refuerzo (hardening) de la aplicación;
• NIST Special Publication 800-53 para el vocabulario de los controles de seguridad;
• Directrices 9/2022 del EDPB sobre la notificación de violaciones de la seguridad de los datos personales.

12.1 Hoja de ruta de certificación

Fibonacci se ha fijado como objetivo evaluar el inicio del proceso de certificación ISO/IEC 27001 cuando se alcance la primera ronda consolidada de clientes piloto del Servicio. El estado de avance de la hoja de ruta se comunica de forma transparente a los Responsables del tratamiento clientes mediante actualizaciones periódicas de este documento y, cuando proceda, mediante comunicaciones específicas.

12.2 Espacio Europeo de Datos Sanitarios: la obligación que llega

El Reglamento (UE) 2025/327 instituye el Espacio Europeo de Datos Sanitarios (EHDS) y establece un marco armonizado para los sistemas de historia clínica electrónica. El reglamento se aplica a partir del 26 de marzo de 2027; para los sistemas destinados al tratamiento de las categorías prioritarias de datos sanitarios electrónicos personales a que se refiere el art. 14, apartado 1, letras a), b) y c), las disposiciones pertinentes se aplican a partir del 26 de marzo de 2029.

Para un sistema de historia clínica electrónica, el régimen previsto por el reglamento comporta: elaboración de la documentación técnica (art. 37), ficha informativa que acompaña al sistema (art. 38), declaración UE de conformidad respecto a los requisitos esenciales del Anexo II (art. 39), evaluación de los componentes de software armonizados en un entorno digital europeo de pruebas (art. 40), colocación del marcado CE de conformidad (art. 41) y registro en la base de datos de la UE de sistemas de historia clínica electrónica (art. 49).

Fibonacci no es hoy un sistema con marcado CE en el sentido del Capítulo III del Reglamento (UE) 2025/327, y no lo declara. El marcado no puede colocarse actualmente: las especificaciones comunes del entorno digital europeo de pruebas y el formato europeo de intercambio de historias clínicas electrónicas se remiten a actos de ejecución de la Comisión.

Lo que sí se puede declarar hoy es el estado del producto respecto a los requisitos del Anexo II que no dependen de dichos actos de ejecución:

13. Contactos operativos

Las notificaciones de vulnerabilidades son bienvenidas y se gestionan conforme a las prácticas de responsible disclosure. A petición de quien notifica, es posible establecer un canal cifrado mediante la clave PGP del equipo de seguridad, que se facilita previa solicitud. Fibonacci se compromete a dar una primera respuesta a quien notifica en un plazo razonable desde la recepción, a no emprender acciones legales contra las notificaciones efectuadas de buena fe y dentro del perímetro indicado, y a reconocer públicamente la contribución de quien notifica, salvo que solicite el anonimato.

14. Última revisión

Última revisión del presente documento: 8 novembre 2026.

El presente documento tiene carácter descriptivo y está actualizado a la versión actual del software Fibonacci. Las modificaciones técnicas significativas de las medidas de seguridad aquí descritas se notifican a los Titulares clientes por correo electrónico a la dirección de contacto indicada en el Contrato de Servicio, con un preaviso razonable respecto a su entrada en vigor. Versión 0.3.