La guía del EDPB sobre brechas no cambia el GDPR, pero sí complica las excusas habituales

El Comité Europeo de Protección de Datos no ha inventado una obligación nueva. Tampoco ha reescrito el GDPR. Lo que ha hecho al destacar de nuevo sus materiales sobre notificación de brechas personales es algo bastante menos vistoso y bastante más útil: recordar que, en 2026, muchas organizaciones siguen fallando en lo básico. No en teoría. En la ejecución.

La referencia del EDPB a Personal data breach notifications y, en particular, a sus Guidelines 01/2021 on Examples regarding Data Breach Notification, devuelve a la mesa una realidad incómoda para equipos legales, CISOs y DPOs: el problema rara vez está en saber que el GDPR exige notificar. El problema está en clasificar bien el incidente, documentarlo con criterio, decidir si activa el artículo 33, valorar si también entra el artículo 34 y hacerlo todo dentro de un reloj que corre desde que la entidad tiene “conocimiento” de la brecha. Ese reloj no espera a que el comité de crisis encuentre un hueco en la agenda.

La pieza del EDPB llega además en un momento regulatorio menos indulgente. Este año, las entidades financieras ya operan con DORA plenamente aplicable desde el 17 de enero de 2025, NIS2 está ya asentada en los programas de ciber y resiliencia de medio continente, y la gestión de incidentes ha dejado de ser una disciplina compartimentada. Un mismo evento puede disparar obligaciones en paralelo bajo GDPR, DORA, NIS2, reglas contractuales con clientes y, si la cosa escala, deberes de comunicación al mercado. Pensar la brecha solo como un asunto de privacidad es una receta antigua. Y en 2026, bastante peligrosa.

Lo interesante aquí no es repetir que hay que notificar en 72 horas. Eso ya lo sabe cualquiera que haya sobrevivido a una sola auditoría de privacidad. Lo relevante es afinar tres preguntas que siguen generando errores caros: cuándo empieza de verdad ese plazo, qué significa “riesgo” frente a “alto riesgo”, y qué nivel de evidencia necesita una organización antes de comunicar a la autoridad o a los afectados. Ahí es donde la guía del EDPB sigue siendo valiosa y donde muchas empresas, seamos sinceros, aún operan con intuición, plantillas recicladas y algo de fe.

El punto legal que más se malinterpreta: el plazo de 72 horas no empieza cuando termina la investigación

El artículo 33.1 del GDPR obliga al responsable del tratamiento a notificar la brecha de datos personales a la autoridad de control competente “sin dilación indebida y, de ser posible, a más tardar 72 horas” después de haber tenido constancia de ella, salvo que sea improbable que la brecha constituya un riesgo para los derechos y libertades de las personas físicas. El matiz decisivo está en “haber tenido constancia”. No dice “cuando el forense entregue el informe final”. No dice “cuando TI confirme el vector exacto de ataque”. No dice “cuando el comité ejecutivo apruebe el wording”.

La interpretación europea, sostenida desde las antiguas directrices del Grupo de Trabajo del Artículo 29 y reforzada por los ejemplos del EDPB, es bastante práctica: una organización tiene constancia cuando dispone de un grado razonable de certeza de que se ha producido un incidente de seguridad que ha comprometido datos personales. Esa certeza puede ser parcial. Puede haber lagunas. Puede faltar el recuento fino de afectados. Aun así, el reloj corre.

Esto tiene consecuencias operativas nada menores. Si un SOC detecta exfiltración, si un proveedor confirma acceso no autorizado a una base de datos con identificadores de clientes, o si un empleado envía por error un fichero con nóminas al destinatario equivocado y la empresa lo sabe, la discusión ya no debería ser “esperemos a entenderlo todo”. Debería ser “qué sabemos ahora, qué riesgo parece haber y qué información mínima necesitamos para decidir”.

