Brecha de seguridad en clínicas sanitarias: protocolo de actuación y notificación a la AEPD

1. Qué es una brecha de seguridad según el RGPD y qué tipos afectan a las clínicas

El artículo 4.12 del RGPD define la brecha de seguridad como «toda violación de la seguridad que ocasione la destrucción, pérdida o alteración accidental o ilícita de datos personales transmitidos, conservados o tratados de otra forma, o la comunicación o acceso no autorizados a dichos datos».

1.1. Los tres tipos, y por qué se distinguen

Esta definición amplia abarca tres tipos de brechas que las clínicas deben distinguir porque tienen consecuencias y tratamientos distintos:

1.2. En sanidad la presunción de riesgo es alta

La obligación de notificar a la AEPD aplica a los tres tipos cuando la brecha supone un riesgo para los derechos y libertades de los pacientes. En el sector sanitario, dado que siempre se manejan datos de categoría especial, la presunción de riesgo es alta en casi cualquier incidente.

1.3. Dónde encaja este protocolo

El marco legal completo que regula estas obligaciones está en nuestra guía completa de cumplimiento RGPD en clínicas sanitarias, y las medidas preventivas que reducen la probabilidad de llegar a este punto en las amenazas de ciberseguridad más comunes.

2. Fase 1 — Contención inmediata: las primeras 2 horas son críticas

Las decisiones de las dos primeras horas son las que más cuesta corregir después.

Las primeras dos horas tras detectar un incidente son las más críticas. Los errores cometidos en esta fase son los más difíciles de corregir y los que más agravan las consecuencias legales y operativas. Sigue este orden estricto:

2.1. Activar el protocolo de incidentes — Minuto 0

• ☐ Notificar inmediatamente al DPO y a la dirección de la clínica.
• ☐ Activar el modo de contingencia manual para la asistencia (agenda en papel si los sistemas están caídos).
• ☐ Designar un responsable único de coordinación del incidente para toda la duración del protocolo.
• ☐ Abrir un registro cronológico del incidente (fecha, hora y descripción de cada acción tomada). Este registro será la prueba documental ante la AEPD.

2.2. Aislar los sistemas afectados — Minutos 0-30

• ☐ Desconectar de la red (Ethernet y Wi-Fi) los equipos sospechosos o confirmadamente comprometidos.
• ☐ NO apagar los equipos afectados salvo instrucción expresa del equipo forense: los logs en memoria RAM son evidencia forense que se pierde al apagar.
• ☐ Revocar o suspender temporalmente las credenciales de acceso al software clínico de los equipos afectados.
• ☐ Si el ataque es activo (ransomware propagándose), desconectar el switch de red principal para aislar toda la red de la clínica.
• ☐ Verificar si las copias de seguridad cloud están intactas e inaccesibles para el malware.

2.3. Llamadas prioritarias — Minutos 30-120

• ☐ Proveedor del software clínico: alertar de la situación y pedir bloqueo preventivo del acceso desde los IPs afectados.
• ☐ Empresa de respuesta a incidentes (DFIR): si no se tiene capacidad interna, contratar soporte externo especializado. El tiempo de respuesta habitual es de 2-4 horas.
• ☐ Compañía de ciberseguros: notificar el incidente en el plazo establecido en la póliza (muchas exigen notificación en las primeras 24-48 horas).
• ☐ Asesoría jurídica especializada: para guiar la comunicación con la AEPD desde el primer momento.

Error crítico más frecuente en esta fase: intentar resolver el problema internamente antes de notificar al DPO y a la asesoría jurídica. Cada hora de retraso en activar el protocolo formal reduce el margen para preparar la notificación a la AEPD y aumenta el riesgo de tomar decisiones (como pagar el rescate sin notificar) que multiplican la sanción.

3. Fase 2 — Evaluación del alcance: las horas 2 a 24

Con los sistemas afectados aislados y el equipo de respuesta activo, el objetivo de esta fase es determinar con precisión qué ha ocurrido para poder tomar decisiones informadas sobre la notificación a la AEPD. Las preguntas que debes responder:

3.1. Naturaleza del incidente

• ¿Qué tipo de brecha es? Confidencialidad, disponibilidad, integridad o combinación.
• ¿Cuál fue el vector de entrada? Email con adjunto malicioso, credencial comprometida, vulnerabilidad de software, dispositivo perdido, acceso interno indebido.
• ¿El ataque está activo o contenido? Si sigue activo, la prioridad es la contención antes que la investigación.
• ¿Cuándo comenzó? Los logs del software clínico y del firewall permiten determinar el inicio real del incidente, que puede ser anterior a la detección.

