Copias de seguridad de pacientes: pasos para configurarlas

También hay que demostrar que existía un procedimiento documentado, que el acceso estaba restringido y que las copias se protegían con medidas proporcionales al riesgo.

Los datos sobre salud mental y los historiales clínicos pertenecen a categorías especiales de datos según el artículo 9 del Reglamento General de Protección de Datos (RGPD). No se pueden tratar como documentos administrativos ordinarios. Una cuenta personal de almacenamiento, un disco externo sin cifrar o una copia manual ocasional no constituyen, por sí solos, un sistema adecuado de protección.

Las copias de seguridad de datos de pacientes en psicología deben cumplir tres objetivos:

• Mantener varias copias independientes.
• Impedir que terceros accedan a la información si el soporte se pierde o es robado.
• Permitir una restauración verificable cuando el sistema principal falle.

La referencia técnica más útil es la regla 3-2-1. No sustituye al análisis de riesgos ni a la documentación exigida por el RGPD, pero proporciona una arquitectura mínima razonable para una consulta profesional.

Qué obligaciones afectan a los historiales de psicología

El RGPD y la Ley Orgánica 3/2018 de Protección de Datos Personales y garantía de los derechos digitales (LOPDGDD) exigen aplicar medidas de seguridad reforzadas cuando se tratan datos de salud. En una consulta de psicología, esta categoría puede incluir:

• Historial clínico y notas de evolución.
• Diagnósticos, síntomas y antecedentes.
• Información sobre medicación o tratamientos.
• Informes remitidos a otros profesionales.
• Grabaciones de sesiones, si existen.
• Datos identificativos vinculados al proceso terapéutico.
• Correos electrónicos o documentos que permitan inferir el estado de salud mental.

La protección no depende del formato. Un archivo PDF exportado desde el programa de gestión sigue conteniendo datos clínicos. Una hoja de cálculo con nombres, citas y observaciones también. Un mensaje de correo puede formar parte del expediente si contiene información suficiente sobre el paciente.

El responsable de la consulta debe poder explicar qué datos conserva, dónde se almacenan, quién puede acceder a ellos y cómo se recuperan después de un incidente. El artículo 5.2 del RGPD recoge el principio de responsabilidad proactiva: no basta con afirmar que se actúa correctamente. Hay que poder acreditarlo.

La copia no es el único control

Una copia de seguridad protege frente a la pérdida de disponibilidad. No corrige una exposición de confidencialidad.

Si un programa malicioso cifra los archivos y también cifra las copias conectadas permanentemente al mismo equipo, el sistema de respaldo fracasa. Si una persona sin autorización puede descargar la copia completa, los datos siguen expuestos aunque el sistema permita restaurarlos. Si el profesional no puede demostrar cuándo se hizo la última copia o nunca ha probado una restauración, la existencia del archivo no garantiza la continuidad de la actividad.

Por eso deben analizarse tres propiedades:

Una copia de seguridad que nadie puede restaurar no es una medida de continuidad. Es un archivo pendiente de verificación.

Diseñar la arquitectura 3-2-1

La regla 3-2-1 exige mantener tres copias de los datos: la original y dos copias adicionales. Deben existir en dos soportes diferentes y una de ellas debe conservarse fuera de las instalaciones.

En una consulta pequeña, la aplicación práctica puede ser sencilla. La historia clínica se guarda en el sistema principal. Una copia se genera en un soporte local cifrado. Otra se almacena en un servicio remoto que permita formalizar la relación con el proveedor y mantener los datos dentro de la Unión Europea.

La estructura no debe depender de un único equipo ni de una única cuenta de usuario.

1. Identificar el origen de los datos

Antes de configurar el respaldo, hay que localizar todos los puntos donde se generan o modifican datos clínicos:

• Programa de gestión de pacientes.
• Ordenadores de la consulta.
• Servidores locales, si existen.
• Carpetas de documentos compartidos.
• Aplicaciones de videoconferencia que permitan grabar sesiones.
• Correo electrónico profesional.
• Dispositivos móviles utilizados para acceder a la agenda.
• Bases de datos de formularios o consentimiento informado digital.
• Discos externos empleados para exportaciones.