El propio GDPR prevé que la notificación inicial sea incompleta. El artículo 33.4 permite facilitar la información por fases cuando no sea posible darla toda al mismo tiempo. Eso desmonta una excusa muy extendida: retrasar la notificación porque aún faltan detalles. Si faltan detalles, se notifica con lo disponible y se amplía después. No es elegante, pero es legal. Y, sobre todo, es mucho más defendible ante una autoridad que una notificación fuera de plazo adornada con la coartada habitual de “seguíamos investigando”.

La Agencia Española de Protección de Datos, como otras autoridades europeas, lleva años en esa línea. No exige omnisciencia. Exige diligencia. Son cosas distintas. Y conviene no confundirlas justo cuando el incidente está caliente.

No toda brecha se notifica, pero documentarlas todas sigue siendo obligatorio

Aquí aparece otro error clásico: creer que si una brecha no alcanza el umbral de notificación, entonces apenas deja huella documental. No. El artículo 33.5 del GDPR exige que el responsable documente cualquier violación de la seguridad de los datos personales, incluidos los hechos relacionados con ella, sus efectos y las medidas correctivas adoptadas. Cualquiera. También las que no se notifican.

Esto importa por dos razones. La primera es jurídica: esa documentación permite a la autoridad verificar el cumplimiento del artículo 33. Sin registro, la empresa no tiene cómo demostrar por qué decidió no notificar. La segunda es operativa: si la organización no genera memoria institucional sobre sus incidentes, repetirá los mismos fallos con admirable constancia. Y sí, hay empresas que consiguen tropezar tres veces con la misma piedra cambiándole solo el nombre al proyecto.

Las directrices del EDPB sobre ejemplos de notificación son especialmente útiles porque bajan el debate del plano abstracto al terreno de los casos reales: pérdida de dispositivos, ransomware, envíos erróneos, indisponibilidad, alteración de datos, acceso interno no autorizado. Ahí se ve con claridad algo que a veces se infravalora: una brecha no es solo confidencialidad. También puede afectar a la integridad o a la disponibilidad. Esa tríada, tan conocida en ciberseguridad, tiene efectos directos en privacidad.

Si una organización sanitaria pierde acceso a historiales por un cifrado malicioso, o si una entidad financiera ve alterados datos de clientes en un sistema crítico, puede haber brecha de datos personales aunque no exista evidencia de exfiltración. La indisponibilidad prolongada y la manipulación de datos personales pueden generar riesgos muy serios para los interesados. El EDPB lleva tiempo recordándolo porque demasiadas empresas han tratado los incidentes de disponibilidad como si fueran solo un asunto de continuidad de negocio. A veces lo son. A veces también son un problema de GDPR.

Riesgo y alto riesgo: la frontera que decide si llamas al regulador, al afectado o a ambos

El esquema legal del GDPR es simple sobre el papel y bastante menos simple a las tres de la mañana. Si la brecha es improbable que suponga un riesgo para los derechos y libertades de las personas físicas, no se notifica a la autoridad. Si sí hay riesgo, entra el artículo 33. Si además es probable que ese riesgo sea alto, entra también el artículo 34 y toca comunicar la brecha a los interesados sin dilación indebida.

La dificultad real está en valorar ese riesgo con algo más serio que una corazonada. El EDPB insiste en factores bastante concretos: tipo de brecha, naturaleza y sensibilidad de los datos, facilidad de identificación de las personas, gravedad de las consecuencias, características de los afectados y particularidades del responsable. No es lo mismo exponer una base con emails de newsletter que un conjunto de datos con información financiera, sanitaria o de identidad suficiente para facilitar fraude.

Un detalle que suele pasarse por alto: el artículo 34 no se activa solo por el volumen. Diez registros pueden bastar si contienen información muy sensible o si afectan a personas en situación de vulnerabilidad. Y al revés, un incidente amplio no siempre implicará comunicación individual si el riesgo efectivo es bajo o si concurren las excepciones del artículo 34.3.

