Programa de pruebas de DORA: mapeo de pruebas a ISO 27001

Es febrero de 2026. El CISO de una entidad de pagos de tamaño medio tiene una reunión del consejo de administración en dos días, una auditoría de seguimiento de ISO/IEC 27001:2022 en seis semanas y un requerimiento del supervisor de DORA en el buzón de cumplimiento.

El regulador no solicita una estrategia de ciberseguridad brillante. El requerimiento es práctico:

• Proporcione su programa de pruebas de resiliencia operativa digital de 2026.
• Muestre qué pruebas cubren funciones críticas o importantes.
• Demuestre cómo se remedian y se vuelven a probar los hallazgos.
• Aporte evidencias de la supervisión del órgano de dirección.
• Explique cómo se incluyen los proveedores terceros de servicios de TIC.
• Proporcione registros de evaluaciones de vulnerabilidades, pruebas basadas en escenarios, pruebas de rendimiento y capacidad, y pruebas de penetración.

El CISO abre cuatro carpetas. Los escaneos de vulnerabilidades están en el sistema de tickets del SOC. Las notas del ejercicio de mesa están en una unidad compartida. Los resultados de las pruebas de carga pertenecen a ingeniería. Los informes de pruebas de penetración están en el repositorio restringido del departamento jurídico. El seguimiento de la remediación está dividido entre Jira, correo electrónico y una hoja de cálculo creada para la auditoría ISO del año pasado.

Nada es falso. Gran parte del trabajo es correcto. Pero todavía no es un programa de pruebas de resiliencia operativa digital de DORA gobernado. Es una colección de pruebas.

Esa diferencia importa en 2026. DORA se aplica desde el 17 de enero de 2025 y establece un marco uniforme de la UE para la resiliencia operativa digital en materia de gestión del riesgo de las TIC, notificación de incidentes, pruebas de resiliencia, intercambio de información sobre ciberamenazas y vulnerabilidades, gestión del riesgo de terceros de TIC, requisitos contractuales y supervisión de proveedores terceros críticos de servicios de TIC. Cubre una amplia gama de entidades financieras, incluidas entidades de crédito, entidades de pago, empresas de servicios de inversión, proveedores de servicios de criptoactivos, entidades aseguradoras y otras entidades reguladas. DORA también actúa como el acto jurídico sectorial de la Unión para las entidades financieras que, de otro modo, estarían sujetas a obligaciones equivalentes de ciberseguridad de NIS2.

La cuestión práctica para los consejos de administración, CISO, responsables de cumplimiento y proveedores de TIC ya no es si se realizan pruebas. La cuestión es si las pruebas están planificadas, basadas en riesgos, evidenciadas, remediadas, revisadas y son reutilizables en DORA e ISO/IEC 27001:2022.

El modelo operativo de Clarysec está diseñado para este problema exacto. Mediante Zenith Blueprint: hoja de ruta de 30 pasos para auditores, la suite de políticas de Clarysec alineada con ISO y Zenith Controls: la guía de cumplimiento transversal, las organizaciones pueden convertir actividades de resiliencia dispersas en un catálogo anual de pruebas controlado que satisfaga a supervisores, auditores, clientes y consejos de administración.

Por qué DORA convierte las pruebas en una cuestión de gobernanza

DORA es explícito respecto de la responsabilidad de la alta dirección. El artículo 5 asigna al órgano de dirección la responsabilidad de la gestión del riesgo de las TIC. El artículo 6 exige un marco de gestión del riesgo de las TIC sólido, integral y bien documentado, integrado en el sistema general de gestión de riesgos de la organización. El artículo 4 añade la proporcionalidad, lo que implica que los requisitos deben aplicarse en función del tamaño, el perfil de riesgo global y la naturaleza, escala y complejidad de los servicios, actividades y operaciones.

Esto convierte las pruebas de resiliencia operativa digital en algo más que una tarea técnica. Se convierten en evidencias de que el órgano de dirección comprende el riesgo, ha aprobado una estrategia, recibe información relevante e impulsa la remediación.

