Brecha de datos: qué hacer en las primeras 72 horas (RGPD)
El artículo 33 del RGPD obliga a notificar a la autoridad de control (en España, la AEPD) las brechas de seguridad de datos personales sin dilación indebida y, cuando sea posible, en un plazo máximo de 72 horas desde que se tiene constancia de ellas.
Hora 0 a 4: contener sin destruir evidencias
Aísla los sistemas afectados de la red, pero no los apagues ni los reinstales a la ligera: perderías la memoria volátil y los registros que permiten saber qué pasó. Cambia credenciales críticas y revoca sesiones y tokens activos.
Hora 4 a 24: entender el alcance
- › Qué datos personales se han visto afectados y de cuántas personas.
- › Vector de entrada y ventana temporal del incidente.
- › Si ha habido exfiltración real o solo acceso.
- › Si los datos estaban cifrados y con qué robustez.
Hora 24 a 72: decidir y notificar
Si la brecha entraña un riesgo para los derechos y libertades de las personas, hay que notificar a la AEPD. Si el riesgo es alto, además debes comunicarlo a los propios afectados en un lenguaje claro. La notificación puede hacerse por fases si aún no tienes toda la información: es preferible notificar con datos parciales que agotar el plazo.
Lo que se evalúa después
La autoridad valora si habías aplicado medidas técnicas y organizativas apropiadas antes del incidente. Aquí es donde tener auditorías periódicas, un plan de respuesta y evidencias de remediación cambia por completo la conversación.
Documenta siempre el incidente en tu registro interno de brechas, aunque decidas no notificar: esa decisión también debe estar justificada.
Qué es una brecha, exactamente
El RGPD define la violación de seguridad como toda la que ocasione destrucción, pérdida, alteración, comunicación o acceso no autorizados a datos personales. Son tres tipos y conviene distinguirlos, porque no todo el mundo piensa en el segundo y el tercero.
- › De confidencialidad: alguien accede a datos sin estar autorizado.
- › De integridad: los datos se alteran de forma no autorizada.
- › De disponibilidad: se pierde el acceso a los datos, y un cifrado por ransomware entra aquí aunque nadie se los lleve.
Qué hay que documentar aunque no se notifique
Todas las brechas, sin excepción. El artículo 33.5 obliga a llevar un registro interno con los hechos, sus efectos y las medidas correctoras, tanto si se notifica como si se decide que no procede. Ese registro es lo primero que pide una autoridad de control cuando aparece por otra vía, y no tenerlo agrava cualquier expediente.
Qué contiene la notificación
- › Naturaleza de la brecha, con las categorías y el número aproximado de afectados y de registros.
- › Datos de contacto del delegado de protección de datos o del punto de contacto.
- › Consecuencias probables.
- › Medidas adoptadas o propuestas, incluidas las de mitigación del daño.
Si no tienes toda la información en 72 horas, se notifica igual y se completa después de forma escalonada. Esperar a tenerlo todo es el error que convierte un incidente en una sanción.
Las primeras cuatro horas deciden el resto
En la práctica el plazo se gana o se pierde antes del incidente. Hace falta saber quién declara la brecha, quién decide si se notifica, quién redacta y quién firma. Si eso se improvisa, se consumen las 72 horas discutiendo si aquello era o no era una brecha.
Cómo reduce el riesgo una auditoría
De dos formas concretas. Encuentra los accesos que permitirían la brecha antes de que ocurra, y comprueba si el cifrado y el control de acceso están donde dices que están, que es lo que puede eximir de notificar a los afectados. Auditamos la aplicación, el correo y la red interna, y a los seis meses verificamos la corrección.
Fuentes
Cómo lo abordamos
Los servicios con los que resolvemos lo que cuenta este artículo:
- ›Auditoría de infraestructura interna · Pentesting desde dentro de tu red, como quien ya ha entrado: movimiento lateral, escalada de privilegios y hasta dónde se llega en el dominio.
- ›Auditoría de Microsoft 365 · Auditoría de tu tenant de Microsoft 365 contra los CIS Benchmarks: MFA, acceso condicional y los permisos concedidos a aplicaciones de terceros.
- ›Auditoría SGSI (ISO 27001 / ENS) · Auditoría de tu SGSI frente a ISO 27001 y ENS: qué controles funcionan de verdad, cuáles están solo sobre el papel y qué falta para certificarte.