El error habitual consiste en respaldar únicamente la carpeta visible del programa. Las notas exportadas a otra ubicación, los documentos adjuntos y las bases de datos auxiliares quedan fuera. El inventario debe indicar qué información contiene cada sistema y cuál es su dependencia técnica.

2. Separar los soportes

Las tres copias no deben ser simples duplicados conectados al mismo dispositivo. Si el ordenador se infecta, el código malicioso puede alcanzar cualquier unidad montada de forma permanente.

Una configuración más resistente separa:

1. La copia operativa del sistema principal.

2. Un respaldo local cifrado y desconectado cuando no se utiliza.

3. Un respaldo remoto con control de acceso, cifrado y ubicación contractual conocida.

La copia fuera de las instalaciones puede ser necesaria para cubrir robos, incendios o daños físicos. El soporte remoto no debe elegirse únicamente por precio o capacidad. Debe analizarse quién presta el servicio, en qué país aloja la información y qué obligaciones asume por contrato.

3. Definir la frecuencia

La frecuencia debe corresponderse con la cantidad de información que la consulta puede permitirse perder. Una consulta que actualiza historiales a diario no tiene el mismo riesgo operativo que otra que solo digitaliza documentos una vez por semana.

El procedimiento debe fijar, como mínimo:

• Qué datos se copian.
• Con qué frecuencia se ejecuta el proceso.
• Qué persona o sistema lo supervisa.
• Cuánto tiempo se conserva cada versión.
• Cómo se detectan los errores.
• Quién autoriza una restauración.
• Dónde se documentan los resultados.

No conviene establecer una frecuencia que nadie pueda verificar. Un proceso automático sin alertas produce una falsa sensación de control. La ausencia de avisos no demuestra que la copia se haya completado.

Cifrado: proteger los datos en reposo y en tránsito

El cifrado debe aplicarse en dos momentos distintos.

Los datos están en reposo cuando permanecen almacenados en un ordenador, un disco externo, un servidor o un servicio de almacenamiento remoto. Están en tránsito cuando se transmiten desde la consulta hasta otro sistema.

Para los datos en reposo, el estándar AES-256 se utiliza habitualmente como referencia de cifrado robusto. La herramienta concreta puede variar, pero el profesional debe conocer qué algoritmo aplica el proveedor, cómo se gestionan las claves y quién puede descifrar la información.

Para los datos en tránsito, deben emplearse protocolos seguros como TLS. No es suficiente con que una página web muestre un icono de conexión segura. Hay que confirmar que la transferencia de copias, la administración de la cuenta y las conexiones entre dispositivos utilizan canales cifrados.

La gestión de claves es parte del cifrado

Cifrar un disco y guardar la contraseña en una nota junto al ordenador elimina buena parte de la protección. También es insuficiente utilizar una clave compartida por todo el equipo sin registro de accesos.

La gestión mínima debe contemplar:

• Contraseñas largas y exclusivas para el servicio.
• Un gestor de contraseñas profesional.
• Autenticación multifactor, preferiblemente mediante aplicación de autenticación o llave física.
• Recuperación de cuenta con datos corporativos, no con un correo personal.
• Separación entre las credenciales del sistema principal y las del respaldo.
• Revocación inmediata cuando una persona deja de trabajar en la consulta.
• Registro de los cambios de permisos y de las restauraciones.

La autenticación de dos factores (2FA) reduce el riesgo de que una contraseña filtrada permita entrar directamente al almacenamiento. No sustituye al cifrado ni a una política de permisos, pero añade una barrera relevante.

El cifrado no anonimiza el expediente

Un dato cifrado sigue siendo un dato personal. Puede dejar de ser legible sin la clave, pero continúa bajo control del responsable mientras sea posible vincularlo con una persona.

La anonimización requiere que la identificación no pueda recuperarse mediante medios razonables. La seudonimización, en cambio, sustituye los identificadores directos por códigos, pero mantiene la posibilidad de reidentificación mediante información adicional. Las copias de historias clínicas normalmente no se convierten en anónimas por el hecho de estar cifradas.

