De ISO 27001 a DORA: cuánto reutilizas y qué te falta de verdad

No, certificarse en ISO 27001 no equivale a cumplir DORA. Y no por una cuestión filosófica ni por ese viejo debate de consultoría sobre si un estándar “ayuda” o “no ayuda”. No equivale porque una cosa es un sistema de gestión certificable y otra un reglamento europeo directamente aplicable, con obligaciones operativas, de gobernanza, supervisión y documentación mucho más concretas.

La confusión sigue viva porque ISO 27001 tiene una virtud y un problema a la vez: ordena. Cuando una entidad financiera sale del caos documental y consigue un ISMS razonable, la sensación interna suele ser de misión cumplida. El regulador, en cambio, tiende a ver otra película. Una bastante menos sentimental.

La pregunta útil no es si ISO 27001 “sirve” para DORA. Sirve, y bastante, como base. La pregunta seria es otra: qué cubre de verdad, qué no cubre y dónde están las brechas que más probablemente van a aparecer en una revisión de cumplimiento.

Aquí está el quid: DORA no premia la elegancia del marco. Premia —o exige, para ser exactos— la capacidad de demostrar control efectivo sobre riesgo ICT, incidentes, pruebas de resiliencia, continuidad, terceros tecnológicos y gobernanza. Si tu organización confunde “tenemos ISO” con “estamos listos”, va tarde.

La tesis corta: ISO 27001 puede ser una base sólida, pero DORA pide bastante más que una base

ISO/IEC 27001:2022 establece los requisitos para implantar, mantener y mejorar un sistema de gestión de seguridad de la información. Ese enfoque encaja bien con parte de lo que DORA espera de una entidad financiera: políticas, roles, evaluación de riesgos, controles, mejora continua, gestión de incidentes, continuidad y trazabilidad documental.

Hasta ahí, bien. El problema aparece cuando se da el salto de un estándar voluntario y transversal a un reglamento sectorial con obligaciones legales específicas. DORA no se limita a pedir “buenas prácticas”. Exige una estructura de gestión del riesgo ICT, un marco de notificación de incidentes, un régimen de pruebas de resiliencia, controles sobre terceros proveedores de servicios TIC y responsabilidades claras del órgano de dirección.

La referencia básica está en DORA art. 5 para el marco de gestión del riesgo ICT y en DORA art. 28 para la gestión del riesgo asociado a terceros proveedores de servicios ICT. En materia de pruebas de resiliencia operativa digital, incluidas las pruebas avanzadas basadas en amenazas para las entidades que entren en ese perímetro, la referencia correcta no está en el art. 26, sino en los artículos del capítulo de testing que siguen dentro del marco de pruebas de resiliencia operativa digital. Ese matiz no es un tecnicismo: citar mal el artículo justo donde el reglamento se vuelve más exigente es la clase de error que delata que se ha leído un resumen, no el texto.

Por eso la frase “ISO 27001 = DORA” no se sostiene. Ni jurídica ni operativamente.

Por qué tanta gente sigue confundiendo una certificación con el cumplimiento regulatorio

Porque ISO 27001 da algo que DORA no da: un sello reconocible. A la dirección le gusta. A compras también. Incluso a muchos clientes. El problema es que el sello no sustituye el análisis de obligaciones concretas.

Una entidad puede tener certificado su ISMS y, aun así, no haber aterrizado bien cuestiones centrales de DORA: la asignación efectiva de responsabilidades al management body, el diseño del registro de información sobre terceros ICT, la lógica de clasificación y reporte de incidentes, el inventario contractual exigible o la forma en que se conectan las funciones críticas o importantes con la arquitectura tecnológica y con las dependencias externas.

No es una anomalía. Es bastante normal. ISO 27001 está pensada para ser adaptable a sectores muy distintos. DORA, en cambio, está escrita para el sistema financiero europeo. Esa diferencia de diseño importa más de lo que parece.

También hay un incentivo psicológico bastante humano: si una organización ha invertido tiempo, presupuesto y capital político en certificarse, le cuesta aceptar que ese esfuerzo no cierra la conversación regulatoria. La tentación de declarar victoria antes de tiempo es fuerte. El supervisor no suele compartir ese entusiasmo.

Lo que ISO 27001 sí aporta de forma clara a una estrategia de cumplimiento DORA

Conviene decirlo sin rodeos: despreciar ISO 27001 sería absurdo. Bien implantada, reduce fricción, acelera la documentación y da una estructura útil para no improvisar. Hay varios puntos donde el alineamiento es real.

