Una brecha de seguridad es todo incidente que compromete la confidencialidad, la integridad o la disponibilidad de la información de una organización. Cuando afecta a datos personales, activa el reloj de las 72 horas del RGPD. Cuando afecta a servicios esenciales, activa un circuito distinto, con otros plazos y otro destinatario. Saber en cuál de los dos estás, y en cuántos a la vez, es lo que separa un incidente gestionado de una sanción.
Contenido revisado y actualizado el 18 de agosto de 2026.
Lo esencial
- Definición amplia: una brecha de seguridad no es solo un ciberataque. Un correo enviado al destinatario equivocado, un portátil perdido o un borrado accidental también lo son.
- 72 horas: si hay datos personales implicados y existe riesgo para las personas, hay que notificar a la Agencia Española de Protección de Datos en un máximo de 72 horas desde que tienes constancia (artículo 33 del RGPD).
- Puede haber más de un destinatario: la AEPD no siempre es el único. Según el sector y el tipo de incidente, entran también INCIBE-CERT, el CCN-CERT o tu supervisor sectorial.
- Documentar siempre: toda brecha se registra internamente, se notifique o no. Es la prueba de que valoraste el riesgo (artículo 33.5 del RGPD).
- Prevención medible: los controles 5.24 a 5.28 del Anexo A de ISO/IEC 27001:2022 cubren el ciclo completo de gestión de incidentes, desde la planificación hasta la recogida de evidencias.
¿Qué es una brecha de seguridad?
Una brecha de seguridad es cualquier evento que rompe alguna de las tres propiedades básicas de la información: la confidencialidad (alguien accede a lo que no debe), la integridad (los datos se alteran sin autorización) o la disponibilidad (dejas de poder acceder a ellos). El RGPD usa una definición equivalente pero acotada a datos personales en su artículo 4.12: toda violación de la seguridad que ocasione la destrucción, pérdida o alteración accidental o ilícita de datos personales, o la comunicación o acceso no autorizados a dichos datos.
La confusión más común en las empresas es asumir que brecha equivale a ataque informático. No es así. La casuística real que llega a las autoridades incluye mucho error humano: un envío masivo con las direcciones en copia visible en lugar de en copia oculta, un archivo compartido con permisos abiertos, documentación en papel extraviada o un empleado que se lleva una base de datos al marcharse.
Por ejemplo: si un ransomware cifra tu servidor de nóminas y tú tienes copia de seguridad íntegra y aislada, sigue siendo una brecha. Hubo pérdida temporal de disponibilidad y, muy probablemente, acceso no autorizado antes del cifrado. Que lo hayas resuelto rápido influye en la valoración del riesgo, no en la calificación del hecho.
¿Qué tipos de brechas de seguridad existen?
Las brechas se clasifican por la propiedad de la información que se ve afectada. Esa clasificación no es teórica: determina qué tienes que notificar y con qué urgencia, porque el riesgo para las personas es distinto en cada caso.
- Brecha de confidencialidad: acceso o divulgación no autorizada. Es la que suele generar mayor riesgo para los afectados, sobre todo si hay datos de categoría especial (salud, ideología, biometría) o datos financieros.
- Brecha de integridad: alteración no autorizada de los datos. Menos visible y con frecuencia detectada tarde. Un historial clínico o un expediente laboral modificado puede causar daño sin que nadie note el cambio durante meses.
- Brecha de disponibilidad: pérdida de acceso, temporal o definitiva. Ransomware, borrado accidental sin copia, fallo de hardware. La AEPD valora aquí si la indisponibilidad es reversible y en cuánto tiempo.
Un mismo incidente puede pertenecer a las tres categorías a la vez, que es exactamente lo que ocurre en la mayoría de ataques de ransomware con exfiltración previa. En ese escenario, la valoración del riesgo debe hacerse sobre el peor de los tres vectores, no sobre el más cómodo.
¿Cómo actuar ante una brecha de seguridad en las primeras 72 horas?
El objetivo de las primeras horas es doble: contener el incidente y reunir información suficiente para decidir si hay que notificar. No necesitas tener el incidente resuelto para notificar, y no puedes esperar a resolverlo para hacerlo. El RGPD permite una notificación por fases si al principio no dispones de todos los datos.
- Detectar y registrar la hora exacta. El plazo de 72 horas cuenta desde que tienes constancia razonable de la brecha, no desde que la confirmas al detalle. Anota fecha, hora y quién dio el aviso.
- Contener. Aísla los sistemas afectados, revoca credenciales comprometidas y corta el vector de entrada. Conserva los registros y las imágenes de disco antes de restaurar, o perderás la evidencia.
- Valorar el alcance. Qué categorías de datos, cuántas personas afectadas, si estaban cifrados y con qué robustez, y qué consecuencias plausibles tiene para esas personas.
- Decidir sobre la notificación. Si hay riesgo para los derechos y libertades, notificas a la AEPD. Si el riesgo es alto, además comunicas a los afectados. Si concluyes que no hay riesgo, esa conclusión se documenta con su razonamiento.
- Notificar por los canales que correspondan, que pueden ser varios. El apartado siguiente los ordena.
- Cerrar y aprender. Registra la brecha en tu registro interno, revisa qué control falló e incorpora la corrección. Un sistema de gestión de incidentes de protección de datos convierte este paso en un procedimiento repetible en lugar de una improvisación.
La AEPD pone a disposición dos herramientas gratuitas que conviene tener localizadas antes de necesitarlas: Asesora Brecha, que te ayuda a valorar si procede notificar, y Comunica-Brecha RGPD, orientada a la comunicación a los afectados.
¿A quién hay que notificar una brecha de seguridad?
Depende de qué se ha visto comprometido y de a qué régimen está sujeta tu empresa. La AEPD es el destinatario cuando hay datos personales con riesgo, pero no agota la lista. Una misma brecha puede obligarte a notificar a dos o tres destinatarios distintos, con plazos que no coinciden entre sí.
| Destinatario | Cuándo aplica | Plazo | Base normativa |
|---|---|---|---|
| AEPD | Brecha con datos personales que supone riesgo para los derechos de las personas | 72 horas desde que tienes constancia | Art. 33 RGPD |
| Personas afectadas | La brecha entraña alto riesgo para ellas | Sin dilación indebida | Art. 34 RGPD |
| Responsable del tratamiento (si tú eres el encargado) | Siempre que la brecha ocurra en sistemas que tratas por cuenta de un tercero | Sin dilación indebida | Art. 33.2 RGPD |
| INCIBE-CERT | Incidentes de ciberseguridad en empresas y ciudadanos, y operadores del ámbito privado | Según protocolo del CERT de referencia | Marco NIS y su desarrollo nacional |
| CCN-CERT | Entidades del sector público sujetas al Esquema Nacional de Seguridad | Según nivel de peligrosidad del incidente | RD 311/2022 (ENS) |
| Supervisor sectorial | Banca, seguros, energía, sanidad y demás sectores regulados | El que fije su normativa específica | Normativa sectorial aplicable |
La consecuencia práctica de esta tabla es que el procedimiento interno de brechas no puede estar escrito solo desde la óptica de protección de datos. Si tu empresa presta servicios de Esquema Nacional de Seguridad a una administración, un mismo incidente puede exigir notificación a la AEPD y al CCN-CERT con criterios de plazo distintos.
Nuestra recomendación: mantén un único registro de incidentes que sirva a la vez de registro del artículo 33.5 del RGPD, de evidencia para el control A.5.27 de ISO/IEC 27001 y de base para la notificación sectorial. Ver empresas con tres registros paralelos que se contradicen entre sí es habitual, y en una inspección esa contradicción pesa más que el incidente original.
¿Cuándo hay que comunicar la brecha a las personas afectadas?
Cuando la brecha entraña un alto riesgo para sus derechos y libertades. El umbral es más exigente que el de la notificación a la AEPD: ahí basta con que exista riesgo, aquí tiene que ser alto. La comunicación debe hacerse sin dilación indebida y en lenguaje claro, no con la redacción de un aviso legal.
El artículo 34.3 del RGPD contempla tres supuestos en los que puedes ahorrarte esa comunicación: que los datos estuvieran protegidos con medidas que los hacen ininteligibles (cifrado robusto con la clave a salvo), que hayas adoptado medidas posteriores que eliminen el alto riesgo, o que la comunicación individual suponga un esfuerzo desproporcionado, en cuyo caso procede una comunicación pública equivalente.
Ojo con el primer supuesto, que es donde más se fuerza la interpretación. El cifrado exime si es robusto y la clave no se ha visto comprometida. Un volumen cifrado cuya clave estaba en el mismo servidor comprometido no cumple esa condición, por mucho que técnicamente haya cifrado de por medio.
¿Qué obligaciones añade NIS2 y desde cuándo se aplican en España?
La Directiva (UE) 2022/2555, conocida como NIS2, obliga a las entidades esenciales e importantes a notificar los incidentes significativos en tres tiempos: alerta temprana en 24 horas, notificación con evaluación inicial en 72 horas e informe final en un mes. Es un circuito paralelo al del RGPD, con distinto destinatario y distinto criterio de activación.
Estado en España, verificado el 18 de agosto de 2026: la Ley de Coordinación y Gobernanza de la Ciberseguridad, que transpone NIS2, sigue sin publicarse en el BOE. El anteproyecto se aprobó en Consejo de Ministros en enero de 2025 y continúa en tramitación. El plazo europeo de transposición venció el 17 de octubre de 2024 y, tras un segundo requerimiento en mayo de 2026, la Comisión Europea llevó a España ante el Tribunal de Justicia de la UE el 8 de julio de 2026 solicitando sanciones económicas.
La lectura práctica para una empresa es que esperar a la publicación de la ley para empezar a prepararse es un mal cálculo. Las obligaciones de fondo de NIS2 (análisis de riesgos, gestión de incidentes, seguridad de la cadena de suministro, continuidad de negocio) ya están definidas en el artículo 21 de la directiva y no van a cambiar en la transposición. Lo que la ley concretará son las autoridades competentes, el régimen sancionador y los umbrales de registro. Si tu organización entra en el ámbito, conviene ir avanzando en la gestión del parque tecnológico bajo NIS2 sin esperar al BOE.
¿Qué sanciones conlleva gestionar mal una brecha de seguridad?
Incumplir las obligaciones de notificación de los artículos 33 y 34 del RGPD se encuadra en el artículo 83.4, con multas de hasta 10 millones de euros o el 2 por ciento del volumen de negocio anual global del ejercicio anterior, la cifra que sea mayor. Si además se aprecia falta de medidas de seguridad adecuadas del artículo 32, la exposición sube.
Conviene entender cómo se llega en la práctica a una sanción. Rara vez es la brecha en sí, que puede ocurrirle a cualquiera. Lo que agrava el expediente es el patrón que aparece después: notificación fuera de plazo sin justificación, ausencia de registro interno que demuestre la valoración del riesgo, medidas de seguridad que no se corresponden con lo declarado, o comunicación a los afectados omitida cuando procedía.
Dicho de otro modo, la brecha se juzga por la trazabilidad de tus decisiones. Una empresa que notifica en plazo, documenta por qué descartó comunicar a los afectados y acredita que tenía controles razonables está en una posición defendible aunque el incidente haya sido grave. Revisar de forma periódica tu gestión de la seguridad de la información es la manera ordinaria de comprobar que esa trazabilidad existe antes de que la pida un inspector.
¿Cómo se previene una brecha de seguridad?
La prevención eficaz combina controles técnicos y un procedimiento de respuesta ensayado. El marco de referencia más usado en España es ISO/IEC 27001, cuyo Anexo A de la versión 2022 dedica cinco controles específicos a incidentes: planificación y preparación (A.5.24), evaluación y decisión (A.5.25), respuesta (A.5.26), aprendizaje (A.5.27) y recogida de evidencias (A.5.28).
Sobre esa base, hay cuatro medidas que reducen de forma desproporcionada la probabilidad y el impacto:
- Doble factor en todos los accesos externos. Neutraliza la mayoría de compromisos por credenciales robadas, que es el vector de entrada más común.
- Copias de seguridad aisladas y probadas. Una copia que nunca se ha restaurado en un simulacro no es una copia, es una suposición.
- Gestión activa de vulnerabilidades. Parchear con criterio de exposición real y no solo por severidad teórica. La gestión de vulnerabilidades es el control que más ventana de ataque cierra por euro invertido.
- Simulacro anual de brecha. Ensayar el procedimiento con reloj, decidiendo si se notifica y redactando el borrador de notificación. La primera vez que lo haces descubres cuántas horas se pierden localizando a quien tiene que autorizar.
Preguntas frecuentes sobre brechas de seguridad
¿Cómo se notifica una brecha de seguridad a la AEPD?
La notificación se presenta por vía electrónica, a través del formulario de notificación de brechas de datos personales de la sede electrónica de la AEPD. No vale el correo ni el teléfono: el artículo 33.3 del RGPD exige un contenido mínimo que el formulario estructura, y es la vía que la Agencia reconoce como válida.
Antes de presentarlo, la AEPD pone a disposición dos herramientas gratuitas de ayuda a la decisión: Asesora Brecha RGPD, para valorar si la brecha debe notificarse, y Comunica-Brecha RGPD, para valorar si además hay que comunicarla a las personas afectadas. Dejar constancia de que se han usado, y del resultado, es la forma más barata de documentar por qué se decidió notificar o no notificar.
¿Cuándo empiezan a contar las 72 horas?
Desde que tienes constancia razonable de que se ha producido la brecha, no desde que completas la investigación. Si a las 72 horas no dispones de toda la información, notificas lo que sabes e indicas que ampliarás. El RGPD admite expresamente la notificación por fases en el artículo 33.4.
¿Hay que notificar todas las brechas a la AEPD?
No. Solo las que suponen un riesgo para los derechos y libertades de las personas. Ahora bien, todas sin excepción deben quedar registradas internamente, incluidas las que decides no notificar, junto con el razonamiento que sustenta esa decisión.
¿Qué diferencia hay entre una brecha del RGPD y un incidente de NIS2?
El RGPD se activa cuando hay datos personales comprometidos y mira el riesgo para las personas. NIS2 se activa cuando hay un incidente significativo en un servicio esencial o importante y mira la continuidad del servicio. Un mismo suceso puede activar ambos circuitos a la vez.
¿Quién es responsable de notificar si la brecha ocurre en un proveedor?
El responsable del tratamiento es quien notifica a la AEPD. El proveedor, en su condición de encargado, debe informar al responsable sin dilación indebida en cuanto tenga conocimiento de la brecha, según el artículo 33.2 del RGPD. Ese deber debe estar recogido en el contrato de encargo.
¿Sirve de algo notificar tarde?
Sí. Notificar fuera de plazo indicando los motivos del retraso es siempre mejor que no notificar, y así lo prevé el propio artículo 33.1. El retraso injustificado se valora, pero la omisión total agrava mucho más el expediente.
Conclusión
Una brecha de seguridad se gestiona bien cuando la empresa ya sabía qué iba a hacer antes de que ocurriera. El reloj de 72 horas es corto para improvisar quién decide, quién valora el riesgo y quién firma la notificación. Y con NIS2 pendiente de transposición pero con sus obligaciones de fondo ya definidas, el mapa de destinatarios seguirá creciendo, no simplificándose.
Si quieres revisar si tu procedimiento de brechas resiste una inspección, o unificar en un solo registro lo que hoy tienes repartido entre protección de datos y seguridad de la información, en Laworatory te ayudamos a montarlo y a documentarlo.
Este contenido tiene finalidad informativa y no constituye asesoramiento jurídico para un caso concreto.
