RGPD y Brechas de Datos: Notificación, Respuesta y Obligaciones Técnicas

Por qué las brechas de datos personales son el mayor riesgo regulatorio

El RGPD (Reglamento General de Protección de Datos, Reglamento UE 2016/679) transformó la gestión de datos personales en Europa. Pero es en la gestión de brechas donde la mayoría de organizaciones se juegan la sanción, la reputación y la confianza de sus clientes.

En 2025, la AEPD impuso sanciones por un total superior a 50 millones de euros, con un porcentaje significativo vinculado a gestión inadecuada de brechas: notificaciones tardías, ausencia de medidas técnicas, o falta de comunicación a los afectados. La tendencia en 2026 es clara: las autoridades de protección de datos no sancionan solo por sufrir una brecha (algo inevitable), sino por gestionarla mal.

Para equipos de seguridad, respuesta a incidentes y DPOs, entender el marco legal y técnico de las brechas bajo el RGPD no es opcional. Es la diferencia entre un incidente contenido y una crisis regulatoria.

Definición legal de brecha de datos personales

Artículo 4.12 del RGPD

El RGPD define la "violación de la seguridad de los datos personales" en su Artículo 4.12 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.

Esta definición es deliberadamente amplia. No se limita a ciberataques o exfiltraciones. Un portátil perdido con datos sin cifrar, un email enviado al destinatario incorrecto, un fallo de sistema que impide acceder a historiales médicos o la eliminación accidental de una base de datos son brechas bajo el RGPD.

Tres tipos de brechas

La AEPD y el EDPB (European Data Protection Board) clasifican las brechas en tres categorías, que pueden darse simultáneamente:

Tipo	Descripción	Ejemplo
Confidencialidad	Acceso o divulgación no autorizada de datos personales	Exfiltración por ransomware, email al destinatario incorrecto, acceso indebido por empleado
Integridad	Alteración no autorizada o accidental de datos personales	Modificación de registros médicos, corrupción de base de datos, inyección SQL que altera datos
Disponibilidad	Pérdida de acceso temporal o permanente a datos personales	Ransomware que cifra datos, fallo de hardware sin backup, ataque DDoS a sistema de historiales

La distinción importa porque el tipo de brecha condiciona la evaluación de riesgos y las medidas de respuesta. Una brecha de confidencialidad con datos de salud exfiltrados tiene implicaciones radicalmente diferentes a una brecha de disponibilidad temporal resuelta en minutos.

La regla de las 72 horas: Artículo 33

Obligación de notificación a la autoridad de control

El Artículo 33.1 establece la obligación nuclear:

En caso de violación de la seguridad de los datos personales, el responsable del tratamiento la notificará a la autoridad de control competente [...] sin dilación indebida y, de ser posible, a más tardar 72 horas después de que haya tenido constancia de ella.

Puntos clave sobre el plazo:

• Inicio del cómputo. Las 72 horas empiezan cuando el responsable del tratamiento "tiene constancia" de la brecha, no cuando ocurrió. Si un encargado del tratamiento detecta la brecha, debe comunicarlo al responsable "sin dilación indebida" (Art. 33.2), y las 72 horas comienzan para el responsable cuando recibe esa comunicación.
• Horas, no días laborables. El plazo se cuenta en horas naturales, incluidos fines de semana y festivos.
• Notificación fuera de plazo. Si se supera el plazo, la notificación debe incluir los motivos del retraso. Esto no exime de la obligación, pero documenta la diligencia.
• Notificación por fases. El Artículo 33.4 permite proporcionar información de forma escalonada si no es posible reunirla en 72 horas. La notificación inicial puede ser parcial, completándose posteriormente.

Contenido obligatorio de la notificación (Art. 33.3)

La notificación a la AEPD debe incluir, como mínimo:

1. Naturaleza de la brecha. Descripción del incidente, categorías y número aproximado de interesados afectados, categorías y número aproximado de registros de datos afectados.
2. Datos del DPO. Nombre y datos de contacto del Delegado de Protección de Datos u otro punto de contacto.
3. Consecuencias probables. Descripción de las consecuencias probables de la brecha.
4. Medidas adoptadas. Descripción de las medidas adoptadas o propuestas para poner remedio a la brecha, incluyendo medidas para mitigar posibles efectos negativos.

Cuándo NO es obligatorio notificar

El Artículo 33.1 incluye una excepción: no es obligatorio notificar si la brecha "no entraña un riesgo para los derechos y libertades de las personas físicas". En la práctica, esto aplica a casos muy limitados:

• Datos ya publicados o de dominio público.
• Datos cifrados con algoritmo robusto y la clave no se ha visto comprometida.
• Datos anonimizados de forma irreversible.
• Brecha que afecta a un único registro de bajo riesgo sin datos sensibles.

La AEPD recomienda documentar internamente la decisión de no notificar y su justificación, porque puede revisarse posteriormente.

Formulario de notificación de la AEPD

La notificación se realiza a través de la Sede Electrónica de la AEPD. El formulario solicita:

• Datos del responsable del tratamiento y del DPO.
• Fecha y hora de detección, y fecha y hora estimada de la brecha.
• Tipo de brecha (confidencialidad, integridad, disponibilidad).
• Categorías de datos afectados (datos básicos, datos de salud, datos financieros, datos de menores, etc.).
• Número de afectados (exacto o estimado).
• Descripción del incidente y vector de ataque (si se conoce).
• Medidas de contención, erradicación y mitigación aplicadas.
• Si se ha comunicado a los afectados (y si no, justificación).
• Evaluación de riesgos para los derechos y libertades.

Comunicación a los afectados: Artículo 34

Cuándo es obligatoria

El Artículo 34.1 establece que la comunicación directa a los afectados es obligatoria cuando la brecha "entrañe un alto riesgo para los derechos y libertades de las personas físicas". El umbral es superior al de notificación a la autoridad de control: no basta con riesgo, debe ser alto riesgo.

Indicadores de alto riesgo según las Directrices del EDPB (WP250rev.01):

• Datos de categorías especiales (salud, orientación sexual, datos biométricos, afiliación sindical).
• Datos financieros que permitan fraude (números de tarjeta, datos bancarios).
• Datos que permitan suplantación de identidad (DNI, pasaporte, credenciales de acceso).
• Datos de menores o personas vulnerables.
• Volumen elevado de afectados.
• Combinación de datos que revele información sensible por agregación.

Contenido de la comunicación

La comunicación al afectado debe redactarse en lenguaje claro y sencillo, e incluir:

• Naturaleza de la brecha.
• Nombre y datos de contacto del DPO.
• Consecuencias probables para el afectado.
• Medidas adoptadas y recomendaciones para que el afectado se proteja (cambio de contraseñas, monitorización de cuentas, etc.).

Excepciones a la comunicación directa (Art. 34.3)

El RGPD contempla tres excepciones:

1. Medidas técnicas previas. Si los datos estaban protegidos con medidas que hacen los datos ininteligibles para cualquier persona no autorizada (cifrado robusto con clave no comprometida).
2. Medidas posteriores. Si el responsable ha adoptado medidas que garantizan que el alto riesgo ya no se materializará.
3. Esfuerzo desproporcionado. Si la comunicación individual supone un esfuerzo desproporcionado, se permite una comunicación pública o medida equivalente.

Procedimiento de respuesta a brechas

Un procedimiento de respuesta eficaz se estructura en cinco fases. Las primeras 72 horas son críticas para cumplir los plazos del RGPD.

Fase 1: Detección y alerta (hora 0 a hora 2)

• Identificación. Detectar la brecha a través de herramientas de monitorización (SIEM, EDR, DLP), reportes de empleados, alertas de terceros o descubrimiento accidental.
• Clasificación inicial. Determinar si el incidente involucra datos personales. Si no los involucra, sigue siendo un incidente de seguridad pero no una brecha RGPD.
• Activación del equipo. Notificar al equipo de respuesta a incidentes, al DPO y a la dirección. Iniciar el registro cronológico del incidente.
• Preservación de evidencias. Asegurar logs, capturas de red, imágenes de disco y cualquier evidencia relevante antes de que las acciones de contención las alteren.