3.2. Datos afectados

• ¿Qué categorías de datos han sido comprometidos? Solo identificativos (nombre, email) o también datos de salud, financieros, datos de menores.
• ¿Cuántos pacientes afectados? Estimación inicial, con ajuste posterior según el análisis forense.
• ¿Los datos estaban cifrados? Si los datos comprometidos estaban cifrados con AES-256, el riesgo real para los pacientes es mínimo aunque haya habido acceso.
• ¿Han sido exfiltrados o solo bloqueados? El ransomware que solo cifra (sin exfiltrar) tiene menor riesgo de confidencialidad que el que extrae los datos antes de cifrarlos.

3.3. Evaluación del riesgo para los pacientes

Esta es la evaluación más crítica porque determina si hay obligación de notificar a los pacientes individualmente. Los factores que elevan el riesgo son:

• Datos de salud expuestos (siempre alto riesgo por su categoría especial).
• Datos de menores comprometidos.
• Combinación de datos que permita el robo de identidad.
• Datos financieros (número de tarjeta, IBAN) accesibles.
• Volumen alto de pacientes afectados.

Los factores que reducen el riesgo son: datos cifrados, número reducido de afectados, datos solo de carácter identificativo sin datos de salud, o brechas internas contenidas sin exfiltración confirmada. La reconstrucción cronológica del propio incidente se apoya en el registro de eventos del sistema, imprescindible para la investigación forense posterior.

Y todo esto depende del registro de accesos. Depende de poder responder quién entró, a qué y cuándo. Si el registro de accesos no existe, o existe pero no distingue una consulta de una exportación, el alcance se estima en vez de acreditarse, y esa estimación es la que hay que corregir al alza delante de la Agencia. En obeliOmed queda constancia de cada cambio con su autor, su fecha y el valor anterior, sobre la misma historia clínica electrónica, y los permisos van por rol y por pantalla. Qué exigirle a cualquier proveedor en esto está en qué debe cumplir un software sanitario.

4. Fase 3 — Notificación a la AEPD: el plazo improrrogable de 72 horas

El artículo 33 del RGPD establece la obligación de notificar la brecha a la autoridad de control (en España, la AEPD) en el plazo de 72 horas desde que el responsable del tratamiento tenga conocimiento de ella. Este plazo es improrrogable.

Si no hay todos los datos a tiempo, una notificación inicial parcial también cuenta.

4.1. Cuándo NO es obligatorio notificar

La notificación a la AEPD no es obligatoria cuando sea improbable que la brecha suponga un riesgo para los derechos y libertades de los pacientes. En la práctica esto significa: brechas con datos irrelevantes o completamente cifrados, errores internos sin exposición externa y con rectificación inmediata. En caso de duda, la AEPD recomienda notificar. No notificar y haber debido hacerlo es una infracción grave; notificar de más no lo es.

4.2. Pasos del proceso de notificación ante la AEPD

1. Accede a sedeagpd.gob.es con certificado digital o Cl@ve PIN del representante legal.
2. Busca el trámite «Notificación de brechas de seguridad».
3. Rellena el formulario con los datos disponibles en ese momento (ver contenido obligatorio abajo).
4. Si no tienes todos los datos, marca la casilla de «notificación parcial» e indica el plazo en el que completarás la información (máximo 30 días adicionales).
5. Guarda el acuse de recibo con número de registro: es tu prueba de notificación en plazo.

4.3. Contenido obligatorio de la notificación

• ☐ Naturaleza de la brecha: tipo (confidencialidad, disponibilidad, integridad), origen y vector de ataque.
• ☐ Categorías de datos afectados: identificativos, datos de salud, financieros, datos de menores.
• ☐ Número aproximado de personas afectadas: pacientes, empleados, proveedores.
• ☐ Consecuencias probables: qué daños pueden sufrir los afectados como resultado de la brecha.
• ☐ Medidas tomadas o propuestas: qué se ha hecho para contener la brecha y qué se va a hacer.
• ☐ Datos del DPO: nombre, email y teléfono de contacto para el seguimiento.
• ☐ Fecha y hora de detección del incidente por la clínica.

El cómputo exacto de las 72 horas.