ISO/IEC 27001:2022 utiliza una lógica similar de sistema de gestión. Las cláusulas 4.1 a 4.4 exigen que la organización comprenda el contexto, las partes interesadas, las obligaciones legales y contractuales, el alcance, las interfaces y las dependencias. Las cláusulas 5.1 a 5.3 exigen liderazgo, alineación de políticas, recursos, comunicación, responsabilidades asignadas e información a la alta dirección. La cláusula 6.1 exige evaluación de riesgos de seguridad de la información y tratamiento de riesgos.

Por tanto, un programa de pruebas de DORA debe conectar:

• Servicios de la organización y funciones críticas o importantes
• Activos de TIC, datos y dependencias de terceros
• Evaluación de riesgos, responsables del riesgo y planes de tratamiento
• Tipos de prueba, frecuencia y desencadenantes
• Autorización, independencia y reglas de actuación
• Hallazgos, plazos de remediación y repetición de pruebas
• Conservación de evidencias y control de acceso
• Información a la dirección y mejora continua

Para entidades financieras más pequeñas o de menor riesgo, el artículo 16 prevé un marco simplificado de gestión del riesgo de las TIC, pero simplificado no significa informal. Incluso los programas escalados siguen necesitando gestión del riesgo de las TIC documentada, supervisión, sistemas resilientes, identificación de fuentes de riesgo de TIC y anomalías, dependencias clave de terceros de TIC, medidas de continuidad y recuperación, pruebas periódicas y lecciones aprendidas.

En otras palabras, DORA no premia el volumen de pruebas. Premia las pruebas gobernadas y basadas en riesgos que acreditan la resiliencia de los servicios que más importan.

¿Qué debe incluir un programa de pruebas de DORA para 2026?

Un programa maduro de pruebas de DORA debe operar como un catálogo anual de pruebas. No debe limitarse a una única prueba de penetración anual ni a un conjunto de exportaciones de escaneos de vulnerabilidades. Debe incluir pruebas básicas y avanzadas, planificadas en función del riesgo, la criticidad del servicio, las obligaciones regulatorias, las dependencias de proveedores, los cambios mayores y los hallazgos previos.

El artículo 24 de DORA establece el programa de pruebas de resiliencia operativa digital. El artículo 25 describe una gama de pruebas, incluidas evaluaciones y escaneos de vulnerabilidades, análisis de fuentes abiertas, evaluaciones de seguridad de red, análisis de brechas, revisiones de seguridad física, cuestionarios, soluciones de escaneo mediante software, revisiones de código fuente cuando sea viable, pruebas basadas en escenarios, pruebas de compatibilidad, pruebas de rendimiento, pruebas de extremo a extremo y pruebas de penetración. El artículo 26 añade pruebas de penetración basadas en amenazas para entidades financieras identificadas por las autoridades competentes.

Para la mayoría de las organizaciones, el catálogo práctico se construye en torno a cuatro familias de pruebas.

La Política de pruebas de seguridad y red teaming de Clarysec proporciona un anclaje sólido de política para este catálogo:

“Tipos de pruebas: el programa de pruebas de seguridad debe incluir, como mínimo: (a) escaneo de vulnerabilidades, consistente 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 por parte de evaluadores 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.”

La misma política exige una programación periódica:

“Calendario de pruebas: la organización debe realizar pruebas de seguridad con una periodicidad regular. Los sistemas clave expuestos a internet y las aplicaciones internas críticas deben someterse a pruebas de penetración al menos una vez al año. Los cambios de alto riesgo, como el despliegue de un nuevo sistema crítico o actualizaciones mayores, requieren pruebas ad hoc antes y/o poco después de la entrada en producción.”

Esto es crítico para DORA. Un plan anual estático no es suficiente si la entidad despliega una nueva pasarela de pagos, migra un sistema esencial a la nube, cambia de proveedor de servicios gestionados o publica un nuevo flujo de autenticación de clientes. Los cambios de alto riesgo deben activar pruebas adicionales.

Construir el catálogo anual de pruebas como fuente única de la verdad