Primero, gobernanza documental. Una organización con un ISMS maduro suele tener políticas, procedimientos, control de cambios, revisiones periódicas, auditorías internas y un ciclo de mejora. Para DORA eso no basta, pero ayuda mucho.

Segundo, evaluación y tratamiento de riesgos. ISO 27001 obliga a definir una metodología, identificar riesgos, tratarlos y revisar su evolución. DORA, en su art. 6 y siguientes dentro del marco general de gestión del riesgo ICT, también descansa sobre una lógica sistemática de identificación, protección, prevención, detección, respuesta y recuperación. Quien ya ha hecho ese trabajo con cierta seriedad no empieza desde cero.

Tercero, gestión de incidentes y continuidad. El estándar y su ecosistema de controles permiten construir una disciplina útil para responder a incidentes, restaurar operaciones y aprender de los fallos. DORA también exige capacidades en esa línea, especialmente en sus disposiciones sobre gestión, clasificación y notificación de incidentes y sobre continuidad operativa.

Cuarto, cultura de control. Parece intangible, pero no lo es. Las entidades que han pasado por certificaciones serias suelen entender mejor qué significa evidenciar decisiones, revisar excepciones, asignar owners y mantener un rastro auditable. Eso, en regulación financiera, vale oro. O al menos evita dolores de cabeza bastante caros.

El error no está en usar ISO 27001 como palanca. El error está en tratarla como destino.

La primera brecha real: DORA no evalúa solo controles, evalúa responsabilidad del órgano de dirección

Una de las diferencias menos discutidas —y más importantes— está en la gobernanza. DORA art. 5 coloca al órgano de dirección en el centro de la responsabilidad sobre el marco de gestión del riesgo ICT. No habla de un patrocinio decorativo ni de aprobar políticas en bloque una vez al año. Habla de definir, aprobar, supervisar y ser responsable de la aplicación de ese marco.

ISO 27001 también exige liderazgo y compromiso de la alta dirección. Pero el tono regulatorio de DORA es más duro y más directo. La cuestión no es si existe un comité. La cuestión es si el órgano de dirección puede demostrar que entiende el riesgo ICT, que aprueba la estrategia correspondiente, que recibe información útil y que toma decisiones verificables.

Eso tiene consecuencias prácticas inmediatas:

• No basta con delegar todo en seguridad o en tecnología. La delegación operativa existe; la responsabilidad última no desaparece.
• Las actas importan. Si el board no discute incidentes significativos, concentración en terceros, resultados de pruebas o carencias materiales, la gobernanza queda en papel mojado.
• La formación deja de ser cosmética. DORA exige que los miembros del órgano de dirección mantengan conocimientos y capacidades suficientes para entender y evaluar el riesgo ICT.

Aquí muchas implantaciones de ISO 27001 pinchan. No porque el estándar lo impida, sino porque en la práctica se ejecuta como un proyecto de segunda línea: mucho equipo técnico, bastante compliance, poca apropiación real por parte del órgano de administración.

La segunda brecha: el riesgo de terceros en DORA no es un apéndice contractual

Si hay un terreno donde se nota enseguida la diferencia entre “tenemos un buen programa de seguridad” y “estamos adaptados a DORA”, es este. DORA art. 28 y los artículos siguientes del capítulo V convierten el riesgo de terceros proveedores de servicios ICT en una disciplina regulatoria propia, no en un anexo menor de vendor management.

ISO 27001 contempla relaciones con proveedores y controles asociados. Eso ayuda. Pero DORA aprieta más en varios planos a la vez: estrategia de riesgo de terceros, registro de información, evaluación previa, monitorización, contenido contractual y atención especial a la dependencia de proveedores que soportan funciones críticas o importantes.

Y aquí aparece una incomodidad habitual: muchas entidades creen tener bien controlados a sus proveedores porque guardan contratos, hacen cuestionarios y revisan SLA. Cuando intentan reconstruir la cadena real de dependencias TIC que sostiene una función crítica, la imagen se vuelve borrosa. A veces muy borrosa.

La pregunta que DORA obliga a formular no es “¿tenemos proveedor?”. Es bastante más incómoda: ¿qué función soporta, qué nivel de criticidad tiene, qué concentración genera, qué subcontratación existe, qué derechos de acceso y auditoría están pactados y cómo salimos de ahí sin romper el servicio?

Esa diferencia entre inventario comercial y control regulatorio es decisiva.

La tercera brecha: pruebas de resiliencia sí, pero no todas valen lo mismo

