¿Qué es una brecha de seguridad de datos personales?
Una brecha de seguridad es un incidente que provoca la destrucción, pérdida, alteración, divulgación o acceso no autorizado a datos personales, ya sea de forma accidental o ilícita.
Por tanto, no todas las brechas tienen su origen en sofisticados ataques informáticos.
Enviar un correo electrónico al destinatario equivocado, perder un portátil que contiene información de clientes o publicar accidentalmente documentación personal también pueden constituir una violación de seguridad de los datos personales.
¿Qué situaciones pueden considerarse una brecha de seguridad?
Entre los incidentes más habituales podemos encontrar:
- El envío de documentación personal al destinatario incorrecto.
- La pérdida o robo de un ordenador, teléfono móvil o memoria USB.
- El acceso no autorizado a una cuenta de correo electrónico.
- Un ataque de ransomware.
- El robo de credenciales mediante phishing.
- La publicación accidental de información personal en una página web.
- La eliminación de información sin disponer de una copia de seguridad.
- El acceso de un trabajador a información para la que no estaba autorizado.
- La exposición de bases de datos, contraseñas o documentos internos.
Una brecha puede afectar a la confidencialidad, cuando alguien accede a información que no debería conocer; a la integridad, cuando los datos se modifican indebidamente; o a la disponibilidad, cuando la organización pierde el acceso a ellos.
1. Detectar y contener el incidente
El primer objetivo debe ser evitar que el problema continúe.
Dependiendo del tipo de incidente, puede ser necesario:
- Cambiar inmediatamente determinadas contraseñas.
- Bloquear cuentas comprometidas.
- Cerrar sesiones abiertas.
- Revocar accesos.
- Desconectar temporalmente equipos afectados.
- Retirar documentos publicados por error.
- Recuperar información desde copias de seguridad.
- Contactar con proveedores tecnológicos.
- Bloquear un dispositivo perdido o robado.
- Conservar evidencias que permitan analizar posteriormente lo sucedido.
Actuar rápidamente puede limitar considerablemente el número de personas y datos afectados.
Sin embargo, la urgencia por contener el incidente no debe provocar que se destruyan evidencias necesarias para determinar posteriormente qué ocurrió.
2. Averiguar qué ha ocurrido
Una vez controlada la situación inicial, la organización debe reconstruir el incidente.
Es importante determinar:
- Cuándo comenzó.
- Cuándo fue detectado.
- Cómo se produjo.
- Si su origen fue interno o externo.
- Si fue accidental o intencionado.
- Qué sistemas estuvieron afectados.
- Durante cuánto tiempo pudo estar expuesta la información.
- Si una tercera persona llegó realmente a acceder a los datos.
Cuanto mejor se conozca el incidente, más precisa podrá ser la valoración de sus consecuencias.
3. Identificar los datos y las personas afectadas
No todas las filtraciones presentan el mismo nivel de riesgo.
La exposición de una dirección de correo electrónico aislada no suele tener las mismas posibles consecuencias que la filtración conjunta de nombres, DNI, cuentas bancarias, contraseñas o datos de salud.
Por ello, debe identificarse tanto el tipo de información comprometida como el número aproximado de registros y personas afectadas.
También debe analizarse si existen colectivos especialmente vulnerables y si los datos estaban protegidos mediante medidas como el cifrado. La AEPD recomienda considerar, entre otros elementos, las categorías de datos, el volumen de información, el número de afectados y la posibilidad real de identificar a las personas.
4. Analizar las posibles consecuencias
El siguiente paso consiste en valorar qué podría ocurrir a las personas cuyos datos se han visto comprometidos.
Entre las posibles consecuencias encontramos:
- Suplantación de identidad.
- Fraude económico.
- Acceso a otras cuentas.
- Utilización de contraseñas filtradas.
- Phishing dirigido.
- Pérdida de confidencialidad.
- Daños reputacionales.
- Discriminación.
- Pérdida de control sobre la información personal.
El análisis debe centrarse fundamentalmente en el riesgo para las personas, no únicamente en el impacto económico o reputacional que el incidente pueda provocar a la empresa.
5. ¿Todas las brechas deben notificarse a la AEPD?
No.
El RGPD establece que una brecha debe notificarse a la autoridad de control cuando sea probable que suponga un riesgo para los derechos y libertades de las personas afectadas.
Si después de realizar el análisis correspondiente se concluye justificadamente que resulta improbable que exista ese riesgo, puede no ser necesario notificarla.
Sin embargo, esto no significa que pueda ignorarse el incidente: todas las brechas deben quedar adecuadamente documentadas, incluyendo los hechos ocurridos, sus efectos y las medidas correctivas adoptadas.
6. El plazo de 72 horas
Cuando la brecha deba notificarse a la Agencia Española de Protección de Datos, la organización deberá hacerlo sin dilación indebida y, siempre que sea posible, dentro de las 72 horas siguientes a haber tenido constancia de ella.
Este plazo es especialmente importante.
No es necesario esperar a que termine completamente una investigación técnica para empezar a actuar.
Si todavía no se dispone de toda la información, el RGPD permite proporcionar determinados datos de manera progresiva y completar posteriormente la notificación. Si se supera el plazo de 72 horas, será necesario explicar los motivos del retraso.
La notificación debe incluir, entre otras cuestiones:
- La naturaleza de la brecha.
- Las categorías de interesados afectados.
- Los datos comprometidos.
- El número aproximado de afectados y registros, cuando sea posible.
- Las posibles consecuencias.
- Las medidas adoptadas o previstas para resolver el incidente.
- Las actuaciones destinadas a reducir sus efectos negativos.
7. ¿Cuándo hay que informar a las personas afectadas?
Existe además una obligación diferente a la notificación ante la AEPD.
Cuando sea probable que la brecha implique un alto riesgo para los derechos y libertades de las personas, también será necesario comunicar directamente el incidente a los afectados.
Esta comunicación debe realizarse sin dilación indebida y utilizando un lenguaje claro y comprensible.
Debe explicar qué ha sucedido, qué información se ha visto afectada, qué posibles consecuencias existen y qué puede hacer la persona para protegerse.
Por ejemplo, podría recomendarse:
- Modificar una contraseña.
- Activar la autenticación en dos pasos.
- Vigilar movimientos bancarios.
- Desconfiar de determinados correos o llamadas.
- Contactar con la organización ante cualquier actividad sospechosa.
El objetivo no es únicamente cumplir una obligación legal, sino permitir que las personas puedan protegerse cuanto antes.
8. ¿Qué ocurre si el incidente sucede en un proveedor?
Muchas empresas utilizan servicios externos para alojar información, gestionar nóminas, enviar comunicaciones, almacenar archivos o utilizar aplicaciones en la nube.
Si uno de estos proveedores actúa como encargado del tratamiento y descubre una brecha que afecta a los datos gestionados por cuenta de su cliente, debe informar al responsable sin dilación indebida.
Será posteriormente el responsable del tratamiento quien valore, con la información disponible, si debe notificar la brecha a la autoridad de control y comunicarla a los afectados.
Por ello, los contratos con proveedores deberían establecer claramente cómo se comunicarán y gestionarán este tipo de incidentes.
9. Documentar todas las decisiones
La documentación resulta fundamental incluso cuando finalmente se decide no notificar una brecha.
El registro interno debería permitir conocer:
- Fecha y hora de detección.
- Descripción del incidente.
- Sistemas afectados.
- Categorías de información comprometida.
- Número aproximado de afectados.
- Evaluación del riesgo.
- Medidas adoptadas.
- Decisión sobre la notificación a la AEPD.
- Decisión sobre la comunicación a los afectados.
- Justificación de esas decisiones.
- Medidas adoptadas posteriormente para evitar incidentes similares.
La AEPD puede solicitar esta información para comprobar que la organización gestionó adecuadamente la incidencia.
10. Evitar que vuelva a ocurrir
La gestión de la brecha no termina cuando se recuperan los sistemas.
También debe analizarse la causa que permitió que el incidente se produjera.
Puede ser necesario:
- Modificar los permisos de acceso.
- Implantar autenticación multifactor.
- Cambiar políticas de contraseñas.
- Cifrar determinados dispositivos.
- Mejorar las copias de seguridad.
- Actualizar sistemas.
- Revisar los procedimientos internos.
- Formar nuevamente a los trabajadores.
- Modificar la relación con determinados proveedores.
Cada brecha debería convertirse también en una oportunidad para mejorar las medidas de seguridad.
Estar preparado antes de que ocurra
Las primeras horas posteriores a una brecha de seguridad pueden ser determinantes.
Por ello, las empresas y profesionales que tratan datos personales deberían contar previamente con un procedimiento de gestión de brechas, definir quién debe intervenir y conocer cómo escalar rápidamente un posible incidente.
La Agencia Española de Protección de Datos dispone además de herramientas como Asesora Brecha, destinadas a ayudar a las organizaciones a valorar si una determinada violación de seguridad debe notificarse.
En materia de protección de datos, prevenir es fundamental, pero saber reaccionar correctamente cuando algo falla lo es igualmente.