Ultima revision
13 de junio de 2026
Fuente
EDPB
La novedad parece modesta: una plantilla. La consecuencia no lo es tanto. El Comité Europeo de Protección de Datos (EDPB) ha aprobado una plantilla común de notificación de brechas de datos personales y la ha enviado a consulta pública hasta el 5 de agosto de 2026. Si acaba implantándose en todas las autoridades de protección de datos de la UE, las empresas tendrán menos excusas para presentar avisos incompletos, tardíos o escritos como si nadie fuese a leerlos.
Traducido al castellano operativo: el reloj de las 72 horas del art. 33 del GDPR no cambia, pero el margen para improvisar sí puede reducirse bastante.
La decisión llegó en el pleno del EDPB del 10 de junio de 2026, el mismo en el que el organismo se reunió con el comisario Michael McGrath. La nota institucional mezcló varios asuntos —Digital Omnibus, protección de menores, publicidad política, transferencias internacionales y financiación de autoridades—, pero la pieza con efecto práctico inmediato para empresas y despachos no está ahí. Está en la plantilla.
No porque cree una obligación nueva. No la crea. El deber de notificar una violación de seguridad de los datos personales a la autoridad competente “sin dilación indebida y, de ser posible, a más tardar 72 horas después de que haya tenido constancia de ella” ya está en el art. 33.1 GDPR. Lo relevante es otra cosa: Bruselas lleva años predicando consistencia, pero hasta ahora cada autoridad nacional tenía sus propios formularios, portales y expectativas materiales. El resultado era previsible. La armonización existía en el PowerPoint; en la práctica, no tanto.
Eso es lo que esta plantilla intenta corregir.
Conviene separar el ruido del dato. El EDPB no ha aprobado una reforma legislativa ni una guía interpretativa del art. 33 comparable a las directrices de fondo sobre brechas. Ha adoptado un “common data breach notification template” y ha abierto una consulta pública sobre su contenido hasta el 5 de agosto de 2026. Después decidirá el calendario de implantación práctica por todas las autoridades nacionales.
Ese último detalle importa. Mucho. Hoy la plantilla no sustituye automáticamente a los formularios de cada DPA. Estamos en la fase previa: diseño común, comentarios del mercado y, más adelante, implementación. Pero precisamente por eso este es el momento útil para leerla. Cuando la plantilla ya sea obligatoria en la práctica, llegarás tarde para discutir si ciertos campos son razonables o si fuerzan a dar una precisión que muchas organizaciones simplemente no tienen en las primeras 24 horas tras un incidente.
Según el propio EDPB, la plantilla busca tres cosas: estructurar, armonizar y unificar los procesos de notificación. También dice que ayudará a garantizar que los avisos incluyan la información requerida por el art. 33 GDPR, facilitará la evaluación por las autoridades y ahorrará tiempo y costes, especialmente a organizaciones pequeñas sin DPO o sin apoyo jurídico interno. Todo eso suena impecable. La pregunta seria es otra: ¿qué cambia en la vida real de un CISO, de un DPO o de un responsable de cumplimiento cuando la teoría europea por fin aterriza en un formulario común?
El art. 33 GDPR lleva aplicándose desde el 25 de mayo de 2018. Sobre el papel, la obligación es bastante clara. Cuando una violación de seguridad de los datos personales sea probable que entrañe un riesgo para los derechos y libertades de las personas físicas, el responsable debe notificarla a la autoridad de control competente. Esa notificación debe describir, al menos, cuatro bloques: la naturaleza de la violación, incluidos cuando sea posible las categorías y el número aproximado de interesados y registros afectados; los datos de contacto del DPO u otro punto de contacto; las posibles consecuencias; y las medidas adoptadas o propuestas para remediarla y mitigar efectos adversos. Eso está en el art. 33.3, letras a) a d).
Si no puedes aportar toda la información a la vez, el art. 33.4 permite facilitarla de manera gradual sin más dilación indebida. Y si no notificas en 72 horas, el art. 33.1 exige acompañar la notificación de los motivos de la demora.
Hasta aquí, la ley. Ahora viene la parte menos elegante: la ley europea no eliminó las diferencias administrativas entre autoridades. Algunas DPAs piden formularios muy guiados; otras permiten más narrativa libre. Algunas fuerzan clasificaciones técnicas tempranas del incidente; otras no. Algunas exigen bastante granularidad sobre categorías de datos, número de afectados o medidas de contención, incluso cuando la investigación aún está verde. Otras son algo más pragmáticas. Para grupos multinacionales, eso se traduce en una molestia conocida: una obligación jurídicamente única con varias experiencias operativas, y no precisamente idénticas.
El EDPB lleva tiempo intentando reducir esa dispersión. La referencia explícita en la nota de prensa a la Helsinki Statement no es casual. Ese texto, adoptado para mejorar claridad, apoyo y engagement, iba exactamente de eso: menos fricción absurda y más consistencia. La plantilla encaja en esa lógica.
La ironía, claro, es que la simplificación europea suele llegar con un documento adicional. Esta vez, sin embargo, puede estar justificada.
En privacidad regulatoria, los formularios nunca son solo formularios. Son una declaración de expectativas del supervisor. Lo que el regulador convierte en campo obligatorio deja de ser un nice to have y pasa a formar parte del estándar mínimo de diligencia documental.
Si la plantilla común acaba desplegándose de forma homogénea, habrá al menos cinco efectos prácticos.
Muchas organizaciones siguen abordando una brecha como un problema puramente técnico durante las primeras 24 horas. Grave error. La plantilla empuja en sentido contrario: desde el minuto uno necesitas una narrativa regulatoria mínimamente coherente. No basta con saber que ha habido acceso no autorizado. Hay que mapear si hay datos personales, qué categorías, qué volumen aproximado, qué impacto plausible y qué medidas se han tomado.
Eso obliga a que respuesta a incidentes, legal, privacidad y negocio hablen el mismo idioma. Y además deprisa.
Cuando cada DPA usa un formulario distinto, una parte de las inconsistencias puede atribuirse al propio canal. Con una plantilla común, esa coartada se debilita. Si una empresa omite sistemáticamente campos básicos o entrega descripciones vagas, la autoridad tendrá una base más fuerte para decir: no es que el proceso fuera confuso; es que ustedes llegaron mal preparados.
Esto interesa a los supervisores más de lo que suelen admitir en las notas de prensa. Si todos notifican con la misma estructura, es más fácil comparar patrones de causa raíz, tiempos de detección, tipos de datos afectados o medidas de mitigación. Y si es más fácil comparar, también es más fácil detectar quién está gestionando incidentes con madurez y quién improvisa cada trimestre.
El GDPR permite completar información por fases. Pero esa flexibilidad no es infinita. Una plantilla más detallada puede generar una expectativa material más alta sobre lo que una organización razonable debe ser capaz de identificar dentro de 72 horas. No lo cambia el artículo. Lo cambia la práctica supervisora.
No todas las DPAs tienen el mismo presupuesto, personal o sofisticación técnica. El propio EDPB aprovechó la reunión con McGrath para insistir en la necesidad de financiación y plantilla suficientes para las autoridades. La plantilla común actúa también como compensación parcial: uniforma criterios de entrada y facilita el triage. Puede no resolver la escasez de recursos, pero sí ordenar el flujo de expedientes.
Casi todas las discusiones internas sobre brechas acaban en la misma pregunta: ¿cuándo empiezan exactamente las 72 horas? La respuesta jurídica corta está en el art. 33.1: cuando el responsable del tratamiento “tenga constancia” de la violación. La respuesta operativa larga es más incómoda: empieza antes de lo que muchas empresas querrían admitir.
El problema no es nuevo. Las directrices del antiguo Grupo de Trabajo del Artículo 29 sobre notificación de brechas, luego asumidas por el ecosistema del EDPB, ya indicaban que un responsable debe considerarse “con conocimiento” cuando tiene un grado razonable de certeza de que se ha producido un incidente de seguridad que ha comprometido datos personales. No hace falta un informe forense final, ni el recuento perfecto de registros afectados, ni una cronología digna de sala de vistas.
Esto choca de frente con la cultura habitual de respuesta a incidentes. El equipo técnico quiere confirmar. Legal quiere matizar. Comunicación quiere esperar. El negocio quiere entender alcance reputacional. Mientras tanto, el reloj no se para por cortesía.
La nueva plantilla puede empeorar esa tensión para quien llegue sin preparación. Si el formulario estandariza preguntas concretas sobre naturaleza de la brecha, categorías de datos, número estimado de afectados o medidas de mitigación, el debate interno sobre si “ya sabemos lo suficiente” va a tener menos margen retórico. O sabes responder algo razonable, aunque provisional, o tendrás que explicar por qué no.
Aquí está el quid: la plantilla no endurece formalmente la ley, pero sí endurece la disciplina probatoria alrededor de la ley.
Quien lea esta noticia como un asunto para el DPO y solo para el DPO está leyendo mal. La notificación de brechas es uno de los puntos donde más brutalmente se ve si una organización tiene gobernanza transversal o solo organigramas bonitos.
Hay cuatro fricciones prácticas que la plantilla va a dejar al descubierto.
Muchas empresas todavía clasifican incidentes con categorías útiles para el SOC pero inútiles para privacidad. “Compromiso de cuenta”, “actividad anómala”, “malware”, “exfiltración potencial”, “error humano”. Bien. Ahora intenta traducir eso, en menos de 72 horas, a si ha habido destrucción, pérdida, alteración, divulgación no autorizada o acceso no autorizado a datos personales; a qué categorías de interesados afecta; y a qué tipos de datos se refiere. Ese salto semántico no se improvisa.
Si el playbook de incidentes no incorpora desde el inicio un árbol de decisión específico para el art. 33 GDPR, la plantilla te va a recordar el problema de forma poco amable.
El art. 33.3.a) no pide exactitud quirúrgica; pide, “cuando sea posible”, categorías y número aproximado de interesados y registros. Aun así, muchas organizaciones no tienen métodos internos pactados para producir estimaciones tempranas y defendibles. Resultado: números inflados “por si acaso”, o ridículamente bajos para ganar tiempo. Ninguna de las dos cosas ayuda.
Con una plantilla común, la consistencia de esas estimaciones será más visible. Si primero notificas 500 afectados, luego corriges a 50.000 y después vuelves a 7.200, la autoridad no solo verá la evolución; verá también que tu proceso de cuantificación probablemente era endeble.
No toda violación de seguridad exige notificación. El art. 33 se activa cuando la brecha sea probable que entrañe un riesgo para los derechos y libertades de las personas físicas. El problema es que muchas empresas siguen evaluando ese riesgo con criterios demasiado abstractos o, peor, con un sesgo puramente reputacional: “si no sale en prensa, no es grave”. No funciona así.
Hay que cruzar al menos tipo de datos, facilidad de identificación, volumen, vulnerabilidad de los afectados, posible reutilización maliciosa y contexto del incidente. Un acceso indebido a nombres y correos internos no pesa igual que historiales de salud, credenciales, datos financieros, documentación de identidad o información sobre menores. Y el EDPB, en su nota del 10 de junio, subrayó precisamente la protección de niños como prioridad. Ese detalle no es decorativo: anticipa sensibilidad regulatoria reforzada cuando el incidente toque datos de menores.
Las brechas de datos ya no viven solas en una esquina del compliance. Una misma crisis puede activar varios relojes regulatorios a la vez. GDPR por un lado. NIS2 por otro, con su esquema de alerta temprana en 24 horas, notificación de incidente en 72 horas e informe final en un mes para determinadas entidades esenciales e importantes, conforme al art. 23 de la directiva. DORA, para entidades financieras, añade su propio régimen de gestión y reporte de incidentes TIC graves en los arts. 17 a 20 y en la normativa técnica asociada. Si además hay impacto contractual, consumo o mercado, la fiesta burocrática ya está completa.
La plantilla del EDPB no resuelve esa superposición. Pero sí obliga a ponerla encima de la mesa. Si tu organización notifica a la autoridad de protección de datos una cifra o una cronología distinta de la enviada al supervisor sectorial, prepárate para preguntas incómodas.
La retórica oficial habla de facilitar el cumplimiento. Y algo de eso hay. Una buena plantilla reduce fricción, especialmente para pymes y entidades sin músculo jurídico interno. Pero sería ingenuo quedarse ahí. La otra cara de la moneda es que la estandarización mejora la capacidad de las autoridades para supervisar con más precisión y menos coste.
Piensa en lo que ocurre cuando decenas de autoridades nacionales reciben miles de notificaciones con estructuras y niveles de detalle distintos. Comparar se vuelve difícil. Priorizar, también. Detectar patrones, más aún. Con un formato común, todo eso mejora. El supervisor puede identificar más rápido incidentes con categorías de datos especialmente sensibles, organizaciones con reincidencia, retrasos sistemáticos, causas técnicas repetidas o sectores con controles inmaduros.
Y no hace falta imaginar un gran salto tecnológico para que eso ocurra. Basta una estructura uniforme y campos estables.
Por eso esta plantilla encaja con otra línea de la nota del EDPB: la insistencia en la cooperación interregulatoria y en la necesidad de reforzar capacidades en un ecosistema digital “dinámico, multicapa y en evolución”. La frase institucional puede sonar a libreto. La implicación práctica no. Cuanto más comparables sean los datos que entran por la ventanilla de las DPAs, más sencillo será compartir patrones y coordinar respuestas, incluso entre reguladores con competencias distintas.
El mismo pleno en el que se adoptó la plantilla sirvió para que el EDPB trasladara a Michael McGrath una advertencia política bastante nítida sobre el llamado Digital Omnibus. El Comité dijo que apoya ciertas simplificaciones, pero rechazó las propuestas de modificación de la definición de dato personal por el riesgo de debilitar de forma significativa la protección de las personas.
Ese mensaje importa porque dibuja la filosofía del momento. El EDPB está dispuesto a hablar de simplificación regulatoria, sí, pero no a costa de vaciar conceptos nucleares del GDPR. Dicho sin rodeos: aceptan simplificar el cumplimiento procedimental; no aceptan simplificar la norma hasta dejarla irreconocible.
La plantilla de brechas es coherente con esa posición. Facilita la ejecución administrativa sin tocar el núcleo material del derecho. Es una simplificación de canal, no de sustancia.
Para las empresas esto tiene una lectura clara. Si alguien esperaba una ola de “desregulación práctica” en privacidad al calor de la competitividad europea, conviene rebajar expectativas. Lo que parece venir es algo menos romántico: procedimientos algo más uniformes y, al mismo tiempo, vigilancia más afinada sobre cómo se cumplen obligaciones ya existentes.
No todo son ventajas. También hay riesgos, y conviene decirlos antes de que la consulta pública cierre el 5 de agosto.
Cuanto más guiado y accesible sea el formulario, más tentación habrá de notificar “por si acaso” incidentes fronterizos. Algunas organizaciones ya lo hacen. Prefieren reportar de más a pelear luego por una omisión. Eso puede inflar el volumen de notificaciones de poco valor, saturar autoridades y desdibujar la frontera entre incidente de seguridad y brecha notifiable.
El EDPB deberá vigilar que la plantilla no transmita el mensaje implícito de que cualquier incidente con datos personales merece subir automáticamente a la DPA. El estándar legal del art. 33 sigue siendo el riesgo para derechos y libertades, no la mera existencia de una anomalía técnica.
Todo formulario largo invita a rellenar casillas con frases estereotipadas. “Se está investigando”, “no se descartan afectados adicionales”, “se han adoptado medidas inmediatas”. Frases que lo dicen todo y no dicen nada. Si la plantilla se convierte en una liturgia de compliance, habrá fracasado. La calidad de la notificación depende tanto de la estructura como de la voluntad del responsable de decir algo útil.
Las autoridades también tienen responsabilidad aquí. Si empiezan a valorar más la completitud superficial del formulario que la honestidad sobre incertidumbres reales, incentivarán justo lo contrario de lo que dicen buscar.
La ventanilla única del GDPR nunca ha sido precisamente un mecanismo libre de fricciones. Determinar autoridad principal, coordinar con interesados en varios Estados miembros y alinear criterios internos ya es bastante trabajoso. Una plantilla común puede ayudar, sí, pero no elimina los problemas de fondo del one-stop-shop ni las tensiones entre autoridades interesadas cuando el incidente es serio o mediático.
En otras palabras: un formulario común no cura una arquitectura institucional compleja. Solo la hace un poco menos caótica en la superficie.
Si trabajas en banca, seguros, pagos o infraestructura de mercado, este movimiento del EDPB no te cae precisamente en una temporada tranquila. DORA ya ha elevado de forma sustancial la conversación sobre incidentes TIC, gobernanza, terceros proveedores y pruebas de resiliencia. En paralelo, NIS2 está reordenando los deberes de ciberseguridad e informe en sectores críticos. Y el GDPR sigue ahí, con su propio vocabulario, sus umbrales y sus consecuencias sancionadoras.
La “mala” noticia es que una plantilla común de brechas obliga a afinar aún más la interoperabilidad entre funciones. La buena es que, para una entidad financiera madura, debería ser una oportunidad para limpiar duplicidades y contradicciones internas.
Hay al menos tres cruces que conviene revisar.
DORA no sustituye el deber de notificar brechas personales cuando se cumplen los requisitos del GDPR. Un incidente TIC grave puede no implicar datos personales; una brecha personal puede no llegar al umbral sectorial de DORA; y a veces tendrás ambas cosas a la vez. Si los equipos trabajan con cronologías, taxonomías y responsables distintos, la inconsistencia documental está servida.
La plantilla del EDPB puede convertirse en el documento que exponga esas costuras. Si en DORA describes una indisponibilidad con impacto operativo de cierta duración y en GDPR presentas una cronología mucho más difusa sobre acceso o exfiltración, el supervisor sectorial y la DPA no tienen por qué enterarse el mismo día, pero sería imprudente asumir que nunca cruzarán impresiones.
NIS2, una vez transpuesta y operativa según cada Estado miembro, obliga a determinadas entidades a una alerta temprana en 24 horas desde tener conocimiento de un incidente significativo, una notificación en 72 horas y un informe final en un plazo de un mes. El paralelismo temporal con el GDPR es engañoso. No miden exactamente lo mismo ni piden exactamente la misma información.
Eso exige una arquitectura de reporting donde haya un núcleo factual común —qué pasó, cuándo se detectó, qué sistemas y datos afectó, qué mitigaciones se activaron— y capas regulatorias diferenciadas según el destinatario. Si no lo tienes, tu organización corre el riesgo de producir tres relatos distintos de un mismo evento. Y eso, llegado el caso, es peor que admitir de inicio que aún faltan datos.
En finanzas, buena parte de las brechas nacen o se detectan en proveedores TIC, procesadores de datos, SaaS críticos o subencargados. El art. 33 GDPR recae sobre el responsable, no sobre el proveedor, aunque el encargado tenga el deber de notificar al responsable “sin dilación indebida” conforme al art. 33.2. Si el proveedor tarda, filtra información a cuentagotas o ni siquiera usa categorías compatibles con la plantilla del EDPB, el responsable llegará cojo a la autoridad.
Aquí DORA vuelve a asomar por la puerta. Su obsesión con terceros TIC críticos y con el control contractual de la cadena no es una manía burocrática; es una constatación de dependencia. Una plantilla común de brechas bajo GDPR hará más visible qué contratos y playbooks con proveedores están mal diseñados.
No todas las consultas públicas merecen tiempo. Esta sí, especialmente para grandes grupos, asociaciones sectoriales, despachos que gestionan incidentes transfronterizos y proveedores forenses o de respuesta a incidentes que luego tienen que traducir hechos técnicos a lenguaje regulatorio.
Las preguntas útiles para comentar no son filosóficas. Son quirúrgicas.
Primero, si los campos distinguen bien entre información obligatoria inicial e información que razonablemente puede aportarse después conforme al art. 33.4. Si la plantilla exige precisión prematura, fomentará respuestas defensivas o directamente especulativas.
Segundo, si la taxonomía propuesta para tipos de incidente, categorías de datos y consecuencias previsibles refleja la realidad operativa. Si no la refleja, los usuarios acabarán encajando incidentes complejos en casillas simplistas. Eso genera malos datos para todos.
Tercero, si el formulario ayuda a explicar incertidumbre sin penalizarla indebidamente. Un buen modelo no obliga a fingir certeza. Permite declarar hipótesis de trabajo, nivel de confianza y próximas actualizaciones.
Cuarto, si contempla bien la posición de pymes y entidades sin DPO. El EDPB presenta la plantilla como una herramienta de ahorro de tiempo y costes para organizaciones con menos recursos. Perfecto. Pero ese objetivo se frustra si el formulario presupone una madurez de inventario de datos o de logging que muchas pequeñas entidades no tienen.
Quinto, si la plantilla facilita la interoperabilidad con otros marcos de reporte. No hace falta que integre DORA o NIS2, pero sí que evite pedir datos en formatos que choquen frontalmente con otros canales regulatorios.
La nota del EDPB también menciona dos trabajos paralelos: futuras directrices sobre tratamiento de datos de menores y avances sobre las directrices relativas a tratamiento de datos personales para segmentar o entregar publicidad política bajo el Reglamento (UE) 2024/900 sobre transparencia y segmentación de la publicidad política. A primera vista, parecen asuntos desconectados de la plantilla de brechas. No del todo.
Sirven para leer la agenda del regulador. Menores y publicidad política son dos áreas donde el impacto sobre derechos fundamentales y la sensibilidad pública son máximos. Si una brecha afecta a datos de menores o a sistemas de segmentación política, el análisis de riesgo bajo el art. 33 y, en su caso, la comunicación a los interesados conforme al art. 34 GDPR, se vuelve más delicado. No por capricho, sino porque el daño potencial es distinto y la tolerancia institucional será previsiblemente menor.
Dicho de otro modo: la plantilla es horizontal, pero el contexto regulatorio alrededor no lo es. Algunos tipos de datos y algunos contextos de tratamiento van a seguir recibiendo una atención mucho más intensa.
No hace falta esperar a la implantación final para sacar trabajo útil de esta noticia. De hecho, esperar sería una forma bastante cara de procrastinación.
Lo sensato ahora es coger la plantilla del EDPB y usarla como prueba de estrés interna. No como documento final, sino como examen. ¿Podrías rellenarla con información fiable dentro de las primeras 24 a 48 horas tras un incidente serio? Si la respuesta es no, ya sabes dónde están tus huecos.
El ejercicio suele revelar fallos muy concretos: inventarios de tratamiento demasiado abstractos para mapear categorías de datos a velocidad útil; contratos con encargados que no exigen notificación lo bastante detallada; playbooks de crisis donde el DPO entra tarde; ausencia de criterios de cuantificación temprana; logs insuficientes para distinguir acceso potencial de acceso confirmado; y, quizá el clásico más deprimente, múltiples hojas de cálculo compitiendo por ser “la versión buena” de los hechos.
También conviene revisar quién firma internamente el juicio de notificación. No legalmente, sino operativamente. El art. 33 exige velocidad con criterio. Si la decisión depende de una cadena de aprobaciones que tarda dos días en reunirse, la organización ya está perdiendo antes incluso de discutir si hubo riesgo significativo.
Una mejora sencilla, y a menudo infravalorada, consiste en preasignar responsables por bloque de información: técnico para cronología y vector; privacidad para base factual de datos personales y riesgo a derechos; negocio para procesos afectados; legal para consistencia regulatoria; comunicación para mensajes externos alineados con el nivel de certeza disponible. Suena básico. No lo es tanto cuando llega el incidente de verdad.
Hay una lectura más amplia. Europa no está rebajando su ambición regulatoria digital. Está intentando hacerla un poco menos errática en la ejecución. No es lo mismo, y conviene no confundirse.
La reunión con McGrath deja ver un equilibrio bastante claro. El EDPB acepta el lenguaje político de la simplificación, pero pone una línea roja cuando esa simplificación amenaza conceptos esenciales como la definición de dato personal. Al mismo tiempo, impulsa mecanismos de homogeneización práctica, como la plantilla de brechas, que reducen fricción para el mercado y mejoran capacidad de supervisión para las autoridades. Es una jugada doble: menos dispersión administrativa, más consistencia exigible.
Para las empresas, eso significa que la vieja estrategia de cumplir “a la manera de cada país” puede empezar a perder eficiencia. La tendencia es la contraria: más normalización europea en la interfaz de cumplimiento, aunque el fondo jurídico siga requiriendo análisis fino caso por caso.
Quien gane con este movimiento no será necesariamente quien más papel produzca. Será quien convierta la obligación de notificar en un proceso repetible, medible y compatible con otras obligaciones regulatorias. Los demás seguirán llamando “incidente aislado” a lo que ya parece un patrón.
La noticia del EDPB no trae la épica de una gran sanción ni el dramatismo de una nueva ley. Trae algo más prosaico y, para bastantes organizaciones, más peligroso: un instrumento que puede hacer visible lo mal que están preparadas para explicar una brecha dentro de plazo.
La consulta pública termina el 5 de agosto de 2026. Después llegará la decisión sobre implantación. Entre medias hay una oportunidad poco glamurosa, pero valiosa: revisar si tu proceso de notificación aguanta un formulario común pensado por reguladores que, esta vez, parecen menos interesados en la retórica y más en la utilidad práctica.
Si tu organización necesita tres reuniones para decidir si una exfiltración con datos personales “entra o no entra”, si aún no puede estimar afectados sin abrir cinco sistemas y llamar a un proveedor, o si privacidad y ciberseguridad siguen trabajando con cronologías distintas, la plantilla del EDPB no será el problema. Solo será el espejo.
Resumen semanal gratis
Suscríbete al resumen semanal de regulación, vulnerabilidades explotadas y acciones para tu equipo.
¿Quieres un plan a medida? Modela tu organización con Agentic Digital Twin.
Es el proceso de vigilar de forma continua los cambios normativos y las vulnerabilidades relevantes, y traducirlos en acciones concretas para los equipos de seguridad, riesgo y compliance.
Una vulnerabilidad explotada puede activar obligaciones de notificación o gestión de riesgo (por ejemplo en DORA, NIS2 o el CRA). Mapear la amenaza al marco aplicable permite priorizar la respuesta.
Un GAP Assessment evalúa tu madurez por control frente al marco elegido (DORA, NIS2, ISO 27001, etc.) y produce un plan de acción con brechas priorizadas.
Recursos oficiales
Descarga políticas, checklists y frameworks de cumplimiento elaborados por expertos en regulación Cyber.