Otro punto donde conviene dejar de hablar en abstracto. DORA exige un programa de pruebas de resiliencia operativa digital proporcionado al tamaño, perfil de riesgo y naturaleza de la entidad, dentro del capítulo correspondiente a testing. Ese programa incluye distintos tipos de pruebas, y para determinadas entidades también prevé pruebas avanzadas basadas en amenazas —las conocidas TLPT— conforme a los artículos específicos del mismo capítulo y a los estándares técnicos que desarrollan ese régimen.

La corrección aquí importa: atribuir TLPT al art. 26 es incorrecto. El reglamento sitúa esas pruebas en disposiciones posteriores dentro del bloque dedicado a testing. Si una organización construye su gap analysis sobre citas mal puestas, acabará tomando atajos justo donde menos conviene.

Qué significa esto en la práctica. Que no basta con poder enseñar un calendario genérico de test, unos cuantos ejercicios de vulnerabilidad o una batería de controles heredados del ISMS. DORA pide un enfoque de pruebas integrado en el marco de resiliencia operativa digital, con trazabilidad, remediación y participación suficiente de las funciones relevantes. Para las entidades sujetas a TLPT, el listón sube todavía más porque entran en juego exigencias metodológicas y de gobernanza que no se reducen a “hacer pentesting”.

Dicho de otro modo: si en tu casa alguien sigue usando “tenemos test de penetración anuales” como respuesta automática a la pregunta sobre pruebas de resiliencia bajo DORA, conviene actualizar esa conversación. Urge, de hecho.

La cuarta brecha: incidentes bajo DORA no son solo incidentes de seguridad

ISO 27001 ayuda a estructurar la gestión de incidentes. Pero DORA opera con una lógica regulatoria más amplia: identificación, gestión, clasificación y, cuando proceda, notificación de incidentes graves relacionados con las TIC, además de la gestión de ciberamenazas significativas en el marco establecido por el reglamento y sus desarrollos técnicos.

Eso cambia la conversación interna por tres motivos.

Primero, porque el foco no se limita a confidencialidad, integridad y disponibilidad en abstracto. DORA mira el impacto operativo sobre servicios y funciones, la duración, el alcance, la afectación a clientes, la posible relevancia transfronteriza y otros criterios de clasificación que se desarrollan en normativa técnica. El incidente ya no pertenece solo al CISO. Pertenece también a operaciones, negocio, continuidad, cumplimiento y supervisión regulatoria.

Segundo, porque la calidad de la clasificación importa tanto como la detección. No sirve de mucho detectar mucho si luego no sabes escalar, documentar y decidir con rapidez qué encaja en el umbral de reporte aplicable.

Tercero, porque hay una diferencia material entre tener un playbook de respuesta y poder demostrar que el playbook está conectado con los circuitos regulatorios correctos. Y esa conexión no aparece por generación espontánea.

La consecuencia práctica es incómoda pero sencilla: una entidad con ISO 27001 puede tener una respuesta técnica razonable y, aun así, necesitar trabajo serio para aterrizar la lógica de clasificación y reporting que exige DORA.

La quinta brecha: DORA exige ver la arquitectura tecnológica desde el servicio, no solo desde el activo

Aquí se cuela uno de los errores más frecuentes en proyectos de madurez. Muchas organizaciones gestionan muy bien activos individuales —servidores, endpoints, aplicaciones, bases de datos, dispositivos de red— y bastante peor el mapa de dependencias que conecta esos activos con procesos de negocio y funciones relevantes.

Para cumplir DORA, ese salto de perspectiva es clave. El reglamento gira una y otra vez alrededor de la capacidad de sostener operaciones y funciones, de prevenir disrupciones y de recuperar servicios. Por eso, al diseñar el inventario y la documentación de soporte, resulta mucho más útil enlazar activos, aplicaciones y proveedores con los servicios y funciones que soportan, especialmente cuando se trata de funciones críticas o importantes en el sentido que utiliza DORA en su régimen sobre terceros ICT.

No hace falta convertir esta idea en una obligación formulada de manera más tajante de lo que permite el texto. Sí hace falta entender su implicación operativa: si tu inventario solo describe componentes técnicos aislados, te costará demostrar impacto, criticidad, dependencia y prioridad de recuperación. Y sin eso, la resiliencia se queda en una palabra bonita para comités.

Este punto parece menor hasta que llega un incidente real. Entonces todo el mundo quiere saber lo mismo y lo quiere saber ya: qué servicio cae, qué clientes afecta, qué tercero interviene, qué alternativa existe y cuánto tardas en volver. Si la organización no puede responder en minutos u horas razonables, descubrirá que tenía muchos activos catalogados y poca resiliencia entendida.

