Hoja de ruta DORA 2026 para riesgo TIC, proveedores y TLPT

El pánico de búsqueda sobre DORA 2026 no trata realmente de regulación, sino de evidencias

Son las 08:15 de un lunes y el responsable de seguridad de la información (CISO) de una entidad de pagos mediana tiene tres pestañas abiertas en el navegador: “lista de verificación DORA RTS/ITS”, “plantilla de registro de terceros TIC DORA” y “requisitos TLPT para entidades financieras”.

El responsable de Cumplimiento ya ha preguntado si el paquete para el consejo debe incluir el flujo de trabajo más reciente de clasificación de incidentes. Compras quiere incorporar una nueva plataforma de analítica en la nube. El director de Operaciones quiere garantías de que el proveedor SaaS del core bancario no tiene exposición oculta a subcontratistas fuera de la UE. Auditoría interna está solicitando un calendario de pruebas. Legal pregunta si los plazos de notificación de brechas del RGPD de la UE se han alineado con la notificación de incidentes de DORA.

Nadie está planteando una pregunta teórica. Están preguntando: “¿Podemos demostrarlo antes del viernes?”

Ese es el verdadero problema de DORA 2026. La mayoría de las entidades financieras comprenden las obligaciones principales: gestión del riesgo TIC, notificación de incidentes relacionados con las TIC, pruebas de resiliencia operativa digital, gestión del riesgo de terceros TIC y supervisión reforzada de proveedores terceros de servicios de TIC críticos. La parte difícil es convertir las Normas Técnicas de Regulación, las Normas Técnicas de Ejecución y las obligaciones a nivel de artículo en una práctica controlada, repetible y auditable.

El Reglamento de Resiliencia Operativa Digital (DORA) exige que las entidades financieras mantengan capacidades sólidas de gestión del riesgo TIC, políticas para gestionar y notificar incidentes relacionados con las TIC, pruebas de sistemas TIC, controles y procesos, y una supervisión estructurada de proveedores terceros de servicios de TIC. También exige proporcionalidad. Una empresa de inversión más pequeña y un gran grupo bancario no necesitan modelos de evidencia idénticos, pero ambas deben demostrar que su enfoque es adecuado para su tamaño, perfil de riesgo, complejidad y funciones críticas.

Los proyectos DORA suelen fallar por una de tres razones. Primero, la organización trata DORA como un ejercicio de mapeo jurídico en lugar de como un modelo operativo. Segundo, el riesgo de proveedores se documenta como una lista de proveedores y no como dependencia, capacidad de sustitución y riesgo de concentración. Tercero, las pruebas se tratan como una prueba anual de penetración y no como un programa de resiliencia que incluya análisis de vulnerabilidades, pruebas basadas en escenarios, ejercicios de incidentes y, cuando corresponda, pruebas de penetración basadas en amenazas, comúnmente buscadas como TLPT.

Un enfoque mejor consiste en construir un único sistema de evidencias que conecte políticas, registros, responsables, riesgos, incidentes, proveedores, pruebas, recuperación y revisión por la dirección. Ahí es donde Zenith Blueprint de Clarysec, sus políticas listas para usar y Zenith Controls ayudan a las entidades financieras a convertir DORA de una fecha límite en una cadencia operativa.

Empiece por el modelo operativo DORA, no por la hoja de cálculo RTS/ITS

Muchos equipos empiezan con una hoja de cálculo que enumera los artículos de DORA y los requisitos RTS/ITS. Es útil, pero no suficiente. Una hoja de cálculo puede indicar qué debe existir. No asigna responsables, no define la frecuencia de revisión, no preserva evidencias ni demuestra que un control funcione realmente.

En Zenith Blueprint: hoja de ruta de 30 pasos para auditores, Clarysec aborda esta cuestión en la fase de Gestión de riesgos, paso 14, Políticas de tratamiento de riesgos y referencias cruzadas regulatorias:

“DORA: Para las empresas del sector financiero, DORA exige un marco de gestión del riesgo TIC muy alineado con lo que hemos hecho: identificar riesgos, implantar controles (y políticas) y probarlos. DORA también hace hincapié en la respuesta a incidentes y su notificación, así como en la supervisión de proveedores terceros de servicios TIC.”

