Lo que deja la entrevista de Maite Álvarez en EFPA: DORA ya no va de teoría, va de gobierno, contratos y pruebas incómodas

Una entrevista en un pódcast rara vez cambia el rumbo regulatorio de nadie. Pero a veces sí sirve para detectar algo más útil: qué temas siguen preocupando de verdad al mercado y cuáles eran puro PowerPoint. La conversación de Maite Álvarez, directora de finReg360, en Al día en finanzas, el pódcast de EFPA, encaja justo ahí. No porque revele un giro normativo inesperado, sino porque llega en 2026, cuando ya no queda espacio para tratar la resiliencia digital como una promesa elegante. Ahora toca demostrarla.

Ese matiz importa. Mucho. Desde que DORA empezó a aplicar el 17 de enero de 2025, la pregunta dejó de ser si las entidades financieras europeas debían prepararse y pasó a ser otra bastante menos cómoda: qué evidencia real tienen para sostener que sus procesos, sus proveedores y su gobierno interno resisten un incidente serio. Y cuando digo serio no hablo del simulacro de siempre con una caída controlada a las 11:00 de un martes. Hablo de interrupción operativa, dependencia de terceros, fallos de comunicación interna, decisiones de crisis tomadas tarde y documentación contractual que, al primer escrutinio, hace agua.

La entrevista de EFPA, publicada por finReg360 este año, tiene interés precisamente por eso. No tanto por la novedad del titular, sino por el momento en que aparece. En 2026, el mercado financiero español ya ha tenido tiempo de convertir DORA en políticas, matrices RACI, inventarios de servicios, anexos contractuales y planes de pruebas. También ha tenido tiempo de descubrir que buena parte de ese trabajo estaba incompleto, mal priorizado o demasiado centrado en “cumplir” y demasiado poco en resistir. Esa contradicción merece análisis propio. Aquí va.

La fase romántica de DORA terminó en 2025

Durante 2024 y buena parte de 2025, DORA se vendió en demasiados foros como una regulación de orden. Una especie de gran armonizador europeo para poner cierto sentido en gestión de riesgo TIC, notificación de incidentes, pruebas de resiliencia y supervisión de terceros. Todo eso es cierto, pero se quedó corto. DORA no es solo una norma de orden; es una norma de disciplina ejecutiva.

El texto base, el Reglamento (UE) 2022/2554, ya lo dejaba bastante claro. El artículo 5 atribuye al órgano de dirección la responsabilidad última sobre la gestión del riesgo relacionado con las TIC. No dice que el consejo “deba estar informado”. Dice algo más incómodo: que debe definir, aprobar, supervisar y responder del marco de gestión de riesgo TIC. Traducido al castellano real de comité de dirección: no basta con delegarlo al CISO, ni esconderlo en segunda línea, ni pedir un cuadro de mando trimestral y seguir con la agenda.

Aquí está una de las claves que la conversación pública sobre DORA suele suavizar. La norma no pide solo más ciberseguridad. Pide más gobierno. Y gobierno significa trazabilidad de decisiones, apetito de riesgo, tolerancias de impacto, escalado, formación del órgano de dirección y capacidad de cuestionar dependencias críticas. Si tu entidad no puede explicar, con actas y decisiones documentadas, por qué acepta determinados riesgos TIC o por qué considera sustituible a un proveedor que en la práctica no lo es, el problema no es técnico. Es de gobierno corporativo.

La ironía es conocida por cualquiera que haya pasado por una inspección o una auditoría interna exigente: muchas entidades tenían políticas brillantes y una comprensión bastante pobre de sus interdependencias reales. DORA vino a pinchar esa burbuja.

El punto ciego más caro: terceros ICT y contratos que no soportan una lectura seria

Si hay un área donde DORA ha obligado a pasar del discurso al bisturí, esa es la gestión de proveedores tecnológicos. El capítulo V del Reglamento, y en particular los artículos 28 a 30, coloca a los terceros ICT en el centro del riesgo operativo financiero. No como nota a pie de página, sino como problema estructural.

El artículo 28 exige a las entidades gestionar el riesgo derivado de terceros prestadores de servicios TIC como parte integrante de su marco de riesgo TIC. Eso suena lógico hasta que una entidad intenta hacer el inventario de todas las dependencias tecnológicas que sostienen funciones críticas o importantes y descubre varias cosas poco agradables a la vez: servicios duplicados, contratos firmados por negocio sin participación suficiente de riesgos o legal, subcontrataciones encadenadas, SLA ambiguos, derechos de auditoría débiles y planes de salida que existen en una política pero no en la operación.