La sexta brecha: continuidad y recuperación bajo DORA exigen una mirada menos cómoda

ISO 27001 e ISO 22301 pueden dar una base útil para continuidad y recuperación. La cuestión no es negar esa utilidad, sino evitar una conclusión demasiado optimista. DORA obliga a encajar continuidad del negocio, respuesta a incidentes ICT, recuperación, comunicación y aprendizaje posterior dentro de un marco coherente de resiliencia operativa digital.

Eso empuja a revisar al menos tres cosas.

La primera es la dependencia tecnológica real. No la teórica del BIA que nadie actualiza, sino la efectiva: integraciones, piezas compartidas, credenciales privilegiadas, herramientas de administración remota, conectividad con terceros, servicios cloud, repositorios de backup, sistemas de monitorización y plataformas de autenticación. Si alguna de esas capas falla, la continuidad escrita en el plan puede quedarse en literatura corporativa.

La segunda es la interdependencia con terceros. DORA dedica un bloque entero al riesgo de terceros ICT por una razón bastante evidente: hoy una interrupción crítica rara vez viaja sola. Llega por proveedor, por subproveedor, por servicio centralizado o por dependencia concentrada. Cualquier plan de continuidad serio bajo DORA tiene que reflejar esa realidad con más granularidad de la que muchas organizaciones manejan hoy.

La tercera es la coherencia entre continuidad, recuperación y pruebas. Un plan que no se prueba de forma útil es una hipótesis optimista. DORA, justamente, desconfía de las hipótesis optimistas. Con razón.

Entonces, ¿qué valor real tiene una certificación ISO 27001 para una entidad sujeta a DORA?

Tiene valor. Y bastante. Lo que no tiene es efecto mágico.

Una certificación ISO 27001 bien mantenida puede reducir de forma notable el esfuerzo de preparación porque deja medio camino andado en materia de políticas, inventario de controles, evaluación de riesgos, formación, auditoría interna, gestión de no conformidades y disciplina documental. También puede facilitar conversaciones con auditores, clientes y áreas internas porque existe un lenguaje común ya asumido.

Pero convertir esa base en cumplimiento DORA exige un ejercicio adicional de traducción regulatoria. No basta con mapear controles de alto nivel. Hay que identificar obligaciones jurídicas concretas y evidencias operativas concretas.

Ese trabajo, en términos prácticos, suele incluir:

• un gap analysis artículo por artículo, no solo control por control;
• una revisión del modelo de gobernanza para verificar el rol real del órgano de dirección bajo DORA art. 5;
• un rediseño o refuerzo del marco de terceros ICT conforme a DORA art. 28 y siguientes;
• una revisión del programa de pruebas para comprobar si encaja con el capítulo de testing de DORA y con el posible perímetro TLPT;
• una adaptación del proceso de incidentes a la lógica de clasificación, escalado y notificación del reglamento;
• una mejora de trazabilidad entre activos, servicios, procesos y funciones críticas o importantes cuando esa relación esté insuficientemente documentada.

Eso no invalida ISO 27001. Al revés: explica cómo aprovecharla sin sobrevendérsela al consejo.

Lo que no conviene prometer internamente

Si eres CISO, responsable de compliance o líder de transformación regulatoria, hay tres frases que conviene desterrar cuanto antes.

La primera: “Con la ISO ya estamos prácticamente.” Puede ser verdad en algunas capas del marco de control. Como lectura global de DORA, es arriesgada.

La segunda: “Esto es sobre todo ciberseguridad.” No. DORA trata de resiliencia operativa digital. Eso incluye ciberseguridad, claro, pero también gobernanza, continuidad, dependencias tecnológicas, proveedores, reporting y supervisión.

La tercera: “Lo que falta es documental.” A veces sí. Muy a menudo no. En muchas entidades la brecha está en el modelo operativo: quién decide, qué se registra, cómo se prueba, qué depende de quién y cuánto tardas en saberlo cuando algo falla.

Prometer un cierre rápido porque ya existe una certificación suele producir el clásico efecto bumerán regulatorio: tranquilidad al principio, sobresalto al final.

La objeción habitual: “pero ISO 27001 ya cubre casi todo si se implanta bien”

La objeción merece una respuesta seria porque contiene una parte de verdad. Una implantación muy madura de ISO 27001, combinada quizá con otros marcos como ISO 22301, NIST CSF o controles sectoriales internos, puede cubrir una porción relevante del terreno operativo que luego DORA exige. Nadie sensato negaría eso.