Fase 2: Contención (hora 2 a hora 12)

• Contención a corto plazo. Aislar sistemas afectados, revocar credenciales comprometidas, bloquear IPs atacantes, desconectar sistemas de la red si es necesario.
• Contención a largo plazo. Implementar medidas que permitan mantener la operación mientras se erradica la amenaza (sistemas en modo degradado, servicios alternativos).
• Evaluación del alcance. Determinar qué datos se han visto afectados, cuántos registros, cuántos interesados, qué categorías de datos.

Fase 3: Evaluación de riesgos y decisión de notificación (hora 12 a hora 48)

• Matriz de riesgos. Evaluar la probabilidad y severidad del impacto para los afectados (ver sección siguiente).
• Decisión de notificación a la autoridad. Si existe riesgo para derechos y libertades, preparar la notificación a la AEPD.
• Decisión de comunicación a afectados. Si existe alto riesgo, preparar la comunicación directa.
• Consulta al DPO. El DPO debe participar en la evaluación y documentar su criterio.

Fase 4: Notificación (hora 48 a hora 72)

• Notificación a la AEPD. Enviar a través de la Sede Electrónica antes de cumplirse las 72 horas. Si la información es incompleta, indicar que se completará posteriormente.
• Comunicación a afectados. Si procede, enviar comunicación directa sin dilación indebida tras la evaluación.
• Notificación a encargados del tratamiento. Comunicar a los encargados afectados para que adopten sus propias medidas.

Fase 5: Erradicación, recuperación y lecciones (posterior a 72 horas)

• Erradicación. Eliminar la causa raíz del incidente (parchear vulnerabilidad, eliminar malware, corregir configuración).
• Recuperación. Restaurar sistemas y datos desde backups verificados.
• Completar notificación. Si la notificación inicial fue parcial, enviar la información complementaria a la AEPD.
• Post-mortem. Análisis de causa raíz, lecciones aprendidas, actualización de procedimientos y medidas técnicas.

Evaluación de riesgos para la notificación

La decisión de notificar (y a quién) depende de una evaluación de riesgos que el EDPB estructura con los siguientes factores:

Factores de probabilidad

Factor	Bajo	Medio	Alto
Tipo de brecha	Disponibilidad temporal	Integridad	Confidencialidad con exfiltración
Datos cifrados	Sí, clave segura	Parcialmente	No cifrados
Datos anonimizados	Irreversiblemente	Pseudonimizados	Sin protección
Actor malicioso	No (error interno)	Desconocido	Sí (ataque dirigido)
Recuperabilidad	Total, backup inmediato	Parcial	Sin backup

Factores de severidad

Factor	Bajo	Medio	Alto
Categoría de datos	Nombre, email corporativo	Datos financieros, ubicación	Datos de salud, biométricos, menores
Volumen de afectados	Menos de 100	100 a 10.000	Más de 10.000
Posibilidad de identificación	Difícil sin datos adicionales	Posible con esfuerzo	Directa (DNI, nombre completo)
Consecuencias para el afectado	Inconveniente menor	Pérdida financiera, discriminación	Daño físico, suplantación de identidad
Vulnerabilidad del afectado	Adulto sin riesgo especial	Empleado del responsable	Menor, paciente, persona vulnerable

Matriz de decisión

Probabilidad / Severidad	Baja	Media	Alta
Baja	No notificar (documentar)	Evaluar caso a caso	Notificar a AEPD
Media	Evaluar caso a caso	Notificar a AEPD	Notificar a AEPD + afectados
Alta	Notificar a AEPD	Notificar a AEPD + afectados	Notificar a AEPD + afectados + medidas urgentes

En caso de duda, la recomendación de la AEPD es notificar. Una notificación innecesaria no tiene consecuencias negativas; una notificación omitida puede multiplicar la sanción.

Registro de brechas: Artículo 33.5

