Persona sujetando un papel que simboliza el Reglamento de Resiliencia Operativa Digital DORA

DORA mapping: de los requisitos a las pruebas preparadas para auditorías

2 septiembre 2026 · 11 min de lectura

No es una obligación explícita, pero resulta decisiva una vez que comienza una auditoría: así es como la DORA mapping vincula la normativa con los procesos, contratos y pruebas que ya tiene tu organización.

Puntos clave: DORA mapping

La DORA mapping vincula los requisitos del Reglamento (UE) 2022/2554 a los procesos, controles y contratos que una entidad financiera en la UE ya tiene implementados.
En ninguna parte de la normativa se exige explícitamente una asignación o mapping, pero los registros, contratos y auditorías hacen que sea difícil trabajar sin ella.
La gestión del riesgo de terceros se basa en dos elementos: un registro central de información y una clasificación CIF para cada proveedor de TIC.
ISO 27001 y NIS2 cubren gran parte del terreno, con lagunas en torno a los plazos de notificación, las cláusulas contractuales obligatorias y las pruebas de penetración.
El panel de métricas de gestión del riesgo humano de SoSafe proporciona las pruebas de concienciación basadas en roles que exige el artículo 13(6).

Por lo general, los requisitos de DORA se asignan a los controles existentes del Anexo A de la norma ISO 27001, que cubren la gestión de riesgos, el control de acceso y las relaciones con los proveedores. Revisa la normativa artículo por artículo, anota qué control cubre ya el requisito y documenta por separado lo que quede, como los plazos de notificación o las pruebas TLPT.

DORA define una función crítica o importante como aquella cuyo fallo perjudicaría sustancialmente el rendimiento financiero, las operaciones comerciales o el cumplimiento de las obligaciones de supervisión. Evalúa a cada proveedor de TIC en función de la actividad que respalde y anota la clasificación en tu registro de información para que otras personas puedan entender el razonamiento.

Según DORA, se espera que vayas más allá del contrato directo y mantengas la visibilidad sobre las cadenas de subcontratación de los proveedores críticos. En la práctica, el cumplimiento de DORA o DORA compliance implica registrar a los subcontratistas siempre que respalden funciones críticas o importantes, y evaluar el riesgo de concentración en diferentes niveles.

La DORA mapping no se sanciona por separado, por lo que no conlleva ninguna penalización en sí misma. El incumplimiento de DORA puede dar lugar a requerimientos de supervisión, multas y declaraciones públicas, cuyas cuantías fijan los Estados miembros. Una asignación o mapping incompleta sí aumenta el riesgo de que las obligaciones subyacentes pasen desapercibidas.

El artículo 13(6) de DORA exige concienciación y formación documentadas y basadas en roles tanto para los empleados como para la dirección. Debe aparecer en una línea independiente dentro de la asignación interna, con un responsable designado y pruebas sólidas que puedan superar cualquier escrutinio, en lugar de limitarse a un simple porcentaje de asistencia.

Más allá de DORA: un vistazo a las métricas y el cumplimiento de las normativas

Desde la evaluación de madurez hasta la preparación de auditorías, estos temas ayudan a los equipos de TI y de ciberseguridad a ubicar la asignación en un panorama más amplio del cumplimiento de las normativas y a planificar los siguientes pasos.

Glossary

DORA compliance: requisitos, checklist y riesgo humano

Glossary

DORA

¿Qué es la DORA mapping?

La DORA mapping es la asignación estructurada de los requisitos establecidos en el Reglamento de Resiliencia Operativa Digital (Reglamento (UE) 2022/2554) a los procesos, controles, contratos y responsabilidades que existen realmente dentro de una entidad financiera. En lugar de revisar los artículos uno por uno, una buena asignación conecta cada requisito con el área en la que la organización ya lo cumple, o donde aún no lo hace.

Aquí convergen tres capas: bajo cuál de los cinco pilares de DORA se enmarca un área (gestión de riesgos de TIC, aviso de incidentes, pruebas de resiliencia, riesgo de proveedores externos de TIC o intercambio de información); qué proceso o control existente ya cubre el requisito; y qué serviría para demostrarlo en una auditoría, ya sea un documento, un registro o la cláusula de un contrato. Es esa última capa la que diferencia a una asignación o mapping de una simple lista de tareas. Una lista de tareas confirma que se está llevando a cabo una acción. Una asignación o mapping muestra qué puedes presentar para demostrarlo.

DORA se aplica de forma directa en todos los Estados miembros de la UE desde el 17 de enero de 2025. Por lo tanto, para la mayoría de las entidades afectadas, la DORA mapping no es un proyecto puntual, sino una tarea constante. Los nuevos proveedores, los cambios en los procesos y la actualización de las normas técnicas de regulación (RTS, por sus siglas en inglés) de las Autoridades Europeas de Supervisión vuelven a modificar el panorama.

Por qué necesitas la DORA mapping en la práctica

Sin la DORA mapping, el cumplimiento de DORA parece un conjunto impreciso de medidas sueltas. Cada medida tiene sentido por sí sola, pero cuando comienza una auditoría, a menudo falta el hilo conductor que las conecta. Una DORA mapping estructurada compensa de formas muy concretas.

