Regulación FCA del 16 de abril de 2026 y el camino hacia DORA 2.0: lo que las instituciones financieras deben preparar arquitectónicamente ahora

8 min. de lectura

El 16 de abril de 2026, la autoridad reguladora financiera británica publicó nuevas normas de notificación de incidentes operativos y terceros, inaugurando así la primera oleada regulatoria post-DORA en Europa. La Financial Conduct Authority exige a las entidades financieras y a sus proveedores externos de TIC nuevos plazos de clasificación y notificación que superan a DORA en profundidad y rigor de supervisión. En paralelo, Bruselas prepara una evaluación de DORA que deberá culminar en un informe de revisión a finales de 2026 y que apunta a un endurecimiento normativo probable para 2027. Los equipos de seguridad no deberían esperar a DORA 2.0, sino poner a prueba su arquitectura frente a las deficiencias ya conocidas.

RelacionadoCVE de ASP.NET Core: consecuencias para el cumplimiento bajo DORA y NIS2  /  Seguridad OT 2026: IEC 62443 y la Ley de Resiliencia Cibernética

Qué cambió concretamente la UK-FCA el 16 de abril

La Financial Conduct Authority publicó el 16 de abril de 2026 su Policy Statement sobre las Operational Incident and Third-Party Reporting Rules. El endurecimiento central es una nueva obligación de notificación de dos categorías: cualquier incidente ICT operativamente relevante que supere un umbral de impacto cuantificado debe notificarse en el plazo de seis horas como Initial Notification, junto con un análisis detallado post-incidente en un plazo de 30 días. Destaca el elemento de Third-Party Reporting: las entidades financieras ya no deben notificar únicamente sus propios incidentes, sino también los incidentes materiales en sus proveedores terceros de ICT cuando estos tengan repercusión sobre los servicios financieros británicos.

DORA en su forma actual exige igualmente la notificación de incidentes, pero deja los umbrales de clasificación considerablemente más abiertos a interpretación. Los RTS de las ESA de 2024 definen criterios cualitativos, pero la práctica de implementación en los primeros 15 meses muestra que las entidades financieras realizan valoraciones muy dispares ante situaciones idénticas. El Reino Unido parece haber tomado nota de ello y ha cuantificado el catálogo de clasificación en su normativa sucesora.

Para las entidades financieras del área DACH, la nueva regulación británica resulta relevante por tres razones. En primer lugar, la mayoría de los grandes bancos y aseguradoras tienen operaciones significativas en el Reino Unido y deben implementar las reglas en cualquier caso. En segundo lugar, el texto británico actúa de facto como modelo para la evaluación de DORA que la Comisión Europea concluirá a finales de 2026. En tercer lugar, los umbrales del Reino Unido establecen un nuevo benchmark con el que los supervisores de los estados miembros de la UE calibrarán sus expectativas antes de que llegue una adaptación formal de DORA.

¿Qué es DORA 2.0? DORA 2.0 no es actualmente un acto legislativo aprobado, sino la denominación abreviada habitual en el sector para referirse a la esperada revisión del Reglamento UE 2022/2554. La Comisión Europea está legalmente obligada a presentar antes del 17 de enero de 2028 una evaluación de la implementación de DORA hasta la fecha. Los primeros documentos de trabajo de las ESA apuntan ya a un endurecimiento de los Technical Standards para 2026, en particular en materia de clasificación de incidentes, alcance de los TLPT y riesgo ICT de terceros. Las entidades financieras deben leer el término como un término provisional que agrupa una combinación de RTS modificados y posibles complementos al reglamento.

Las tres vulnerabilidades que las auditorías DORA 2025/2026 detectan sistemáticamente

Quien analiza los primeros comentarios de los supervisores de Alemania, Francia y los Países Bajos encuentra siempre las mismas tres lagunas. Son el foco más probable de un endurecimiento posterior de DORA.

Clasificación de incidentes sin homogeneidad. Las RTS definen los criterios de impacto de forma cualitativa: afectación a clientes, duración, dimensión de protección de datos, efecto reputacional. Suena ordenado, pero en la práctica genera decisiones inconsistentes. Dos entidades que experimentan el mismo fallo en la nube llegan con frecuencia a clasificaciones distintas. En revisiones de incidentes hemos observado en varias ocasiones que un evento se consideraba internamente «major», pero se notificaba a la BaFin como «significant» porque la obligación de reporte se activa antes en la categoría «major». El enfoque del Reino Unido con umbrales rígidos es la respuesta directa a este problema.