El Artículo 33.5 establece una obligación independiente de la notificación: todo responsable del tratamiento debe mantener un registro de todas las brechas de datos personales, incluyendo aquellas que no se notifican a la autoridad de control.

Contenido obligatorio del registro

Para cada brecha, el registro debe documentar:

• Hechos. Qué ocurrió, cuándo se detectó, cuándo ocurrió, duración, vector de ataque.
• Efectos. Tipos de datos afectados, número de registros, número de interesados, consecuencias observadas.
• Medidas correctivas. Acciones de contención, erradicación, recuperación y prevención adoptadas.
• Decisión de notificación. Si se notificó a la AEPD (y fecha), si se comunicó a los afectados, o justificación de la decisión de no notificar.

Este registro debe estar disponible para inspección por la AEPD en cualquier momento. La ausencia de registro es una infracción independiente, con sanciones propias.

Formato recomendado

No existe un formato oficial obligatorio. La AEPD recomienda un formato estructurado que permita la trazabilidad. Los campos mínimos son:

Campo	Descripción
ID de brecha	Identificador único interno
Fecha de detección	Timestamp con hora exacta
Fecha estimada de la brecha	Cuándo ocurrió realmente
Tipo de brecha	Confidencialidad, integridad, disponibilidad
Categorías de datos	Tipos de datos personales afectados
Número de afectados	Exacto o estimado
Descripción del incidente	Resumen factual
Causa raíz	Identificada o en investigación
Medidas de contención	Acciones inmediatas
Medidas correctivas	Acciones a medio plazo
Notificación AEPD	Sí/No, fecha, número de expediente
Comunicación a afectados	Sí/No, fecha, medio utilizado
Responsable de la gestión	Persona o equipo asignado
Estado	Abierta, en investigación, cerrada

Medidas técnicas preventivas

El RGPD no prescribe medidas técnicas concretas (a diferencia del ENS), pero el Artículo 32 establece la obligación de implementar medidas "apropiadas" al riesgo. La AEPD ha publicado guías que concretan estas medidas en el contexto español.

Cifrado y pseudonimización (Art. 32.1.a)

El cifrado es la medida más citada por el RGPD porque tiene un efecto directo en la obligación de notificación: si los datos estaban cifrados con un algoritmo robusto y la clave no se ha comprometido, puede no ser necesario comunicar la brecha a los afectados (Art. 34.3.a).

• En reposo. AES-256 para bases de datos y backups. Cifrado de disco completo (LUKS, BitLocker, FileVault) para dispositivos portátiles.
• En tránsito. TLS 1.2 como mínimo, TLS 1.3 recomendado. HSTS obligatorio.
• Pseudonimización. Separar identificadores directos de los datos, almacenándolos en sistemas diferentes con controles de acceso independientes.

Control de acceso

• Principio de mínimo privilegio. Cada usuario accede solo a los datos necesarios para su función.
• Autenticación multifactor (MFA). Obligatoria para acceso a sistemas con datos personales sensibles.
• Revisión periódica de permisos. Al menos trimestral. Revocación inmediata al cambio de rol o baja.
• Segregación de funciones. El administrador de sistemas no debe ser quien audita los accesos.

Monitorización y detección

• Logging de accesos. Registrar quién accede a datos personales, cuándo y qué operaciones realiza. Retención mínima de logs: el periodo necesario para detectar y gestionar brechas (la AEPD recomienda al menos 2 años).
• SIEM. Correlación de eventos para detectar patrones anómalos (accesos masivos, exfiltración, escalada de privilegios).
• DLP (Data Loss Prevention). Prevenir la salida no autorizada de datos personales por email, USB, cloud o impresión.
• Alertas en tiempo real. Configurar alertas para eventos que puedan indicar una brecha: múltiples intentos de acceso fallidos, descargas masivas, accesos fuera de horario.

Backups y recuperación