Esas excepciones importan mucho más de lo que parece. El artículo 34.3 permite no comunicar a los interesados si el responsable ha aplicado medidas técnicas y organizativas apropiadas que hagan ininteligibles los datos para cualquier persona no autorizada, como el cifrado; si ha tomado medidas ulteriores que garanticen que ya no existe probabilidad de alto riesgo; o si la comunicación individual exigiera un esfuerzo desproporcionado, en cuyo caso procede una comunicación pública o medida similar. Esto significa que el cifrado bien implementado no es un adorno de compliance: puede cambiar de forma radical la carga de notificación y el impacto reputacional.

Aquí está uno de los mensajes menos glamourosos y más estratégicos para 2026: la arquitectura de seguridad determina consecuencias regulatorias. Un cifrado robusto, una segmentación eficaz, una gestión seria de claves o una minimización real de datos no solo reducen la probabilidad de incidente. También mejoran la posición jurídica cuando el incidente sucede, que es cuando la poesía corporativa deja paso a los hechos.

Los ejemplos del EDPB siguen siendo útiles porque desmontan automatismos peligrosos

Las Guidelines 01/2021 del EDPB, publicadas para consulta pública en enero de 2021 y aún muy citadas en la práctica, no son una lectura emocionante. Tampoco pretenden serlo. Su valor está en que obligan a salir del pensamiento binario. No todo ransomware se trata igual. No toda pérdida de dispositivo implica notificación. No todo email enviado por error acaba en artículo 34. Los hechos importan.

Pongamos ransomware. Durante años, muchas organizaciones asumieron que si no había prueba de exfiltración, el asunto quedaba en continuidad de negocio y recuperación. El EDPB complica ese confort. Un ataque que cifre datos personales puede constituir una brecha por pérdida de disponibilidad; si además existen indicios razonables de acceso o extracción, entra también la dimensión de confidencialidad. Y si la indisponibilidad afecta a servicios esenciales para los interesados, el riesgo puede subir con rapidez. En un hospital, una aseguradora de salud o una entidad de pagos, esa evaluación no admite respuestas prefabricadas.

Otro ejemplo recurrente es el correo enviado al destinatario equivocado. Demasiadas empresas siguen tratándolo como “error menor” por reflejo cultural. El EDPB obliga a mirar más fino: quién recibió la información, qué datos incluía, si el receptor está sujeto a deberes de confidencialidad, si confirmó borrado, si hubo acceso efectivo, si el contenido permitía fraude, discriminación o perjuicio económico. Un fichero con nóminas, datos bancarios o categorías especiales del artículo 9 no se parece en nada a un mensaje con nombre y apellido ya conocidos por el destinatario. Meter ambos incidentes en la misma casilla es gestión perezosa.

También resulta útil la atención a brechas internas. El hecho de que el acceso indebido provenga de un empleado no reduce automáticamente el riesgo. A veces lo agrava, porque el usuario interno sabe dónde buscar, entiende el contexto de negocio y puede explotar mejor la información. El GDPR no distingue entre curiosidad corporativa y acceso no autorizado con malas intenciones. Si no había legitimación para acceder, hay incidente que evaluar.

Lo que cambia en 2026: las brechas ya no se gestionan solo con el manual de privacidad

A estas alturas, el mayor error de gobernanza no es interpretar mal el artículo 33. Es tratarlo como un silo. Un incidente de datos personales puede activar varias capas regulatorias a la vez, con tiempos, destinatarios y taxonomías diferentes. Ese cruce es donde están chocando muchas organizaciones este año.

En el sector financiero, DORA exige mecanismos de gestión, clasificación y notificación de incidentes relacionados con las TIC. El reglamento base fija la obligación general en su artículo 17 para la gestión del proceso de incidentes y en su artículo 19 para la notificación de incidentes graves relacionados con las TIC. Luego llegan las normas técnicas y los marcos nacionales de supervisión para afinar criterios, plazos y plantillas. La consecuencia práctica es obvia: un incidente puede ser brecha de datos personales bajo GDPR y, al mismo tiempo, incidente grave bajo DORA. El equipo de privacidad puede pensar en derechos y libertades; el equipo de resiliencia, en impacto operativo y servicios críticos; el supervisor financiero, en estabilidad y dependencia tecnológica. Todos miran el mismo fuego desde ventanas distintas.