El plazo empieza cuando el responsable del tratamiento (la dirección de la clínica) tiene conocimiento suficiente del incidente, no cuando ocurrió. Si el ataque ocurrió a las 2:00 del martes pero no lo descubriste hasta las 9:00 del miércoles, las 72 horas empiezan el miércoles a las 9:00. Esto hace que la velocidad de detección sea crítica: cada hora que un ataque pasa desapercibido consume margen del plazo de notificación.

5. Fase 4 — Comunicación a los pacientes afectados

El artículo 34 del RGPD añade una segunda obligación cuando la brecha supone un alto riesgo para los derechos y libertades de los pacientes: comunicarlo individualmente a cada uno de los afectados. Esta comunicación no sustituye a la notificación a la AEPD, se hace en paralelo.

5.1. Cuándo es obligatoria la comunicación a los pacientes

La comunicación individual es obligatoria cuando la brecha puede producir daños significativos a los afectados: discriminación, robo de identidad, pérdidas financieras, daño a la reputación o cualquier otro perjuicio económico o social. En el sector sanitario, la exposición de datos de salud de cualquier paciente activa casi siempre esta obligación por la sensibilidad inherente de esos datos.

5.2. Excepciones a la comunicación individual

No es obligatoria la comunicación individual cuando se cumple alguna de estas tres condiciones:

• Los datos estaban cifrados de forma que son inaccesibles para quien los obtuvo.
• Se han tomado medidas posteriores que garantizan que el riesgo elevado ya no existe (por ejemplo, se ha recuperado el dispositivo perdido sin evidencia de acceso).
• La comunicación individual supondría un esfuerzo desproporcionado, en cuyo caso puede sustituirse por una comunicación pública (nota de prensa, aviso en la web). La AEPD debe valorar este supuesto.

5.3. Qué debe decir la comunicación al paciente

La comunicación debe redactarse en lenguaje claro y sencillo, sin tecnicismos, y debe incluir:

• Descripción de lo ocurrido en términos comprensibles (sin detalles técnicos innecesarios).
• Qué datos suyos pueden haber sido afectados.
• Las consecuencias probables para el paciente.
• Las medidas que la clínica ha tomado para solucionar el problema.
• Las medidas que el paciente puede tomar para protegerse (cambiar contraseñas, revisar movimientos bancarios, alertar a su banco si hay datos financieros).
• Datos de contacto del DPO para consultas.
• Derecho a reclamar ante la AEPD.

6. Fase 5 — Recuperación y mejora post-incidente

Una vez contenida la brecha y cumplidas las obligaciones de notificación, llega la fase de recuperación. Esta fase es también la más valiosa desde el punto de vista de la mejora continua: ningún incidente de seguridad debe cerrarse sin extraer las lecciones que eviten el siguiente.

6.1. Recuperación técnica

• ☐ Restaurar desde las copias de seguridad más recientes no comprometidas. Verificar su integridad antes de restaurar.
• ☐ Eliminar el vector de entrada antes de reconectar los sistemas a la red (si fue una vulnerabilidad de software, aplicar el parche; si fue una credencial comprometida, cambiarla y activar MFA).
• ☐ Escaneado completo de todos los sistemas antes de volver a la operativa normal.
• ☐ Monitorización intensiva durante las 72 horas siguientes a la recuperación para detectar reinfecciones.
• ☐ Verificar que las copias de seguridad siguen intactas y funcionales tras la recuperación.

6.2. Análisis post-incidente

En los 30 días siguientes al cierre del incidente, el DPO debe elaborar un informe post-incidente que responda a:

• ¿Cómo entró el atacante? ¿Qué vulnerabilidad o error humano lo permitió?
• ¿Cuánto tiempo estuvo activo sin detectarse? ¿Qué falló en la monitorización?
• ¿Las medidas de contención funcionaron correctamente?
• ¿La notificación a la AEPD se hizo en plazo y con información correcta?
• ¿Qué medidas técnicas u organizativas habrían prevenido o limitado el incidente?

6.3. Actualización del plan de seguridad

El plan de seguridad y el protocolo de brechas deben actualizarse con las lecciones aprendidas antes de cerrarse el expediente. Un incidente que no mejora el sistema de seguridad es un incidente que se repite. La auditoría RGPD post-incidente debe ejecutarse en los 60 días siguientes para verificar que todas las mejoras se han implementado correctamente.

7. Plantillas de notificación listas para adaptar

Estas plantillas son puntos de partida. Adáptalas a las circunstancias específicas de tu incidente y revísalas siempre con tu asesoría jurídica antes de enviar.

7.1. Plantilla de notificación interna al DPO y dirección

7.2. Plantilla de comunicación al paciente afectado