El mensaje práctico es sencillo: no construya el “cumplimiento de DORA” como una burocracia paralela. Construya una capa de gobernanza TIC basada en riesgos que mapee los requisitos de DORA con políticas, registros, responsables de controles, registros de pruebas, evidencias de proveedores y revisión por la dirección.

Un modelo operativo DORA práctico debe contar con cinco pilares de evidencia:

Para las entidades financieras reguladas, esta estructura convierte la implantación RTS/ITS en un sistema de evidencias preparado para auditoría. Para las entidades sujetas a una gestión simplificada del riesgo TIC, el mismo modelo puede escalarse a menos documentos y registros más sencillos. Las disciplinas esenciales siguen siendo las mismas: identificar, proteger, detectar, responder, recuperar, probar y gobernar proveedores.

Gestión del riesgo TIC: el registro es la sala de control

Las expectativas de DORA en materia de gestión del riesgo TIC exigen que las entidades financieras identifiquen, clasifiquen y gestionen los riesgos TIC en sistemas, datos, procesos, funciones críticas o importantes y dependencias de terceros.

El fallo habitual no es la ausencia de un registro de riesgos. Es que el registro está desconectado de proveedores, activos, incidentes y pruebas. DORA no premia una hoja de cálculo impecable si no puede explicar por qué un proveedor de alto riesgo no tiene plan de salida o por qué una plataforma crítica de pagos de clientes no se ha probado.

La Política de gestión de riesgos para pymes de Clarysec proporciona a las entidades financieras más pequeñas una base concisa de evidencia:

“Cada entrada de riesgo debe incluir: descripción, probabilidad, impacto, puntuación, propietario y plan de tratamiento.”
De la sección “Requisitos de gobernanza”, cláusula de la política 5.1.2.

Para entidades financieras de mayor tamaño, la Política de gestión de riesgos para empresas de Clarysec exige un proceso más formal:

“Debe mantenerse un proceso formal de gestión de riesgos conforme a ISO/IEC 27005 e ISO 31000, que cubra la identificación, el análisis, la evaluación, el tratamiento, la supervisión y la comunicación de riesgos.”
De la sección “Requisitos de gobernanza”, cláusula de la política 5.1.

Esta distinción importa. DORA es proporcional, pero proporcionalidad no significa informalidad. Una pequeña entidad de pagos puede utilizar un registro simplificado, mientras que un grupo bancario puede usar herramientas GRC integradas. En ambos casos, el auditor seguirá preguntando: ¿cuáles son sus riesgos TIC? ¿Quién los acepta? ¿Cuál es el plan de tratamiento? ¿Qué evidencias demuestran el avance? ¿Cómo afectan los proveedores y las funciones críticas a la puntuación?

Un registro sólido de riesgos TIC DORA debe incluir estos campos:

Un ejercicio práctico consiste en tomar un servicio TIC crítico, como una plataforma de monitorización de transacciones alojada en la nube, y crear una entrada de riesgo en 20 minutos. Describa el escenario de fallo o compromiso, puntúe la probabilidad y el impacto, asigne un responsable, identifique los proveedores relacionados, defina un plan de tratamiento y vincule la entrada con evidencias como diligencia debida de proveedores, SLA, cláusulas de incidentes, BIA, resultados de pruebas de DR, paneles de supervisión y revisiones de acceso.

Esa única entrada se convierte en el hilo conductor que conecta la gestión del riesgo TIC de DORA, la supervisión de terceros, la detección de incidentes, la continuidad y las pruebas. Así es como un registro de riesgos se convierte en una sala de control, no en un archivador.

Preparación RTS/ITS: mapee obligaciones con políticas, no con promesas

El término práctico de búsqueda “lista de verificación DORA RTS/ITS” suele significar “¿qué documentos esperarán los supervisores?”. Las entidades financieras deben evitar prometer cumplimiento mediante declaraciones genéricas. Necesitan un mapeo que vincule cada obligación con una política, un control, un responsable y un elemento de evidencia.

La Política de Cumplimiento Legal y Normativo para pymes de Clarysec establece un anclaje sencillo de gobernanza:

“El DG debe mantener un Registro de Cumplimiento simple y estructurado que enumere:”
De la sección “Requisitos de gobernanza”, cláusula de la política 5.1.1.

Para DORA 2026, su registro de cumplimiento debe incluir:

• Obligación DORA o área de requisito RTS/ITS.
• Aplicabilidad, incluida la justificación de proporcionalidad.
• Referencia de política o procedimiento.
• Responsable del control.
• Ubicación de las evidencias.
• Frecuencia de revisión.
• Deficiencias abiertas y fecha límite de remediación.
• Estado de reporte al consejo o a la dirección.

Esto se alinea con el enfoque del paso 14 de Zenith Blueprint: mapear los requisitos regulatorios con controles y políticas del SGSI para que nada quede sin cubrir. En lugar de preguntar “¿cumplimos DORA?”, la dirección puede preguntar “¿qué elementos de evidencia DORA están vencidos, qué proveedores críticos carecen de planes de salida y qué actividades de prueba aún no han generado evidencias de remediación?”.

Riesgo de terceros TIC: concentración, capacidad de sustitución y subcontratistas

DORA ha cambiado la conversación sobre proveedores en los servicios financieros. Ya no basta con preguntar si un proveedor tiene una certificación de seguridad, un seguro o un contrato de encargo de tratamiento. Las entidades financieras deben evaluar si un proveedor genera riesgo de concentración, si puede sustituirse de forma realista, si varios servicios críticos dependen de un mismo proveedor o de proveedores relacionados, y si la subcontratación introduce exposición legal o de resiliencia adicional.

Esta es la cuestión que quita el sueño a muchos CISO. Una entidad puede depender de un gran proveedor de servicios en la nube para el procesamiento de transacciones, la analítica de datos, los portales de clientes y la colaboración interna. Si ese proveedor sufre una indisponibilidad prolongada, una disputa regulatoria o un fallo de un subcontratista, la pregunta no es solo “¿tenemos un contrato?”. La pregunta es “¿podemos continuar los servicios críticos, comunicarnos con los clientes y demostrar que entendíamos la dependencia antes de que fallara?”.

La Política de Seguridad de Terceros y Proveedores para pymes de Clarysec establece la base:

“Debe mantenerse un registro de proveedores y actualizarse por el contacto administrativo o de contratación. Debe incluir:”
De la sección “Requisitos de gobernanza”, cláusula de la política 5.4.

Para programas empresariales, la Política de Gestión del Riesgo de Dependencia de Proveedores de Clarysec profundiza en la dependencia y la capacidad de sustitución específicas de DORA:

“Registro de dependencias de proveedores: la VMO deberá mantener un registro actualizado de todos los proveedores críticos, incluidos detalles como los servicios/productos proporcionados; si el proveedor es de proveedor único; proveedores alternativos disponibles o capacidad de sustitución; términos contractuales vigentes; y una evaluación del impacto si el proveedor fallara o se viera comprometido. El registro deberá identificar claramente a los proveedores con alta dependencia (por ejemplo, aquellos para los que no existe una alternativa rápida).”
De la sección “Requisitos de implantación”, cláusula de la política 6.1.

Esta es la evidencia de proveedores que los proyectos DORA suelen omitir. Un registro de proveedores indica quién es el proveedor. Un registro de dependencias indica qué ocurre cuando el proveedor falla.

Zenith Blueprint, fase de Controles en acción, paso 23, Controles organizativos, proporciona un flujo de trabajo práctico para la supervisión de proveedores. Recomienda recopilar una lista completa de proveedores, clasificarlos en función del acceso a sistemas, datos o control operativo, verificar que las expectativas de seguridad estén incorporadas en los contratos, gestionar el riesgo de subcontratistas y de la cadena descendente, definir procedimientos de cambio y supervisión, y crear un proceso de evaluación de servicios en la nube.

En Zenith Controls: la guía de cumplimiento transversal, el control 5.21 de ISO/IEC 27002:2022, Gestión de la seguridad de la información en la cadena de suministro TIC, se mapea como control preventivo que apoya la confidencialidad, integridad y disponibilidad. Se asocia con la seguridad de la relación con proveedores y el concepto de ciberseguridad Identificar. Conecta con ingeniería segura, codificación segura, control de acceso, pruebas de seguridad, recopilación de evidencias, ciclo de vida de desarrollo seguro y desarrollo externalizado.

Esa es exactamente la realidad de la supervisión de terceros en DORA. El riesgo de proveedores no es solo Compras. Afecta a la arquitectura, el desarrollo, la respuesta a incidentes, el control de acceso, la continuidad del negocio y el ámbito jurídico.