El artículo 30 remata la jugada con los elementos contractuales clave. Ahí no hay poesía regulatoria. Hay requisitos concretos: descripción completa de funciones y servicios, lugares de prestación, disponibilidad, integridad, confidencialidad, acceso, recuperación, asistencia en incidentes, cooperación con autoridades competentes, derechos de terminación y apoyo ordenado a la salida. Si una entidad firma contratos marco de cloud o de servicios gestionados que no aterrizan estos puntos, no tiene un pequeño defecto documental; tiene un agujero de cumplimiento y, peor aún, un agujero operativo.

En 2026, esa es probablemente la parte de DORA que más trabajo silencioso está generando en bancos, aseguradoras, gestoras, entidades de pago y otras firmas cubiertas por el Reglamento. Porque revisar el gobierno interno es difícil, sí, pero renegociar contratos con grandes proveedores tecnológicos es otra liga. Ahí el poder negociador no siempre está del lado de la entidad financiera. Y esa asimetría explica por qué tantas organizaciones han avanzado más rápido en políticas internas que en remediación contractual.

Conviene decirlo sin rodeos: DORA no acepta el argumento de que el proveedor no quiso. La obligación sigue siendo de la entidad financiera. Luego ya discutiremos si el mercado de servicios TIC ofrece contratos realmente alineados con la expectativa regulatoria. Pero ante el supervisor, el problema seguirá siendo tuyo.

Esto conecta con una discusión que en España ya no debería seguir tratándose como secundaria: la diferencia entre tener un inventario de proveedores y tener un mapa de concentración y criticidad. No es lo mismo saber con quién trabajas que saber qué pasaría si ese proveedor falla, cuánto tardarías en sustituirlo, qué subproveedores intervienen y qué funciones críticas quedarían afectadas. DORA empuja justamente hacia esa segunda capa. La primera, francamente, era lo mínimo.

Las pruebas de resiliencia separan a quien documenta de quien resiste

Otra lección que deja el debate alrededor de DORA, y que la entrevista de Maite Álvarez ayuda a poner de nuevo sobre la mesa, es que la palabra “testing” se ha usado con demasiada ligereza. El capítulo IV del Reglamento obliga a establecer un programa de pruebas de resiliencia operativa digital proporcionado al tamaño, perfil de riesgo y complejidad de la entidad. El artículo 24 pide herramientas, sistemas y procesos para detectar actividades anómalas. El artículo 25 se centra en respuesta y recuperación. El artículo 26, en aprendizaje y evolución. El artículo 23 ya había fijado la necesidad de marcos de continuidad y recuperación TIC. Todo eso converge en una pregunta brutalmente sencilla: cuando algo falla de verdad, puedes demostrar que el negocio sigue funcionando dentro de tus tolerancias?

Las entidades que han afrontado esto con honestidad se han topado con tres problemas repetidos.

Primero, las tolerancias de impacto no siempre estaban definidas con suficiente precisión. DORA obliga a identificar funciones críticas o importantes y fijar criterios claros de continuidad y recuperación. Pero muchas organizaciones partían de BIA heredados, con categorías poco afinadas, tiempos de recuperación teóricos y dependencias mal enlazadas con la arquitectura real.

Segundo, las pruebas se hacían por silos. Infraestructura probaba restauración. Seguridad probaba detección. Negocio hacía continuidad. Proveedores, a veces, mandaban certificados. Muy ordenado sobre el papel; muy poco útil cuando el incidente atraviesa sistemas, personas, terceros y decisiones de comunicación. DORA empuja hacia pruebas más integradas porque el incidente real no respeta organigramas.

Tercero, costaba extraer lecciones operativas de cada prueba. El artículo 26 no se conforma con hacer ejercicios. Exige revisar la estrategia de resiliencia digital en función de resultados y lecciones aprendidas. Dicho de otra forma: si pruebas y no corriges, has montado teatro regulatorio. Del caro.

La pieza más exigente, claro, son las pruebas avanzadas basadas en amenazas, las famosas threat-led penetration tests o TLPT del artículo 26 y del desarrollo regulatorio posterior. No todas las entidades tienen obligación de realizarlas con la misma intensidad, pero el mensaje del legislador es inequívoco: para determinadas entidades, la resiliencia no puede evaluarse solo con escaneos, pentests tradicionales o ejercicios de mesa. Hace falta simular adversarios creíbles, procesos críticos y cadenas de ataque realistas. Y hace falta hacerlo con gobierno, remediación y repetición posterior.

