“Protección de Datos: Aclarando conceptos” Entrada 7 — Incidente vs. brecha de seguridad: cómo distinguirlos y qué hacer en cada caso

 

“Protección de Datos: Aclarando conceptos”

Entrada 7 — Incidente vs. brecha de seguridad: cómo distinguirlos y qué hacer en cada caso

1. Por qué este concepto necesita aclararse

En protección de datos, pocas distinciones son tan importantes —y tan mal entendidas— como la diferencia entre:

• un incidente de seguridad,
• y una brecha de seguridad de datos personales.

Muchas organizaciones:

• notifican de más, por miedo,
• notifican de menos, por desconocimiento,
• o notifican tarde, por falta de criterios claros.

El resultado es doblemente peligroso:

• se generan obligaciones innecesarias,
• o se incumplen obligaciones críticas.

Esta entrada explica cómo distinguir ambos conceptos y cómo actuar con rigor.

2. Qué es un incidente de seguridad (y qué no es)

Un incidente de seguridad es cualquier evento que afecta a:

• la disponibilidad,
• la integridad,
• o la confidencialidad de un sistema,
• pero sin afectar necesariamente a datos personales.

Ejemplos típicos:

• caída de un servidor,
• fallo temporal de acceso,
• error interno sin exposición de datos,
• intento de ataque bloqueado,
• pérdida de un dispositivo vacío o cifrado.

Clave: Un incidente puede ser grave, pero no siempre implica datos personales. Por tanto, no siempre activa obligaciones del RGPD.

3. Qué es una brecha de seguridad de datos personales

Una brecha de seguridad es un incidente que sí afecta a datos personales, provocando:

• pérdida,
• alteración,
• acceso no autorizado,
• divulgación,
• o destrucción.

Ejemplos típicos:

• envío de datos a un destinatario incorrecto,
• acceso indebido por un empleado,
• ransomware que cifra datos personales,
• pérdida de un dispositivo sin cifrar,
• publicación accidental de información sensible.

Clave: Toda brecha es un incidente, pero no todo incidente es una brecha.

4. Cómo distinguirlos en la práctica (modelo operativo)

Paso 1 — Identificar el evento

¿Qué ha ocurrido exactamente?

Paso 2 — Determinar si hay datos personales afectados

Si no hay datos personales → incidente. Si sí los hay → posible brecha.

Paso 3 — Evaluar el impacto

¿Existe riesgo para los derechos y libertades?

• Si el riesgo es bajo → brecha no notificable, pero documentable.
• Si el riesgo es alto → brecha notificable a la AEPD.
• Si el riesgo es muy alto → brecha notificable también a los afectados.

Paso 4 — Documentar siempre

Incluso si no se notifica.

5. Señales de que una empresa está gestionando mal esta distinción

• Notifica incidentes que no afectan a datos personales.
• No notifica brechas que sí afectan a datos personales.
• No documenta incidentes ni brechas.
• No evalúa el riesgo para los derechos de las personas.
• No distingue entre impacto técnico e impacto jurídico.
• No tiene un procedimiento formal de gestión de brechas.

6. Qué hacer ante un incidente (modelo práctico)

1.    Identificar el evento.

2.    Contener el impacto técnico.

3.    Verificar si hay datos personales afectados.

4.    Documentar el incidente.

5.    Revisar medidas de seguridad.

Si no hay datos personales afectados, no hay brecha.

7. Qué hacer ante una brecha (modelo práctico)

1.    Activar el protocolo interno.

2.    Evaluar el riesgo para los derechos y libertades.

3.    Determinar si es notificable (AEPD y/o afectados).

4.    Documentar todo el proceso.

5.    Implementar medidas correctoras.

6.    Revisar políticas y controles.

Regla de oro: La notificación debe hacerse en 72 horas desde que se tiene conocimiento.

8. Cierre: hacia la Entrada 8

Comprender la diferencia entre incidente y brecha permite reaccionar con precisión, evitar notificaciones innecesarias y cumplir con las obligaciones del RGPD cuando realmente corresponde.

La Entrada 8 abordará otro concepto crítico en la práctica diaria:

Transferencias internacionales: qué significa realmente transferir datos fuera de la UE y cuándo se activa esta obligación.