Desde una perspectiva de cumplimiento transversal, Zenith Controls mapea la seguridad de la cadena de suministro TIC con GDPR Article 28 y Article 32 porque los encargados y subencargados del tratamiento deben seleccionarse y supervisarse con medidas técnicas y organizativas adecuadas. Sustenta las expectativas de seguridad de la cadena de suministro de NIS2, incluidas Article 21 sobre medidas de gestión de riesgos de ciberseguridad y Article 22 sobre evaluaciones coordinadas del riesgo de la cadena de suministro. Se mapea de forma sólida con DORA Article 28, Article 29 y Article 30, donde el riesgo de terceros TIC, el riesgo de concentración, la subexternalización y las disposiciones contractuales son centrales.

Las normas de apoyo refuerzan la evidencia. ISO/IEC 27036-3:2021 sustenta la seguridad en la adquisición TIC y la selección de proveedores. ISO/IEC 20243:2018 sustenta la integridad de productos tecnológicos de confianza y la seguridad de la cadena de suministro. ISO/IEC 27001:2022 conecta todo ello con el tratamiento de riesgos y los controles de proveedores del Anexo A.

Notificación de incidentes: construya la cadena de escalado antes del incidente

La notificación de incidentes en DORA no consiste únicamente en enviar una notificación. Consiste en detectar, clasificar, escalar, comunicar y aprender de los incidentes relacionados con las TIC. Las entidades financieras deben mantener procesos de gestión y notificación de incidentes TIC con roles definidos, criterios de clasificación, rutas de notificación y análisis posterior al incidente.

La Política de Respuesta a Incidentes para pymes de Clarysec conecta los tiempos de respuesta con los requisitos legales:

“Los plazos de respuesta, incluidas la recuperación de datos y las obligaciones de notificación, deben documentarse y alinearse con los requisitos legales, como el requisito del RGPD de la UE de notificar las brechas de datos personales en un plazo de 72 horas.”
De la sección “Requisitos de gobernanza”, cláusula de la política 5.3.2.

Para entornos empresariales, la Política de Respuesta a Incidentes de Clarysec añade la perspectiva de escalado de datos regulados:

“Si un incidente da lugar a una exposición confirmada o probable de datos personales u otros datos regulados, Legal y el DPO deben evaluar la aplicabilidad de:”
De la sección “Requisitos de implantación de la política”, cláusula de la política 6.4.1.

La cita termina en el punto de activación, que es exactamente donde fallan muchos procesos de incidentes. Si el desencadenante no está claro, los equipos debaten las obligaciones de notificación mientras el reloj ya corre.

Zenith Blueprint, fase de Controles en acción, paso 16, Controles sobre las personas II, enfatiza la notificación de incidentes impulsada por el personal. Empleados, contratistas y partes interesadas deben saber cómo reconocer y notificar posibles incidentes de seguridad mediante canales sencillos, como un buzón dedicado, un portal o una línea directa. Blueprint lo vincula con GDPR Article 33, NIS2 Article 23 y DORA Article 17 porque la notificación regulatoria empieza con la concienciación interna y el escalado.

En Zenith Controls, el control 5.24 de ISO/IEC 27002:2022, planificación y preparación de la gestión de incidentes de seguridad de la información, se mapea como control correctivo que apoya la confidencialidad, integridad y disponibilidad, alineado con Responder y Recuperar. Se vincula directamente con la evaluación de eventos, el aprendizaje a partir de incidentes, el registro de eventos y la supervisión, la seguridad durante la interrupción, la continuidad de la seguridad de la información y el contacto con autoridades. La guía lo mapea con DORA Article 17 a Article 23 para la gestión, clasificación y notificación de incidentes relacionados con las TIC y la notificación voluntaria de ciberamenazas, GDPR Article 33 y Article 34 para la notificación de brechas, y NIS2 Article 23 para la notificación de incidentes.

Un proceso de incidentes preparado para DORA debe incluir:

• Canales claros de entrada de incidentes.
• Triaje de eventos y criterios de clasificación.
• Flujo de trabajo de escalado de incidentes graves relacionados con las TIC.
• Puntos de decisión jurídica, del DPO y de notificación regulatoria.
• Desencadenantes de notificación de incidentes de proveedores.
• Requisitos de preservación de evidencias.
• Reglas de comunicación a la alta dirección y al consejo.
• Revisión posterior al incidente y lecciones aprendidas.
• Vinculación con actualizaciones del registro de riesgos y remediación de controles.