Va escrita tuteando, que es como habla el resto de este sitio. Si tu centro emplea un registro más formal con sus pacientes, cambia el tratamiento en toda la carta —no a medias— y deja el resto igual: lo que importa son las seis preguntas, que son las que exige el artículo 34.2 del RGPD.

8. Errores críticos que agravan la sanción de la AEPD

8.1. Los seis que más se repiten

Estos son los errores más frecuentes en la gestión de brechas en clínicas privadas. Cualquiera de ellos empeora la posición del centro, porque todos tocan algún criterio de graduación:

1. No notificar pensando que «no ha pasado nada grave». La obligación de notificar a la AEPD existe aunque no haya confirmación de daño real. La evaluación del riesgo la hace el responsable del tratamiento —es decir, la clínica—, y por eso hay que dejarla razonada y fechada por escrito, se notifique o no. Si había riesgo y no se notificó, la sanción es doble: por la brecha y por la omisión de notificación.
2. Pagar el rescate del ransomware sin notificar. El pago del rescate no elimina la obligación de notificación a la AEPD. Hacerlo sin notificar convierte la brecha en dos infracciones independientes.
3. Esperar a tener «todos los datos» para notificar. El RGPD prevé la notificación parcial: si no tienes todos los datos, notifica con lo que tienes y completa después. Esperar a tenerlo todo para no superar las 72 horas es el error más común y el más sancionado.
4. Destruir o alterar evidencias. Formatear los equipos afectados antes del análisis forense destruye evidencias que podrían determinar el alcance exacto de la brecha y potencialmente exonerar a la clínica de responsabilidad adicional.
5. Comunicar la brecha en redes sociales antes que a la AEPD. Publicar mensajes en redes sociales sobre el incidente antes de notificar a la AEPD puede usarse en contra de la clínica para acreditar que tenía conocimiento del incidente antes de lo declarado.
6. No documentar el proceso de respuesta. Sin registro cronológico del incidente, la clínica no puede demostrar que actuó con diligencia. La AEPD mira tanto qué ocurrió como cómo se gestionó.

8.2. El que no sale en las listas: no avisar a tu propio proveedor

Si el incidente afecta a un sistema de un tercero, el contrato de encargo suele obligarle a avisarte a ti, pero también a ti a comunicarle lo que detectes. Se olvida casi siempre, y deja al proveedor sin poder contener lo que sigue abierto en otros clientes. Es además una buena prueba de diligencia: el correo enviado a las dos horas, con su hora, pesa en el expediente. Quién responde de qué en esa cadena está en cómo encajan el RGPD y la ley española.

8.3. Y el más caro de todos: no tener a quién llamar

El protocolo se cae si a las once de la noche nadie sabe quién decide. Tres teléfonos escritos y actualizados —dirección, delegado de protección de datos y proveedor— resuelven más que cualquier documento largo, y son lo primero que falta cuando el incidente cae en fin de semana. Cuándo es obligatorio tener delegado y qué se le pide está en cuándo es obligatorio el DPO en clínicas, y lo que la Agencia mira después, en qué sanciona la AEPD a clínicas sanitarias.

9. Qué aporta obeliOmed cuando el reloj ya corre

9.1. Reconstruir quién vio qué

La fase 2 se atasca siempre en el mismo punto: acreditar el alcance. Cuando alguien corrige un dato del expediente, el dato se modifica —hace falta, porque los profesionales se equivocan al guardar— y el cambio queda registrado con su autor, su fecha y el valor anterior. Eso es lo que se lleva a la notificación en vez de una estimación que luego haya que corregir al alza.

9.2. Permisos por rol, que es lo que evita el incidente más común

El acceso indebido de alguien de dentro es el caso que más se repite, y su agravante es el permiso de más. Los permisos se conceden por rol y por pantalla sobre la misma historia clínica electrónica, de forma que recepción no llega a lo que no necesita. Es la medida con mejor relación entre esfuerzo y riesgo evitado de toda esta guía.

9.3. Dónde están los datos, y qué sigue siendo tuyo

Los servidores están en España. Los documentos clínicos y los campos marcados como sensibles se cifran con AES-256-GCM, con la clave derivada por ámbito mediante HKDF-SHA-256 y rotación de claves, y la conexión viaja bajo TLS. Se cifran esos documentos y esos campos, no el expediente entero, y esa precisión importa al invocar la excepción del artículo 34.3. Y cada centro puede descargar en cualquier momento una copia de sus propios datos.