Alcance del TLPT demasiado restringido. Las pruebas de penetración basadas en amenazas son obligatorias bajo DORA para las entidades sistémicamente relevantes, y el marco TIBER-EU es el estándar de facto. En las primeras rondas de TLPT de 2025, muchas entidades limitaron el alcance a sus propios canales digitales. La cadena de suministro de TIC fue excluida con frecuencia. La ESMA señaló en un informe trimestral del primer trimestre de 2026 que las futuras inspecciones deberán cubrir toda la cadena de TIC crítica. Esto supone técnicamente un gran salto: ejecutar escenarios de red team contra proveedores de servicios gestionados y su infraestructura requiere contratos y disposición a cooperar que hoy rara vez están documentados.

Registro de terceros de TIC incompleto. El registro de TIC de DORA es, en teoría, una representación exhaustiva de todos los servicios de TIC críticos. En la práctica, las relaciones con subencargados del tratamiento suelen quedar sin registrar. La integración de Commvault en Google Cloud del 22 de abril es un buen ejemplo: quien hoy tiene a Commvault como proveedor de backup en el registro deberá añadir potencialmente también a Google Cloud como subencargado tras la integración. Si estos cambios no se actualizan, se genera una brecha entre la realidad operativa y el estado del registro que quedará expuesta en la próxima inspección.

Quien gestiona un registro de TIC como un inventario que se actualiza una vez al año no ha comprendido en 2026 ni la norma del Reino Unido ni el próximo endurecimiento de DORA. Los registros son operativos en 2026, o son inútiles.

Lo que muestran con sobriedad las primeras evaluaciones de las ESA en 2025/26

Las autoridades europeas de supervisión EBA, ESMA y EIOPA publicaron a principios de 2026 una evaluación conjunta de la primera fase de aplicación de DORA. Las conclusiones principales coinciden en gran medida con los hallazgos de supervisores nacionales individuales como la BaFin y el DNB neerlandés. Tres conclusiones se repiten de forma consistente en los informes.

En primer lugar: la calidad de los reportes es desigual. Para el mismo tipo de incidente, las declaraciones de impacto varían entre entidades por un factor de tres a cinco. Es menos un problema de mala fe que un problema metodológico. Las RTS definen criterios cualitativos sin un modelo de cálculo concreto; los gestores de incidentes en los bancos no disponen de una plantilla uniforme de referencia. La consecuencia: los supervisores tienen dificultades para realizar comparaciones transversales, cuando ese es precisamente el propósito de un reglamento de alcance europeo.

En segundo lugar: la visibilidad sobre los terceros proveedores se detiene casi siempre en el primer nivel. Una entidad conoce a sus proveedores directos de TIC, pero rara vez el segundo o tercer nivel. Esto contradice la aspiración de DORA, ya que el reglamento exige transparencia en la cadena hasta los subencargados críticos. La práctica de cumplimiento está por detrás de lo que exige la norma. Cuando un incidente grave en un subencargado afecta al banco, la reconstrucción a posteriori resulta laboriosa o directamente imposible.

En tercer lugar: los resultados de los TLPT se tratan internamente con frecuencia como un evento puntual. Las RTS prevén que los hallazgos se incorporen al análisis de riesgos continuo. En la práctica, suelen acabar en un informe extenso que se presenta al consejo de administración una única vez, sin que de él se deriven sistemáticamente decisiones de arquitectura. El efecto de aprendizaje queda por debajo de lo que el reglamento tenía previsto.

Cinco pasos que los equipos de seguridad deben dar ahora

El endurecimiento llegará, pero no hoy. La respuesta útil no es esperar, sino preparar el terreno de forma selectiva, con medidas que tienen sentido independientemente del texto exacto de un RTS de DORA 2. Cinco puntos que deberían ejecutarse en los próximos 120 días.

Primero: taxonomía unificada de incidentes. Alinear la clasificación interna con los umbrales de la FCA, aunque la entidad no opere en el Reino Unido. Los criterios cuantitativos reducen la varianza entre distintos gestores de incidentes y aportan una argumentación defendible ante los supervisores. El esfuerzo equivale a una semana de taller más ajustes en las herramientas.

Segundo: ampliar el alcance del TLPT. Cuando llegue la próxima ventana de TLPT en 2026 o 2027, la cadena de suministro ICT debería estar incluida en el scope. En términos concretos: incorporar explícitamente al menos un proveedor de servicios gestionados central en el escenario de red team, con el consentimiento contractual correspondiente. Aunque DORA 2.0 aún no lo exija, el valor informativo para la propia arquitectura es elevado.

Tercero: mantener el registro ICT de forma operativa. No tratar el registro como un documento de cumplimiento, sino como una base de datos activa con integraciones automatizadas hacia la gestión de contratos y la CMDB. Cada nueva integración de un proveedor ICT debería actualizar el registro de forma automática. Ante cambios en la cadena de subprocesadores, una revisión trimestral.