Las normas de apoyo aportan estructura. ISO/IEC 27035-1:2023 proporciona principios de planificación y preparación para la gestión de incidentes. ISO/IEC 27035-2:2023 detalla los pasos de gestión de incidentes. ISO/IEC 22320:2018 sustenta el mando, el control y la comunicación estructurada de crisis. Esto importa cuando una indisponibilidad TIC se convierte en una crisis con impacto en clientes y la entidad debe demostrar que las decisiones fueron oportunas, coordinadas y basadas en evidencias.

Pruebas de resiliencia operativa digital y TLPT: no permita que la prueba se convierta en el incidente

Las pruebas son uno de los temas más buscados de DORA 2026 porque combinan una fuerte carga técnica y de gobernanza. Las entidades financieras deben probar sistemas TIC, controles y procesos. Para las entidades designadas, las pruebas avanzadas como TLPT se convierten en un requisito central conforme a DORA Article 26.

La pregunta de auditoría no es solo “¿se realizaron pruebas?”. Es “¿la prueba estuvo basada en riesgos, autorizada, fue segura, independiente cuando era exigible, remediada y vinculada a objetivos de resiliencia?”.

La Política de pruebas de seguridad y red teaming para empresas de Clarysec define con claridad el programa mínimo de pruebas:

“Tipos de pruebas: el programa de pruebas de seguridad deberá incluir, como mínimo: (a) escaneos de vulnerabilidades, consistentes en escaneos automatizados semanales o mensuales de redes y aplicaciones para identificar vulnerabilidades conocidas; (b) pruebas de penetración, consistentes en pruebas manuales en profundidad de sistemas o aplicaciones específicos realizadas por probadores cualificados para identificar debilidades complejas; y (c) ejercicios de red teaming, consistentes en simulaciones basadas en escenarios de ataques reales, incluida la ingeniería social y otras tácticas, para probar en conjunto las capacidades de detección y respuesta de la organización.”
De la sección “Requisitos de implantación”, cláusula de la política 6.1.

Este es el puente entre las pruebas rutinarias y la madurez TLPT. Los escaneos de vulnerabilidades detectan debilidades conocidas. Las pruebas de penetración validan la explotabilidad. El red teaming prueba la detección y la respuesta como sistema. TLPT, cuando sea aplicable, debe integrarse dentro de un programa de pruebas gobernado con control de alcance, reglas de seguridad, gestión de riesgos en producción, captura de evidencias y seguimiento de remediación.

Zenith Blueprint, fase de Controles en acción, paso 21, aborda la protección de los sistemas de información durante auditorías y pruebas. Advierte que las auditorías, pruebas de penetración, revisiones forenses y evaluaciones operativas pueden introducir riesgos porque pueden implicar acceso elevado, herramientas intrusivas o cambios temporales en el comportamiento del sistema. Blueprint mapea esta preocupación con GDPR Article 32, las expectativas de DORA sobre pruebas de resiliencia operativa digital, los impactos en la continuidad de las operaciones de NIS2 y las prácticas COBIT 2019 para la ejecución segura de auditorías y evaluaciones.

En Zenith Controls, el control 5.35 de ISO/IEC 27002:2022, revisión independiente de la seguridad de la información, se mapea como preventivo y correctivo, y apoya la confidencialidad, integridad y disponibilidad. Se vincula con el cumplimiento de políticas, las responsabilidades de la dirección, el aprendizaje a partir de incidentes, la protección de registros, la eliminación de información, el registro de eventos y la supervisión. Para DORA, las obligaciones de prueba relevantes son principalmente Article 24 a Article 27, incluido Article 26 para TLPT. Esto también sustenta GDPR Article 32(1)(d), que exige pruebas y evaluación periódicas de las medidas técnicas y organizativas, y NIS2 Article 21, que exige medidas de gestión de riesgos de ciberseguridad.

Un paquete de preparación TLPT para DORA debe incluir:

La lección clave de DORA es que las evidencias de las pruebas no deben terminar en el informe. Los auditores preguntarán si los hallazgos se calificaron por riesgo, se asignaron, se remediaron y se volvieron a probar. También pueden comprobar si las pruebas cubrieron funciones críticas o importantes, y no solo activos expuestos a internet.

