7 Min. de lectura<\/p>\n
DORA es obligatorio para las entidades financieras de la UE desde el 17 de enero de 2025. Tras quince meses de aplicaci\u00f3n normativa, ya se han completado los primeros ciclos de auditor\u00eda. Las lecciones aprendidas son concretas e inc\u00f3modas para los equipos de seguridad de bancos, aseguradoras y gestores de activos. La notificaci\u00f3n de incidentes en cuatro horas, los contratos con terceros con nuevas cl\u00e1usulas y el r\u00e9gimen de pruebas TLPT llevan las operaciones al l\u00edmite, algo que los procesos habituales ya no pueden cubrir.<\/strong><\/p>\n Lo esencial en breve<\/p>\n Relacionado<\/span>Rutas de notificaci\u00f3n NIS2: Gestionar operativamente la primera hora de un incidente<\/a> \/<\/span> MFA adaptativo en Entra, Okta y Duo: Despliegue de NIS2<\/a><\/p>\n Los supervisores de la UE (BaFin, EBA, ESMA, EIOPA y el BCE para las entidades m\u00e1s grandes) llevaron a cabo las primeras rondas de auditor\u00edas en 2025 y el primer trimestre de 2026. Las preguntas de contenido eran previsibles. Las respuestas de las entidades, en cambio, rara vez lo fueron. Los hallazgos m\u00e1s frecuentes en las conversaciones con los departamentos de cumplimiento de los bancos alemanes pueden agruparse en tres temas: clasificaci\u00f3n de incidentes en plazos ajustados, lagunas contractuales con proveedores externos y capacidades de prueba infra dimensionadas para TLPT. Ninguno de estos temas es nuevo, pero todos han adquirido un marco vinculante con DORA que supera las tolerancias internas anteriores. Adem\u00e1s, los supervisores afinan su interpretaci\u00f3n a medida que se presentan m\u00e1s casos. Lo que en 2025 se acept\u00f3 como una interpretaci\u00f3n piloto de la norma, en 2026 se eval\u00faa con mayor rigor.<\/p>\n La primera hora tras un incidente es el per\u00edodo decisivo. La regulaci\u00f3n exige una notificaci\u00f3n inicial en un plazo de cuatro horas tras clasificar un ICT-Incident como *major*. La clasificaci\u00f3n en s\u00ed debe basarse en criterios trazables. En la pr\u00e1ctica, esto significa que si a las tres de la madrugada salta una alerta que podr\u00eda ser un *major incident*, el SOC debe decidir en pocas horas si se alcanza el umbral de notificaci\u00f3n. Paralelamente, se prepara el propio informe. Quien no lo tenga automatizado en el *runbook*, se enfrenta a una situaci\u00f3n de estr\u00e9s. La lecci\u00f3n de las primeras auditor\u00edas: las entidades sin cadenas de escalado claras y sin una matriz de clasificaci\u00f3n definida acumularon m\u00e1s de un hallazgo en este \u00e1mbito durante los primeros meses.<\/p>\n El segundo gran desaf\u00edo son los contratos con proveedores externos de TIC. DORA exige cl\u00e1usulas expl\u00edcitas en los contratos sobre derechos de auditor\u00eda, estrategias de salida, garant\u00edas de nivel de servicio, obligaciones de seguridad e informes de incidentes. La realidad: la mayor\u00eda de los contratos de cloud, suscripciones SaaS y acuerdos de externalizaci\u00f3n de a\u00f1os anteriores no cumplen plenamente estos requisitos. La renegociaci\u00f3n no es unilateral. Los proveedores con poder de mercado (hyperscalers, plataformas SaaS l\u00edderes) tienen sus propios est\u00e1ndares contractuales, que no siempre coinciden con los requisitos de DORA.<\/p>\n La lecci\u00f3n de los primeros quince meses: las entidades que abordaron el tema de manera proactiva y temprana obtuvieron anexos contractuales adaptados de los hyperscalers que cubren gran parte de los requisitos de DORA. Las que esperaron, ahora est\u00e1n negociando a posteriori. La posici\u00f3n negociadora es notablemente peor, ya que el proveedor sabe que el tiempo apremia. Un detalle que suele pasarse por alto: la obligaci\u00f3n de registro es acumulativa. Cada actualizaci\u00f3n de un contrato, cada nueva conexi\u00f3n de subcontratistas y cada cambio en la criticidad debe reflejarse puntualmente en el registro DORA. Sin un flujo de trabajo para su mantenimiento continuo, el registro queda obsoleto en pocos meses.<\/p>\n D\u00f3nde fracasan las implementaciones de DORA en 2026<\/p>\n Qu\u00e9 sustenta la preparaci\u00f3n para DORA<\/p>\n La estrategia de salida es el \u00e1mbito en el que muchas entidades han subestimado lo que se exige. DORA no solo requiere una cl\u00e1usula de rescisi\u00f3n, sino un plan s\u00f3lido sobre c\u00f3mo, en caso de fallo del proveedor o terminaci\u00f3n del contrato, se migrar\u00e1 la operaci\u00f3n a una alternativa en un plazo razonable. En el caso de un sistema bancario central SaaS cr\u00edtico, esto no es un tema jur\u00eddico, sino un proyecto de transici\u00f3n de varios a\u00f1os. Los supervisores han documentado en las primeras auditor\u00edas que un plan de salida en papel, sin una simulaci\u00f3n realista, no es suficiente.<\/p>\n En la pr\u00e1ctica, esto significa que, para los cinco a diez principales proveedores externos cr\u00edticos de cada entidad, se necesita un plan de transici\u00f3n detallado con plazos, arquitectura objetivo, enfoque de migraci\u00f3n de datos y una clara asignaci\u00f3n de responsabilidades. Para los proveedores de cloud, esto suele implicar una configuraci\u00f3n multi-cloud o multi-regi\u00f3n; para los sistemas centrales SaaS, una estrategia de proveedor de respaldo o un plan de contingencia interno. La documentaci\u00f3n de estos planes es el primer paso; su actualizaci\u00f3n peri\u00f3dica y la realizaci\u00f3n ocasional de simulacros, el segundo. Quienes lo toman en serio descubren debilidades en sus propios procesos que no son visibles en el funcionamiento habitual.<\/p>\n Las pruebas de penetraci\u00f3n basadas en amenazas seg\u00fan TIBER-EU son el requisito de evaluaci\u00f3n m\u00e1s estricto bajo DORA y se aplican a las entidades que superan los umbrales TLPT (simplificado: grandes bancos, proveedores de servicios de pago y operadores de infraestructuras de mercado). La prueba es realizada por proveedores de equipos Red acreditados, con el objetivo de atacar el sistema de producci\u00f3n real y sin previo aviso al equipo de defensa operativo. El desaf\u00edo para 2026 es doble.<\/p>\n En primer lugar, el mercado de proveedores acreditados es limitado. En Alemania y Europa hay cifras de dos d\u00edgitos, no de tres, de proveedores de equipos Red acreditados para TLPT. Sus agendas est\u00e1n completas con seis a nueve meses de antelaci\u00f3n. Quien quiera realizar la prueba en el segundo semestre de 2026, debe negociar ahora. En segundo lugar, la madurez interna es decisiva. Un TLPT solo aporta conocimientos si el equipo Blue, la cadena de detecci\u00f3n y los procesos de respuesta a incidentes est\u00e1n lo suficientemente maduros como para procesar la simulaci\u00f3n. Las entidades que han elegido demasiado pronto el momento para el TLPT han consumido una valiosa capacidad del equipo Red en un resultado que ya habr\u00eda sido evidente con un inventario de activos.<\/p>\n La secuencia pragm\u00e1tica que se perfila para 2026 es la siguiente: primero, evaluaci\u00f3n del grado de madurez interna; despu\u00e9s, ejercicios espec\u00edficos de Purple Team durante seis meses; y, por \u00faltimo, TLPT con un proveedor externo acreditado. Quien empiece directamente con el TLPT se enfrentar\u00e1 a una auditor\u00eda muy costosa con hallazgos mayoritariamente gen\u00e9ricos. Quien desarrolle las fases previas obtendr\u00e1 del TLPT informes espec\u00edficos de vulnerabilidades que justificar\u00e1n su valor a\u00f1adido.<\/p>\n Un punto adicional que se hace visible en la segunda ronda de DORA es la integraci\u00f3n de los hallazgos del TLPT en la gesti\u00f3n continua de riesgos. Muchas entidades tratan los informes TLPT como informes cl\u00e1sicos de pentesting: los hallazgos se priorizan, se solucionan y se dan por cerrados. Esto es insuficiente. La supervisi\u00f3n espera que los hallazgos del TLPT se incorporen al an\u00e1lisis estrat\u00e9gico de riesgos, que se documenten las tendencias de vulnerabilidades a lo largo de varias pruebas y que se verifique la eficacia de las mitigaciones en pruebas posteriores. La diferencia entre el mero seguimiento de pentesting y una verdadera gesti\u00f3n de la resiliencia se convertir\u00e1 en un campo de evaluaci\u00f3n en la segunda ronda de auditor\u00eda.<\/p>\n Tambi\u00e9n se examinar\u00e1 la interfaz con la planificaci\u00f3n de la continuidad del negocio. El TLPT simula escenarios de atacantes, mientras que el BCP planifica escenarios de fallos. Ambas disciplinas funcionan por separado en muchas entidades. DORA exige su interconexi\u00f3n. Quien coordine los ejercicios generar\u00e1 evidencia para la evaluaci\u00f3n de resiliencia, que ser\u00e1 considerablemente m\u00e1s s\u00f3lida que las pruebas individuales por separado.<\/p>\n Para los equipos de seguridad que han superado el primer a\u00f1o de DORA y ahora se preparan para la segunda ronda de auditor\u00eda, ha demostrado su eficacia un ritmo en cuatro fases.<\/p>\n Este ritmo presenta dos ventajas. En primer lugar, desvincula la ejecuci\u00f3n del TLPT de la preparaci\u00f3n para la auditor\u00eda, de modo que ambos temas reciben la atenci\u00f3n que requieren. En segundo lugar, da tiempo al equipo de gesti\u00f3n de incidentes para incorporar los cambios en los runbooks tras cada fase, evitando acumulaciones. Quienes concentran todo en el cuarto trimestre acaban con una documentaci\u00f3n que queda bien sobre el papel, pero que no se aplica en la operaci\u00f3n real.<\/p>\n Una observaci\u00f3n recurrente en las conversaciones de auditor\u00eda: los supervisores no solo verifican la existencia de procesos, sino su aplicaci\u00f3n real. Un proceso de clasificaci\u00f3n de incidentes que no se haya utilizado en los \u00faltimos seis meses por falta de un incidente grave ser\u00e1 evaluado igualmente. Los supervisores exigir\u00e1n entonces ejercicios o simulacros (tabletop exercises) que demuestren la capacidad de respuesta. Las entidades que realizan estos ejercicios trimestralmente salen mucho mejor paradas en estas cuestiones que aquellas que solo los hacen anualmente.<\/p>\n Otro aspecto que suele destacar en la segunda oleada es el papel de la direcci\u00f3n. DORA no es un tema exclusivo de cumplimiento ni de TI. La responsabilidad recae en el consejo de administraci\u00f3n, no en el segundo nivel directivo. Los supervisores comprueban si el consejo gestiona activamente las medidas de DORA, si recibe informes peri\u00f3dicos y si ha participado en la aprobaci\u00f3n de la hoja de ruta de remediaci\u00f3n. Quienes delegan esto en la direcci\u00f3n de TI reciben hallazgos a nivel de consejo. Las entidades con una revisi\u00f3n de riesgos TIC establecida en el consejo (generalmente trimestral, con su propia agenda) ofrecen evidencias mucho m\u00e1s cre\u00edbles que aquellas que tratan DORA como un proyecto t\u00e9cnico.<\/p>\n Por \u00faltimo, DORA est\u00e1 transformando la colaboraci\u00f3n entre seguridad de la informaci\u00f3n, operaciones de TI y cumplimiento operativo. Estas tres funciones deben operar dentro de los mismos flujos de trabajo, no en silos separados. Las entidades que en la primera ronda a\u00fan trabajaban con traspasos basados en Excel entre el CISO, el CIO y Cumplimiento est\u00e1n implementando en la segunda ronda plataformas GRC comunes, donde se gestionan de forma centralizada los hallazgos, las medidas y las evidencias. Esto reduce los tiempos de b\u00fasqueda durante la auditor\u00eda y muestra a los supervisores una organizaci\u00f3n coordinada, en lugar de m\u00faltiples documentaciones individuales.<\/p>\n Para concluir, un aspecto que marca la diferencia entre el cumplimiento de la auditor\u00eda y el beneficio en resiliencia. En la pr\u00e1ctica, DORA es un marco que eleva la madurez de la respuesta a incidentes y la gesti\u00f3n de riesgos de terceros a un nivel que muchas entidades necesitan de todos modos. Quienes ven los requisitos solo como una obligaci\u00f3n de cumplimiento acaban con una documentaci\u00f3n costosa sin valor a\u00f1adido. Quienes aprovechan estos requisitos como una oportunidad para mejorar su resistencia frente a perturbaciones TIC, tras doce meses no solo obtienen un informe de auditor\u00eda impecable, sino tambi\u00e9n menos sorpresas nocturnas. Las inversiones en automatizaci\u00f3n de SIEM, runbooks claros y planes de salida robustos rinden frutos independientemente de la regulaci\u00f3n. DORA establece el plazo en el que deben implementarse.<\/p>\n La regulaci\u00f3n se aplica a todas las entidades financieras supervisadas en la UE: bancos, aseguradoras, empresas de valores, proveedores de servicios de pago, entidades de dinero electr\u00f3nico, fondos de inversi\u00f3n, infraestructuras de mercado y proveedores cr\u00edticos de TIC externos. Existen facilidades para peque\u00f1as entidades por debajo de ciertos umbrales, pero no una exenci\u00f3n total. Quienes act\u00faen como proveedores de servicios para instituciones financieras sin estar regulados, recibir\u00e1n requisitos relevantes de DORA \u00abpor la puerta de atr\u00e1s\u00bb a trav\u00e9s de las cl\u00e1usulas de terceros de sus clientes.<\/p>\n DORA es espec\u00edfica para el sector financiero y establece requisitos m\u00e1s detallados en materia de notificaci\u00f3n de incidentes, pruebas y gesti\u00f3n de proveedores externos. NIS2 tiene un alcance transversal y, en algunos aspectos, es m\u00e1s superficial. Cuando ambas normativas coinciden, DORA prevalece dentro de su \u00e1mbito de aplicaci\u00f3n.<\/p>\n Los supervisores de la UE designan como CTPP a aquellos proveedores que resultan cr\u00edticos para varias entidades financieras, someti\u00e9ndolos a un r\u00e9gimen de supervisi\u00f3n propio. Suele tratarse de grandes proveedores de cloud, proveedores centrales de servicios de pagos y especialistas en sistemas bancarios centrales. La lista de CTPP se actualiza anualmente.<\/p>\n Para las entidades sujetas a la obligaci\u00f3n de TLPT, se exige realizar una prueba al menos cada tres a\u00f1os. Tras cambios significativos en el panorama de TI o tras incidentes relevantes, la autoridad supervisora puede exigir una prueba anticipada. Los plazos de planificaci\u00f3n oscilan entre seis y nueve meses.<\/p>\n La auditor\u00eda interna tiene un papel central. Verifica de forma continua si los procesos de gesti\u00f3n de riesgos de TIC cumplen con los requisitos de DORA. Al mismo tiempo, informa a la junta directiva y al consejo de supervisi\u00f3n. Sin una capacidad suficiente de auditor\u00eda interna, la supervisi\u00f3n externa se convierte en un examen de estr\u00e9s para el que no estar\u00e1 preparado.<\/p>\n\n
Lo que realmente han revelado las primeras auditor\u00edas de 2026<\/h2>\n
Registros de terceros y escenarios de salida<\/h2>\n
\n
\n
TLPT en la pr\u00e1ctica: mercado, capacidad y madurez interna<\/h2>\n
El plan operativo para equipos de seguridad en la segunda fase de DORA<\/h2>\n
Preguntas frecuentes<\/h2>\n
\u00bfQu\u00e9 instituciones est\u00e1n sujetas a DORA?<\/h3>\n
\u00bfEn qu\u00e9 se diferencia DORA de NIS2?<\/h3>\n
\u00bfCu\u00e1l es el papel de los proveedores cr\u00edticos de TIC externos (CTPP)?<\/h3>\n
\u00bfCon qu\u00e9 frecuencia debe realizarse un TLPT?<\/h3>\n
\u00bfQu\u00e9 papel desempe\u00f1an las auditor\u00edas internas en la implementaci\u00f3n de DORA?<\/h3>\n
M\u00e1s del MBF Media Network<\/h2>\n