La forma más eficiente de satisfacer DORA e ISO/IEC 27001:2022 es crear un único catálogo anual de pruebas controlado. Puede residir en una plataforma GRC, en un flujo de trabajo de tickets o en una hoja de cálculo controlada. El formato importa menos que la trazabilidad.

Cada prueba debe responder cinco preguntas de auditoría:

1. ¿Qué servicio, activo, proveedor, aplicación o proceso se probó?
2. ¿Qué riesgo, obligación o requisito de control activó la prueba?
3. ¿Quién autorizó y ejecutó la prueba?
4. ¿Qué hallazgos fueron identificados, aceptados, remediados o diferidos?
5. ¿Qué evidencia demuestra que la prueba se realizó y que el resultado fue revisado?

Un catálogo práctico al estilo Clarysec incluye estos campos.

La Política de auditoría y supervisión del cumplimiento para pymes de Clarysec proporciona una regla de gobernanza concisa que encaja con esta estructura:

“Cada auditoría debe incluir un alcance definido, objetivos, personal responsable y evidencias requeridas.”

Aunque está escrita para auditorías, la misma regla debe aplicarse a las pruebas de resiliencia. Si un escaneo de vulnerabilidades, un ejercicio de mesa, una simulación de conmutación por error o una prueba de penetración no tiene alcance, objetivo, propietario y evidencias requeridas definidos, será débil tanto bajo el escrutinio de DORA como en una auditoría ISO.

La misma política establece:

“Las evidencias deben conservarse durante al menos dos años, o durante más tiempo cuando lo exijan la certificación o los acuerdos con clientes.”

Para entidades financieras reguladas por DORA y proveedores de TIC, dos años deben tratarse como un mínimo. Las obligaciones contractuales, las expectativas supervisoras, los ciclos de certificación y las investigaciones de incidentes pueden requerir una conservación más prolongada.

Mapear los tipos de prueba de DORA a evidencias ISO 27001

La ventaja de un programa integrado es que una prueba puede satisfacer múltiples obligaciones. La clave consiste en etiquetar correctamente las evidencias y conectarlas con el SGSI.

El Zenith Blueprint lo explica en la fase de auditoría, revisión y mejora, Paso 24:

“Su SoA debe ser coherente con su Registro de Riesgos y su Plan de Tratamiento de Riesgos. Compruebe de nuevo que cada control elegido como tratamiento del riesgo esté marcado como “Aplicable” en la SoA.”

Para un programa de pruebas de DORA, el catálogo de pruebas se convierte en el puente entre el tratamiento de riesgos y las evidencias operativas. La Declaración de Aplicabilidad no debe indicar que un control aplica mientras las evidencias de prueba se encuentran en otro lugar, sin mapear y sin gestionar.

Esta tabla ayuda a un CISO a responder la pregunta habitual del Director General: “¿Son suficientes nuestras pruebas de penetración y escaneos de vulnerabilidades de ISO para DORA?”

La respuesta es: pueden formar parte del cumplimiento de DORA, pero solo si están basadas en riesgos, vinculadas a funciones críticas o importantes, gobernadas por una política, seguidas hasta la remediación e informadas a la dirección.

Evaluaciones de vulnerabilidades: evidencias continuas, no solo resultados de escaneo

La evaluación de vulnerabilidades suele ser la actividad de pruebas más fácil de ejecutar y la más fácil de gestionar mal. Muchas organizaciones pueden generar informes de escaneo. Menos pueden demostrar que los escaneos cubren los activos adecuados, priorizan los servicios críticos, generan remediación oportuna y alimentan las decisiones de tratamiento de riesgos.

La Política de gestión de vulnerabilidades y parches para pymes de Clarysec empieza con el objetivo correcto:

“Identificar y evaluar vulnerabilidades conocidas en todos los activos de TI de forma oportuna y coherente”

Para DORA, esto respalda la identificación de fuentes de riesgo de TIC, sistemas resilientes y actualizados, supervisión, detección de anomalías y mejora continua. Para ISO/IEC 27001:2022, se mapea directamente a 8.8 Gestión de vulnerabilidades técnicas, y también se apoya en 5.9 Inventario de información y otros activos asociados, 8.16 Actividades de supervisión y 8.32 Gestión de cambios.