• Backup cifrado. Los backups contienen datos personales y deben estar cifrados con la misma rigurosidad que los datos en producción.
• Pruebas de restauración. Verificar periódicamente que los backups son recuperables. Un backup que no se puede restaurar no es un backup.
• Retención y rotación. Alinear la política de retención de backups con la política de retención de datos personales. Cuando un dato debe eliminarse, debe eliminarse también de los backups (o documentar la excepción).

Sanciones de la AEPD: régimen sancionador español

Marco general de sanciones RGPD

El RGPD establece dos niveles de sanciones:

• Infracciones del Artículo 83.4. Hasta 10 millones de euros o el 2% de la facturación anual global. Aplica a: obligaciones del responsable y encargado (Art. 25-39), incluida la notificación de brechas.
• Infracciones del Artículo 83.5. Hasta 20 millones de euros o el 4% de la facturación anual global. Aplica a: principios básicos del tratamiento, derechos de los interesados, transferencias internacionales.

Casos relevantes de la AEPD

La AEPD ha sancionado brechas de datos en múltiples sectores. Algunos patrones recurrentes:

• Telecomunicaciones. Sanciones millonarias por brechas de confidencialidad con acceso a datos de clientes por empleados no autorizados, o portabilidades fraudulentas (SIM swapping).
• Sector financiero. Sanciones por envío de documentación bancaria a destinatarios incorrectos y por falta de medidas técnicas en aplicaciones móviles.
• Sector sanitario. Sanciones por acceso a historiales clínicos sin justificación asistencial y por envío de resultados médicos a pacientes incorrectos.
• Sector público. Apercibimientos (las administraciones públicas no reciben multas económicas bajo la LOPDGDD) por publicación de datos personales en portales de transparencia sin anonimizar.

Factores que agravan la sanción

La AEPD considera especialmente graves:

• No notificar la brecha o notificarla fuera de plazo sin justificación.
• Ausencia de registro de brechas.
• Ausencia de DPO cuando es obligatorio.
• No haber implementado medidas técnicas básicas (cifrado, MFA, backups).
• Reincidencia.
• No cooperar con la investigación de la AEPD.

Factores que atenúan la sanción

• Notificación proactiva dentro de plazo.
• Medidas técnicas robustas implementadas antes de la brecha.
• Cooperación activa con la AEPD durante la investigación.
• Plan de remediación implementado tras la brecha.
• Comunicación transparente a los afectados.

RGPD vs NIS2: comparativa de notificación de incidentes

Para organizaciones sujetas tanto al RGPD como a NIS2, las obligaciones de notificación se solapan parcialmente pero tienen diferencias significativas.

Aspecto	RGPD (Art. 33-34)	NIS2 (Art. 23)
Ámbito	Brechas de datos personales	Incidentes de ciberseguridad significativos
Autoridad	AEPD (autoridad de protección de datos)	CSIRT de referencia (CCN-CERT, INCIBE-CERT)
Plazo inicial	72 horas	24 horas (alerta temprana)
Plazo notificación detallada	72 horas (puede completarse después)	72 horas
Informe final	Sin plazo específico (completar "sin dilación")	1 mes
Comunicación a afectados	Obligatoria si alto riesgo (Art. 34)	Obligatoria si puede afectar a usuarios (Art. 23.7)
Sanciones máximas	20M EUR o 4% facturación	10M EUR o 2% facturación
Responsabilidad personal	DPO no tiene responsabilidad personal directa	Alta dirección personalmente responsable
Registro obligatorio	Sí (Art. 33.5)	Sí (implícito en gestión de incidentes)

Cuando un incidente es simultáneamente una brecha RGPD y un incidente NIS2 (por ejemplo, un ransomware que exfiltra datos personales y afecta a un servicio esencial), las organizaciones deben:

1. Notificar al CSIRT en 24 horas (NIS2).
2. Notificar a la AEPD en 72 horas (RGPD).
3. Comunicar a los afectados sin dilación si existe alto riesgo (RGPD).
4. Enviar informe final al CSIRT en 1 mes (NIS2).

Las notificaciones son independientes. Notificar al CSIRT no exime de notificar a la AEPD, y viceversa.

Checklist de preparación para brechas RGPD