En la práctica, eso está elevando el listón no solo para los equipos de seguridad, sino para legal, compliance, riesgos, continuidad y compras. Porque una TLPT bien hecha toca accesos, entornos, terceros, exclusiones, seguros, confidencialidad, gestión de hallazgos y evidencias. Si alguien aún piensa que esto era “cosa del SOC”, llega tarde.

La notificación de incidentes ya no se puede improvisar

Otro frente donde DORA ha dejado poco margen para el autoengaño es la gestión de incidentes. Los artículos 17 a 20 obligan a establecer un proceso de gestión, clasificación y notificación de incidentes graves relacionados con TIC, además de notificación voluntaria de ciberamenazas significativas en ciertos casos. El núcleo del régimen está en clasificar con criterios armonizados y reportar de forma estructurada.

Esto tiene una implicación práctica que no siempre se entiende bien: la clasificación regulatoria del incidente no puede depender de una discusión caótica entre tecnología, seguridad, negocio, compliance y comunicación cuando la crisis ya está encima. Si no has definido antes umbrales, responsables, fuentes de información, flujos de validación y criterios de gravedad, llegarás tarde o reportarás mal. Y las dos cosas cuentan.

La comparación con GDPR es útil. El artículo 33 del Reglamento (UE) 2016/679 exige notificar violaciones de seguridad de los datos personales a la autoridad de control, en principio, en un plazo máximo de 72 horas desde que se tiene constancia. DORA no copia ese mecanismo, pero sí comparte una lógica parecida: la velocidad sin criterio genera ruido; el criterio sin preparación genera retraso. Las entidades que intentan resolver esto con una plantilla genérica de incidentes suelen descubrir, demasiado tarde, que los datasets necesarios para decidir una notificación no están integrados: impacto sobre clientes, criticidad del servicio, duración, alcance geográfico, causa raíz preliminar, afectación a terceros, medidas de contención.

Y aquí aparece una fricción interesante con NIS2. La Directiva (UE) 2022/2555, en su artículo 23, introduce también obligaciones de notificación por etapas para incidentes significativos de entidades esenciales e importantes. Para grupos financieros complejos o entidades sujetas a varios regímenes, el problema no es solo cumplir una norma u otra, sino evitar que cada una genere taxonomías, formularios y relojes distintos dentro de la misma organización. No es un ejercicio académico. Es una fuente muy real de duplicidades, inconsistencias y retrasos durante una crisis.

La conclusión operativa es menos glamourosa que cualquier keynote, pero bastante más útil: en 2026, una entidad madura debería tener al menos un motor único de triage para incidentes, capaz de alimentar los deberes de DORA, GDPR, NIS2 y, si aplica, esquemas nacionales o sectoriales, con reglas de escalado y validación ya pactadas. Si cada régimen sigue teniendo su miniuniverso, la resiliencia regulatoria es frágil aunque la técnica sea excelente.

Lo que la entrevista sugiere entre líneas: DORA es un examen de cultura, no solo de cumplimiento

Hay un motivo por el que entrevistas como la de EFPA interesan más de lo que aparentan. Cuando profesionales que están en la trinchera regulatoria explican DORA al mercado, el valor no siempre está en el titular explícito, sino en lo que se repite, en lo que preocupa y en lo que ya nadie intenta maquillar. Y lo que se desprende del momento actual es esto: la batalla no está en entender la letra de la norma. Está en cambiar hábitos.

Por ejemplo, sigue habiendo entidades que tratan el registro de información sobre terceros como una tarea administrativa y no como una herramienta de gestión. Error. El ecosistema de desarrollos regulatorios de DORA, incluidos los estándares técnicos vinculados al registro de información para acuerdos con terceros prestadores de servicios TIC, ha obligado a muchas organizaciones a bajar al detalle: entidad contratante, función soportada, criticidad, cadena de subcontratación, ubicación, tipo de servicio, datos tratados, dependencia. Ese ejercicio no sirve solo para “entregar el template”. Sirve para descubrir concentración, fragilidad y puntos de fallo. Si el dato no se usa para decidir, se convierte en burocracia cara.

Otro hábito que DORA ha puesto en cuestión es la costumbre de separar demasiado la conversación de ciberseguridad de la conversación de negocio. El Reglamento insiste en resiliencia operativa digital, no en higiene tecnológica abstracta. Eso obliga a traducir vulnerabilidades, deuda técnica, obsolescencia o dependencia cloud en impacto sobre pagos, distribución, siniestros, negociación, custodia, onboarding o atención al cliente. El CISO que siga hablando solo en términos de CVSS y el negocio que siga respondiendo solo con objetivos comerciales se encontrarán en el peor momento posible: cuando haya que decidir en crisis.