Los auditores rara vez preguntan si cumples con DORA en términos generales. A lo que te enfrentarás es a preguntas concretas: ¿cómo demuestras el requisito X en el proceso Y mediante el control Z? La DORA mapping te proporciona toda esa cadena desde el requisito hasta la prueba, en lugar de obligarte a improvisar en plena sala.

Además, las deficiencias también se pueden identificar de manera más fiable. Solo al colocar el requisito junto al proceso real queda claro cuándo falta algo, ya sea una cláusula contractual exigida por el artículo 30 que no figura en un acuerdo en vigor con un proveedor, o una cadena de notificación de progreso que aún no refleja los ajustados plazos establecidos por el reglamento.

La mayoría de las entidades reguladas ya cumplen con gran parte de DORA a través de marcos como la norma ISO 27001 o la NIS2, sin que este solapamiento esté documentado en ninguna parte. La DORA mapping lo plasma en papel y te evita tener que hacer el mismo trabajo dos veces.

Para los equipos de ciberseguridad con recursos limitados, es ahí donde reside el verdadero valor práctico. Cumplir con el requisito cuesta lo mismo de siempre. Demostrarlo en una auditoría cuesta considerablemente menos una vez que la cadena existe en papel.

La perspectiva legal: ¿es obligatoria la DORA mapping?

No, no de forma explícita. En ninguna parte de DORA se exige elaborar una «asignación» o mapping. Lo que el reglamento sí hace vinculante es lo siguiente:

mantener un registro de información en continua actualización que abarque todos los contratos con proveedores externos de TIC (art. 28(3)), que las autoridades de control pueden solicitar cuando sea necesario;
llevar a cabo un proceso de diligencia debida previo a la firma de un contrato, que abarque, entre otras cosas, la sustituibilidad, el riesgo de insolvencia, la protección de datos y las cadenas de subcontratación (art. 28(4)),
incluir disposiciones contractuales mínimas en virtud del artículo 30 para los contratos que respaldan «funciones críticas o importantes»;
supervisar de manera constante las relaciones con los proveedores (art. 28(6)).

En la práctica, resulta difícil cumplir con estas obligaciones sin algún tipo de asignación estructurada de los requisitos a los procesos, los controles y las pruebas, sobre todo porque las revisiones de supervisión suelen seguir exactamente esa cadena, desde la actualización del registro hasta comprobar si las cláusulas obligatorias del artículo 30 figuran en los contratos. Por lo tanto, en la práctica es difícil evitar la DORA mapping, aunque nunca se mencione como una obligación en sí misma. Decir simplemente que «ya cumplimos con los requisitos individuales» sin documentarlos ni asignarlos hace que resulte considerablemente más difícil demostrarlo.

Procesos, controles y responsabilidades

La traducción interna de un requisito de DORA en un proceso concreto que ya exista o que aún deba crearse, con una responsabilidad clara, es la parte más eficaz de cualquier DORA mapping. Si omites ese paso, la asignación se quedará en una simple hoja de cálculo sin valor operativo.

En la práctica, cuatro columnas son suficientes: requisito, función, control y pruebas. El proceso de gestión de incidentes muestra el aspecto de esas filas.

Requisito de DORA	Función afectada	Control	Pruebas
Notificación de incidentes graves relacionados con las TIC en plazos escalonados (art. 19)	Seguridad de TI, respuesta ante incidentes	Proceso de notificación de progreso con canales de notificación y plazos definidos	Registro de incidentes, informes presentados ante la autoridad de control
Clasificación de los incidentes relacionados con las TIC según su gravedad (art. 18)	Seguridad de TI	Sistema de clasificación con un conjunto de criterios definidos	Decisión de clasificación documentada para cada incidente
Supervisión continua de los proveedores externos de TIC (art. 28(6))	Gestión de proveedores, adquisiciones	Revisión periódica de la supervisión según el nivel de criticidad	Registros de la revisión, registro de información actualizado

Cada una de las cinco áreas de DORA se puede desarrollar de la misma manera. Ninguna fila debería quedarse sin un responsable designado, ya sea una persona o un cargo. Si se omite, el límite entre TI, el cumplimiento de las normativas y la gestión de riesgos se difumina, que es de donde suelen provenir las conclusiones de las auditorías sobre gobernanza.

Hay un elemento que se subestima con frecuencia en la DORA mapping: el factor humano. El artículo 13(6) establece que la concienciación y la formación documentadas y basadas en roles son obligatorias tanto para los empleados como para la dirección. No es un añadido opcional, y se merece una línea propia en la asignación, con sus correspondientes pruebas como cualquier otro requisito. Presentar esto ante un auditor requiere algo más que un simple porcentaje de asistencia. Es necesario contar con contenido específico para cada rol y pruebas de que los conocimientos se mantienen. El panel de métricas de gestión del riesgo humano de SoSafe cubre exactamente esa deficiencia, con contenido de formación basada en roles y registros preparados para auditorías, de modo que la fila se pueda completar con datos fiables en lugar de una mera declaración de intenciones.

