DORA
Gobierno del riesgo TIC en DORA: el órgano de dirección ya no puede delegar la responsabilidad
19 min lectura
Imagen generada por IAEl riesgo TIC ya no es un asunto que el órgano de dirección pueda dejar en manos del CISO, del CIO o de un proveedor tecnológico y revisar una vez al año, cuando toque aprobar el presupuesto. Desde el 17 de enero de 2025, DORA exige que la máxima dirección de las entidades financieras europeas asuma una responsabilidad directa sobre la resiliencia operativa digital. En 2026, esa obligación ya no admite la excusa de la transición.
La diferencia no es semántica. Un consejo puede aprobar una política de ciberseguridad sin haber ejercido realmente el gobierno del riesgo. Puede recibir un cuadro de mando lleno de indicadores verdes y seguir sin saber qué sistema sostiene una función crítica, qué proveedor concentra el riesgo o cuánto tardaría la entidad en recuperar un servicio esencial. DORA pretende cerrar precisamente ese agujero: obliga a convertir la supervisión tecnológica en una práctica de gobierno demostrable.
Los artículos 5 y 6 del Reglamento (UE) 2022/2554 son el núcleo de esa arquitectura. El artículo 5 sitúa la responsabilidad última en el órgano de dirección; el artículo 6 exige un marco de gestión del riesgo TIC sólido, completo y documentado, integrado en la gestión general del riesgo. No basta con tener controles. Hay que poder explicar quién decidió, con qué información, contra qué tolerancia y qué evidencia demuestra que el control funciona.
La pregunta incómoda: ¿quién responde cuando falla un servicio crítico?
En muchas entidades, la respuesta operativa parece sencilla: el equipo de tecnología restaura el servicio, seguridad contiene el incidente y continuidad de negocio coordina la comunicación. La respuesta de gobierno es bastante menos cómoda. ¿Quién aprobó la dependencia? ¿Quién aceptó que el sistema careciera de una alternativa? ¿Quién conocía el tiempo de recuperación real? ¿Quién decidió que el presupuesto no alcanzaba para corregir la vulnerabilidad?
DORA no convierte al consejo en un equipo de respuesta a incidentes. Tampoco exige que sus miembros sepan configurar un cortafuegos o revisar código. Lo que exige es que entiendan el riesgo suficiente para tomar decisiones informadas y supervisar su gestión. El artículo 5 establece que el órgano de dirección define, aprueba y supervisa las disposiciones relacionadas con el marco de riesgo TIC y asume la responsabilidad última de ese riesgo.
La consecuencia práctica es clara: la delegación de la ejecución no equivale a la delegación de la responsabilidad. El CISO puede diseñar el programa; el CIO puede operar la infraestructura; el comité de riesgos puede revisar métricas. Ninguna de esas funciones elimina la obligación del órgano de dirección de aprobar la estrategia, fijar la tolerancia al riesgo, asegurar recursos y supervisar los planes de continuidad, respuesta y recuperación.
Aquí está el quid. El regulador no necesita demostrar que cada consejero debía conocer el contenido de un log. Le bastará con preguntar si recibió información adecuada, si planteó preguntas razonables y si actuó cuando los indicadores mostraban una exposición inaceptable. Un acta que solo recoge que el consejo fue informado no prueba necesariamente que ejerciera supervisión.
Qué exige exactamente el artículo 5 de DORA
El artículo 5 no se limita a una declaración de principios. Atribuye al órgano de dirección un conjunto de decisiones concretas. Entre ellas están la aprobación y revisión periódica de la estrategia de resiliencia operativa digital, de la tolerancia al riesgo TIC y de las políticas necesarias para gestionar ese riesgo.
La tolerancia al riesgo no debería confundirse con una cifra genérica de apetito de riesgo incluida en el marco global de la entidad. Para que sea útil, debe traducirse a límites operativos: indisponibilidad máxima por servicio, pérdida de datos aceptable, número de vulnerabilidades críticas fuera de plazo, concentración máxima por proveedor, porcentaje de activos sin soporte y tiempo objetivo de recuperación. Si el consejo aprueba una tolerancia de riesgo que no puede conectarse con esos límites, ha aprobado una etiqueta, no un mecanismo de gobierno.
El artículo 5 también exige que el órgano de dirección asegure una asignación adecuada de recursos y apruebe la política de continuidad de negocio y los planes de respuesta y recuperación relacionados con las TIC. Esto tiene una implicación que suele perderse en las presentaciones ejecutivas: el presupuesto de resiliencia no es solo el presupuesto de seguridad.
Una entidad puede contar con una plataforma de detección avanzada y seguir siendo frágil si no dispone de personal para recuperar aplicaciones, procedimientos manuales para operar durante una caída o contratos que permitan obtener rápidamente datos y soporte. La resiliencia incluye prevención, respuesta y recuperación. El consejo que aprueba más herramientas de monitorización mientras mantiene sin financiación la recuperación de sistemas críticos está gestionando una parte del riesgo y dejando otra fuera de la fotografía.
El Reglamento exige además que los miembros del órgano de dirección mantengan conocimientos y capacidades suficientes para comprender y evaluar el riesgo TIC y su impacto en las operaciones. DORA no prescribe un título académico ni una certificación concreta. Sí obliga a que la entidad pueda demostrar que la formación existe y que responde a las responsabilidades reales de sus consejeros.
Una sesión anual de dos horas sobre amenazas genéricas difícilmente prepara a un consejo para decidir sobre una migración a la nube, la externalización de un sistema de pagos o la aceptación de una desviación de un plan de recuperación. La formación pertinente debería incluir, según el perfil de la entidad, dependencia de terceros, concentración tecnológica, escenarios de indisponibilidad, notificación de incidentes y resultados de pruebas.
El artículo 6 convierte el riesgo TIC en un sistema, no en una carpeta
El artículo 6 exige un marco de gestión del riesgo TIC sólido, completo y bien documentado, integrado en el marco general de gestión del riesgo de la entidad. Esa integración importa porque impide tratar la tecnología como un universo paralelo, con sus propios informes, sus propios comités y una conexión débil con riesgo operacional, continuidad, cumplimiento y auditoría interna.
El marco debe cubrir las estrategias, políticas, procedimientos, protocolos y herramientas necesarios para proteger los activos de información y TIC. Eso incluye software, hardware, servidores, instalaciones y los activos que soportan los procesos de la entidad. El inventario, por tanto, no es un ejercicio puramente técnico. Debe permitir conectar activos, servicios, procesos, datos, proveedores y responsables.
Si el inventario solo dice que existen 4.000 servidores, no responde a la pregunta que interesa al órgano de dirección: cuáles de ellos sostienen una función crítica o importante y qué ocurre si dejan de estar disponibles. La unidad de análisis debe avanzar desde el activo hacia el servicio. Un servidor es relevante porque sostiene una capacidad de negocio; una dependencia de nube es relevante porque puede afectar a pagos, contratación, liquidación, custodia o acceso de clientes.
El marco de DORA debe permitir identificar, clasificar, proteger, detectar, responder y recuperarse de los riesgos TIC. No es necesario imponer una nomenclatura única, pero sí construir una cadena de control verificable. Para cada servicio crítico debería poder responderse, como mínimo, a estas preguntas:
- ¿Qué proceso y función crítica o importante depende del servicio?
- ¿Qué activos internos y terceros ICT lo soportan?
- ¿Qué objetivos de recuperación y pérdida de datos se han aprobado?
- ¿Qué controles reducen los escenarios de interrupción, corrupción o acceso no autorizado?
- ¿Qué prueba demuestra que esos controles funcionan?
- ¿Quién acepta el riesgo residual cuando el control no cumple?
El artículo 6 establece también que el marco debe revisarse al menos una vez al año y después de incidentes importantes o cuando las autoridades competentes lo soliciten. La revisión anual no debería ser una actualización cosmética de fechas y nombres de documentos. Debe incorporar cambios en la arquitectura, proveedores, amenazas, resultados de pruebas, incidentes y deficiencias abiertas.
La obligación de revisar tras un incidente importante introduce una disciplina útil: el incidente debe producir aprendizaje institucional. Si una caída demuestra que el inventario estaba incompleto, que el proveedor no podía restaurar los datos en el plazo contractual o que el canal de escalado no funcionaba, la revisión no puede limitarse a modificar el procedimiento de comunicación. Debe preguntarse si el marco de riesgo TIC estaba mal diseñado.
El órgano de dirección necesita información que permita decidir
El problema de muchos cuadros de mando no es la falta de datos, sino su escasa utilidad para decidir. Contar vulnerabilidades, alertas o pruebas realizadas puede servir al equipo operativo, pero no basta para gobernar la resiliencia. El órgano de dirección necesita información conectada con impacto, tolerancia y decisiones pendientes.
Un indicador como el porcentaje de parches aplicados en plazo solo adquiere sentido si muestra qué activos están fuera de plazo, qué servicios soportan y quién ha aceptado el riesgo. Un indicador de disponibilidad mensual puede ocultar una interrupción de 20 minutos en un servicio de pagos que, por su momento y duración, supera la tolerancia aprobada. Un porcentaje de proveedores evaluados puede ocultar que el proveedor que concentra la función más crítica aún no ha entregado evidencias suficientes.
Una información ejecutiva mínimamente útil debería distinguir entre exposición bruta, controles existentes, riesgo residual y decisiones que requieren escalado. También debería mostrar la antigüedad de las excepciones y su fecha de vencimiento. Una excepción sin propietario, sin compensación y sin fecha de cierre no es gestión del riesgo: es una vulnerabilidad con buena presentación.
Para cada servicio crítico, el consejo debería poder ver una ficha que conecte:
- la función de negocio y el impacto de su interrupción;
- el objetivo de tiempo de recuperación y el resultado de la última prueba;
- los principales activos y terceros ICT involucrados;
- las vulnerabilidades o deficiencias que exceden la tolerancia aprobada;
- la dependencia de una región, plataforma, proveedor o subcontratista;
- las decisiones de inversión, aceptación o mitigación pendientes.
El formato no está impuesto por DORA, pero la lógica sí. Si un consejero no puede entender qué riesgo está aceptando, durante cuánto tiempo y con qué alternativa, la información no está cumpliendo su función de gobierno.
La evidencia será el verdadero examen
DORA cambia la conversación con auditoría y supervisión porque desplaza el debate desde la existencia formal de políticas hacia la demostración de que se aplican. Una política aprobada en enero no acredita que los controles funcionen en septiembre. Un procedimiento de recuperación no demuestra que la entidad pueda recuperar el servicio dentro del objetivo declarado.
La evidencia debería construirse alrededor de decisiones y controles, no como una colección de documentos almacenados en una carpeta. Para demostrar el cumplimiento de los artículos 5 y 6, una entidad debería poder reunir, entre otros elementos, las actas del órgano de dirección, el registro de formación, la aprobación de la tolerancia al riesgo, el presupuesto asignado, el inventario de activos y servicios, las evaluaciones de riesgo, los resultados de pruebas, las excepciones abiertas y el seguimiento de medidas correctoras.
La trazabilidad es especialmente importante. Una decisión de aceptar una desviación del objetivo de recuperación debería enlazar con el servicio afectado, el análisis de impacto, la razón de la aceptación, la persona o comité autorizado, la fecha de caducidad y los controles compensatorios. Sin esa cadena, la entidad puede demostrar que habló del riesgo, pero no que lo gobernó.
Checklist de evidencias para auditoría
La siguiente lista no sustituye al marco de control, pero ayuda a detectar lagunas concretas:
- Responsabilidad: mandato formal del órgano de dirección, roles definidos y asignación de la función de control del riesgo TIC.
- Conocimiento: plan y registros de formación de los miembros del órgano de dirección, con contenidos relacionados con sus decisiones reales.
- Tolerancia: límites aprobados para indisponibilidad, recuperación, pérdida de datos, vulnerabilidades y dependencias de terceros.
- Recursos: decisiones presupuestarias y justificación de que cubren prevención, detección, respuesta, continuidad y recuperación.
- Marco: políticas, procedimientos, protocolos y herramientas vinculados al inventario de activos, servicios y riesgos.
- Pruebas: resultados de ejercicios de continuidad, pruebas técnicas, análisis de fallos y seguimiento de deficiencias.
- Incidentes: registros de evaluación, escalado, comunicación, causa raíz y cambios introducidos tras incidentes relevantes.
- Excepciones: registro de riesgos aceptados con propietario, fecha de revisión, controles compensatorios y decisión de cierre.
La evidencia debe conservar contexto y fecha. Un pantallazo sin periodo de referencia o una exportación de una herramienta sin responsable puede tener poco valor probatorio. La auditoría necesita saber qué se midió, contra qué criterio, quién lo revisó y qué ocurrió cuando el resultado fue insuficiente.
La conexión con terceros ICT cambia la agenda del consejo
El gobierno del riesgo TIC no termina en el perímetro de la entidad. El artículo 28 de DORA exige gestionar el riesgo relacionado con terceros ICT y obliga a las entidades a mantener la responsabilidad plena por el cumplimiento de sus obligaciones regulatorias, aunque externalicen funciones.
Esta es una de las áreas donde la distancia entre el contrato y la realidad suele ser mayor. Un contrato puede incluir niveles de servicio, derechos de auditoría y obligaciones de notificación, pero la entidad seguirá necesitando saber qué subcontratistas intervienen, dónde se procesan los datos, qué ocurre en caso de insolvencia y cómo se recupera el servicio si el proveedor falla.
El registro de acuerdos contractuales con terceros ICT previsto por DORA debe servir para el gobierno, no solo para una entrega al supervisor. El órgano de dirección necesita conocer las concentraciones relevantes: un mismo proveedor para varias funciones críticas, una región tecnológica común, una plataforma de identidad utilizada por múltiples canales o una cadena de subcontratación que la entidad no puede observar directamente.
El artículo 30 establece requisitos contractuales para los acuerdos sobre servicios ICT que soportan funciones críticas o importantes. Entre ellos figuran elementos relacionados con niveles de servicio, acceso, asistencia, cooperación con autoridades, terminación y estrategias de salida. La revisión de estos contratos no debería delegarse por completo en compras o legal. Si la salida de un proveedor exige nueve meses y la entidad ha aprobado una tolerancia de interrupción de 24 horas, existe una incoherencia de gobierno que el consejo debe conocer.
DORA también introduce la supervisión europea de determinados proveedores ICT críticos por parte de las autoridades europeas de supervisión. Eso no convierte al proveedor en responsable del cumplimiento de la entidad financiera. La entidad sigue teniendo que evaluar su exposición, documentar su dependencia y demostrar que sus controles y contratos son adecuados.
Continuidad, pruebas e incidentes: donde los papeles se encuentran con la realidad
El gobierno del riesgo TIC se pone a prueba cuando la entidad deja de funcionar como estaba previsto. DORA exige políticas de continuidad y planes de respuesta y recuperación, pero el valor de esos documentos depende de que hayan sido probados contra escenarios plausibles.
Un ejercicio que solo valida la llamada entre responsables no demuestra la capacidad de recuperación. Las pruebas deben poner a prueba supuestos: pérdida de una región cloud, indisponibilidad de un proveedor de identidad, corrupción de datos, ataque de ransomware, fallo de una conexión con un sistema de liquidación o imposibilidad de acceder a las herramientas de administración.
El órgano de dirección no necesita revisar cada paso técnico del ejercicio, pero sí debería recibir sus resultados y decidir sobre las deficiencias relevantes. Si una prueba demuestra que el tiempo real de recuperación duplica el objetivo aprobado, la cuestión no es si el informe está bien redactado. La cuestión es si se corrige el diseño, se reduce la tolerancia o se acepta formalmente el riesgo con una explicación defendible.
El capítulo sobre gestión, clasificación y notificación de incidentes de DORA añade otra capa de responsabilidad. Los incidentes graves relacionados con las TIC deben clasificarse con arreglo a los criterios aplicables y notificarse a la autoridad competente. La organización necesita, por tanto, un proceso que conecte detección técnica, evaluación de impacto, decisión regulatoria y comunicación ejecutiva.
La relación con el Reglamento General de Protección de Datos también requiere precisión. Si un incidente TIC implica una violación de datos personales, el artículo 33 del GDPR puede exigir notificación a la autoridad de protección de datos en un plazo de 72 horas desde que el responsable tiene constancia, salvo que sea improbable que exista riesgo para los derechos y libertades. DORA y GDPR no tienen el mismo umbral, finalidad ni canal. Una matriz que trate ambos marcos como un único procedimiento puede provocar retrasos o notificaciones incompletas.
La misma lógica se aplica a NIS2 cuando la entidad o su actividad entra en su ámbito de aplicación. El artículo 21 de la Directiva exige medidas de gestión del riesgo de ciberseguridad, mientras que el artículo 23 establece obligaciones de notificación de incidentes. Para una entidad financiera cubierta por DORA, la coordinación normativa debe evitar duplicidades, pero no permite ignorar diferencias de alcance, autoridad o plazo.
La independencia de control importa tanto como la responsabilidad
El artículo 5 contempla la asignación de responsabilidad por el riesgo TIC a una función de control y exige que las entidades que no sean microempresas preserven la independencia adecuada de esa función. La arquitectura concreta dependerá del tamaño y modelo de la entidad, pero el principio es difícil de esquivar: quien opera una plataforma no debería ser la única persona que decide si los controles de esa plataforma son suficientes.
Esto afecta a la relación entre primera y segunda línea. Tecnología y seguridad operan controles y gestionan riesgos diarios; una función de control independiente establece criterios, desafía decisiones y escala incumplimientos; auditoría interna ofrece aseguramiento independiente conforme a su mandato. Mezclar esas capas produce informes más cómodos y controles menos creíbles.
La independencia no significa aislamiento. Una función de control que solo aparece al final del proceso para rechazar proyectos tampoco aporta buen gobierno. Debe participar en la definición de tolerancias, revisar cambios relevantes, evaluar excepciones y comprobar que la información que llega al órgano de dirección no oculta riesgos materiales.
El error habitual consiste en interpretar la independencia como una cuestión del organigrama. También es una cuestión de acceso, autoridad y capacidad de escalado. Si el responsable de control no puede acceder a contratos, resultados de pruebas, registros de incidentes o información de proveedores, su independencia formal sirve de poco.
Qué debería cambiar en las reuniones del órgano de dirección
La aplicación práctica de DORA se verá en las preguntas que se hagan y en las decisiones que queden registradas. Una agenda eficaz no necesita convertir al consejo en un comité técnico, pero sí debe abandonar el ritual de aprobar documentos sin discutir sus consecuencias.
Al revisar el riesgo TIC, el órgano de dirección debería preguntar qué funciones críticas dependen de un único proveedor, qué desviaciones superan la tolerancia, cuál fue el resultado de la última prueba de recuperación y qué riesgos llevan más tiempo sin una solución. También debería preguntar qué ha cambiado desde la revisión anterior: nuevas adquisiciones, migraciones, vulnerabilidades, subcontratistas, incidentes o cambios regulatorios.
La calidad de las actas es parte del control. No hace falta transcribir cada intervención, pero sí dejar constancia de la información recibida, las decisiones adoptadas, las excepciones aceptadas, las condiciones impuestas y las fechas de seguimiento. Un acta que solo dice que el consejo tomó conocimiento convierte una decisión relevante en una sombra administrativa.
Para el CISO y cumplimiento, esto implica preparar informes que permitan elegir. Cada asunto debería identificar la decisión solicitada, el riesgo si no se actúa, las alternativas disponibles, el coste, el plazo, el propietario y la evidencia que se utilizará para comprobar la mejora. Pedir al consejo que apruebe un plan de ciberseguridad de 80 páginas es una forma elegante de no pedirle ninguna decisión concreta.
El cruce con NIST CSF 2.0, GDPR y controles internos
DORA no obliga a utilizar NIST CSF 2.0, ISO 27001 o un marco concreto. Sin embargo, esos modelos pueden ayudar a ordenar la ejecución si se evita tratarlos como sustitutos del Reglamento. NIST CSF 2.0 incorpora la función Govern, que resulta útil para conectar estrategia, roles, política y supervisión. DORA aporta el requisito jurídico aplicable a las entidades financieras europeas y fija responsabilidades que una referencia voluntaria no puede reemplazar.
La relación con GDPR art. 32 también merece una gestión conjunta. Las medidas técnicas y organizativas apropiadas para garantizar la seguridad del tratamiento pueden compartir controles con el marco TIC de DORA, pero la finalidad y el perímetro no son idénticos. Un inventario de servicios críticos puede no equivaler a un registro de tratamientos; una prueba de recuperación puede no demostrar por sí sola la confidencialidad o integridad exigidas para datos personales.
En grupos financieros sujetos a controles internos tipo SOX, la trazabilidad de aprobación, segregación de funciones, evidencias y remediación ofrece una ventaja. Pero SOX se centra en controles sobre la información financiera y DORA en la resiliencia operativa digital. Un control puede estar correctamente documentado para auditoría financiera y no cubrir la dependencia tecnológica que amenaza una función crítica.
La regla práctica es sencilla: reutilizar controles cuando comparten objetivo, pero mantener separados el criterio legal, el propietario, la evidencia y el umbral de cumplimiento. Una matriz que solo asigna una etiqueta DORA a controles antiguos no constituye un análisis de cobertura.
El criterio que marcará la diferencia en 2026
La madurez bajo DORA no se medirá por el número de políticas aprobadas ni por la cantidad de reuniones celebradas. Se medirá por la coherencia entre lo que la entidad dice tolerar, lo que financia, lo que prueba y lo que está dispuesta a aceptar.
Una entidad madura puede mostrar que el órgano de dirección aprobó una tolerancia concreta; que esa tolerancia se tradujo en objetivos técnicos y contractuales; que los servicios críticos están vinculados a activos y proveedores; que las pruebas han medido el rendimiento real; que las desviaciones tienen propietario y fecha; y que los incidentes han producido cambios verificables.
Una entidad menos madura puede tener documentos impecables y no poder responder cuánto tardaría en recuperar un servicio esencial si el proveedor principal quedara indisponible. Esa diferencia resume el problema. DORA no pide una biblioteca normativa. Pide una capacidad de decisión y recuperación que pueda demostrarse.
Para el órgano de dirección, la conclusión es poco cómoda pero útil: el riesgo TIC ya está dentro de sus responsabilidades fiduciarias y prudenciales, aunque la infraestructura esté externalizada. Para el CISO y cumplimiento, la conclusión es igualmente clara: el trabajo no termina al diseñar controles. Hay que construir la evidencia que permita al consejo ejercer su responsabilidad y demostrar al supervisor que no aprobó resiliencia sobre el papel.
La pregunta que conviene llevar a la próxima reunión no es si la entidad cumple DORA. Es más concreta: si mañana fallara el servicio tecnológico más importante, ¿podríamos demostrar qué decisión de gobierno permitió operar dentro de la tolerancia aprobada? Si la respuesta exige buscar documentos en cinco departamentos, el problema no es de archivo. Es de gobierno.