El problema está en el “casi”. En cumplimiento regulatorio, casi es una palabra peligrosa. Sobre todo cuando el tramo que falta incluye responsabilidades del órgano de dirección, régimen de terceros ICT, requisitos de testing, clasificación regulatoria de incidentes o obligaciones de documentación y supervisión asociadas a funciones críticas o importantes.

Hay otra trampa en esa objeción: suele hablar del nivel de madurez ideal, no del estado real de las implantaciones. Y entre ambos mundos media un océano. Sobre el papel, el ISMS integra negocio, tecnología, terceros y continuidad. En la práctica, muchas implantaciones viven encapsuladas en seguridad, con mapas de dependencia incompletos, ownership difuso y contratos heredados que nadie querría enseñar en una revisión exhaustiva.

Así que sí: una ISO 27001 excepcionalmente bien implantada puede acercarte mucho. Lo que no permite decir, sin más, es que DORA queda absorbido por el certificado.

Cómo debería enfocar la pregunta una entidad financiera sensata

No preguntes “¿nos vale la ISO?”. Pregunta esto:

• Qué obligaciones de DORA ya podemos evidenciar con artefactos existentes.
• Qué obligaciones requieren rediseño de procesos, no solo documentación adicional.
• Qué decisiones deben subir al órgano de dirección y con qué cadencia.
• Qué dependencias de terceros afectan a funciones críticas o importantes y cómo están registradas.
• Qué parte del programa de pruebas realmente responde al capítulo de testing de DORA.
• Qué incidentes sabríamos clasificar y escalar correctamente hoy, no en una presentación bonita.

Ese cambio de preguntas mejora el diagnóstico de inmediato. Y, de paso, evita el típico proyecto que dedica meses a rehacer políticas con redacción elegante mientras deja intactos los puntos donde después se atasca la evidencia.

Mi lectura: ISO 27001 es una buena base, pero usarla como coartada para DORA es una mala idea

La mejor forma de decirlo quizá sea esta: ISO 27001 puede ser el esqueleto; DORA exige músculos, nervios y reflejos. El estándar ordena la casa. El reglamento quiere comprobar si la casa resiste un golpe, si sabes qué parte se cae primero, qué proveedor arrastra la avería, quién decide, cuándo reportas y cómo recuperas.

Confundir ambos planos no es un error académico. Es un riesgo de ejecución. Porque retrasa inversiones donde hacen falta, genera falsas seguridades ante el consejo y convierte el gap analysis en un ejercicio de autocomplacencia con membrete.

La ironía es que muchas organizaciones ya tienen bastante de lo necesario. Lo que les falta no siempre es control; a menudo es precisión regulatoria, trazabilidad entre piezas y voluntad de aceptar que el certificado no cierra la discusión. Solo la empieza con algo más de orden.

Si tu entidad ya tiene ISO 27001, perfecto: parte con ventaja. Si cree que con eso basta para DORA, no parte con ventaja. Parte con una ilusión cara.

Qué hacer ahora, sin teatro y sin rehacer medio programa desde cero

El enfoque útil no pasa por tirar el ISMS y empezar de nuevo. Pasa por usarlo como base y someterlo a una lectura estrictamente regulatoria. En términos operativos, eso significa revisar el texto de DORA por capítulos y traducir cada obligación relevante en evidencias existentes, evidencias parciales o carencias reales.

Empieza por DORA art. 5 y pregunta si el órgano de dirección puede demostrar, con actas y decisiones, que asume el papel que el reglamento le atribuye. Sigue por el bloque de gestión del riesgo ICT y comprueba si la arquitectura documental del ISMS refleja de verdad identificación, protección, detección, respuesta, recuperación y mejora continua en clave operativa, no solo metodológica. Después ve al art. 28 y siguientes y analiza si tu marco de terceros ICT aguanta una revisión seria sobre estrategia, registro, concentración, contenido contractual y salida.

Haz luego una parada incómoda en el capítulo de pruebas. No des por bueno que tus ejercicios actuales equivalen a lo que DORA pide. Léelos frente al reglamento, no frente a tus hábitos. Y termina con incidentes, continuidad y recuperación, pero haciéndote la pregunta que casi nadie quiere formular en voz alta: si mañana cae un servicio relevante por una dependencia tecnológica externa, sabríamos clasificar el incidente, activar la gobernanza correcta, sostener el servicio y dejar evidencia suficiente de todo ello?

Si la respuesta es “más o menos”, todavía no has llegado. Y “más o menos” es una expresión estupenda para una cena improvisada. Para cumplimiento regulatorio, bastante menos.