Y hay una tercera costumbre bastante arraigada que DORA castiga con elegancia, pero la castiga: dejar la formación del órgano de dirección en un trámite anual sin profundidad. El artículo 5.4 exige que los miembros del órgano de dirección mantengan conocimientos y competencias suficientes para comprender y evaluar el riesgo TIC y su impacto. No habla de escuchar una charla motivacional sobre ransomware y firmar asistencia. Habla de competencia suficiente para ejercer supervisión. Si un consejo no entiende concentración tecnológica, tolerancias de impacto, dependencia de identidades, riesgos de subcontratación o límites de recuperación, no puede gobernar el riesgo TIC. Puede recibir diapositivas. No es lo mismo.

Implicaciones para entidades financieras españolas

Para el mercado español, la conversación tiene una capa adicional. DORA es directamente aplicable en toda la UE, pero su aterrizaje práctico ocurre en organizaciones supervisadas por autoridades con expectativas muy concretas y con una larga memoria sobre riesgo operativo, externalización y continuidad. En España, bancos, aseguradoras, gestoras, entidades de pago, proveedores de servicios de criptoactivos dentro de su perímetro aplicable y otros actores cubiertos por DORA ya trabajan en una realidad distinta a la de hace dos años: ahora hay que poder enseñar la evidencia.

Eso cambia la dinámica de varios equipos a la vez.

Para compliance, el trabajo ya no consiste en mapear artículos del Reglamento contra políticas existentes y declarar convergencia razonable. Ahora hace falta revisar si los controles generan prueba auditable. ¿Existe aprobación formal del marco de riesgo TIC por el órgano de dirección? ¿Hay evidencia de revisión periódica? ¿Se documentan decisiones de aceptación de riesgo? ¿Las pruebas se traducen en planes de remediación con responsables y fechas? ¿Se han adaptado contratos de terceros críticos conforme al artículo 30? Si la respuesta depende de perseguir correos y presentaciones sueltas, todavía no está maduro.

Para riesgos operacionales, DORA obliga a romper la vieja frontera entre riesgo TIC y riesgo de negocio. El análisis de escenarios ya no puede dejar a los terceros como una variable abstracta. Tampoco puede tratar la recuperación como una promesa homogénea. Lo que importa es función por función, proceso por proceso, dependencia por dependencia.

Para compras y legal, la presión es especialmente visible. La revisión contractual DORA no se resuelve con una cláusula estándar añadida al final. Requiere renegociar temas sensibles: localización del servicio, subcontratación posterior, cooperación con autoridades, niveles de servicio, soporte a pruebas, derechos de acceso, terminación y salida. Cada uno de esos puntos tiene implicación comercial y operativa. Y algunos proveedores siguen vendiendo flexibilidad con una mano mientras blindan limitaciones con la otra.

Para tecnología y seguridad, la exigencia es doble: mejorar capacidades reales y mejorar la capacidad de explicarlas a primera y segunda línea. Porque un control técnico excelente que nadie puede vincular a una obligación concreta o a una función crítica termina infrautilizado en el proceso de supervisión. Y, a la inversa, una matriz de cumplimiento preciosa que no descansa sobre telemetría, inventario, arquitectura y pruebas termina siendo un decorado regulatorio.

En España, además, hay un factor cultural que no conviene ignorar: muchas entidades medianas han avanzado mucho en conciencia regulatoria, pero no siempre tienen la misma profundidad de recursos que los grandes grupos. DORA, sin embargo, no desaparece por falta de escala. Sí permite proporcionalidad en varios frentes, pero la proporcionalidad no equivale a indulgencia. Significa adaptar la intensidad, no ignorar la obligación.

La tentación de convertir DORA en un proyecto cerrado es un error

Uno de los reflejos más peligrosos que se observan en 2026 es tratar DORA como un programa con fecha de cierre. Se entendió así en 2024. Se intentó ejecutar así en 2025. A estas alturas ya debería quedar claro que esa mentalidad no funciona.

DORA no se “implanta” y se archiva. DORA altera procesos permanentes: gestión de cambios, onboarding de proveedores, clasificación de funciones críticas, reporting al consejo, ejercicios de continuidad, pruebas de detección, respuesta y recuperación, taxonomía de incidentes, formación directiva, revisión contractual y estrategia de salida. Todo eso se degrada si no se mantiene. La resiliencia operativa, por definición, no es una fotografía.

Hay una razón casi cómica por la que muchas organizaciones caen en esa trampa: un programa tiene presupuesto, PMO y fecha. La disciplina operativa, en cambio, exige pelear cada trimestre por datos, evidencias, coordinación y decisiones incómodas. Es mucho menos presentable en una slide de transformación. También es mucho más parecido a la realidad.

