Estas son las áreas que revisar en tu lista de comprobación de cumplimiento de DORA:
- Confirmar si DORA se aplica y definir el alcance
- Establecer el gobierno y la responsabilidad
- Crear un marco de gestión del riesgo de TIC
- Mantener inventarios de activos, servicios y dependencias
- Aplicar controles de protección, prevención y detección
- Definir la gestión y notificación de incidentes de TIC
- Establecer un programa de pruebas de resiliencia
- Gestionar el riesgo de terceros de TIC
- Preparar la continuidad, las copias de seguridad y la recuperación
- Mantener las evidencias, los informes y la mejora continua
La Ley de Resiliencia Operativa Digital (DORA), formalmente el Reglamento (UE) 2022/2554, se aplica desde el 17 de enero de 2025. Exige a las entidades financieras gestionar el riesgo de TIC, prepararse para interrupciones operativas, notificar incidentes graves y supervisar a los proveedores tecnológicos de los que dependen sus servicios críticos.
DORA no se limita al departamento de TI. Afecta al gobierno corporativo, la gestión de riesgos, las compras, la continuidad de negocio, la respuesta ante incidentes, la auditoría interna y la supervisión de la alta dirección. Esta lista de comprobación ofrece una forma práctica de revisar las principales áreas de preparación. El Reglamento DORA oficial debe consultarse junto con las normas regulatorias y técnicas aplicables.
10 áreas que revisar para el cumplimiento de DORA
1. Confirmar si DORA se aplica y definir el alcance
Identificar las entidades incluidas
Comienza identificando cada entidad jurídica, sucursal y unidad de negocio que pueda estar sujeta a DORA. El análisis debe considerar si la organización es un banco, una empresa de inversión, una entidad de pago, una compañía de seguros, un proveedor de servicios de criptoactivos, un mercado regulado u otra categoría incluida en el Reglamento.
El alcance también debe tener en cuenta las estructuras de grupo. Una sociedad matriz puede proporcionar tecnología, seguridad o servicios operativos compartidos a varias entidades reguladas, mientras que cada entidad puede conservar la responsabilidad independiente sobre sus propias obligaciones regulatorias.
Documentar la decisión sobre el alcance
La organización debe registrar por qué cada entidad, servicio y entorno tecnológico se incluye o se excluye. Esta decisión debe ser aprobada por el órgano de gobierno correspondiente y revisarse cuando cambie el negocio, se adquiera otra entidad o se introduzca un nuevo servicio regulado.
Una decisión clara sobre el alcance evita deficiencias posteriores en la evaluación del riesgo de TIC, el inventario de proveedores, el proceso de gestión de incidentes y el programa de evidencias.
2. Establecer el gobierno y la responsabilidad
Asignar la responsabilidad a la dirección
DORA atribuye una responsabilidad significativa al órgano de dirección. El órgano de dirección debe aprobar el marco de gestión del riesgo de TIC, comprender los riesgos tecnológicos relevantes y supervisar el programa de resiliencia de la organización.
Las responsabilidades deben documentarse en mandatos, políticas, reglamentos de comités y calendarios de informes. Debe estar claro quién aprueba la aceptación de riesgos, quién recibe los informes de incidentes y quién decide si una debilidad de control requiere inversión adicional.
Conectar el gobierno con las evidencias
El gobierno debe poder demostrarse. Entre los registros útiles se incluyen políticas aprobadas, actas de reuniones, informes de riesgos, decisiones sobre medidas correctivas, revisiones de incidentes, resultados de pruebas y aprobaciones de la dirección.
Las organizaciones que ya utilizan un marco estructurado de gestión de riesgos pueden ampliarlo para incluir las responsabilidades de DORA, en lugar de crear un proceso separado.
3. Crear un marco de gestión del riesgo de TIC
Utilizar una metodología coherente
El marco debe identificar las amenazas, vulnerabilidades, posibles impactos, servicios afectados y salvaguardas existentes. Debe cubrir la confidencialidad, integridad, disponibilidad, autenticidad y resiliencia operativa.
El registro de riesgos debe mostrar el responsable, la valoración, la decisión de tratamiento, la fecha objetivo y la exposición restante de cada riesgo relevante. También debe distinguir entre riesgos aceptados, transferidos, mitigados o evitados.
Vincular los riesgos con el tratamiento y las evidencias
Una evaluación de riesgos de DORA está incompleta si solo enumera riesgos. Cada riesgo significativo necesita una medida de tratamiento, un responsable y evidencias de soporte. La organización debe poder demostrar cómo se tomó una decisión y si el tratamiento redujo realmente la exposición.
La relación entre el registro de riesgos, las medidas de tratamiento y las evidencias puede estructurarse mediante un plan de tratamiento de riesgos ISO 27001, incluso cuando la certificación ISO 27001 no forme parte del alcance inmediato.
4. Mantener inventarios de activos, servicios y dependencias
Registrar los activos y servicios de TIC
El inventario debe cubrir aplicaciones, infraestructura, servicios cloud, redes, endpoints, almacenes de datos, identidades, interfaces y herramientas de seguridad. También debe identificar los responsables, ubicaciones, niveles de criticidad, dependencias y requisitos de recuperación.
Los equipos tecnológicos deben conciliar el inventario con los registros de compras, las plataformas de identidad, las cuentas cloud, los sistemas de gestión de configuración y los registros de proveedores. También deben tenerse en cuenta las herramientas informales y las soluciones adoptadas sin aprobación central.
Mapear las funciones críticas o importantes
La organización debe conectar los activos de TIC con los servicios empresariales y las funciones críticas o importantes. Esto ayuda a determinar qué sistemas necesitan objetivos de recuperación más exigentes, supervisión adicional o pruebas más frecuentes.
Un enfoque estructurado para proteger la infraestructura frente a ciberataques puede ayudar a organizar la información técnica, pero la empresa debe definir las relaciones entre servicios y la importancia operativa de cada activo.
5. Aplicar controles de protección, prevención y detección
Proteger el acceso y las configuraciones
DORA exige gestionar la identidad, la autenticación, los accesos privilegiados, la configuración segura, los cambios, los parches y el tratamiento de vulnerabilidades. Los controles deben ser proporcionales a los riesgos del sistema o servicio correspondiente.
Entre las preguntas importantes se encuentran:
- ¿Los accesos privilegiados están limitados y se revisan?
- ¿Las actualizaciones de seguridad se siguen hasta su finalización?
- ¿Los cambios se aprueban, prueban y pueden revertirse?
- ¿Los entornos de producción y desarrollo están separados adecuadamente?
- ¿Están documentadas las responsabilidades sobre el cifrado y la gestión de claves?
Supervisar la actividad anómala
La prevención debe estar respaldada por la detección. Los registros, la supervisión y las alertas deben cubrir los sistemas importantes, la actividad administrativa, los eventos de seguridad y la degradación de los servicios.
Las medidas de supervisión deben definir quién revisa las alertas, cómo se escalan los eventos y cómo se conservan los registros. El proceso también debe explicar cómo continúa la supervisión durante una interrupción de un proveedor u otra situación de disrupción.
6. Definir la gestión y notificación de incidentes de TIC
Crear un proceso de escalado
El proceso de incidentes debe definir qué constituye un incidente relacionado con las TIC, cómo se clasifican los incidentes y quién coordina la respuesta.
Debe reunir a los equipos de tecnología, riesgos, legal, cumplimiento, comunicaciones, privacidad y negocio. Las funciones deben estar claras antes de que ocurra un incidente, incluido quién conserva las evidencias, quién informa a la dirección y quién coordina la respuesta con los proveedores afectados.
Preparar la notificación regulatoria
DORA establece requisitos para clasificar y notificar los incidentes graves relacionados con las TIC. La organización debe definir los criterios de decisión, las responsabilidades de notificación, el proceso de aprobación y los registros necesarios para respaldar las comunicaciones.
Las plantillas y los plazos aplicables deben comprobarse según las normas regulatorias más recientes, incluidos los estándares técnicos para la notificación de incidentes graves.
Las simulaciones de incidentes deben probar tanto la respuesta técnica como la toma de decisiones regulatorias. Un ejercicio de mesa debe demostrar si la organización puede preparar una notificación precisa mientras continúa gestionando la interrupción.
7. Establecer un programa de pruebas de resiliencia
Definir un calendario de pruebas
Las pruebas deben basarse en el perfil de riesgo de la organización y en la criticidad de sus servicios. Entre las actividades posibles se incluyen evaluaciones de vulnerabilidades, pruebas de penetración, ejercicios basados en escenarios, pruebas de recuperación, ejercicios de conmutación por error y simulaciones de crisis.
El plan de pruebas debe identificar el sistema o proceso evaluado, el objetivo, los participantes, las evidencias esperadas y el responsable de las medidas correctivas. Las pruebas no deben tratarse como un ejercicio de certificación puntual.
Abordar las pruebas avanzadas cuando corresponda
Algunas entidades financieras pueden estar sujetas a requisitos más exigentes de pruebas de penetración basadas en amenazas. La organización debe confirmar si estos requisitos se aplican y planificar el alcance necesario, los evaluadores cualificados, las evidencias y las medidas correctivas.
Los resultados deben comunicarse a la dirección y los hallazgos relevantes deben seguirse mediante el proceso de riesgos y medidas correctivas.
8. Gestionar el riesgo de terceros de TIC
Realizar diligencia debida antes de la contratación
Las revisiones de proveedores deben evaluar los controles de seguridad, la resiliencia, los subcontratistas, las ubicaciones de los datos, la notificación de incidentes, los accesos, la capacidad de recuperación y las dependencias del servicio.
La revisión debe cubrir más que un cuestionario. Los contratos, informes independientes de garantía, resúmenes de pruebas de penetración, información sobre continuidad de negocio y documentación técnica también pueden ser relevantes. Además, DORA exige mantener un registro de información con todos los acuerdos contractuales con proveedores terceros de servicios de TIC, que la entidad debe presentar periódicamente a su autoridad competente.
En las organizaciones que dependen mucho de proveedores SaaS o API, la supervisión de proveedores, el tratamiento de datos y la dependencia operativa deben evaluarse conjuntamente. El análisis de PrivaLex sobre riesgos de privacidad que las empresas SaaS suelen pasar por alto muestra por qué las dependencias técnicas y de privacidad no deben revisarse de forma aislada.
Incluir requisitos contractuales y de salida
Los contratos relacionados con DORA pueden necesitar disposiciones sobre obligaciones de seguridad, derechos de auditoría, cooperación, notificación de incidentes, acceso a la información, subcontratación y apoyo durante la terminación.
La organización también debe evaluar el riesgo de concentración. Si varios servicios críticos dependen del mismo proveedor cloud, proveedor de conectividad o socio de seguridad gestionada, una interrupción puede afectar simultáneamente a varias funciones empresariales.
El plan de salida debe determinar si los datos, configuraciones, registros y documentos operativos pueden exportarse dentro de un plazo realista. También debe considerar proveedores alternativos, apoyo durante la transición y los recursos necesarios para migrar.
9. Preparar la continuidad, las copias de seguridad y la recuperación
Definir los objetivos de recuperación
Las medidas de continuidad de negocio deben identificar los servicios que deben restaurarse, la interrupción máxima tolerable y las dependencias que deben estar disponibles durante la recuperación.
Los objetivos de recuperación deben respaldarse con medidas técnicas y organizativas prácticas, incluidas copias de seguridad, infraestructura redundante, canales de comunicación alternativos, procedimientos manuales y mecanismos de toma de decisiones de emergencia.
Probar la recuperación en condiciones realistas
Una copia de seguridad no demuestra que los sistemas puedan recuperarse. La organización debe comprobar si los datos pueden restaurarse, si los sistemas pueden reconstruirse, si el acceso puede restablecerse y si las operaciones críticas pueden continuar.
Las pruebas deben incluir escenarios de fallo de proveedores, ransomware, pérdida de acceso privilegiado, interrupción de una región cloud y corrupción de datos. Las lecciones aprendidas deben documentarse, asignarse a responsables y revisarse por la dirección.
10. Mantener las evidencias, los informes y la mejora continua
Crear una estructura de evidencias
El conjunto de evidencias de DORA puede incluir:
- Evaluaciones y registros de riesgos de TIC.
- Inventarios de activos y dependencias.
- Políticas y procedimientos.
- Revisiones de acceso y registros de cambios.
- Informes de vulnerabilidades y parches.
- Registros de incidentes y notificaciones regulatorias.
- Resultados de las pruebas de continuidad y recuperación.
- Evaluaciones y contratos de proveedores, y registro de información de proveedores de TIC.
- Informes de pruebas de penetración.
- Registros de formación del personal.
- Actas de la dirección y de los comités.
- Seguimiento de medidas correctivas.
Las evidencias deben estar vinculadas a controles, riesgos y responsables concretos. Una carpeta llena de documentos no es suficiente si la organización no puede explicar qué demuestra cada registro o cuándo se revisó por última vez.
Revisar y mejorar el programa
DORA exige un enfoque continuo de la resiliencia. Después de un incidente, una prueba o una auditoría, la organización debe identificar las lecciones aprendidas, actualizar los controles y realizar el seguimiento de las medidas correctivas hasta su finalización.
Cuando se solapan la privacidad, el riesgo de TIC y las evidencias regulatorias, la evaluación de siete puntos sobre la necesidad de un DPO externo de PrivaLex puede ayudar a determinar cuándo está justificada una capacidad adicional de gobierno.
Convertir los requisitos de DORA en un programa operativo con PrivaLex
En PrivaLex, ayudamos a las organizaciones financieras y tecnológicas a convertir las obligaciones de DORA en un programa operativo que puedan utilizar los equipos de dirección, seguridad, cumplimiento y tecnología.
El trabajo suele comenzar con la confirmación del alcance y una evaluación de madurez. Identificamos las entidades, servicios de TIC, funciones empresariales críticas, proveedores y marcos existentes que deben tenerse en cuenta. Esto crea una base práctica antes de que la organización invierta en nuevas herramientas, políticas o actividades de prueba.
A continuación, ayudamos a estructurar el programa principal: metodología de riesgos de TIC, registro de riesgos, plan de tratamiento, responsables de controles, flujo de revisión de proveedores, escalado de incidentes, pruebas de resiliencia y requisitos de evidencias. Cada acción prioritaria se vincula con un responsable, un plazo, un resultado esperado y un registro de soporte.
Cuando la organización ya cuenta con un programa ISO 27001, RGPD, NIS2 o ENS, asignamos los requisitos compartidos a un único modelo de gobierno manteniendo visibles las obligaciones específicas de DORA. Esto puede reducir las evaluaciones duplicadas y proporcionar a la dirección una visión más clara de qué controles respaldan varios requisitos regulatorios.
PrivaLex también puede apoyar la supervisión de proveedores y subcontratistas, la planificación de continuidad, los ejercicios de incidentes, los informes a la dirección, la preparación de auditorías internas y el seguimiento de medidas correctivas. Si ya existe una plataforma de cumplimiento, ayudamos a configurarla según el alcance y el modelo operativo reales de la organización, evitando que se convierta en una colección de listas de comprobación desconectadas.
El objetivo es crear un programa de DORA capaz de responder ante un incidente, una revisión de proveedores, una auditoría interna o una inspección supervisora. Debe demostrar no solo que existen políticas, sino que los controles tienen responsables, funcionan, se prueban y mejoran.
Conclusión
El cumplimiento de DORA depende de mucho más que una biblioteca de políticas o un cuestionario completado. Las entidades financieras necesitan un modelo operativo conectado que cubra el gobierno, el riesgo de TIC, los inventarios de activos, la respuesta ante incidentes, las pruebas de resiliencia, la supervisión de proveedores, la recuperación y las evidencias.
Una secuencia práctica de implementación consiste en:
- Confirmar el alcance y las responsabilidades.
- Mapear los servicios críticos y las dependencias de TIC.
- Crear el marco de riesgos y controles.
- Revisar los proveedores y las protecciones contractuales.
- Probar los procesos de respuesta y recuperación.
- Organizar las evidencias para la dirección y la supervisión regulatoria.
Reserva una sesión estratégica con PrivaLex para evaluar tu preparación frente a DORA y priorizar las próximas acciones. También puedes solicitar una evaluación de riesgos gratuita si necesitas una primera visión de tu exposición actual.
Preguntas Frecuentes (FAQs)
El cumplimiento de DORA consiste en establecer las medidas de gobierno, gestión del riesgo de TIC, notificación de incidentes, pruebas de resiliencia y supervisión de terceros exigidas por la Ley de Resiliencia Operativa Digital.
DORA se aplica a una amplia variedad de entidades financieras establecidas en la Unión Europea, incluidos bancos, empresas de inversión, entidades de pago, compañías de seguros, proveedores de servicios de criptoactivos y otras organizaciones reguladas cubiertas por el Reglamento. También establece obligaciones que afectan a los proveedores terceros de servicios de TIC del sector financiero.
Las principales áreas son la gestión del riesgo de TIC, el gobierno, la gestión y notificación de incidentes, las pruebas de resiliencia, la continuidad de negocio, el intercambio de información y la gestión del riesgo de terceros de TIC.
No. ISO 27001 y DORA abordan requisitos relacionados, pero diferentes. ISO 27001 proporciona un sistema estructurado de gestión de la seguridad de la información, mientras que DORA incluye obligaciones específicas para la resiliencia del sector financiero, la notificación de incidentes, las pruebas y la supervisión de terceros de TIC.
Los proveedores cloud y SaaS pueden quedar incluidos en el marco de riesgo de terceros de TIC de DORA cuando prestan servicios a entidades financieras. La entidad financiera sigue siendo responsable de gestionar su propio riesgo de terceros, aunque un proveedor opere infraestructura o controles de seguridad importantes.
Los controles deben revisarse según el riesgo, los requisitos regulatorios, los cambios significativos, los incidentes y los resultados de las pruebas. Las revisiones no deben depender únicamente de un calendario anual. Los nuevos proveedores, los cambios importantes de sistemas, las vulnerabilidades graves y los incidentes pueden requerir una revisión anticipada.
PrivaLex apoya el análisis del alcance, la gestión del riesgo de TIC, la supervisión de proveedores, la preparación ante incidentes, las pruebas de resiliencia, la preparación de evidencias, la alineación entre marcos y los informes a la dirección. El trabajo puede adaptarse tanto a organizaciones que comienzan desde cero como a aquellas que necesitan mejorar un programa de DORA existente.
PrivaLex es una consultora boutique especializada que asesora a empresas tecnológicas, plataformas digitales y otras organizaciones basadas en datos en materia de privacidad, seguridad de la información, certificaciones y cumplimiento normativo.
Combinamos el RGPD, ISO 27001, ENS, NIS2, DORA y la gobernanza de la IA en un único modelo de asesoramiento, lo que permite abordar múltiples obligaciones regulatorias mediante un marco de gobierno integrado.
PrivaLex actúa como asesor estratégico a largo plazo, apoyando a las organizaciones desde el diseño de su modelo de gobierno y la preparación para certificaciones hasta los servicios de DPO externo, la respuesta ante incidentes y el cumplimiento normativo continuo.