Un registro sólido de evaluación de vulnerabilidades debe incluir:

• Instantánea del inventario de activos utilizada para delimitar el alcance
• Fecha de escaneo, herramienta y método autenticado o no autenticado
• Exclusiones y justificación de negocio
• Hallazgos por severidad, explotabilidad y servicio de la organización
• Mapeo a funciones críticas o importantes y tipos de datos
• Referencias de tickets y responsable del riesgo
• SLA de remediación y fecha límite
• Resultado de repetición de prueba
• Excepciones con aprobación del riesgo residual

Zenith Controls posiciona 8.8 Gestión de vulnerabilidades técnicas como un área central de evidencias para la identificación, evaluación, priorización y seguimiento de la remediación. También muestra por qué los auditores probarán procesos adyacentes. Si el inventario de activos está incompleto, la cobertura de vulnerabilidades es incompleta. Si se elude la gestión de cambios, el despliegue de parches puede crear nuevo riesgo operativo. Si la supervisión es débil, los intentos de explotación pueden no detectarse.

Pruebas de escenarios: demostrar la toma de decisiones antes del incidente real

Las pruebas basadas en escenarios son donde la resiliencia operativa se hace visible para la alta dirección. Un ejercicio de mesa sobre ransomware, una simulación de indisponibilidad de una región en la nube, un ejercicio de compromiso de acceso privilegiado o un escenario de fallo de un proveedor crítico de TIC revelarán debilidades que un escaneo no puede detectar.

Los artículos 17 a 20 de DORA exigen un ciclo de vida formal de incidentes relacionados con las TIC: detectar, gestionar, notificar, registrar, supervisar, tratar, hacer seguimiento, documentar la causa raíz, remediar, clasificar la severidad, asignar roles, escalar incidentes graves e informar en las fases requeridas. Cuando se vean afectados los intereses financieros de los clientes, estos deben ser informados sin demora indebida.

NIS2 tiene una urgencia similar para las entidades dentro de su alcance, incluida alerta temprana, notificación, informes intermedios e informe final. Para las entidades financieras dentro del alcance, DORA es el acto jurídico sectorial para obligaciones equivalentes de gestión del riesgo de ciberseguridad y notificación. Los proveedores de TIC, plataformas SaaS, MSP y MSSP aún deben comprobar si están directamente dentro del alcance de NIS2 o si quedan incorporados contractualmente al aseguramiento DORA por clientes regulados.

El Zenith Blueprint, fase controles en acción, Paso 23, ofrece el modelo práctico de evidencias:

“Seleccione un evento reciente o realice un ejercicio de mesa para validar su plan. Capture y registre todas las decisiones, roles y comunicaciones (5.26), y actualice el plan con las lecciones aprendidas (5.27).”

Una prueba basada en escenarios de DORA debe producir registros auditables, no solo notas de reunión:

• Resumen del escenario y objetivos
• Participantes y roles, incluidos Jurídico, Comunicaciones, TI, SOC, propietario del servicio y contactos de proveedores
• Cronología de inyecciones y decisiones
• Decisión de clasificación y análisis de umbrales de notificación
• Borradores de comunicaciones internas y externas
• Acciones de preservación de evidencias
• Lecciones aprendidas
• Responsables de acciones y fechas límite
• Procedimientos de incidentes, continuidad o comunicación actualizados

La Política de continuidad del negocio y recuperación ante desastres para pymes de Clarysec refuerza la expectativa de pruebas anuales:

“La organización debe probar tanto sus capacidades de BCP como de DR al menos una vez al año. Las pruebas deben incluir:”

El catálogo de pruebas debe traducir esa obligación en ejercicios específicos, como ejercicio de mesa de gestión de crisis, prueba de restauración de copias de seguridad, prueba de conmutación por error en la nube, prueba del árbol de contactos y simulación de interrupción de proveedores.