Cuarto: monitorización de terceros. La normativa del Reino Unido exige notificaciones sobre incidentes en proveedores externos. Eso solo funciona si la entidad dispone de monitorización activa sobre sus proveedores críticos. En la práctica: APIs de incidentes, scraping de páginas de estado y llamadas periódicas de coordinación SOC. Muchas entidades lo tienen para sus sistemas centrales, pero no para los subprocesadores.

Quinto: revisar los runbooks. El plazo de notificación de seis horas de la FCA solo es realizable si el runbook interno define de forma estricta los primeros 90 minutos. Quien durante un incidente grave todavía debate quién llama a la línea directa de la BaFin no cumplirá el plazo.

Un detalle que suele perderse en el debate: ni DORA ni la normativa del Reino Unido exigen divulgación simultánea al público en general. La notificación va al supervisor; la comunicación con clientes y prensa es responsabilidad de la entidad. Quien confunde ambas cosas genera riesgos reputacionales innecesarios. Para la defensa en tres líneas esto significa que compliance, comunicación y seguridad IT deben tener roles claramente delimitados en el playbook de respuesta a incidentes. Parece trivial, pero en la práctica es una de las causas de fallo más frecuentes.

La brecha de disciplina entre las exigencias de DORA y su aplicación real también explica por qué algunas entidades asumen costes de rectificación desproporcionadamente elevados tras un único incidente. Quien escribe los runbooks con antelación y los practica con tabletop exercises tres o cuatro veces al año se mueve en un rango de cinco cifras medias. Quien reacciona una vez documentado un incidente grave se encuentra rápidamente con varios cientos de miles de euros en consultoría externa, porque cada ajuste se ejecuta bajo presión de tiempo.

En la práctica se observa además que la coordinación con los proveedores ICT críticos funciona mejor cuando la propia entidad cuenta con procesos internos sólidos. Un proveedor que recibe tres solicitudes contradictorias de su cliente bancario sobre un mismo incidente se vuelve defensivo y entrega información mínima. Un cliente bancario con un único punto de contacto inequívoco y un camino de escalada claro obtiene una cooperación significativamente más amplia. No es un argumento regulatorio, sino experiencia operativa; en conversaciones informales con supervisores esto suele confirmarse.

Para la planificación presupuestaria de 2027 merece la pena un sencillo reality check. Las entidades que hasta ahora han visto su arquitectura DORA como un bloque de costes deberían aprovechar los próximos doce meses para hacer visible el valor operativo. Un registro ICT bien mantenido con conexión a CMDB y gestión de contratos no es solo trabajo de cumplimiento, sino la base para una gestión razonable de proveedores. Un modelo de taxonomía de incidentes operacionalizado acelera los post-mortems y reduce el Mean Time to Resolution. Quien lo formule de forma articulada obtendrá los presupuestos para la fase dos con mayor facilidad.

Preguntas frecuentes

¿Cuándo llegará DORA 2.0?

No hay una fecha confirmada. La Comisión Europea debe presentar una evaluación antes del 17 de enero de 2028. Las primeras adaptaciones de las RTS son probables entre 2026 y 2027. El término DORA 2.0 resume estos ajustes de forma habitual en el sector, pero no constituye un acto jurídico oficial.

¿Son vinculantes las normas del Reino Unido para las entidades de la UE?

Solo si una entidad opera dentro del perímetro del Reino Unido, en cuyo caso sí. Para las entidades con sede exclusivamente en la UE tienen un efecto de señal. Los supervisores del continente orientan sus expectativas hacia lo que ocurre en la vecindad; es probable que los umbrales de la FCA se utilicen como referencia en futuras revisiones de las RTS.

¿Qué es concretamente el TLPT?

El Threat-Led Penetration Testing es una prueba exhaustiva de equipo rojo realizada bajo condiciones reales de ataque. El marco TIBER-EU del BCE es el estándar europeo. El alcance, las normas y el procedimiento son considerablemente más estrictos que en las pruebas de penetración clásicas. Para las entidades de importancia sistémica, el TLPT es obligatorio bajo DORA.

¿Con qué frecuencia debe actualizarse el registro TIC?

Al menos trimestralmente, e inmediatamente cuando se produzcan cambios en la cadena de proveedores críticos. Como regla general: cuando se incorpora un nuevo subencargado del tratamiento o uno existente migra su infraestructura, el registro debe mantenerse sincronizado. Herramientas como OneTrust o Archer ofrecen flujos de trabajo adecuados para ello.

¿Qué costes son realistas para los cinco pasos?

Para una entidad financiera de tamaño mediano, los costes adicionales oscilan entre 150.000 y 400.000 euros en el primer año, en función del grado de madurez de la gestión de riesgos TIC existente. El mayor esfuerzo se concentra en la ampliación del alcance del TLPT; el menor, en la armonización taxonómica.

Fuente imagen de portada: Pexels / Sora Shimazaki (px:5669619)

Sobre el autor: Alec Chizhik

Más artículos de Alec Chizhik