¿Qué software necesita una entidad financiera española para cumplir DORA? Respuesta directa: una herramienta que ayude a gestionar los principales bloques operativos del Reglamento de Resiliencia Operativa Digital: la gestión del riesgo de las TIC (arts. 5-16), la notificación de incidentes graves (arts. 17-23), las pruebas de resiliencia operativa (arts. 24-27) y, sobre todo, el registro de información sobre proveedores TIC y la gestión del riesgo de terceros (arts. 28-44). DORA se aplica desde el 17 de enero de 2025 a bancos, aseguradoras, empresas de inversión, entidades de pago y proveedores de servicios de criptoactivos supervisados por el Banco de España, la CNMV y la DGSFP. No hay un “software DORA” universal: la decisión clave es entre una plataforma GRC generalista y una herramienta específica de resiliencia TIC.
Esta guía de compra explica qué debe cubrir la herramienta y cómo elegir según su perfil.
Puntos clave
- DORA se aplica desde el 17 de enero de 2025 a las entidades financieras del art. 2 del Reglamento.
- Los bloques operativos centrales son riesgo TIC, notificación de incidentes, pruebas de resiliencia y riesgo de terceros; DORA también regula acuerdos voluntarios de intercambio de información.
- El registro de información sobre proveedores TIC es la obligación documental más exigente y la que más automatiza un software.
- Para obligaciones equivalentes de riesgo TIC y notificación de incidentes de entidades financieras incluidas en ambos regímenes, DORA puede operar como norma sectorial especial; otras actividades y entidades requieren una comprobación separada.
Qué debe cubrir un software DORA
El Reglamento (UE) 2022/2554 (DORA) estructura la resiliencia operativa digital en pilares que un software debe soportar de forma trazable:
- Gestión del riesgo de las TIC (arts. 5-16). Marco de gobernanza, identificación de funciones críticas, protección, detección, respuesta y recuperación, con supervisión del órgano de dirección.
- Notificación de incidentes graves (arts. 17-23). Clasificación de incidentes según umbrales, notificación inicial, intermedia y final a la autoridad competente en los plazos regulados.
- Pruebas de resiliencia operativa (arts. 24-27). Programa de pruebas periódicas y, para entidades seleccionadas conforme a los criterios aplicables, pruebas de penetración basadas en amenazas (TLPT).
- Gestión del riesgo de terceros TIC (arts. 28-44). Registro de información sobre todos los acuerdos con proveedores TIC, evaluación de riesgo, cláusulas contractuales obligatorias y estrategia de salida.
- Intercambio de información (art. 45). Participación voluntaria en acuerdos de intercambio de inteligencia sobre amenazas.
La concreción española de estas obligaciones y las autoridades implicadas las tratamos en nuestra guía sobre DORA y las entidades financieras en España.
El registro de información: la obligación que más pesa
Si hay una función que justifica adquirir un software DORA, es el registro de información sobre acuerdos con proveedores TIC (art. 28). Las entidades deben mantener y remitir a su autoridad competente un registro estructurado, en un formato normalizado por las Autoridades Europeas de Supervisión (ESAs), con datos precisos de cada proveedor, cada función soportada y su criticidad.
Mantener ese registro en hojas de cálculo puede volverse difícil cuando hay numerosos contratos, entidades o subcontratistas; la calidad depende del modelo de datos y de su revisión. Un software especializado puede ayudar a modelar la cadena de subcontratación, marcar las funciones críticas o importantes, generar el registro en el formato exigido y detectar concentraciones de riesgo. Pida al proveedor que demuestre cada función con los datos y plantillas aplicables a su entidad; la etiqueta «DORA» no prueba que el archivo entregado sea válido.
Criterios de selección y comparación de enfoques
Hay dos enfoques principales, y la elección depende de su tamaño y madurez:
| Criterio | GRC generalista | Herramienta DORA específica |
|---|---|---|
| Cobertura | Varios marcos (ISO, NIS2, DORA) | Enfocada en resiliencia TIC |
| Registro de información | Comprobar configuración y exportación ESAs | Comprobar módulo y exportación ESAs con una fila real |
| Pruebas de resiliencia | Demostrar planificación y evidencias, incluido TLPT si aplica | Demostrar planificación y evidencias, incluido TLPT si aplica |
| Implantación | Medir carga de datos, integración y corrección | Medir carga de datos, integración y corrección |
| Posible encaje | Grupos que ya gestionan varios marcos | Entidades que priorizan procesos DORA |
Una plataforma GRC generalista puede permitir gestionar DORA junto a ISO 27001, el ENS o NIS2, si su configuración y sus exportaciones lo demuestran. Puede encajar en grupos que ya gestionan varios marcos. Una herramienta DORA específica centra su propuesta en la resiliencia TIC, pero el registro, las pruebas y el tiempo de implantación deben demostrarse con datos, integraciones y controles de la entidad; el nombre de la categoría no acredita funciones nativas ni un despliegue más rápido.
Para las entidades que además tratan datos personales, conviene coordinar la resiliencia TIC con el cumplimiento de protección de datos, porque un incidente TIC puede requerir además una evaluación de violación de datos personales. La documentación de resiliencia debe coordinarse con el cumplimiento del RGPD, pero cada evento tiene criterios y destinatarios propios.
Cuando se reutilizan respuestas sobre seguridad, compruebe su relación con el servicio concreto. La evaluación de software de cuestionarios permite probar fuentes, alcance, aprobación y exportación, evitando que una respuesta de otra edición o entidad se comparta sin revisión.
Hoja de ruta para implantar DORA con software
Adquirir la herramienta no basta; hay que desplegarla en un orden que respete la lógica del Reglamento. Una secuencia probada es la siguiente:
-
Identifique las funciones críticas o importantes. Antes de nada, determine qué servicios sostienen su actividad y no pueden fallar. Todo el marco DORA gira en torno a ellos.
-
Levante el registro de información. Cargue en el software todos los acuerdos con proveedores TIC, con su función soportada, su criticidad y la cadena de subcontratación. Es la base documental que remitirá a la autoridad.
-
Formalice el marco de riesgo TIC. Configure la gobernanza, las políticas y los controles de los arts. 5-16, con la supervisión del órgano de dirección claramente trazada.
-
Prepare el circuito de incidentes. Defina los umbrales de clasificación y las plantillas de notificación inicial, intermedia y final. Ensaye el flujo antes de necesitarlo.
-
Planifique las pruebas de resiliencia. Establezca el programa de pruebas periódicas y, si es entidad significativa, las pruebas de penetración basadas en amenazas (TLPT).
-
Revise los contratos con proveedores. Incorpore las cláusulas obligatorias del art. 30 y defina la estrategia de salida para cada función crítica. Este trabajo se coordina con la revisión de encargados de tratamiento del RGPD.
-
Establezca la mejora continua. DORA no es un proyecto que se cierra: exige revisión periódica del riesgo, actualización del registro tras cada cambio de proveedor y aprendizaje tras cada incidente.
Las Autoridades Europeas de Supervisión publican las normas técnicas (RTS e ITS) que concretan estos pasos; conviene seguir las guías de la Autoridad Bancaria Europea (EBA) y de las demás ESAs, porque el formato del registro y los umbrales de incidentes derivan de ellas. Durante la prueba de compra verifique la versión del formato disponible, el proceso de actualización y la calidad de una exportación real.
DORA frente a NIS2: no duplique el trabajo
Una duda frecuente es si una entidad financiera debe cumplir DORA y NIS2 a la vez. El artículo 4 de NIS2 permite aplicar un acto sectorial de la Unión cuando sus requisitos de gestión de riesgos TIC o notificación de incidentes tienen efecto al menos equivalente. DORA opera en ese marco para las entidades financieras pertinentes, pero no elimina sin examen todos los posibles deberes de una entidad con otras actividades. Documente el alcance por entidad jurídica, actividad y obligación. Si el grupo también tiene entidades no financieras que entren en NIS2, revise nuestra comparativa de software de cumplimiento NIS2 para ese perímetro.
La supervisión en España la ejercen el Banco de España, la CNMV y la Dirección General de Seguros y Fondos de Pensiones, cada una sobre su sector. Las obligaciones de DORA y de protección de datos se analizan por separado; una infracción TIC no determina por sí misma una infracción RGPD. El análisis de sanciones del sector financiero trata esta segunda dimensión.
Véase también: software de cumplimiento del AI Act y software de registro de tratamientos.
FAQ
¿Desde cuándo se aplica DORA en España?
DORA se aplica plenamente desde el 17 de enero de 2025 a las entidades financieras enumeradas en su art. 2, sin necesidad de transposición nacional al tratarse de un reglamento de aplicación directa. Las autoridades españolas (Banco de España, CNMV y DGSFP) supervisan su cumplimiento en sus respectivos sectores desde esa fecha.
¿Es obligatorio un software para cumplir DORA?
La ley no obliga a usar un software concreto, pero el registro de información sobre proveedores TIC en el formato de las ESAs puede requerir controles específicos de consistencia cuando crece el número de acuerdos. Una herramienta puede facilitar la validación y remisión si demuestra que sus exportaciones cumplen el formato; una entidad también puede organizar el proceso de otra manera si conserva precisión, responsables y pruebas suficientes.
¿Una entidad financiera debe cumplir DORA y NIS2 a la vez?
No se responde solo por la etiqueta «entidad financiera». Para los requisitos equivalentes de gestión de riesgos TIC y notificación de incidentes cubiertos por DORA, este reglamento actúa como norma sectorial especial en los términos del artículo 4 de NIS2. Hay que comprobar la entidad jurídica, sus actividades concretas, el ámbito de cada obligación y la transposición nacional: una actividad adicional puede generar deberes distintos, y otras sociedades del grupo pueden estar sujetas a NIS2 por sí mismas. Documente esa matriz antes de configurar la herramienta.
Prueba de compra: construir una fila del registro real
Antes de valorar una demostración comercial, prepare un acuerdo ficticio con un proveedor TIC que sostiene una función importante. Debe incluir la entidad contratante, la entidad que utiliza el servicio, el identificador del acuerdo, el tipo de servicio, las funciones respaldadas, la fecha y condiciones contractuales y los proveedores de la cadena que resulten pertinentes. Pida al vendedor que introduzca los datos una sola vez y genere las plantillas del Reglamento de Ejecución (UE) 2024/2956, sin retoques manuales posteriores. Compruebe que los identificadores relacionan acuerdos, entidades, funciones y servicios entre tablas. Una captura de pantalla de un «registro DORA» no demuestra que el archivo exportado respete el formato exigido.
La prueba debe incluir un cambio. Suponga que una filial pasa a contratar el servicio de forma directa o que un subcontratista empieza a sostener la función importante. La herramienta debe conservar la versión anterior, señalar los campos afectados, solicitar aprobación y producir un registro actualizado coherente a nivel individual y, si corresponde, consolidado. Pregunte qué ocurre con acuerdos intragrupo y con proveedores sin identificador estándar. Son situaciones habituales que revelan si el modelo de datos del producto soporta la realidad jurídica de la entidad. El registro de información DORA merece una prueba específica, no una promesa incluida en una lista de funciones.
Vincular riesgo, contrato, incidente y salida
La misma función crítica o importante debería aparecer en el inventario de servicios, la evaluación de riesgos, el contrato TIC, la prueba de continuidad y el plan de salida. Si cuatro módulos mantienen nombres distintos, el responsable de cumplimiento necesitará un proceso de reconciliación. En la demostración, cambie la criticidad de una función y observe qué evaluaciones y contratos pasan a revisión. Exija que cada excepción tenga propietario, justificación, fecha límite y decisión del órgano competente. DORA exige gobernanza y gestión del riesgo; un semáforo sin evidencia no acredita la eficacia de un control.
El plan de salida debe poder ejecutarse. Para un servicio de autenticación o pagos, no basta con escribir «cambiar proveedor»: indique qué datos y configuraciones pueden exportarse, en qué formato, cuánto tiempo durará la transición, quién mantendrá el servicio durante ella y cómo se probará el nuevo entorno. Verifique si el contrato permite acceso a información y cooperación para la supervisión, según la función afectada. Una herramienta útil enlaza el plan con el contrato y avisa de dependencias que hagan inviable la salida. Los criterios para riesgo de proveedores TIC también deben aplicarse a la concentración, incluidas varias funciones alojadas en una misma infraestructura.
Ensayar un incidente antes de comprar
Introduzca un escenario en el que un proveedor deja de estar disponible y afecta a clientes. La herramienta debe registrar la hora de detección, la evolución, los servicios afectados y la base de la clasificación del incidente. Pida que muestre las decisiones para determinar si se trata de un incidente TIC grave, las tareas pendientes, la aprobación de la notificación y las versiones de los informes. El circuito ha de permitir información incompleta y correcciones posteriores; nadie dispone de una causa raíz definitiva durante las primeras horas. La gestión de incidentes DORA exige criterios y canales propios, definidos en el Reglamento y en las normas técnicas aplicables. Si además hay datos personales, el equipo debe abrir una evaluación RGPD separada; una indisponibilidad TIC grave no es automáticamente una brecha de datos.
Haga el ensayo con los perfiles reales: operaciones, seguridad, jurídico y persona que autoriza la comunicación. Si solo el administrador del producto puede avanzar el expediente, el flujo fallará de noche o durante una ausencia. Compruebe permisos, sustituciones, registro de decisiones y exportación en un formato que pueda leerse fuera de la plataforma. Pregunte al proveedor cómo se actualizan los formularios cuando cambian las normas técnicas y cómo se verifican los cambios antes de usarlos en producción. Una supuesta «actualización automática» sin control de versiones puede crear un riesgo nuevo.
Contrato y coste total de operación
Compare las propuestas con un mismo perímetro: número de entidades, contratos, usuarios, importación histórica, conectores, pruebas de exportación, formación y soporte en incidentes. Solicite el coste de recuperar todos los datos y evidencias al terminar el contrato. Las licencias por proveedor o por expediente pueden cambiar mucho cuando crece el registro. Revise ubicación del tratamiento, subencargados y obligaciones de protección de datos del proveedor cuando el sistema almacena información personal; la residencia de datos por sí sola no resuelve las transferencias ni los accesos remotos.
La decisión final no debería decir «cumple DORA». Debe decir qué procesos quedan cubiertos, cuáles requieren otros sistemas o trabajo manual, qué exportaciones se probaron y quién será responsable de las brechas. Un grupo con una GRC implantada puede necesitar únicamente un módulo de registro interoperable; una entidad menor puede preferir un flujo más sencillo con controles manuales claros. Reevalúe la decisión cuando cambien servicios críticos, estructura del grupo o especificaciones regulatorias. El producto adecuado reduce esfuerzo y errores verificables, pero el órgano de dirección sigue siendo responsable de la resiliencia operativa.
Fuentes normativas para la demostración
Use el Reglamento DORA y las plantillas oficiales del registro de información como guion de pruebas. Compare la documentación de su supervisor sectorial con el proceso interno antes de fijar fechas o canales de remisión. Las especificaciones de un vendedor no sustituyen esos textos ni prueban el cumplimiento de la entidad.
Conclusión
El mejor software DORA es el que resuelve su prioridad real: registro de información sobre proveedores TIC, gestión del riesgo y notificación de incidentes en plazo. Compare una GRC generalista con una herramienta DORA específica mediante la misma prueba de datos, exportación, integración y tiempo de implantación; ninguna categoría garantiza por sí sola un despliegue rápido. Antes de decidir, sitúe su obligación con nuestra guía de DORA para entidades financieras en España y coordine la resiliencia TIC con su cumplimiento de protección de datos.