Pruebas de rendimiento, capacidad y recuperación: la evidencia de resiliencia desatendida

Las pruebas de rendimiento se tratan a menudo como una cuestión de ingeniería. Bajo DORA, se convierten en evidencia de resiliencia.

Una plataforma de negociación, un servicio de pagos, un sistema de siniestros, una plataforma de identidad o un portal de clientes no necesita un ciberataque para fallar a los clientes. El agotamiento de capacidad, la saturación de colas, los cuellos de botella de bases de datos, el autoescalado mal configurado o una conmutación por error defectuosa pueden crear la misma interrupción operativa que un incidente de seguridad.

ISO/IEC 27001:2022 Anexo A 8.6 Gestión de capacidad es el anclaje principal. Las evidencias pueden incluir pruebas de carga, pruebas de estrés, pruebas de degradación del servicio, validación de umbrales de infraestructura, pruebas de restauración de copias de seguridad y simulaciones de conmutación por error.

Un buen registro de prueba de rendimiento y capacidad debe capturar:

• Supuestos de carga normal de referencia y carga pico
• Recorridos críticos de transacciones probados
• Límites de infraestructura y nube probados
• Paneles de supervisión y umbrales de alerta
• Modos de fallo, como saturación de colas o cuellos de botella de bases de datos
• Relevancia de RTO y RPO cuando se prueba conmutación por error o recuperación
• Impacto en las operaciones de la organización si se superan los umbrales
• Acciones de remediación, decisiones de escalado o cambios de arquitectura
• Aceptación por la dirección del riesgo residual de capacidad

El Zenith Blueprint, Paso 23, conecta las expectativas de recuperación con las evidencias:

“Verifique que los Objetivos de Tiempo de Recuperación (RTO) y los Objetivos de Punto de Recuperación (RPO) de los sistemas críticos estén alineados con las expectativas de continuidad del negocio (5.30). Realice al menos una prueba técnica de recuperación o simulación de conmutación por error y documente los resultados.”

Esa es la diferencia entre decir “tenemos copias de seguridad” y demostrar que un servicio crítico fue restaurado dentro de la tolerancia acordada, con resultados documentados y visibilidad de la dirección.

Pruebas de penetración y red teaming: la evidencia sólida necesita un control sólido

Las pruebas de penetración son evidencias de gran valor, pero también conllevan riesgo operativo. Las pruebas mal gobernadas pueden afectar a sistemas de producción, exponer datos sensibles, activar alarmas no controladas, crear problemas legales o interrumpir a los clientes.

La Política de requisitos de seguridad de las aplicaciones para pymes establece una puerta clara de liberación:

“Antes del despliegue, todas las aplicaciones deben someterse a pruebas de seguridad para verificar las características de referencia enumeradas anteriormente.”

Para aplicaciones críticas, esto debe alimentar el catálogo DORA como pruebas de seguridad en preproducción, validación posterior a la entrada en producción para cambios de alto riesgo y pruebas de penetración periódicas basadas en exposición y criticidad.

La Política de pruebas de seguridad y red teaming refuerza la cadena de remediación:

“Remediación de hallazgos: todas las vulnerabilidades o debilidades identificadas deben documentarse en un informe de hallazgos con clasificaciones de severidad. Tras la recepción del informe, los propietarios de sistemas son responsables de crear un plan de remediación con fechas límite; por ejemplo, los hallazgos críticos deberán remediarse en un plazo de 30 días y los hallazgos de alta severidad en un plazo de 60 días, de acuerdo con la Política de gestión de vulnerabilidades y parches de la organización. El STC debe realizar el seguimiento del avance de la remediación. Se realizarán nuevas pruebas para confirmar que los problemas críticos se han resuelto o mitigado adecuadamente.”

La misma política define las expectativas de informe:

“Informes: se emitirá un informe formal al cierre de cada prueba. Para las pruebas de penetración, el informe debe incluir un resumen ejecutivo, la metodología y hallazgos detallados con evidencias de respaldo y recomendaciones.”

El Zenith Blueprint, Paso 21, también destaca la protección durante auditorías y pruebas:

“Ninguna prueba o auditoría debe proceder sin aprobación documentada de los propietarios de sistemas o de las partes interesadas pertinentes.”

Las reglas de actuación, ventanas de prueba, contactos de emergencia, acceso temporal, manejo de datos, registro de eventos, procedimientos de reversión y aprobaciones legales no son burocracia. Son salvaguardas de resiliencia.

Incluir a los proveedores terceros de servicios de TIC antes de que falle la prueba

DORA convierte el riesgo de terceros de TIC en una cuestión central de resiliencia. El artículo 28 exige que las entidades financieras gestionen el riesgo de terceros de TIC dentro del marco de gestión del riesgo de las TIC, sigan siendo responsables cuando utilicen servicios de TIC, mantengan un registro de información, notifiquen determinados acuerdos, realicen evaluaciones precontractuales y utilicen proveedores que cumplan estándares adecuados de seguridad de la información. Los artículos 29 y 30 abordan el riesgo de concentración, la subcontratación, la recuperación de datos, las protecciones contractuales, los niveles de servicio, la asistencia ante incidentes, los derechos de auditoría, las pruebas de contingencia de proveedores, la participación en pruebas cuando proceda y los acuerdos de salida.

ISO/IEC 27001:2022 Anexo A proporciona controles de proveedores de apoyo, incluidos 5.19 Seguridad de la información en las relaciones con proveedores, 5.20 Tratamiento de la seguridad de la información en los acuerdos con proveedores, 5.21 Gestión de la seguridad de la información en la cadena de suministro de TIC, 5.22 Supervisión, revisión y gestión de cambios de los servicios de proveedores y 5.23 Seguridad de la información para el uso de servicios en la nube.

Un catálogo de pruebas de DORA debe identificar qué pruebas requieren participación de proveedores o evidencias de proveedores. Algunos ejemplos son:

• Supuestos de conmutación por error del proveedor de nube
• Escalado del SOC gestionado y preservación de evidencias
• Comunicación de incidentes de plataforma bancaria esencial
• Escenario de indisponibilidad del procesador de pagos
• Prueba de recuperación del proveedor de identidad
• Atestaciones de pruebas de penetración del proveedor SaaS
• Evaluación de impacto de la cadena de subcontratistas críticos

Un programa que excluye a los proveedores críticos de TIC fallará la prueba de realidad. El servicio orientado al cliente puede ser suyo, pero la dependencia de resiliencia puede estar en una región de nube, un SOC externalizado, un proveedor de identidad, un proveedor de software, un procesador de pagos o un centro de datos.

Mapeo de cumplimiento transversal: un conjunto de evidencias, muchas obligaciones

Un programa de pruebas de DORA bien diseñado reduce la fatiga de auditoría. Las mismas evidencias pueden respaldar revisiones de gobernanza de DORA, ISO/IEC 27001:2022, NIS2, GDPR, NIST CSF 2.0 y COBIT 2019 si se etiquetan, conservan e informan correctamente.

GDPR no debe olvidarse. Si las pruebas de resiliencia implican datos personales, registros de eventos, registros de clientes, datos de identidad, registros de Recursos Humanos, biometría o datos de categorías especiales, la organización debe respetar los principios de GDPR, incluida la licitud, lealtad, transparencia, minimización de datos, limitación del plazo de conservación, integridad, confidencialidad y responsabilidad proactiva. Las copias de datos de prueba, los registros de eventos exportados y las evidencias de pruebas de penetración pueden convertirse en repositorios de datos regulados. El programa de pruebas debe definir quién puede acceder a ellos, cuánto tiempo se conservan y cómo se eliminan de forma segura.

Cómo auditarán los auditores el mismo programa

Un supervisor DORA, un auditor ISO, un evaluador basado en NIST, un revisor COBIT y un auditor de cliente pueden inspeccionar las mismas evidencias a través de lentes distintos.

