DORA Gestión de Riesgos TIC para Bancos 2026: Guía de Cumplimiento Capítulo II
El Reglamento DORA (UE 2022/2554) es aplicable desde el 17 de enero de 2025. El Capítulo II (Arts. 5–15) es el núcleo regulatorio: exige un marco de gestión de riesgos TIC documentado y aprobado por el consejo de administración, con responsabilidad personal de los consejeros. Cubre el ciclo completo: identificación de activos, protección, detección, respuesta, recuperación y aprendizaje. Este artículo analiza cada artículo con los requisitos concretos que inspeccionarán el Banco de España, la CNMV y el BCE.
Marco de Gestión de Riesgos TIC (DORA Cap. II): Conjunto documentado de estrategias, políticas, procedimientos y herramientas que la entidad financiera debe establecer, implementar y mantener para identificar, clasificar, proteger, detectar, responder, recuperarse y aprender de los riesgos TIC. El órgano de administración (consejo de administración o equivalente) es directamente responsable de su aprobación y supervisión continuada, sin posibilidad de delegación al CTO o CISO.
€10M
"Sanción administrativa máxima por incumplimiento grave de DORA para entidades de crédito (o el 2% de la facturación mundial total si es mayor). Los supervisores nacionales comenzaron evaluaciones desde el Q1 2025."
— Reglamento DORA (UE) 2022/2554, Art. 50
¿Qué exige exactamente el art. 5 sobre gobernanza TIC?
El art. 5 es el punto de partida y el más inspeccionado. Exige que el órgano de gestión —no el departamento de IT— defina, apruebe y supervise activamente la estrategia de resiliencia digital de la entidad. Esto implica que el consejo de administración debe: aprobar la política de gestión de riesgos TIC al menos anualmente, asignar un presupuesto TIC adecuado al perfil de riesgo, garantizar que la entidad disponga de personal cualificado en TIC, y recibir al menos una vez al año un informe del responsable de seguridad TIC (CISO o función equivalente). Los supervisores están revisando actas del consejo y formación de consejeros en ciberseguridad para verificar implicación real, no solo formal.
¿Qué debe contener el inventario de activos TIC según el art. 8?
El art. 8 obliga a mantener un inventario actualizado de todos los activos TIC (hardware, software, datos y dependencias con terceros) clasificados por criticidad. El Reglamento Delegado 2024/1774 (RTS sobre herramientas de gestión de riesgos TIC) especifica los campos mínimos del registro: identificador del activo, tipo de activo, función de negocio soportada, clasificación de criticidad (crítico/importante/estándar), propietario responsable, ubicación, contrato de soporte y fecha de fin de vida. La revisión debe ser al menos anual y tras cualquier cambio significativo de infraestructura. Una brecha frecuente: los proveedores SaaS y cloud usados por unidades de negocio que no están en el inventario central del departamento de IT.
¿Qué controles de protección y prevención exige el art. 9?
El art. 9 establece los controles mínimos de protección. Para sistemas clasificados como críticos, la autenticación multifactor (MFA) es obligatoria. Otros controles requeridos: segmentación de red para aislar sistemas críticos, cifrado de datos en tránsito y en reposo (equivalente a AES-256), gestión de parches de seguridad con SLAs definidos por nivel de criticidad (parches críticos CVSSv3 ≥9.0 en 24–72h), política de gestión de accesos con revisión trimestral de privilegios, y política formal de criptografía y gestión de claves aprobada por el órgano de gestión. El RTS 2024/1774 exige además que la política de seguridad de la información sea formalmente aprobada por el órgano de administración y revisada al menos anualmente.
¿Cómo se estructura el requisito de detección del art. 10?
El art. 10 exige mecanismos para detectar rápidamente actividades TIC anómalas, incluyendo en los puntos de acceso de terceros. En la práctica, requiere un sistema SIEM (Security Information and Event Management) con umbrales de alerta definidos, monitorización continua de toda la infraestructura TIC crítica, correlación de eventos de seguridad, y un proceso de escalada documentado con tiempos de respuesta. El RTS exige que la entidad defina el comportamiento normal de referencia para sus sistemas críticos y que las desviaciones generen alertas automáticas. Las entidades que dependen de servicios cloud deben extender la monitorización a los logs de los proveedores.
¿Qué exigen los arts. 11–13 sobre respuesta, recuperación y aprendizaje?
El art. 11 exige un Plan de Continuidad de Negocio (BCP) y un Plan de Recuperación ante Desastres (DRP) con RTO (Recovery Time Objective) y RPO (Recovery Point Objective) definidos para cada sistema crítico. Los planes deben probarse al menos anualmente, o tras un incidente mayor o un cambio significativo de infraestructura. Los resultados de las pruebas —incluyendo las deficiencias encontradas y las acciones correctoras— deben documentarse y presentarse al órgano de gestión. El art. 12 exige copias de seguridad diarias como mínimo, con copias offline para sistemas críticos y pruebas anuales de restauración completa. El art. 13 obliga a realizar revisiones post-incidente para todos los incidentes mayores y a integrar la inteligencia de amenazas en la mejora continua del marco de riesgos TIC.
| Artículo DORA | Requisito principal | Brecha más frecuente |
|---|---|---|
| Art. 5 — Gobernanza | Consejo aprueba y supervisa estrategia TIC | Aprobación formal sin implicación real del consejo |
| Art. 8 — Activos TIC | Inventario completo clasificado por criticidad | SaaS de unidades de negocio no registrados |
| Art. 9 — Protección | MFA, cifrado, gestión de parches con SLA | Política de criptografía no aprobada formalmente |
| Art. 10 — Detección | SIEM con alertas y escalada documentada | Sin baseline de comportamiento normal definida |
| Art. 11 — Respuesta/Recuperación | BCP/DRP con RTO/RPO probados anualmente | Planes no probados con evidencia documentada |
| Art. 15 — Revisión | Revisión independiente anual del marco TIC | Auditoría interna no cumple requisito de independencia |
Cómo lo resuelve IgeraLegal
Consulta del compliance officer:
"¿DORA art. 8 nos obliga a incluir los SaaS que usan nuestros departamentos de RR.HH. y marketing en el inventario TIC?"
IgeraLegal responde:
"Sí. El art. 8(1) DORA exige identificar TODOS los activos TIC, incluyendo dependencias con terceros proveedores TIC, independientemente de si el proveedor es 'crítico' bajo el Capítulo V. Ese estatus afecta al régimen de supervisión del proveedor, no a vuestras obligaciones de identificación. Por tanto, los SaaS de RR.HH. y marketing que soporten funciones de negocio (aunque no sean funciones críticas o importantes) deben incluirse en el inventario con su clasificación de criticidad correspondiente."
En resumen: DORA Capítulo II para bancos
- El consejo debe aprobar y supervisar la estrategia TIC de forma activa (Art. 5). No basta la aprobación formal.
- Inventario de todos los activos TIC con clasificación de criticidad (Art. 8). Incluye SaaS de unidades de negocio.
- MFA obligatoria para sistemas críticos. Gestión de parches con SLA. Política de criptografía formal (Art. 9).
- SIEM con alertas definidas y baseline de comportamiento normal documentada (Art. 10).
- BCP/DRP con RTO/RPO definidos y probados anualmente con evidencia documentada (Art. 11).
- Revisión independiente anual del marco TIC (Art. 15). Auditoría interna puede no ser suficiente.
- IgeraLegal responde dudas sobre cada artículo y genera las plantillas de políticas TIC.
Preguntas frecuentes sobre DORA Capítulo II
¿Puede el consejo delegar la responsabilidad DORA en el CTO o CISO?
No. El art. 5 DORA es explícito: la responsabilidad de la gestión de riesgos TIC recae sobre el órgano de administración. Puede delegar la gestión operativa, pero la supervisión estratégica y la aprobación de la política TIC son no delegables. Los supervisores están verificando que las actas del consejo reflejen debates sustantivos sobre riesgos TIC, no solo aprobaciones rutinarias.
¿Con qué frecuencia debe revisarse el marco de riesgos TIC?
Al menos una vez al año, y siempre tras un incidente TIC significativo o un cambio material en la infraestructura o el modelo de negocio. La revisión anual incluye también la revisión del inventario de activos TIC (art. 8) y la actualización de la política de seguridad de la información (art. 9).
¿La auditoría interna satisface el requisito de revisión independiente del art. 15?
No siempre. El art. 15 exige una revisión independiente del marco de gestión de riesgos TIC. Si la función de auditoría interna tiene la independencia y la capacitación técnica requerida, puede ser suficiente. Pero en muchos casos, las entidades necesitan complementar con una revisión externa —especialmente si el auditor interno carece de expertise específico en ciberseguridad financiera.
¿Qué RTO y RPO son aceptables para sistemas críticos bajo DORA?
DORA no establece valores mínimos de RTO/RPO, sino que exige que estén definidos en función del perfil de riesgo de cada sistema y que sean realizables (probados en los ejercicios anuales de BCP/DRP). La EBA ha indicado en sus directrices que para sistemas de pago y servicios esenciales se esperan RTOs de horas, no días. El supervisor evaluará si los objetivos son coherentes con el impacto que tendría la interrupción del servicio.
¿IgeraLegal genera la documentación del marco TIC?
Sí. IgeraLegal actúa como asistente de compliance RAG: responde preguntas sobre los artículos concretos del Capítulo II de DORA y los RTS asociados, genera plantillas de política de gestión de riesgos TIC, modelos de política de seguridad de la información, checklists de revisión anual del marco y borradores del informe del CISO al consejo. Todo citando el artículo exacto aplicable.
¿Las entidades de menor tamaño tienen requisitos distintos en el Capítulo II?
Sí. El art. 16 DORA establece un marco simplificado de gestión de riesgos TIC para microempresas y entidades pequeñas y no complejas. El Reglamento Delegado 2024/1773 (RTS sobre marco simplificado) define qué entidades se pueden acoger y qué requisitos del Capítulo II se simplifican. No obstante, los pilares de notificación de incidentes y gestión de contratos con terceros TIC aplican sin simplificación a todas las entidades.
¿Tu marco DORA Capítulo II está listo para una inspección?
IgeraLegal responde preguntas de cumplimiento DORA desde el texto del Reglamento y las Directrices de la EBA/EIOPA/ESMA — con el artículo exacto citado, en segundos.
Prueba gratis 14 díasActualizado: junio 2026 · Fuentes: Reglamento (UE) 2022/2554 (DORA), Arts. 5–15; Reglamento Delegado (UE) 2024/1774 (RTS herramientas gestión riesgos TIC); Reglamento Delegado (UE) 2024/1773 (RTS marco simplificado); Directrices conjuntas EBA/ESMA/EIOPA sobre gestión de riesgos TIC 2024 · Autor: Equipo editorial Igera Solutions · No constituye asesoramiento jurídico.
Guía de referencia
← Volver a la guía Industrial: RAG Industrial: Mantenimiento y Documentación TécnicaArtículos relacionados en este clúster:
- → Reglamento DORA 2025: Guía de Cumplimiento para Entidades Financieras y Fintech
- → Plazos de Reporte DORA 2026: Guía Completa para Entidades Financieras
- → Reglamento DORA de la UE y Contratos TIC con Terceros: Guía para Gestores de Activos y PropTech (2026)
- → Reglamento DORA de la UE y riesgo TIC de terceros: lo que necesitan saber los administradores de fincas