Tu certificado ISO 27001 no activa los plazos de DORA
Las entidades financieras siguen mapeando los controles ISO 27001 en los artículos de DORA y denominando al resto documentación. Las verdaderas adiciones de DORA son obligaciones que deben realizarse, con una especificación y en un plazo, algo que un certificado nunca fue diseñado para verificar.

Una forma común de iniciar un programa DORA es con una hoja de cálculo. Una columna lista los requisitos del Reglamento (UE) 2022/2554, otra los controles de ISO/IEC 27001:2022 Anexo A que la empresa ya ha implementado en su SGSI certificado, y una tercera registra la superposición. Cuando se completa el mapeo, la superposición es grande: gestión de riesgos TIC, control de acceso, gestión de proveedores, continuidad del negocio, gestión de incidentes. El residuo puede parecer un ejercicio de redacción basado en un certificado existente.
Ese marco es la trampa. No está equivocado sobre la superposición, que es real. Lo que falla es la interpretación de lo que es el residuo. Las partes de DORA que una empresa certificada en ISO 27001 no ha realizado aún no son simplemente documentación por escribir. Varias de ellas son obligaciones que deben cumplirse, con una especificación y en un plazo, y un certificado es el instrumento equivocado para demostrar su cumplimiento.
Un certificado atestigua un sistema acotado; un reglamento impone obligaciones
ISO/IEC 27001:2022 certifica que un sistema de gestión de seguridad de la información de un alcance definido cumple con los requisitos de la norma. La certificación no es un momento único: un organismo de certificación emite el certificado tras una auditoría y, por lo general, se mantiene a lo largo de un ciclo de tres años con auditorías de seguimiento y recertificación. Dos aspectos lo acompañan que importan aquí. El objeto certificado es un sistema de gestión, delimitado por la declaración de alcance, y la pregunta de certificación es la conformidad: ¿el SGSI cumple con los requisitos?
DORA no está construido así. Se aplica directamente a las entidades financieras desde el 17 de enero de 2025 (Reglamento (UE) 2022/2554), y sus disposiciones no son un sistema de gestión al que conformarse, sino obligaciones que cumplir, varias de ellas con plazos y especificaciones concretas. Puedes tener un certificado ISO 27001 válido, en alcance y vigente, y aún así incumplir DORA, porque el certificado responde a una pregunta que DORA no plantea. Tres de las obligaciones de DORA funcionan con plazos o especificaciones que un certificado nunca ha verificado; una cuarta transfiere la responsabilidad a un ámbito que un certificado nunca comprueba.
El registro
El Artículo 28(3) exige a las entidades financieras mantener un registro de información sobre sus acuerdos contractuales para el uso de servicios TIC prestados por proveedores de servicios TIC de terceros, y presentar información sobre esos acuerdos a su autoridad competente al menos anualmente. El registro es un artefacto estructurado, no un documento de formato libre: el Reglamento de Ejecución (UE) 2024/2956 de la Comisión, publicado en el Diario Oficial el 2 de diciembre de 2024, establece las plantillas y campos de datos estándar. Según los acuerdos de notificación de las Autoridades Europeas de Supervisión, las autoridades competentes recopilan estos registros de las entidades supervisadas y los envían a las AES, siendo la primera recogida en 2025.
Una empresa certificada ya gestiona sus proveedores TIC bajo controles del Anexo A como A.5.19 a A.5.23, seleccionados a través de su tratamiento de riesgos y registrados en su Declaración de Aplicabilidad. Lo que esto no produce por sí solo es un registro en el esquema prescrito, poblado con los campos de datos de DORA, reconciliado con los contratos reales de la empresa y presentable a un supervisor en el ciclo de recogida. Gestionar proveedores y presentar un artefacto estructurado específico a un regulador son obligaciones distintas, y la segunda no queda evidenciada por la primera.
El reloj de los incidentes
El Artículo 19 obliga a las entidades financieras a notificar a la autoridad competente los incidentes importantes relacionados con las TIC, y la norma técnica fija los plazos. El Reglamento Delegado (UE) 2025/301 de la Comisión, de 23 de octubre de 2024, exige una notificación inicial en un plazo de cuatro horas desde que el incidente se clasifica como importante y, ordinariamente, no más tarde de 24 horas después de que la entidad haya tomado conocimiento del mismo; un informe intermedio en un plazo de 72 horas desde esa notificación inicial; y un informe final en un plazo de un mes desde el informe intermedio (o el último informe intermedio actualizado). Si un incidente es "importante" o no se decide mediante los criterios de clasificación del Reglamento Delegado (UE) 2024/1772 de la Comisión.
El detalle clave merece leerse dos veces. El reloj de cuatro horas de DORA comienza en el momento en que un incidente se clasifica como importante, lo que convierte la clasificación precisa y oportuna en parte de la obligación, no en un paso previo. Esta estructura es distinta de las obligaciones de notificación de incidentes que los equipos financieros ya conocen: la alerta temprana de NIS2 funciona en un plazo de 24 horas desde que se toma conocimiento de un incidente significativo (Directiva (UE) 2022/2555, Artículo 23), y el RGPD exige a un responsable notificar una violación de datos personales que suponga un riesgo para los derechos de las personas sin demora indebida y, cuando sea posible, en un plazo de 72 horas desde que se tiene conocimiento de la misma (Reglamento (UE) 2016/679, Artículo 33). No son plazos intercambiables. Bajo los controles del Anexo A A.5.24 a A.5.27, una empresa certificada planifica, evalúa, responde y aprende de los incidentes de seguridad de la información mediante el proceso que ha implementado, y un auditor aceptó ese proceso como conforme. Que un auditor acepte que el proceso es conforme no equivale a que ese proceso produzca una notificación regulatoria correctamente clasificada en un plazo de cuatro horas desde la clasificación.
La obligación de pruebas
El Artículo 26 exige a las entidades financieras identificadas por sus autoridades competentes, en función de su tamaño, perfil de riesgo e importancia sistémica, realizar pruebas de penetración basadas en amenazas al menos cada tres años, en sistemas de producción en vivo que respalden funciones críticas o importantes. Los tres años son un mínimo que la autoridad competente puede ajustar, y la metodología detallada y los criterios de identificación se establecen en el Reglamento Delegado (UE) 2025/1190 de la Comisión, aplicable desde el 8 de julio de 2025. Esto no afecta a todas las entidades financieras, y la identificación corresponde al regulador. Pero para una empresa en el ámbito de aplicación, es una obligación recurrente y evidenciable de un tipo específico.
ISO/IEC 27001 pide a una empresa que supervise, mida y evalúe el rendimiento de su SGSI (apartado 9.1) y que realice auditorías internas (apartado 9.2), y el control del Anexo A A.8.29 cubre las pruebas de seguridad en desarrollo y aceptación. Ninguno de estos, por sí solo, evidencia un ejercicio de red team basado en inteligencia contra producción, repetido en la cadencia de DORA y realizado según la metodología supervisora. Una empresa puede estar totalmente certificada y nunca haber realizado una.
La responsabilidad que un certificado no alcanza
El Artículo 5(2) establece sobre el órgano de administración la obligación de definir, aprobar, supervisar y ser responsable del marco de gestión de riesgos TIC, y el punto (a) lo hace "asumir la responsabilidad última de gestionar el riesgo TIC de la entidad financiera". El Artículo 5(4) añade una obligación personal: los miembros del órgano de administración deben mantener sus conocimientos y habilidades actualizados para comprender y evaluar el riesgo TIC. Esta es la única de las cuatro que no tiene un plazo. Es una obligación de gobernanza continua.
La cláusula 5.1 de ISO/IEC 27001 ya exige el liderazgo y compromiso de la alta dirección, por lo que esta es el área de mayor superposición. La brecha es más estrecha y específica que "ISO ignora al consejo". DORA fija la responsabilidad última en el "órgano de administración", un término jurídicamente definido, e impone una obligación de competencia personal a sus miembros. La "alta dirección" de ISO y el "órgano de administración" de DORA no son necesariamente las mismas personas, y la certificación demuestra el compromiso de liderazgo con el SGSI, no el cumplimiento del Artículo 5(2)(a) o 5(4). Se puede obtener un certificado sin haber verificado nunca la responsabilidad específica que DORA menciona.
Por qué el mapeo oculta las cuatro
La hoja de cálculo falla de manera consistente: compara texto de control con texto de control, y el peso adicional de DORA no está solo en el texto. Un control dice "la organización debe gestionar los incidentes de seguridad de la información", y la evidencia ISO de la empresa también lo dice, y las celdas coinciden. Lo que la celda no muestra es que DORA ha añadido un reloj con punto de referencia de cuatro horas, un esquema de registro prescrito, una obligación de pruebas al menos cada tres años y un órgano responsable nombrado legalmente a actividades que ISO expresa como capacidades. Dos requisitos pueden usar palabras casi idénticas y, aun así, satisfacerse con actos distintos, porque uno pregunta si existe un sistema conforme dentro de un alcance y el otro si se realizó una obligación especificada.
Esta es la objeción que merece tomarse en serio, y es la que mantiene a muchos programas en la vía de la documentación. El Anexo A, se argumenta, ya cubre la gestión de incidentes, la gestión de proveedores y las pruebas, por lo que DORA es la misma sustancia con un envoltorio de cumplimiento. La respuesta es que una especificación y un plazo no son un envoltorio alrededor de un control. Un punto de referencia, un formato de presentación, una cadencia de pruebas ajustable y una responsabilidad legal nombrada son obligaciones nuevas que la existencia de un control no exime, y son precisamente las que un mapeo control-a-control hace invisibles.
La regla que vale la pena conservar
Cuando mapees una certificación sobre un reglamento, mapea las obligaciones operativas, no el texto del control. Un certificado atestigua que un sistema de gestión cumplió una norma, dentro de un alcance, a lo largo de un ciclo de auditoría. Un reglamento dice qué debe hacer ese sistema, con qué especificación y en qué plazo. Donde ambos describen la misma actividad, verifica si el reglamento ha añadido un reloj con punto de referencia, un formato, una cadencia o una responsabilidad nombrada, porque esos son los añadidos que un mapeo control-a-control hace invisibles y los que es probable que verifique un supervisor.
Este instinto se generaliza más allá de DORA, aunque los detalles varían según el régimen. NIS2 exige a los Estados miembros imponer tanto obligaciones de gobernanza del órgano de administración (Directiva (UE) 2022/2555, Artículo 20) como un plazo de alerta temprana de 24 horas (Artículo 23), sobre actividades que los controles existentes ya describen. El Reglamento de Ciberresiliencia adjunta plazos de notificación de vulnerabilidades explotadas activamente e incidentes graves a los fabricantes de productos con elementos digitales, con esas obligaciones de notificación aplicables desde el 11 de septiembre de 2026 (Reglamento (UE) 2024/2847, Artículo 14). Los modelos de responsabilidad no son idénticos, pero la disciplina de lectura es la misma: encuentra el verbo, encuentra el reloj o la especificación, y trata cada obligación con un plazo o un destinatario definido como una obligación operativa, no como un documento por escribir.
Si tu tarea a corto plazo es separar la superposición real entre ISO 27001 y DORA de las obligaciones con plazos y especificaciones que un certificado no evidencia, ese cruce de referencias con los artículos y normas técnicas reales es el tipo de trabajo para el que ISMS Copilot está diseñado. Una gran superposición en el mapeo es real. También es evidencia reutilizable que aún requiere validación específica para DORA, no un cumplimiento que puedas trasladar sin cambios, razón por la cual no es la parte que debe guiar el plan.
Este es un análisis de cumplimiento práctico, no asesoramiento legal. Confirma el alcance y las obligaciones de tu entidad según el reglamento y sus normas técnicas, y, cuando sea relevante, con tu autoridad competente o asesoría legal.
Artículos relacionados

La declaración de alcance es el certificado
"Certificado ISO 27001" no es un hecho de sí o no sobre una empresa. La afirmación real es la declaración de alcance en el certificado, y es verificable.

El CRA es un problema de 2026, no de 2027
La obligación de notificación del Reglamento de Resiliencia Cibernética (CRA) entra en vigor el 11 de septiembre de 2026, más de un año antes de sus requisitos esenciales. Los equipos que planifican hacia atrás desde la marca CE de 2027 están secuenciando el trabajo en el orden incorrecto.

La matriz de riesgo 5x5 sobrevive a auditorías, no al escrutinio
ISO 27001 nunca pide un mapa de calor. Lo que sí pide (resultados consistentes, válidos y comparables) es la prueba que la mayoría de las matrices de riesgo no superan.