Zenith Controls resulta útil aquí como brújula de cumplimiento transversal. Para las pruebas de DORA, Clarysec destaca 5.35 Revisión independiente de la seguridad de la información, 8.8 Gestión de vulnerabilidades técnicas y 8.6 Gestión de capacidad como anclajes especialmente importantes de ISO/IEC 27001:2022 Anexo A. Ayudan a los propietarios de controles a conectar las pruebas con el aseguramiento independiente, la gestión de vulnerabilidades y la capacidad operativa.

La Política de seguridad de la información de Clarysec también respalda la pista de auditoría:

“Los propietarios de controles deben mantener resultados de pruebas, registros de eventos y registros de revisión para respaldar auditorías periódicas.”

Esa frase debe convertirse en una regla operativa. Cada propietario de prueba debe saber qué conservar, dónde conservarlo, cómo protegerlo y cómo se vincula con las evidencias de riesgo y control.

Construir un paquete de evidencias DORA a ISO en una semana

Una entidad financiera o proveedor de TIC puede lograr avances significativos en cinco días laborables.

Día 1: Definir alcance y criticidad

Utilice la lógica de las cláusulas 4.1 a 4.4 de ISO/IEC 27001:2022. Identifique partes interesadas, obligaciones regulatorias, obligaciones contractuales, interfaces y dependencias. Liste servicios de la organización, funciones críticas o importantes, activos clave, tipos de datos y proveedores de TIC.

Resultado: registro de alcance de pruebas DORA.

Día 2: Crear el catálogo anual de pruebas

Utilice las cuatro familias de pruebas: vulnerabilidades, escenarios, rendimiento y penetración. Para cada servicio, defina qué pruebas aplican, frecuencia, propietario, nivel de independencia y desencadenante. Incluya desencadenantes por cambios de alto riesgo.

Resultado: catálogo de pruebas de resiliencia operativa digital 2026.

Día 3: Mapear controles y obligaciones

Mapee cada prueba a ISO/IEC 27001:2022 Anexo A, el Registro de Riesgos, la SoA, los artículos de DORA, las obligaciones de proveedores y las entradas pertinentes de Zenith Controls. Por ejemplo, los escaneos mensuales externos de vulnerabilidades se mapean a 8.8 Gestión de vulnerabilidades técnicas, tratamiento de riesgos, supervisión, gestión del riesgo de las TIC de DORA y resultados de vulnerabilidades de NIST CSF.

Resultado: matriz de mapeo de controles.

Día 4: Estandarizar las carpetas de evidencias

Cree una estructura de evidencias controlada:

• 01 Plan y autorización
• 02 Alcance y reglas de actuación
• 03 Resultados brutos
• 04 Informe final
• 05 Registro de hallazgos
• 06 Tickets de remediación
• 07 Evidencias de repetición de pruebas
• 08 Información a la dirección
• 09 Lecciones aprendidas y actualizaciones de políticas

Resultado: repositorio de evidencias con reglas de conservación.

Día 5: Revisar hallazgos e informes

Consolide los hallazgos abiertos por severidad, servicio, responsable del riesgo y fecha límite. Identifique remediaciones vencidas, riesgos aceptados y brechas de repetición de pruebas. Prepare un panel para el órgano de dirección que muestre cobertura de pruebas, hallazgos principales, acciones vencidas, problemas de terceros y riesgo residual.

Resultado: panel de pruebas DORA e ISO listo para el consejo.

Errores comunes en programas de pruebas de DORA

El fallo más común no es la falta de pruebas. Es la falta de gobernanza.

Preste atención a estos problemas:

• Pruebas de penetración realizadas anualmente, pero sin seguimiento de los hallazgos hasta su cierre
• Escaneos de vulnerabilidades ejecutados con frecuencia, pero con activos críticos fuera del alcance
• Ejercicios de mesa realizados, pero sin registro de decisiones ni plan de acciones de lecciones aprendidas
• Pruebas de restauración de copias de seguridad completadas, pero no mapeadas a RTO y RPO
• Pruebas de carga ejecutadas por ingeniería, pero no informadas a riesgos o cumplimiento
• Proveedores de TIC excluidos de pruebas de escenarios y recuperación
• Evidencias almacenadas en carpetas personales, hilos de chat o unidades no gestionadas
• Informes al consejo centrados en recuentos de actividad en lugar de riesgos de resiliencia no resueltos
• La SoA indica que un control aplica, pero no existen evidencias de prueba
• Las pruebas crean riesgo en producción porque la autorización y los límites no están claros