NIS2 añade otra capa para entidades esenciales e importantes. Su artículo 23 establece deberes de notificación escalonada: alerta temprana en 24 horas desde que se tenga conocimiento del incidente significativo, notificación en 72 horas y un informe final en el plazo de un mes, salvo ajustes de transposición nacional. Ese calendario no coincide exactamente con GDPR, que habla de 72 horas para la autoridad de protección de datos. Si tu organización está sujeta a ambas normas y no tiene un playbook unificado, la probabilidad de contradicciones entre notificaciones aumenta bastante. Y los reguladores leen. Vaya si leen.

El choque más frecuente es terminológico. Bajo GDPR, la pregunta central es el riesgo para los derechos y libertades de personas físicas. Bajo DORA o NIS2, el análisis pivota más sobre gravedad operativa, impacto en servicios, duración, extensión geográfica, afectación a terceros o repercusión económica. Un incidente puede no parecer dramático desde ciberresiliencia y sí ser gravísimo en privacidad, o al revés. Por eso la coordinación entre CISO, DPO, legal, riesgo operacional, continuidad y comunicación ya no es una buena práctica voluntaria. Es la única manera sensata de no decir cosas incompatibles a tres autoridades distintas en la misma semana.

Qué esperan de verdad las autoridades cuando notificas una brecha

La fantasía corporativa consiste en creer que la autoridad espera un documento perfecto, estanco y definitivo. La realidad es más prosaica. Lo que suele esperar es una notificación temprana, honesta, suficientemente concreta y coherente con los hechos conocidos en ese momento.

El artículo 33.3 del GDPR es claro sobre el contenido mínimo de la notificación: describir la naturaleza de la violación, incluidas, cuando sea posible, las categorías y el número aproximado de interesados y de registros afectados; comunicar el nombre y datos de contacto del DPO o de otro punto de contacto; describir las posibles consecuencias; y describir las medidas adoptadas o propuestas para remediar la violación y mitigar sus posibles efectos adversos. No es poco, pero tampoco exige una autopsia forense completa en 72 horas.

Lo que sí penaliza mucho una autoridad es la inconsistencia. Si la notificación inicial minimiza el incidente sin base razonable, si omite categorías de datos que luego aparecen, si el relato cambia porque nadie validó internamente los hechos, el problema no es solo el incidente. Es la credibilidad de la organización. Y esa credibilidad se vuelve crucial si después toca defender por qué no se comunicó a los afectados, por qué no se notificó antes o por qué la documentación interna no cuadra con lo dicho fuera.

Otra expectativa creciente es la trazabilidad de la decisión. Cuando una empresa concluye que no notifica porque el riesgo es improbable, debería poder enseñar la evaluación que llevó a esa conclusión: naturaleza de los datos, contexto del acceso, controles de protección, posibilidad real de abuso, reversibilidad del incidente y medidas de contención. Si la respuesta documental es una línea en una hoja Excel que dice “impacto bajo”, mala señal. Muy mala.

La brecha empieza antes del incidente: diseño, minimización y cifrado pesan más que el comunicado

Las guías del EDPB sobre notificación suelen leerse cuando ya hay un problema. Tiene lógica. Pero la lección realmente útil está antes. El artículo 25 del GDPR, desarrollado por las Guidelines 4/2019 sobre protección de datos desde el diseño y por defecto, conecta directamente con la severidad de las brechas. Si recoges más datos de los necesarios, los retienes más tiempo del debido, los replicas sin control o los dejas expuestos en entornos con privilegios excesivos, no solo aumentas la superficie de ataque. Aumentas el alcance regulatorio del incidente cuando llegue.

La minimización del artículo 5.1.c, la limitación del plazo de conservación del artículo 5.1.e y la seguridad del artículo 32 no son piezas separadas del debate sobre brechas. Son el prólogo. Y aquí conviene decir algo incómodo para muchas organizaciones: el mejor formulario de notificación no compensa una mala higiene de datos. Si almacenas cinco años de documentación que ya no necesitas, tendrás cinco años de dolor potencial cuando alguien entre.