Continuidad del negocio y recuperación ante desastres: la resiliencia debe ser operativa

DORA es una regulación de resiliencia operativa digital. La recuperación importa tanto como la prevención. Un marco documentado de riesgo TIC no ayudará si una indisponibilidad de una plataforma de pagos revela que los objetivos de tiempo de recuperación nunca se probaron, los árboles de contacto de proveedores están desactualizados y el equipo de crisis no se pone de acuerdo sobre quién comunica a los clientes.

La Política de Continuidad del Negocio y Recuperación ante Desastres para pymes de Clarysec establece una base clara:

“La organización debe probar tanto su BCP como sus capacidades de DR al menos una vez al año. Las pruebas deben incluir:”
De la sección “Requisitos de implantación de la política”, cláusula de la política 6.4.1.

La Política de Continuidad del Negocio y Recuperación ante Desastres para empresas comienza con el impacto en la organización:

“El análisis de impacto en el negocio (BIA) deberá realizarse al menos una vez al año para todas las unidades críticas de la organización y revisarse ante cambios significativos en sistemas, procesos o dependencias. Los resultados del BIA deberán definir:”
De la sección “Requisitos de gobernanza”, cláusula de la política 5.2.

Para DORA, el BIA debe conectarse con activos TIC, proveedores, respuesta a incidentes y pruebas. Si el BIA identifica “pagos de clientes” como función crítica, el registro de dependencias de proveedores debe identificar los encargados, servicios en la nube y proveedores de red que la soportan. El registro de riesgos debe incluir escenarios de fallo. El plan de pruebas debe incluir validación de resiliencia. El Plan de Respuesta a Incidentes debe incluir escalado y comunicación. La prueba de DR debe generar evidencias, no solo una nota de reunión.

Esta trazabilidad es lo que convierte el cumplimiento de DORA en un sistema de resiliencia operativa.

Cumplimiento transversal: un conjunto de evidencias, muchas preguntas de auditoría

Las entidades financieras rara vez se enfrentan solo a DORA. Suelen tener obligaciones del RGPD de la UE, exposición a NIS2, compromisos contractuales de seguridad, objetivos de ISO/IEC 27001:2022, requisitos de auditoría interna, diligencia debida de clientes, expectativas SOC e informes de riesgo al consejo. La respuesta no es crear silos de evidencias separados. La respuesta es construir un modelo de evidencias de cumplimiento transversal.

Zenith Controls es la brújula de cumplimiento transversal de Clarysec. No inventa obligaciones nuevas. Mapea normas y marcos oficiales para que las organizaciones comprendan cómo un área de control apoya varios resultados de cumplimiento.

Esto importa para el presupuesto y la gobernanza. Un CISO puede explicar al consejo que mejorar la clasificación de incidentes apoya la notificación DORA, la notificación de brechas del RGPD de la UE, la gestión de incidentes NIS2 y la resiliencia interna. Un responsable de Compras puede justificar el mapeo de dependencias de proveedores porque apoya el riesgo de concentración DORA, la diligencia debida de encargados conforme al RGPD de la UE y la seguridad de la cadena de suministro NIS2. Un responsable de pruebas puede demostrar que los ejercicios de red team y las revisiones independientes apoyan las pruebas DORA, la evaluación de controles del RGPD de la UE y un aseguramiento más amplio.

Perspectiva de auditoría: cómo evaluarán los asesores sus evidencias DORA

La preparación ante DORA se vuelve real cuando alguien solicita evidencias. Auditores y evaluadores distintos abordarán el mismo tema desde ángulos diferentes.

Un auditor orientado a ISO/IEC 27001:2022 comenzará con la lógica del SGSI: alcance, evaluación de riesgos, tratamiento de riesgos, aplicabilidad de controles del Anexo A, auditoría interna, revisión por la dirección y evidencias de que los controles están implantados. Para la seguridad de la cadena de suministro TIC, revisará políticas, clasificación de proveedores, cláusulas contractuales, diligencia debida y supervisión continua. Para la gestión de incidentes, inspeccionará el plan, roles, rutas de escalado, herramientas y registros. Para las pruebas, esperará intervalos planificados, independencia cuando proceda, remediación y entradas para la revisión por la dirección.