Esta distinción afecta al registro de actividades, al análisis de riesgos y a la gestión de proveedores. No debe utilizarse la palabra anonimización como atajo para reducir las obligaciones del RGPD.

Cómo seleccionar un servicio de almacenamiento remoto

Las herramientas gratuitas destinadas al almacenamiento personal no son adecuadas por defecto para conservar copias de historiales clínicos. El problema no es que sean gratuitas. El problema es que pueden no ofrecer las garantías contractuales, técnicas y de localización necesarias.

Antes de contratar un servicio, hay que revisar varios elementos.

Contrato de Encargado del Tratamiento

El proveedor que almacena copias por cuenta de la consulta puede actuar como encargado del tratamiento. En ese caso, debe existir un Contrato de Encargado del Tratamiento (CET) con las condiciones exigidas por el artículo 28 del RGPD.

El contrato debe identificar, entre otros aspectos:

• El objeto y la duración del tratamiento.
• La naturaleza y finalidad del almacenamiento.
• El tipo de datos tratados.
• Las categorías de personas afectadas.
• Las instrucciones documentadas del responsable.
• Las medidas de seguridad aplicadas.
• La gestión de subencargados.
• La devolución o eliminación de los datos al terminar el servicio.
• La asistencia en caso de brecha o ejercicio de derechos.

Aceptar las condiciones generales de una cuenta de consumo no equivale necesariamente a formalizar un CET válido. Si el proveedor no permite contratar bajo estas condiciones, el servicio no ofrece una base suficiente para almacenar historiales clínicos.

Ubicación de los servidores

La consulta debe saber dónde se alojan los datos y desde qué países puede acceder el proveedor. La ubicación dentro de la Unión Europea simplifica el análisis de transferencias internacionales, aunque no elimina el resto de obligaciones.

No basta con que la empresa tenga domicilio en España o en otro país de la Unión Europea. La infraestructura puede depender de subcontratistas situados fuera del Espacio Económico Europeo. La política de privacidad y la documentación contractual deben revelar esa cadena cuando sea relevante.

Eliminación y recuperación

El servicio debe permitir eliminar una copia de forma verificable y recuperar los datos en un formato utilizable. Una plataforma que retiene versiones antiguas indefinidamente puede conservar información clínica más tiempo del necesario.

También hay que comprobar:

• Si existe historial de versiones.
• Durante cuánto tiempo se conservan los archivos eliminados.
• Si la cuenta puede exportar todos los datos.
• Qué ocurre si se cancela la suscripción.
• Cuánto tarda una restauración completa.
• Si hay límites de volumen o de número de archivos.
• Cómo se informa de una incidencia.

La continuidad de la consulta no puede depender de que el proveedor mantenga indefinidamente una interfaz concreta. La portabilidad forma parte del control operativo.

Publicidad y garantías técnicas

Expresiones como almacenamiento seguro, privacidad avanzada o protección empresarial no describen una medida concreta. Hay que traducir cada promesa a una especificación verificable:

• ¿Cifra los datos antes de almacenarlos?
• ¿Utiliza AES-256 u otro estándar reconocido?
• ¿Protege las comunicaciones mediante TLS?
• ¿Permite 2FA?
• ¿Registra los accesos administrativos?
• ¿Aísla las copias frente al borrado masivo?
• ¿Realiza pruebas de restauración?
• ¿Notifica incidentes dentro de un plazo operativo razonable?

Si la respuesta aparece únicamente en material comercial, no es suficiente. La documentación técnica y el contrato tienen más valor que una página de ventas.

Documentar el procedimiento de copia

El RGPD exige responsabilidad proactiva. La consulta debe redactar un procedimiento que otra persona pueda ejecutar sin interpretar intenciones.

El documento puede ser breve. Debe ser preciso. Como mínimo, debe incluir:

1. Ámbito. Sistemas, carpetas y bases de datos incluidos en la copia.

2. Responsable. Persona encargada de comprobar la ejecución y revisar los avisos.

3. Frecuencia. Periodicidad de las copias automáticas y manuales.

4. Destino. Soporte local, soporte remoto y ubicación de cada uno.