El cifrado merece una mención aparte porque su efecto es doble. Por un lado, es una medida de seguridad del artículo 32 expresamente citada en el GDPR. Por otro, puede reducir o eliminar la obligación de comunicar a los afectados bajo el artículo 34.3.a si los datos quedan ininteligibles para terceros no autorizados. La palabra clave es “ininteligibles”. No basta con una promesa vaga de protección. Si las claves estaban expuestas junto con los datos, o si el esquema de cifrado no resistía un análisis serio, el argumento pierde fuerza rápidamente.

Lo mismo ocurre con la pseudonimización. Ayuda, sí. Pero no convierte mágicamente un incidente en irrelevante. Si los datos siguen siendo atribuibles con medios razonables, el riesgo persiste y la evaluación debe reflejarlo.

Implicaciones para entidades financieras españolas

Para bancos, aseguradoras, gestoras, entidades de pago, establecimientos de dinero electrónico y buena parte del ecosistema fintech en España, el recordatorio del EDPB llega en un punto especialmente sensible. Este año ya no vale separar “incidente de privacidad” de “incidente TIC” como si fueran departamentos que apenas se saludan en el ascensor.

Si una entidad sufre un acceso no autorizado a datos de clientes alojados en un proveedor cloud, pueden coexistir, como mínimo, cuatro planos de trabajo. Primero, el análisis GDPR: artículos 33 y 34, evaluación de riesgo, notificación a la AEPD y eventual comunicación a interesados. Segundo, la capa DORA: clasificación del incidente, posible reporte al supervisor competente si alcanza el umbral de gravedad, y revisión de controles sobre terceros TIC en la lógica del capítulo V y, en particular, del artículo 28 y siguientes sobre gestión del riesgo de terceros proveedores de servicios TIC. Tercero, obligaciones contractuales con clientes y socios, que a menudo exigen avisos en plazos incluso más agresivos que la ley. Cuarto, disciplina de mercado y continuidad operativa, especialmente si el incidente afecta a servicios esenciales o genera indisponibilidad relevante.

En España, además, el mapa supervisor no es ornamental. La AEPD mira la dimensión de protección de datos; Banco de España, CNMV o DGSFP pueden entrar por la vertiente sectorial según la entidad; y, si el incidente encaja en NIS2 a través de la transposición nacional aplicable, puede haber otro carril más. El viejo sueño de “un único reporte y asunto cerrado” rara vez sobrevive al primer incidente serio.

¿Dónde están viendo más fricción las entidades? En tres puntos muy concretos. Uno: dependencia de proveedores para confirmar hechos, lo que retrasa la evaluación sin detener los plazos legales. Dos: taxonomías distintas entre privacidad, ciber y resiliencia, que producen narrativas incompatibles. Tres: decisiones de comunicación al cliente tomadas más por temor reputacional que por criterios jurídicos y de riesgo documentados. Esa combinación es mala. Y bastante común.

Hay además un ángulo que DORA ha hecho imposible ignorar: la calidad del inventario de terceros TIC. Si no sabes con precisión qué proveedor trata qué datos, en qué jurisdicción, con qué subencargados y con qué tiempos de respuesta contractual ante incidentes, tu capacidad para cumplir el artículo 33 del GDPR se resiente. La privacidad depende mucho más de procurement de lo que a algunos les gustaría admitir.

El error de fondo: seguir tratando la notificación como un trámite y no como una capacidad

Las organizaciones maduras no improvisan la notificación de brechas. Ensayan. Tienen criterios de escalado, umbrales, roles definidos, formularios listos para usar, matrices de riesgo coherentes y mecanismos para registrar decisiones. No porque amen la burocracia, sino porque el tiempo disponible en un incidente real es brutalmente escaso.

La guía del EDPB sigue siendo relevante en 2026 por eso mismo. No aporta un titular explosivo, pero sí una disciplina mental: obligarte a razonar por escenarios, no por slogans. Si la empresa solo activa al DPO cuando el incidente ya ha salido en prensa, llega tarde. Si legal y seguridad no comparten una definición operativa de “brecha de datos personales”, llegarán a conclusiones distintas. Si comunicación redacta antes de que forense, DPO y negocio alineen hechos, el daño puede duplicarse.