Cada brecha puede resolverse. La solución no es más pruebas aleatorias. La solución es un único programa controlado que vincule riesgo, actividad de pruebas, remediación, evidencias y supervisión de la dirección.

Qué debe ver realmente el consejo de administración

DORA convierte la resiliencia de las TIC en responsabilidad del órgano de dirección. Un informe útil para el consejo no debe incluir todos los hallazgos técnicos. Debe responder si la organización es suficientemente resiliente frente a su apetito de riesgo y tolerancia a la interrupción.

Un informe trimestral o semestral sólido incluye:

• Cobertura de pruebas respecto de funciones críticas o importantes
• Pruebas completadas frente a pruebas planificadas
• Hallazgos críticos y altos por servicio
• Remediación vencida por propietario
• Tasa de aprobación de repetición de pruebas
• Hallazgos relacionados con proveedores y preocupaciones de concentración
• Lecciones de pruebas de escenarios que afectan a planes de crisis o incidentes
• Riesgos de capacidad frente al crecimiento de la organización y los periodos pico
• Riesgos residuales que requieren aceptación por la dirección
• Restricciones de presupuesto, recursos o herramientas

Este informe se convierte en entrada de revisión por la dirección ISO, evidencia de gobernanza DORA y herramienta práctica de decisión.

De pruebas dispersas a resiliencia estratégica

El problema original del CISO no era que faltaran pruebas. La organización tenía escaneos, ejercicios de mesa, informes de carga y PDF de pruebas de penetración. El problema era que esas actividades todavía no contaban una historia coherente de evidencias.

Un programa unificado de pruebas DORA e ISO/IEC 27001:2022 cambia eso. La evaluación de riesgos impulsa el catálogo. El catálogo impulsa las pruebas autorizadas. Las pruebas generan hallazgos. Los hallazgos impulsan la remediación y la repetición de pruebas. Los resultados alimentan la información a la dirección. Las lecciones aprendidas actualizan políticas, procedimientos, contratos y controles.

Así es como una carga de cumplimiento se convierte en una capacidad estratégica.

Clarysec ayuda a las organizaciones a evitar programas de cumplimiento paralelos. DORA, ISO/IEC 27001:2022, NIS2, GDPR, NIST CSF 2.0 y COBIT 2019 no necesitan universos de evidencias separados. Necesitan un único modelo operativo gobernado que pueda presentarse mediante distintos enfoques de auditoría.

Nuestro enfoque combina:

• Zenith Blueprint para la implantación ISO por fases y la preparación para auditorías
• Zenith Controls para el mapeo de cumplimiento transversal entre controles, marcos y expectativas de auditoría
• Políticas para empresas y pymes sobre pruebas de seguridad, supervisión de auditoría, gestión de vulnerabilidades, seguridad de aplicaciones, continuidad y seguridad de la información
• Registros prácticos, estructuras de evidencias y plantillas de informes a la dirección

Si sus evidencias de pruebas DORA de 2026 están dispersas entre herramientas de escaneo, carpetas de ingeniería, notas de ejercicios de mesa y PDF de pruebas de penetración, ahora es el momento de consolidarlas.

Empiece con un único catálogo anual de pruebas mapeado al tratamiento de riesgos de ISO/IEC 27001:2022, su SoA, funciones críticas o importantes, terceros de TIC e informes a la dirección. Después utilice Zenith Blueprint, Zenith Controls y el kit de herramientas de políticas de Clarysec para convertir ese catálogo en evidencias de auditoría defendibles.

Clarysec puede ayudarle a diseñar el programa, mapear los controles, estructurar el paquete de evidencias y preparar el informe de resiliencia para el consejo antes de que llegue el próximo requerimiento del supervisor.