Una perspectiva de auditoría ISO/IEC 19011:2018 se centra en la ejecución de la auditoría. En Zenith Controls, la metodología de auditoría para la seguridad de la cadena de suministro TIC señala que los auditores examinan políticas de adquisición, plantillas de RFP y procesos de gestión de proveedores para verificar que los requisitos de seguridad específicos de TIC estén incorporados desde la adquisición hasta la eliminación. Para la gestión de incidentes, los auditores examinan el Plan de Respuesta a Incidentes en cuanto a completitud y alineación con buenas prácticas. Para la revisión independiente, buscan evidencias de que se han realizado auditorías o revisiones independientes.

Una perspectiva ISO/IEC 27007:2020 es más específica de auditoría del SGSI. Zenith Controls señala que los auditores pueden entrevistar a responsables de contratación, personal de seguridad de TI y responsables de proveedores para evaluar la comprensión y ejecución de los controles de la cadena de suministro TIC. Para la preparación de incidentes, confirman que existe un equipo de respuesta a incidentes y que está operativo. Para la revisión independiente, verifican que el programa de auditoría interna cubra todo el alcance del SGSI y cuente con recursos adecuados.

Un evaluador de pruebas informado por NIST SP 800-115 se centrará en la metodología de evaluación de vulnerabilidades y pruebas de penetración. Puede examinar si el alcance de las pruebas, las reglas de actuación, los hallazgos, la clasificación de severidad, la remediación y las repruebas están documentados. Para TLPT de DORA, esto significa que el evaluador no se conformará con una presentación de red team. Querrá prueba de gobernanza, seguridad, profundidad técnica y cierre.

Un auditor de estilo COBIT 2019 o ISACA preguntará si se cumplen los objetivos de gobernanza: quién es propietario del proceso, cómo se mide el desempeño, cómo se aprueban las excepciones y cómo recibe aseguramiento la dirección.

La lista de verificación práctica de preparación DORA 2026

Utilice esta lista como base de trabajo para convertir las búsquedas sobre DORA en acciones.

Gobernanza y mapeo RTS/ITS

• Mantenga un registro de cumplimiento DORA con área de obligación, aplicabilidad, responsable, evidencias, frecuencia de revisión y estado de deficiencias.
• Mapee los requisitos de DORA con políticas, registros, controles e informes a la dirección.
• Defina la justificación de proporcionalidad para la gestión simplificada o escalada del riesgo TIC cuando sea aplicable.
• Asigne responsabilidad ejecutiva para el riesgo TIC, la notificación de incidentes, la supervisión de terceros y las pruebas.
• Incluya el estado DORA en la revisión por la dirección y en los informes de riesgo al consejo.

Gestión del riesgo TIC

• Mantenga un registro de riesgos TIC con descripción, probabilidad, impacto, puntuación, responsable y plan de tratamiento.
• Vincule los riesgos con funciones críticas o importantes.
• Vincule los riesgos con activos TIC, proveedores y procesos.
• Revise los riesgos tras incidentes graves, cambios de proveedores, cambios tecnológicos o hallazgos de pruebas.
• Realice el seguimiento de las acciones de tratamiento hasta su cierre o aceptación formal del riesgo.

Supervisión de terceros TIC

• Mantenga un registro de proveedores y un registro de dependencias de proveedores.
• Identifique los proveedores que soportan funciones críticas o importantes.
• Evalúe proveedores de proveedor único y capacidad de sustitución.
• Revise subcontratistas y acuerdos de subexternalización.
• Incorpore cláusulas de seguridad, acceso, notificación de incidentes, auditoría y salida en los contratos.
• Supervise a los proveedores críticos al menos una vez al año o tras cambios materiales.
• Mantenga planes de salida y contingencia para proveedores con alta dependencia.

Gestión y notificación de incidentes

• Mantenga procedimientos de gestión de incidentes con roles y rutas de escalado claros.
• Defina criterios de clasificación de incidentes TIC.
• Alinee los desencadenantes de notificación DORA con el RGPD de la UE, NIS2 y las obligaciones contractuales de notificación.
• Forme a empleados y contratistas sobre los canales de notificación de incidentes.
• Mantenga registros de incidentes, registros de decisiones y evidencias.
• Realice revisiones posteriores al incidente y actualice riesgos y controles.

Pruebas, red teaming y TLPT