Antes de que ocurra la brecha

• DPO designado (obligatorio para administraciones públicas, tratamiento a gran escala de datos sensibles, y monitorización habitual y sistemática a gran escala).
• Procedimiento de respuesta documentado. Roles, responsabilidades, cadena de comunicación, plantillas de notificación.
• Registro de actividades de tratamiento (Art. 30) actualizado. Sin él, es imposible evaluar el alcance de una brecha.
• Evaluación de impacto (EIPD/DPIA, Art. 35) realizada para tratamientos de alto riesgo.
• Contratos con encargados (Art. 28) que incluyan obligación de notificación inmediata de brechas.
• Medidas técnicas implementadas. Cifrado en reposo y tránsito, MFA, logging, DLP, backups cifrados.
• Formación al personal. Todos los empleados deben saber reconocer una posible brecha y a quién reportarla internamente.
• Simulacros de brecha. Al menos un ejercicio anual de respuesta a brecha (tabletop exercise) que incluya notificación simulada a la AEPD.

Durante las primeras 72 horas

• Activar equipo de respuesta. DPO, CISO, legal, comunicación, dirección.
• Contener la brecha. Detener la exfiltración o pérdida de datos.
• Preservar evidencias. Logs, capturas, imágenes forenses.
• Evaluar riesgo. Tipo de datos, volumen, posibilidad de identificación, consecuencias para los afectados.
• Decidir notificación. ¿Riesgo para derechos y libertades? Notificar a AEPD. ¿Alto riesgo? Comunicar a afectados.
• Notificar a la AEPD si procede (Sede Electrónica, formulario de notificación).
• Comunicar a los afectados si procede (lenguaje claro, recomendaciones de protección).
• Registrar en el registro interno de brechas con toda la información disponible.

Después de las 72 horas

• Completar la notificación a la AEPD si fue parcial.
• Erradicar la causa raíz. Parchear, remediar, reconfiguar.
• Post-mortem. Análisis de causa raíz, lecciones aprendidas.
• Actualizar medidas. Implementar controles adicionales para prevenir recurrencia.
• Actualizar procedimientos. Incorporar lecciones al plan de respuesta.
• Cerrar el registro de la brecha con toda la documentación final.

Recursos y referencias

Texto legal y guías oficiales

• Reglamento (UE) 2016/679 (RGPD): texto completo del Reglamento General de Protección de Datos.
• LOPDGDD (Ley Orgánica 3/2018): adaptación española del RGPD.
• AEPD: Guía para la gestión y notificación de brechas de seguridad: guía práctica de la Agencia Española de Protección de Datos.
• AEPD: Herramienta Comunica-Brecha RGPD: herramienta para evaluar si una brecha requiere comunicación a los afectados.
• EDPB: Guidelines on Personal Data Breach Notification (WP250rev.01): directrices del EDPB sobre notificación de brechas.

Formularios de notificación

• Sede Electrónica AEPD: Notificación de brechas: formulario oficial de notificación de brechas de datos personales a la AEPD.

Frameworks complementarios

• ENS (Esquema Nacional de Seguridad). Las medidas técnicas del ENS (especialmente ENS Alto) proporcionan una base sólida para cumplir el Artículo 32 del RGPD.
• ISO 27001:2022. Los controles del Anexo A (especialmente A.5.24 a A.5.28 sobre gestión de incidentes) se alinean con las obligaciones de respuesta a brechas del RGPD.
• NIST CSF 2.0. Las funciones Respond (RS) y Recover (RC) proporcionan un marco técnico complementario para la respuesta a brechas.
• NIS2. Para organizaciones en sectores cubiertos, las obligaciones de notificación de NIS2 se suman a las del RGPD (ver comparativa anterior).

Herramientas de la AEPD

• Facilita RGPD: herramienta para empresas de bajo riesgo.
• Evalúa Riesgo RGPD: evaluación de riesgo para determinar la necesidad de EIPD.
• Gestiona EIPD: herramienta para realizar Evaluaciones de Impacto de Protección de Datos.