5. Cifrado. Método aplicado en reposo y durante la transmisión.

6. Autenticación. Cuentas autorizadas, 2FA y gestión de credenciales.

7. Retención. Criterios para conservar y eliminar versiones.

8. Restauración. Pasos para recuperar un expediente o el sistema completo.

9. Pruebas. Frecuencia y resultado de los ensayos de recuperación.

10. Incidencias. Canal de comunicación y escalado ante un fallo o una brecha.

El documento debe mantenerse actualizado. Si cambia el programa de gestión, el proveedor o el lugar de almacenamiento, también debe revisarse el procedimiento.

Registrar las pruebas de restauración

La restauración es la única forma de comprobar que una copia sirve. El ensayo debe realizarse sobre una ubicación separada para no sobrescribir los datos operativos.

La prueba puede verificar:

• Que el archivo se abre correctamente.
• Que los adjuntos siguen vinculados.
• Que las fechas y versiones son coherentes.
• Que la base de datos no presenta errores.
• Que las claves de descifrado están disponibles.
• Que los permisos no se amplían durante la recuperación.
• Que el sistema vuelve a funcionar después de restaurar.

El registro debe indicar la fecha, la persona responsable, el conjunto recuperado, el resultado y las incidencias detectadas. No se necesita una redacción extensa. Sí se necesita trazabilidad.

Documentar una copia fallida no la convierte en válida. Documentar la prueba de restauración demuestra que el control funciona.

Protocolo ante pérdida, acceso no autorizado o ransomware

Una brecha de seguridad puede afectar a la confidencialidad, la integridad o la disponibilidad de los datos. La pérdida de un disco, el envío de un historial al destinatario equivocado, el acceso indebido a una cuenta o el cifrado malicioso de la base de datos deben evaluarse como incidentes potenciales.

La respuesta debe estar definida antes del problema.

Paso 1. Contener el incidente

Hay que impedir que continúe el acceso o la propagación:

• Desconectar de la red el equipo afectado si existe actividad maliciosa.
• Bloquear la cuenta comprometida.
• Revocar sesiones activas y credenciales expuestas.
• Aislar los soportes de copia.
• No borrar evidencias antes de documentarlas.
• Evitar restaurar sobre el sistema comprometido.

La improvisación puede destruir información útil para determinar el alcance del incidente.

Paso 2. Determinar qué datos están afectados

La consulta debe identificar:

• Qué sistemas o soportes han quedado expuestos.
• Qué pacientes aparecen en ellos.
• Qué tipos de datos contiene cada archivo.
• Si los datos estaban cifrados.
• Cuándo se produjo el acceso o la pérdida.
• Qué personas podían utilizar la cuenta.
• Si la copia también ha sido alterada.

El cifrado puede reducir el riesgo para los afectados, pero no elimina automáticamente la obligación de analizar la brecha.

Paso 3. Registrar la decisión

El responsable debe dejar constancia de los hechos conocidos, las medidas aplicadas y la valoración del riesgo. También debe registrar la decisión de notificar o no notificar.

Cuando una brecha pueda suponer un riesgo para los derechos y libertades de las personas, el artículo 33 del RGPD establece un plazo máximo de 72 horas para notificarla a la Agencia Española de Protección de Datos (AEPD) desde que se tiene constancia de ella. Si el riesgo para los afectados es alto, puede ser necesaria también la comunicación a las personas afectadas, conforme a las condiciones del RGPD.

El plazo no empieza cuando la investigación termina por completo. Empieza cuando la organización tiene constancia suficiente de que se ha producido una violación de seguridad. La información adicional puede completarse después, pero la falta de datos perfectos no justifica ignorar el plazo.

Errores que invalidan un sistema aparentemente correcto

Mantener el disco de copia conectado permanentemente

Esta configuración facilita la automatización, pero también permite que un atacante o un programa malicioso modifique o elimine el respaldo. El soporte debe desconectarse cuando la arquitectura lo permita o contar con mecanismos de aislamiento y versiones protegidas.

Usar una cuenta personal