• Mantenga un calendario de pruebas basado en riesgos.
• Realice escaneos de vulnerabilidades y pruebas de penetración a intervalos definidos.
• Use ejercicios de red team basados en escenarios para probar la detección y la respuesta.
• Para la preparación TLPT, defina alcance, reglas de actuación, controles de seguridad y coordinación con proveedores.
• Proteja los sistemas de producción durante las pruebas.
• Realice seguimiento de hallazgos, remediación, repruebas y lecciones aprendidas.
• Informe los resultados de las pruebas a la dirección.

Continuidad y recuperación

• Realice un BIA anual para unidades críticas de la organización y actualícelo tras cambios significativos.
• Defina objetivos de recuperación para funciones críticas y servicios TIC de soporte.
• Pruebe las capacidades de BCP y DR al menos una vez al año.
• Incluya escenarios de indisponibilidad de proveedores e incidente cibernético.
• Preserve evidencias de pruebas, deficiencias, acciones de remediación y resultados de repruebas.
• Alinee los planes de continuidad con la respuesta a incidentes y las comunicaciones de crisis.

Cómo ayuda Clarysec a las entidades financieras a pasar de resultados de búsqueda a evidencias preparadas para auditoría

La preparación DORA 2026 no se logra descargando una lista de verificación y esperando que la organización pueda cubrir las deficiencias más adelante. Requiere un modelo operativo estructurado que conecte riesgo, proveedores, incidentes, pruebas, continuidad y evidencias de auditoría.

El enfoque de Clarysec combina tres capas.

Primero, Zenith Blueprint proporciona la hoja de ruta de implantación. El paso 14 ayuda a las organizaciones a establecer referencias cruzadas entre requisitos regulatorios, tratamiento de riesgos y políticas. El paso 16 refuerza la notificación de incidentes impulsada por el personal. El paso 21 asegura que las auditorías y pruebas no pongan en peligro los sistemas de producción. El paso 23 convierte la supervisión de proveedores en un flujo de trabajo práctico que cubre clasificación, contratos, subcontratistas, supervisión y evaluación de la nube.

Segundo, las políticas de Clarysec proporcionan una gobernanza lista para operar. La Política de gestión de riesgos, la Política de Cumplimiento Legal y Normativo, la Política de Seguridad de Terceros y Proveedores, la Política de Gestión del Riesgo de Dependencia de Proveedores, la Política de Respuesta a Incidentes, la Política de pruebas de seguridad y red teaming y la Política de Continuidad del Negocio y Recuperación ante Desastres ofrecen a los equipos cláusulas concretas, modelos de responsabilidad y expectativas de evidencia.

Tercero, Zenith Controls proporciona el mapa de cumplimiento transversal. Muestra cómo la seguridad de la cadena de suministro TIC, la planificación de la gestión de incidentes y la revisión independiente se conectan con DORA, el RGPD de la UE, NIS2, ISO/IEC 27001:2022, ISO/IEC 27002:2022, ISO/IEC 27035, ISO/IEC 27036, ISO/IEC 22320, ISO/IEC 20243, COBIT 2019 y las prácticas de pruebas de NIST.

El resultado es un programa de cumplimiento DORA defendible en auditoría y útil durante un incidente real, un fallo de proveedor o una prueba de resiliencia.

Siguiente paso: construya su paquete de evidencias DORA antes de la próxima solicitud de auditoría

Si su equipo sigue buscando “lista de verificación DORA RTS/ITS”, “plantilla de gestión del riesgo TIC DORA”, “supervisión de terceros DORA” o “requisitos TLPT DORA”, el siguiente paso es convertir esas búsquedas en evidencias controladas.

Empiece esta semana con cuatro acciones:

1. Cree o actualice su registro de cumplimiento DORA utilizando el modelo de políticas de Clarysec.
2. Seleccione una función crítica y trace su recorrido por el registro de riesgos, el registro de dependencias de proveedores, el flujo de trabajo de incidentes, el BIA y el plan de pruebas.
3. Revise sus cinco principales proveedores TIC en cuanto a capacidad de sustitución, subcontratistas, cláusulas de incidentes y opciones de salida.
4. Construya un paquete de evidencias de pruebas con alcance, autorización, resultados, remediación y repruebas.

Clarysec puede ayudarle a implantarlo mediante Zenith Blueprint, plantillas de políticas y Zenith Controls, de modo que su programa DORA 2026 sea práctico, proporcionado y preparado para auditoría.