Qué hacer ante una brecha de datos y cómo notificarla a la AEPD
Si tu empresa sufre una brecha de datos personales, tienes 72 horas desde que te enteras para notificarla a la Agencia Española de Protección de Datos, salvo que sea improbable que suponga un riesgo para los afectados. No son 72 horas desde que ocurrió el incidente: son 72 horas desde que tienes constancia de él. Y no hace falta que hayas terminado la investigación para notificar. Este artículo te explica, paso a paso y sin jerga, qué hacer desde el minuto uno.
Qué es exactamente una brecha de datos
El Reglamento General de Protección de Datos (RGPD) define la brecha como cualquier incidente que provoque la destrucción, pérdida, alteración, comunicación o acceso no autorizado a datos personales. Es una definición mucho más amplia de lo que la mayoría imagina.
Es una brecha que te entren en el servidor y se lleven la base de datos de clientes, sí. Pero también lo son:
- Enviar un correo a cien clientes con todas las direcciones en el campo «Para» en lugar de en copia oculta.
- Perder un portátil o un móvil de empresa sin cifrar con la agenda de contactos dentro.
- Que un ransomware te cifre los ficheros y te deje sin acceso a los datos, aunque nadie se los haya llevado.
- Que un empleado que se fue siga teniendo acceso al CRM y entre a mirar.
- Que un formulario de tu web guarde los envíos en una carpeta accesible desde internet.
- Tirar a la basura documentación en papel con datos sin destruir.
La destrucción y la pérdida de disponibilidad cuentan igual que el robo. Es el error más común: creer que si nadie ha visto los datos, no ha pasado nada.
Las primeras horas: contener antes que investigar
Lo primero no es notificar, es parar la sangría. El orden importa porque cada hora que el agujero sigue abierto amplía el número de afectados y empeora tu posición.
- Contén. Desconecta el sistema comprometido de la red, revoca las credenciales expuestas, cierra el acceso público a lo que estuviera abierto. Si es un correo mal enviado, pide la retirada y avisa a los destinatarios de que lo borren.
- No borres las pruebas. Esto es contraintuitivo. Apagar y formatear el servidor destruye los registros que necesitas para saber qué pasó y para demostrar después que actuaste bien. Haz una copia del estado del sistema y de los registros de acceso antes de tocar nada.
- Levanta un acta. Fecha y hora en que lo detectaste, quién lo detectó, qué se vio. Ese momento de constancia es el que marca el inicio del plazo de 72 horas y es lo primero que te preguntarán.
- Avisa a quien corresponda. Dirección, delegado de protección de datos si lo tienes, y tu proveedor tecnológico. Si el incidente está en un servicio contratado, el proveedor actúa como encargado del tratamiento y tiene obligación de avisarte a ti sin dilación indebida.
Cómo decidir si hay que notificar o no
El artículo 33 del RGPD obliga a notificar salvo que sea improbable que la brecha suponga un riesgo para los derechos y libertades de las personas. La carga de justificar que no hay riesgo recae en ti, no en la Agencia.
Para valorarlo se miran tres cosas: qué tipo de datos se han visto afectados, a cuánta gente afectan y qué consecuencias reales puede tener. No es lo mismo una lista de correos de una newsletter que un fichero con DNI, datos bancarios o información de salud. Los datos de las categorías especiales del artículo 9 del RGPD (salud, ideología, origen étnico, orientación sexual, biometría) elevan el riesgo casi automáticamente.
Hay un matiz que salva a muchas empresas: si los datos estaban cifrados con un algoritmo robusto y la clave no se ha visto comprometida, el riesgo real para los afectados baja mucho. Es el mejor argumento para no tener que notificar, y solo lo tienes si cifraste antes de que pasara nada.
Ante la duda, notifica. Notificar de más no se sanciona. No notificar cuando había que hacerlo, sí.
Cómo se presenta la notificación a la AEPD
La notificación se hace por vía electrónica en la sede electrónica de la AEPD, con el formulario específico de notificación de brechas de seguridad de datos personales. Necesitas certificado digital o Cl@ve para identificarte.
El artículo 33.3 del RGPD fija el contenido mínimo, que el propio formulario te va pidiendo:
- Naturaleza de la brecha: qué ha pasado, cómo y cuándo.
- Categorías y número aproximado de interesados afectados y de registros comprometidos.
- Datos de contacto del delegado de protección de datos o del punto de contacto de la empresa.
- Consecuencias probables de la brecha.
- Medidas adoptadas o propuestas para resolverla y mitigar sus efectos.
Dos detalles prácticos que quitan mucha presión. El primero: el artículo 33.4 permite notificar por fases. Si a las 60 horas sabes que has sufrido un incidente pero todavía no conoces el alcance exacto, notificas con lo que tienes y completas la información después. El segundo: si se te pasa el plazo, notifica igual, indicando los motivos del retraso. Llegar tarde es mejor que no llegar.
Cuándo tienes que avisar también a tus clientes
La notificación a la AEPD y la comunicación a los afectados son dos obligaciones distintas. El artículo 34 del RGPD exige avisar a los interesados, sin dilación indebida, cuando la brecha entrañe un alto riesgo para sus derechos y libertades. Es un listón más alto que el de notificar a la Agencia.
El aviso debe ir en lenguaje claro y sencillo, no en jerga jurídica, y explicar qué ha pasado, qué datos están afectados, qué consecuencias puede tener y qué debe hacer la persona. Si se han comprometido contraseñas, lo útil es decir «cambia tu contraseña y, si la repetías en otros servicios, cámbiala también allí», no un párrafo de responsabilidad limitada.
El RGPD te exime de avisar uno a uno si los datos estaban cifrados, si ya has tomado medidas que eliminan el alto riesgo, o si contactar individualmente supone un esfuerzo desproporcionado; en este último caso basta con una comunicación pública equivalente.
El registro de brechas: la obligación que casi nadie cumple
El artículo 33.5 del RGPD te obliga a documentar todas las brechas, incluidas las que decides no notificar. Ese registro interno es lo que la Agencia pide cuando investiga, y es la prueba de que hiciste un análisis razonado en lugar de mirar hacia otro lado.
No necesitas una herramienta cara. Una tabla con estos campos cumple:
| Campo | Qué anotar |
|---|---|
| Fecha y hora del incidente | Cuándo ocurrió, si se sabe, y cuándo lo detectaste |
| Descripción | Qué pasó y por qué vía |
| Datos y personas afectadas | Categorías de datos y número aproximado de interesados |
| Valoración del riesgo | Alto, medio o bajo, y el razonamiento |
| Decisión | Notificado a la AEPD, comunicado a los afectados, o ninguna de las dos y por qué |
| Medidas | Qué se hizo para contener y qué se cambió para que no se repita |
Guárdalo con los correos, capturas y registros que respalden cada entrada.
Cómo reducir el riesgo antes de que pase
Las brechas que peor acaban no son las más sofisticadas: son aquellas en las que la empresa no sabe qué datos tiene, dónde están ni quién accede a ellos. Cuatro medidas que marcan la diferencia y que puedes abordar este trimestre:
- Inventaría tus datos. Qué datos personales tratas, en qué sistemas viven y quién tiene acceso. Sin esto no puedes valorar el riesgo de nada en 72 horas.
- Cifra lo que sale de la oficina. Portátiles, móviles, copias de seguridad. Es lo que puede convertir un incidente grave en uno sin obligación de comunicar.
- Revisa los accesos cada trimestre. Cuentas de gente que ya no está, permisos de administrador repartidos sin criterio, accesos de proveedores antiguos.
- Escribe el protocolo antes. Un folio con a quién llamar, quién decide y quién presenta la notificación. En caliente nadie improvisa bien.
Por dónde empezar esta semana
Una brecha de datos se gestiona en horas, y lo que determina si acabas con un susto o con un expediente es lo que tengas preparado de antes: el inventario de datos, el cifrado, el control de accesos y un protocolo de tres pasos que alguien sepa ejecutar. La notificación en 72 horas es el trámite; la trazabilidad de lo que hiciste es lo que te sostiene después.
Si tu web, tu tienda online o tu aplicación tratan datos de clientes y no tienes claro dónde están ni quién puede llegar a ellos, ese es el punto de partida. En Tangram Consulting revisamos la arquitectura de datos y los accesos de aplicaciones a medida y de webs y tiendas en Drupal, y dejamos por escrito el protocolo que hay que seguir si algo falla. Cuéntanos cómo tratáis los datos de vuestros clientes y te decimos qué hay que ordenar primero.