La consecuencia práctica es que el modelo de operating model importa tanto como el gap analysis inicial. Quien haya concentrado todo DORA en una oficina de proyecto sin integrarlo en BAU probablemente note ahora los síntomas: registros que envejecen, decisiones de criticidad desalineadas entre áreas, contratos todavía pendientes, planes de pruebas que compiten con prioridades del negocio, indicadores que no aterrizan en decisiones y cansancio organizativo. Nada de eso se arregla con otro workshop.

Qué deberían revisar ahora los responsables de DORA, sin teatro regulatorio

Si la entrevista de Maite Álvarez sirve como recordatorio oportuno, la utilidad real está en llevar la conversación al terreno de la evidencia. No hace falta inventar una gran transformación nueva. Hace falta revisar dónde siguen los huecos que más suelen aparecer en 2026.

Primero: órgano de dirección. Revisa si las actas reflejan decisiones concretas sobre riesgo TIC, tolerancias de impacto, resultados de pruebas, incidentes relevantes y dependencia de terceros. Si solo hay reporting descriptivo, el artículo 5 está débilmente aterrizado.

Segundo: funciones críticas o importantes. Verifica que la clasificación no sea un ejercicio heredado del BIA sin validación reciente. Tiene que conectar con procesos, activos, terceros, datos y tiempos de recuperación reales.

Tercero: registro y concentración de terceros. No basta con listar proveedores. Hay que identificar quién soporta qué, dónde hay dependencia múltiple del mismo grupo, qué subcontrataciones existen y cuál es el coste real de salida.

Cuarto: contratos. Comprueba cláusula a cláusula si los acuerdos con terceros TIC que soportan funciones críticas incorporan los elementos del artículo 30. Donde no los incorporen, documenta remediación, riesgo residual y estrategia de negociación. Fingir que el contrato estándar “ya cubre bastante” es una invitación a problemas.

Quinto: pruebas. Mira si el programa está diseñado por capacidades aisladas o por escenarios de negocio. La diferencia es enorme. Las pruebas útiles cruzan detección, decisión, recuperación, comunicación y terceros.

Sexto: incidentes y notificación. Asegura que existe una lógica única de clasificación y escalado compatible con DORA y, cuando aplique, con GDPR y NIS2. Si cada regulación vive en una carpeta distinta, la crisis lo pondrá en evidencia.

Séptimo: lecciones aprendidas. Exige trazabilidad. Toda prueba o incidente relevante debería dejar un rastro verificable: hallazgo, impacto, dueño, plazo, remediación, validación de cierre. Sin eso, el artículo 26 queda convertido en retórica.

Nada de esto suena épico. Precisamente por eso suele ser lo que diferencia a una entidad preparada de una que solo está cansada de hablar de DORA.

La lectura de fondo: 2026 es el año en que DORA empieza a revelar a los rezagados

La entrevista publicada por finReg360 no trae una bomba regulatoria ni falta que hace. Su valor está en la oportunidad del momento. En 2026, la conversación útil sobre DORA ya no consiste en explicar qué es el Reglamento a quien no lo haya leído. Esa fase terminó. La conversación útil consiste en detectar dónde persiste la ficción de cumplimiento.

Y la ficción adopta formas muy reconocibles: consejo informado pero no realmente implicado; inventarios de terceros sin análisis de concentración; contratos con anexos incompletos; pruebas abundantes pero fragmentadas; incidentes gestionados con heroicidad improvisada; reporting que tranquiliza más de lo que aclara. Todo eso puede convivir con una apariencia razonable de madurez. Hasta que deja de hacerlo.

La buena noticia, si queremos llamarla así, es que DORA ofrece una ventaja frente a otros regímenes más abiertos: su arquitectura obliga a aterrizar. Gobierno, riesgo TIC, incidentes, pruebas, terceros, intercambio de información. No deja demasiados sitios donde esconder el problema durante mucho tiempo. La mala noticia es que tampoco deja demasiado margen para seguir posponiendo conversaciones incómodas dentro de la organización.

Si eres CISO, responsable de continuidad, compliance officer, responsable de riesgos o counsel de tecnología, aquí está la pregunta que merece tu siguiente comité: qué parte de nuestra resiliencia digital podríamos defender hoy con evidencia, sin depender de explicaciones benevolentes. Si la respuesta te incomoda, mejor descubrirlo ahora que durante una inspección, una auditoría o un incidente grave.

Eso, al final, es lo más relevante que deja esta conversación pública en 2026. No un eslogan sobre regulación financiera. Un recordatorio bastante menos amable: la resiliencia operativa digital no se presume. Se prueba.