Demostrado, no solo afirmado

Descubre en una demo de producto cómo proporciona SoSafe pruebas de auditoría irrebatibles.

Solicita una demo

Gestión del riesgo de terceros en la DORA mapping

DORA deja poco margen de interpretación aquí: puedes externalizar el servicio, pero no la resiliencia ni el riesgo que conlleva. Cuando una función crítica depende de un proveedor externo de TIC, la responsabilidad recae en la entidad sujeta a DORA. La documentación sobre el cumplimiento de las normativas del propio proveedor, por muy exhaustiva que sea, no puede sustituir a la tuya.

En la práctica, de esto se derivan tres aspectos:

Mantén un único registro central: El registro no distingue entre una plataforma global en la nube y una herramienta SaaS especializada. Ambas se incluyen en un único registro de información actualizado en virtud del artículo 28(3), con la identidad del proveedor, el servicio prestado, los datos del contrato y la cadena de subcontratación que hay detrás.
Clasifica según la criticidad: El hecho de que un proveedor brinde soporte técnico a una función crítica o importante (CIF) rige casi todo lo que viene a continuación. El artículo 30 aplica su conjunto completo de cláusulas obligatorias, desde los derechos de auditoría hasta las estrategias de salida y la portabilidad de los datos, únicamente a ese grupo.
Comprueba que los contratos incluyen las cláusulas obligatorias: Los acuerdos en vigor deben revisarse en función de lo que establece el artículo 30. En el caso de los contratos marco más antiguos, esa revisión a menudo se convierte en una renegociación en sí misma.

En la actualidad, varios de los principales proveedores de TIC publican su propia documentación sobre DORA, entre ellos GoTo, GitLab y SAP. Conviene tener en cuenta en qué consiste ese material: es información aportada por el proveedor, no tu propia asignación o mapping. Este tipo de documentos resultan útiles para la revisión de contratos y para la diligencia debida hacia ese proveedor en concreto. Sin embargo, no sustituyen a tu registro general de información de todos los proveedores ni a la clasificación interna de la criticidad, que solo puede llevar a cabo la propia entidad financiera.

DORA mapping: ISO 27001 y NIS2

Pocas organizaciones comienzan su DORA mapping totalmente desde cero. Cualquiera que ya cuente con la certificación de la norma ISO 27001, o que haya implementado los requisitos de la NIS2, ya cubre una parte sustancial de DORA. Hacer visibles esos solapamientos ahorra la duplicación del trabajo, y a menudo es exactamente lo que los auditores piden ver.

He aquí una visión simplificada de los puntos en los que las áreas de DORA se relacionan con la norma ISO 27001 y con la NIS2:

Área de DORA	Estructura relacionada de la norma ISO 27001	Referencia de la NIS2 relacionada
Gestión de riesgos de TIC (Art. 5–15)	Controles del Anexo A sobre la gestión de riesgos y el control de acceso	Medidas de gestión de riesgos (Art. 21)
Aviso de incidentes (Art. 17–23)	Controles sobre la gestión de incidentes	Obligaciones de notificación (Art. 23)
Riesgo de proveedores externos de TIC (Art. 28–30)	Controles sobre las relaciones con los proveedores	Seguridad de la cadena de suministro (Art. 21(2)(d))
Pruebas de penetración basadas en amenazas (Art. 24–27)	Sin equivalente directo	Sin equivalente directo

DORA e ISO 27001

La gestión de riesgos de TIC es donde la DORA mapping a ISO 27001 resulta más útil, ya que los controles del Anexo A ya cubren gran parte de los artículos 5 al 15. El límite de esta asignación o mapping se encuentra en aquellas áreas de DORA que la ISO 27001 nunca tuvo motivo para abordar: los plazos estrictos y escalonados tras un incidente, y las pruebas de penetración basadas en amenazas (TLPT) en las entidades importantes. Por lo tanto, contar con una certificación previa es un buen punto de partida, pero no sustituye las pruebas concretas de DORA.

DORA y NIS2

Con DORA y NIS2, la seguridad de la cadena de suministro y las medidas de gestión de riesgos vuelven a mostrar la mayor coincidencia. El reto es diferente al de ISO 27001: NIS2 es una directiva, la cual se transpone de manera distinta de un país a otro, mientras que DORA se aplica de forma directa y uniforme como reglamento. Para las entidades financieras que también entran en el ámbito de aplicación de la NIS2, se aplica una regla adicional: al ser la normativa específica del sector, DORA prevalece en caso de duda. Documentar esto explícitamente en la DORA mapping evita duplicar esfuerzos y generar procesos contradictorios.

Cinco pilares, una tabla

Los cinco pilares de DORA, ISO 27001 y NIS2, junto con el tipo de pruebas recomendado para cada requisito.

Descarga el PDF

Esta guía pretende servir de orientación inicial y no constituye un asesoramiento jurídico. Fuentes jurídicas: Reglamento (UE) 2022/2554 (DORA), ISO/IEC 27001:2022, Directiva (UE) 2022/2555 (NIS2). Última actualización: septiembre de 2026