Una capacidad real de notificación se apoya, como mínimo, en cinco piezas. Detección temprana con capacidad de distinguir incidentes de seguridad que afectan a datos personales. Escalado interno con tiempos medibles y responsables nombrados. Evaluación de riesgo con criterios repetibles, no con intuiciones cambiantes según quién esté de guardia. Documentación de decisiones, también cuando se decide no notificar. Y coordinación multirregulatoria para evitar contradicciones entre GDPR, DORA, NIS2 y obligaciones sectoriales o contractuales.

Eso no suena épico. Tampoco vende camisetas. Pero separa a las organizaciones que controlan el incidente de las que pasan una semana persiguiendo versiones distintas del mismo hecho.

Lo que deberían revisar ahora mismo los equipos de privacidad y ciber

Si tu organización sigue usando un procedimiento de brechas redactado hace cuatro o cinco años y apenas retocado desde entonces, probablemente ya va tarde. No porque el artículo 33 haya cambiado, sino porque el contexto operativo sí lo ha hecho. Hoy un incidente puede nacer en un SaaS, escalar en una API, impactar a un proveedor crítico, cruzar varias jurisdicciones y afectar a clientes, empleados y terceros en cuestión de horas. Los procedimientos heredados, pensados para la pérdida de un portátil o el email mal enviado, no siempre resisten ese nivel de complejidad.

La revisión debería centrarse en preguntas muy concretas. ¿Quién decide formalmente cuándo la organización tiene “constancia” de una brecha? ¿Existe una plantilla que recoja desde el primer momento los elementos del artículo 33.3? ¿Está definido cuándo debe implicarse el DPO y cuándo debe entrar además el equipo responsable de DORA o NIS2? ¿Los contratos con encargados y proveedores TIC obligan a informar lo bastante rápido como para que el responsable cumpla sus 72 horas? ¿Hay criterios escritos sobre cuándo el cifrado permite descartar la comunicación a interesados bajo el artículo 34.3.a? Si la respuesta a varias de estas preguntas es “depende”, eso suele significar “no está resuelto”.

También conviene revisar algo menos evidente: la calidad del registro histórico de incidentes. El artículo 33.5 no pide una tumba documental. Pide una base razonable que permita demostrar hechos, efectos y medidas correctivas. Ese registro, bien trabajado, sirve además para afinar controles: dónde se repiten errores, qué proveedores generan más fricción, qué unidades de negocio notifican tarde internamente, qué categorías de datos disparan riesgos recurrentes. Sin esa visión, cada incidente se gestiona como si fuese el primero. Y esa amnesia sale cara.

La lectura correcta del mensaje del EDPB

La actualización o visibilización de los materiales del EDPB sobre notificación de brechas no debería leerse como un gesto rutinario de archivo. El subtexto es más útil: las autoridades europeas siguen viendo valor en educar porque siguen viendo fallos repetidos. No solo en pymes sin recursos. También en organizaciones grandes, muy reguladas y llenas de comités que producen diapositivas impecables hasta que aparece una brecha de verdad.

La tesis central, si hay que condensarla, es esta: el cumplimiento en brechas ya no se mide por conocer la regla, sino por convertirla en capacidad operativa bajo presión. El GDPR, en sus artículos 33 y 34, da el marco. El EDPB da ejemplos para no perderse en abstracciones. DORA y NIS2 añaden una capa de complejidad que castiga la descoordinación. Y 2026 no está siendo un año especialmente tolerante con los programas de compliance que viven de plantillas bonitas y decisiones lentas.

Si algo debería sacar el lector de este recordatorio europeo no es miedo al formulario de notificación. Es una conclusión mucho menos decorativa: la próxima brecha no te preguntará si tu gobernanza está madura. Simplemente la pondrá a prueba. Y cuando eso ocurra, descubrirás muy deprisa si tu organización tiene un proceso o solo un documento.