Una cuenta personal mezcla información profesional y privada. Puede carecer de CET, control administrativo, trazabilidad y gestión de bajas. Además, si el titular pierde acceso a la cuenta, la consulta puede quedar sin capacidad de recuperación.

Confiar en la sincronización

La sincronización replica cambios. Si un archivo se borra o se cifra, el cambio puede propagarse a todos los dispositivos. Una copia de seguridad debe conservar versiones independientes y permitir recuperar un estado anterior.

Guardar la contraseña junto al soporte

El cifrado pierde eficacia si la clave se almacena en el mismo cajón que el disco. Las credenciales deben gestionarse por separado y protegerse con 2FA cuando el servicio lo permita.

No probar la restauración

Un proceso puede informar de que ha finalizado correctamente y producir archivos incompletos, dañados o imposibles de descifrar. Sin una prueba, el resultado es desconocido.

Ignorar los dispositivos móviles

El acceso desde un teléfono o una tableta crea nuevos puntos de exposición. Hay que aplicar bloqueo de pantalla, cifrado del dispositivo, actualización automática y borrado remoto cuando sea posible. Si el dispositivo descarga documentos clínicos, también debe incluirse en el análisis de riesgos.

Conservar copias sin criterio

Guardar todas las versiones indefinidamente no es una política de protección. Aumenta el volumen de datos expuestos y dificulta la eliminación controlada. La conservación debe responder a obligaciones clínicas, legales y organizativas previamente definidas.

Configuración mínima para una consulta pequeña

Una consulta con pocos profesionales puede aplicar un modelo reducido sin convertirlo en improvisado:

• Sistema principal con cuentas individuales.
• Permisos limitados según la función de cada usuario.
• 2FA para el programa de gestión y el almacenamiento remoto.
• Copia local cifrada con AES-256.
• Copia remota alojada en la Unión Europea y cubierta por un CET.
• Transmisiones protegidas mediante TLS.
• Separación física o lógica entre el sistema operativo y las copias.
• Regla 3-2-1 documentada.
• Registro de ejecuciones y errores.
• Prueba periódica de restauración.
• Procedimiento escrito ante pérdida, acceso indebido o ransomware.
• Revisión cuando se incorpora una herramienta nueva.

Este diseño no garantiza que nunca se produzca un incidente. Ningún proveedor serio debería prometerlo. Su función es reducir la probabilidad, limitar el impacto y permitir una respuesta demostrable.

Verificación final del sistema

Antes de dar por configuradas las copias de seguridad de pacientes, el responsable de la consulta debe poder responder afirmativamente a estas preguntas:

• ¿Se han inventariado todos los sistemas que contienen datos clínicos?
• ¿Existen tres copias, incluida la original?
• ¿Están distribuidas en dos soportes distintos?
• ¿Hay una copia fuera de las instalaciones?
• ¿Los datos almacenados están cifrados?
• ¿Las transferencias utilizan TLS?
• ¿Las cuentas tienen 2FA?
• ¿Cada usuario tiene permisos propios?
• ¿Se ha firmado un CET con el proveedor correspondiente?
• ¿Se conoce la ubicación de los servidores y de los subencargados?
• ¿Existe un procedimiento escrito?
• ¿Se registran los fallos?
• ¿Se ha probado la restauración?
• ¿Se sabe quién debe actuar ante una brecha?
• ¿Puede notificarse el incidente dentro del plazo de 72 horas cuando corresponda?

Si alguna respuesta es negativa, el sistema está incompleto. No necesariamente significa que toda la organización incumpla el RGPD, pero sí que existe un riesgo operativo o documental que debe mitigarse.

Las copias de seguridad de datos de pacientes en psicología no deben configurarse como una tarea aislada del sistema de privacidad. Forman parte del control de acceso, la gestión de proveedores, la continuidad de la consulta y la respuesta ante incidentes. La regla 3-2-1 aporta redundancia. El cifrado limita la exposición. La documentación acredita la responsabilidad proactiva. Las pruebas de restauración demuestran que todo lo anterior funciona.

El criterio es simple: conservar menos promesas y más evidencias. El sistema debe poder cifrar, recuperar, registrar y justificar cada decisión relevante.