Pregunta a cualquier clínica si hace copias de seguridad y la respuesta será que sí. Pregunta cuándo fue la última vez que alguien restauró una de esas copias para comprobar que funcionaba, y el silencio es casi unánime. Esa distancia, entre tener copias y poder recuperarlas, es exactamente lo que la norma regula, y casi nadie la lee así.
Porque el Reglamento General de Protección de Datos no dice en ningún sitio "haga copias de seguridad". Dice otra cosa, y es más exigente.
Lo que dice el artículo 32, letra por letra
El artículo 32.1 del RGPD obliga al responsable y al encargado del tratamiento a aplicar medidas técnicas y organizativas apropiadas para garantizar un nivel de seguridad adecuado al riesgo. Y enumera, entre esas medidas, tres que aquí importan:
- Letra b): la capacidad de garantizar la confidencialidad, integridad, disponibilidad y resiliencia permanentes de los sistemas y servicios de tratamiento. La disponibilidad está al mismo nivel que la confidencialidad: que nadie vea los datos y que tú puedas verlos son dos obligaciones, no una.
- Letra c): la capacidad de restaurar la disponibilidad y el acceso a los datos personales de forma rápida en caso de incidente físico o técnico. La palabra clave no es copiar, es restaurar, y no es restaurar algún día, es con rapidez.
- Letra d): un proceso de verificación, evaluación y valoración regulares de la eficacia de las medidas técnicas y organizativas. Es decir: hay que comprobar periódicamente que lo que has montado funciona. Una copia que nunca se ha restaurado no ha superado ninguna verificación.
El apartado 2 remata el razonamiento: para evaluar si el nivel de seguridad es adecuado hay que tener en cuenta, en particular, los riesgos de destrucción, pérdida o alteración accidental o ilícita de los datos. No solo el acceso no autorizado.
Traducido a una clínica: la obligación no se cumple teniendo un disco duro con copias. Se cumple pudiendo demostrar que, si mañana el servidor arde o se cifra, la agenda y las historias clínicas vuelven a estar disponibles en un plazo que has definido y has probado.
Sincronizar no es copiar
Este es el malentendido más caro y el más extendido, porque parece que está resuelto y no lo está.
Una carpeta sincronizada con la nube replica lo que pasa en tu ordenador. Si borras un archivo, se borra en la nube. Si un ransomware cifra tus ficheros, la versión cifrada se sube y sustituye a la buena. Si alguien edita una historia clínica por error, el error viaja. La sincronización protege frente a que se rompa el disco duro, y poco más.
Una copia de seguridad es otra cosa: es una fotografía del estado de los datos en un momento determinado, guardada en un sitio que no se ve afectado por lo que pase en el origen, y con histórico suficiente para poder volver a antes del problema. Si tu única protección es una carpeta sincronizada, lo que tienes es una réplica de tus errores en dos sitios.
La diferencia tiene una prueba sencilla: si borras algo hoy y te das cuenta dentro de tres semanas, ¿puedes recuperarlo? Si la respuesta es no, no tienes copias de seguridad.
La regla 3-2-1, y los dos números que se le añadieron después
La regla clásica de copias de seguridad es la 3-2-1: tres copias de los datos, en dos soportes o tecnologías distintas, y una de ellas fuera de las instalaciones. Nació mucho antes que el ransomware y sigue siendo el mínimo razonable.
Lo que el ransomware cambió es que una copia accesible desde la red no es una copia a salvo: si el equipo comprometido puede escribir en ella, el cifrado llega también allí. De ahí que hoy se hable de 3-2-1-1-0, donde el primer uno nuevo es una copia inmutable o desconectada, que no se puede modificar ni borrar durante un periodo definido, y el cero es cero errores en la verificación de la restauración.
Ese cero final es, en términos legales, la letra d) del artículo 32. No es una ocurrencia del sector: es la traducción operativa de lo que la norma pide.
La prueba que casi nadie hace
Restaurar una copia de prueba es incómodo, lleva tiempo y parece innecesario mientras todo funciona. Es también lo único que distingue un plan de copias de una carpeta con ficheros.
Una prueba de restauración decente responde a cuatro preguntas, y conviene escribir las respuestas con fecha:
- ¿Se puede abrir lo restaurado? No basta con que el fichero exista: hay que comprobar que la base de datos monta, que las imágenes se ven y que los documentos adjuntos están.
- ¿Cuánto se ha tardado? Ese número es tu tiempo real de recuperación, y es el que tienes que comparar con lo que tu clínica puede aguantar cerrada.
- ¿Cuántos datos se habrían perdido? La distancia entre la última copia buena y el momento del incidente. Si la copia es diaria a las tres de la madrugada y el servidor cae a las siete de la tarde, se pierde un día de consulta.
- ¿Quién sabe hacerlo? Si solo lo sabe una persona y esa persona está de vacaciones, el plan tiene un punto único de fallo que no es técnico.
Con hacerlo una vez al año y dejarlo documentado, una clínica pequeña está por delante de la mayoría, y tiene algo que enseñar si alguna vez le preguntan.
Perder los datos es una brecha, y se notifica
Conviene saberlo antes de que pase. El artículo 33 del RGPD obliga a notificar a la autoridad de control cualquier violación de la seguridad de los datos personales, sin dilación indebida y, de ser posible, en un plazo máximo de 72 horas desde que se tiene constancia, salvo que sea improbable que suponga un riesgo para los derechos y libertades de las personas.
Y una violación no es solo que alguien acceda a los datos. La pérdida de disponibilidad también lo es. Un servidor cifrado por un ransomware del que no se puede recuperar la información es una brecha notificable aunque el atacante no se haya llevado un solo dato.
Aquí está el argumento que convence a quien no se deja convencer por la ley: una copia de seguridad que funciona convierte un desastre en una molestia. Con restauración probada, el incidente se resuelve en horas y el riesgo para los pacientes puede ser bajo. Sin ella, hay que notificar, posiblemente informar a los pacientes afectados, y explicar por qué no se podía recuperar la información que se estaba obligado a custodiar.
Cuánto tiempo hay que poder recuperar
La respuesta no está en el RGPD sino en la Ley 41/2002. Su artículo 17.1 obliga a conservar la documentación clínica en condiciones que garanticen su mantenimiento y su seguridad, como mínimo cinco años desde la fecha del alta de cada proceso asistencial, y precisa que no es necesario conservarla en el soporte original. Los datos relativos al nacimiento, incluidas las pruebas de filiación materna, no se eliminan nunca.
Ese plazo tiene una consecuencia práctica que se pasa por alto: no basta con poder restaurar el estado de ayer. Hay que poder acreditar la documentación de hace años, lo que obliga a pensar en el archivo a largo plazo y en qué pasa si cambias de software por el camino.
Y una responsabilidad que no se delega: el mismo artículo 17 deja la custodia en manos de la dirección del centro y, en el caso de los profesionales que ejercen de forma individual, en las suyas propias. El proveedor de software es encargado del tratamiento; el responsable sigue siendo la clínica. Si el proveedor pierde los datos, el paciente reclama a la clínica.
Seis preguntas para tu proveedor
Si tu historia clínica está en la nube, buena parte de esto lo hace otro. Eso no te exime, pero sí convierte tu obligación en saber qué te están dando. Estas son las preguntas que conviene hacer por escrito:
- ¿Cada cuánto se hace la copia y cuánta información se perdería en el peor caso?
- ¿Dónde están físicamente las copias? Si salen de la Unión Europea, hay que saberlo y documentarlo.
- ¿Están cifradas en tránsito y en reposo, y quién tiene las claves?
- ¿Hay una copia que el propio sistema no pueda modificar ni borrar? Es la defensa frente al ransomware.
- ¿Quién prueba las restauraciones y con qué periodicidad? Pide el resultado de la última.
- ¿Qué pasa si me voy? En qué formato y en cuánto tiempo recuperas tus datos, y qué pasa con las copias después.
Si alguna de las seis no tiene respuesta clara, ahí está tu riesgo.
Cómo lo resolvemos en DriCloud
Siendo concretos, que es de lo que va este artículo: en DriCloud las copias de seguridad son diarias, cifradas y replicadas en dos países europeos, Alemania y Francia, con redundancia geográfica. Los datos viajan con cifrado SSL de 256 bits y se guardan cifrados también en el servidor. Cada clínica tiene su propia base de datos y su instancia, de modo que los datos de dos clientes nunca se mezclan. Y todo el alojamiento, copias incluidas, permanece dentro de la Unión Europea.
A eso se suma la parte de control de accesos, que es la otra mitad del artículo 32: permisos por rol, restricción de acceso por IP para que solo se entre desde donde tú decidas, doble factor de autenticación y auditoría completa de cada acción con su autor y su fecha. Está detallado en la página de seguridad y cumplimiento.
Lo que sigue siendo tuyo, y conviene no olvidarlo, es el resto del cumplimiento: la base legal con la que tratas los datos, el delegado de protección de datos si tu centro entra en el supuesto, y el protocolo de las primeras 72 horas. Lo hemos desarrollado en el artículo sobre protección de datos en una clínica.
