Evidencias de DORA TLPT con controles de ISO 27001

Son las 07:40 de un lunes por la mañana y el CISO de una entidad de pagos de tamaño medio está viendo tres versiones de la misma pregunta incómoda.

El Consejo de Administración quiere saber si la organización puede resistir una indisponibilidad del portal de pagos de clientes provocada por ransomware. El regulador quiere evidencias de que las pruebas de resiliencia operativa digital no son un ejercicio de PowerPoint. La auditoría interna quiere una trazabilidad clara desde las obligaciones de DORA hasta el riesgo de TIC, los controles de ISO 27001, los resultados de las pruebas, los planes de remediación, las evidencias de proveedores y la aprobación formal de la dirección.

El CISO tiene un informe de red team. El SOC tiene capturas de pantalla de alertas. Infraestructura tiene un registro de restauración de copias de seguridad. Legal tiene un registro de seguimiento de preparación para DORA. Compras tiene atestaciones de proveedores en la nube.

Nada está conectado.

Aquí es donde fallan muchos programas de DORA TLPT y de pruebas de resiliencia. No porque las pruebas sean débiles, sino porque las evidencias están fragmentadas. Cuando un auditor pregunta: “Muéstreme cómo esta prueba demuestra la resiliencia de una función crítica o importante”, la respuesta no puede ser una carpeta llena de capturas de pantalla. Debe ser una cadena de evidencias defendible.

Esa cadena es donde un SGSI alineado con ISO/IEC 27001:2022 ISO/IEC 27001:2022 aporta verdadero valor. ISO 27001 estructura el alcance, la evaluación de riesgos, la selección de controles, la Declaración de Aplicabilidad, el control operacional, la auditoría interna, la revisión por la dirección y la mejora continua. DORA aporta la presión sectorial específica. La metodología de Clarysec y sus herramientas de cumplimiento cruzado conectan ambos elementos en un único modelo de evidencias preparado para auditoría.

DORA TLPT es una prueba de gobernanza, no solo una simulación de ataque

Las pruebas de penetración guiadas por amenazas, o TLPT, se malinterpretan con facilidad. Técnicamente pueden parecer un ejercicio sofisticado de red team: inteligencia de amenazas, rutas de ataque realistas, sigilo, intentos de explotación, escenarios de movimiento lateral y validación de la respuesta del blue team.

Para DORA, la cuestión de fondo es la resiliencia operativa digital. ¿Puede la entidad financiera resistir, responder y recuperarse de una disrupción grave de TIC que afecte a sus procesos de negocio? ¿Puede demostrar que las funciones críticas o importantes permanecen dentro de las tolerancias de impacto? ¿Puede la dirección demostrar que el riesgo de TIC se gobierna, financia, prueba, remedia y mejora?

El Artículo 1 de DORA establece un marco uniforme de la UE para la seguridad de las redes y los sistemas de información que dan soporte a los procesos de negocio de las entidades financieras. Cubre la gestión del riesgo de TIC, la notificación de incidentes graves relacionados con las TIC, las pruebas de resiliencia operativa digital, la gestión del riesgo de terceros de TIC, los requisitos contractuales obligatorios para proveedores de TIC, la supervisión de proveedores terceros críticos de TIC y la cooperación supervisora. DORA es aplicable desde el 17 de enero de 2025.

Para las organizaciones también cubiertas por NIS2, DORA actúa como el acto jurídico de la Unión sectorial específico para los requisitos de ciberseguridad solapados. En términos prácticos, las entidades financieras deben priorizar DORA para la gestión del riesgo de TIC, la notificación de incidentes, las pruebas y el riesgo de terceros de TIC cuando los regímenes se solapen, sin dejar de comprender las expectativas de NIS2 para estructuras de grupo, proveedores y servicios digitales no financieros.

DORA también sitúa la responsabilidad proactiva en el nivel más alto. El Artículo 5 exige que el órgano de dirección defina, apruebe, supervise e implemente las medidas de gestión del riesgo de TIC. Esto incluye la estrategia de resiliencia operativa digital, la política de continuidad de las operaciones de TIC, los planes de respuesta y recuperación, los planes de auditoría, los presupuestos, las políticas relativas a terceros de TIC, los canales de notificación y conocimientos suficientes sobre riesgo de TIC mediante formación periódica.

Por tanto, la pregunta de auditoría no es simplemente: “¿Ejecutaron una TLPT?”

Es:

• ¿La TLPT estaba vinculada a funciones críticas o importantes?
• ¿Estaba autorizada, acotada, ejecutada de forma segura y sometida a evaluación de riesgos?
• ¿Se incluyeron proveedores, dependencias de servicios en la nube y servicios de TIC externalizados cuando procedía?
• ¿La prueba generó evidencias de detección, respuesta, recuperación y lecciones aprendidas?
• ¿Los hallazgos se convirtieron en tratamiento de riesgos, remediación con seguimiento, repetición de pruebas e informes a la dirección?
• ¿La Declaración de Aplicabilidad explicó qué controles del Anexo A de ISO 27001 se seleccionaron para gestionar el riesgo?

Por eso Clarysec trata las evidencias de DORA TLPT como un problema de evidencias del SGSI, no solo como un entregable de pruebas de penetración.

Construya la columna vertebral de evidencias de ISO 27001 antes de iniciar la prueba

ISO 27001 exige que una organización establezca, implemente, mantenga y mejore continuamente un SGSI que preserve la confidencialidad, integridad y disponibilidad mediante un proceso de gestión de riesgos. Las cláusulas 4.1 a 4.4 exigen que la organización comprenda las cuestiones internas y externas, las partes interesadas, las obligaciones legales y reglamentarias, las interfaces, las dependencias y, a continuación, documente el alcance del SGSI.

Para una entidad regulada por DORA, este ejercicio de definición de alcance debe capturar explícitamente las funciones críticas o importantes, los activos de TIC, las plataformas en la nube, las operaciones externalizadas, los sistemas de pago, los portales de clientes, los servicios de identidad, las plataformas de registro de eventos, los entornos de recuperación y los proveedores terceros de servicios de TIC. Si el alcance de la TLPT no se vincula de nuevo con el alcance del SGSI, la pista de auditoría ya es débil.

Las cláusulas 6.1.1, 6.1.2 y 6.1.3 de ISO 27001, junto con las cláusulas 8.2 y 8.3, exigen un proceso de evaluación y tratamiento de riesgos. Los riesgos deben identificarse frente a la confidencialidad, integridad y disponibilidad. Deben asignarse propietarios del riesgo. Deben evaluarse la probabilidad y la consecuencia. Los controles deben seleccionarse y compararse con el Anexo A. El riesgo residual debe ser aceptado por los propietarios del riesgo.

Este es el puente entre DORA y unas pruebas preparadas para auditoría.

Zenith Blueprint: An Auditor’s 30-Step Roadmap de Clarysec Zenith Blueprint, en la fase de gestión de riesgos, Paso 13, describe claramente esta función de trazabilidad:

La SoA es, en la práctica, un documento puente: vincula la evaluación y el tratamiento de riesgos con los controles reales disponibles. Al completarla, también se comprueba si se ha omitido algún control.

Para DORA TLPT, la Declaración de Aplicabilidad no debe ser un artefacto estático de certificación. Debe explicar por qué controles como la seguridad de proveedores, la gestión de incidentes, la preparación de las TIC para la continuidad del negocio, el registro de eventos, la supervisión, la gestión de vulnerabilidades técnicas, las copias de seguridad, el desarrollo seguro y las pruebas de seguridad son aplicables al escenario de resiliencia.

Un escenario práctico de riesgo podría formularse así:

“El compromiso de credenciales privilegiadas de un proveedor de identidad permite a un atacante acceder a los sistemas de administración del procesamiento de pagos, modificar configuraciones de enrutamiento e interrumpir una función crítica de pagos, provocando indisponibilidad del servicio, obligaciones de notificación regulatoria, perjuicio a clientes y daño reputacional”.

Ese único escenario puede dirigir el alcance de la TLPT, los casos de uso de detección, la participación de proveedores, el simulacro de recuperación, los informes al Consejo de Administración y el conjunto de evidencias.

Zenith Blueprint también recomienda hacer explícita la trazabilidad regulatoria:

Referencie normativas de forma cruzada: si determinados controles se implementan específicamente para cumplir con GDPR, NIS2 o DORA, puede anotarlo bien en el Registro de Riesgos, como parte de la justificación del impacto del riesgo, o en las notas de la SoA.

Ese consejo es simple, pero cambia la conversación de auditoría. En lugar de indicar a un auditor que DORA fue tenido en cuenta, la organización puede mostrar dónde aparece DORA en el Registro de Riesgos, la SoA, el programa de pruebas, el conjunto de políticas y la revisión por la dirección.

Mapee las pruebas DORA a controles de ISO 27001 que los auditores reconocen

El Artículo 6 de DORA espera un marco documentado de gestión del riesgo de TIC integrado en la gestión global de riesgos. El Anexo A de ISO 27001 proporciona el catálogo de controles que convierte esto en operación.

Para DORA TLPT y las pruebas de resiliencia, estos controles del Anexo A de ISO/IEC 27001:2022 son especialmente importantes:

Zenith Controls: The Cross-Compliance Guide de Clarysec Zenith Controls ayuda a las organizaciones a evitar tratar estos controles como elementos aislados de una lista de verificación. Mapea controles ISO/IEC 27002:2022 con atributos, dominios, capacidades operativas, expectativas de auditoría y patrones de marcos cruzados.

Por ejemplo, Zenith Controls clasifica el control 5.30 de ISO/IEC 27002:2022, preparación de las TIC para la continuidad del negocio, como “Correctivo”, alineado con “Disponibilidad”, asociado al concepto de ciberseguridad “Responder” y situado en el dominio “Resiliencia”. Esta clasificación es útil para explicar a los auditores por qué un simulacro de recuperación no es solo una operación de TI, sino un control de resiliencia con una función definida en el entorno de control.

Zenith Controls también clasifica el control 8.29, pruebas de seguridad en desarrollo y aceptación, como un control preventivo que respalda la confidencialidad, integridad y disponibilidad, con capacidades operativas en seguridad de aplicaciones, aseguramiento de la seguridad de la información y seguridad de sistemas y redes. Para hallazgos de TLPT que se remontan a debilidades de diseño de aplicaciones, comportamiento inseguro de interfaces de programación de aplicaciones, flujos de autenticación deficientes o validación insuficiente, esta es la vía de control hacia la gobernanza del desarrollo seguro.

El control 5.35, revisión independiente de la seguridad de la información, también es importante. Respalda el cuestionamiento independiente, el aseguramiento de la gobernanza y la mejora correctiva. Los equipos internos pueden coordinar las pruebas, pero las evidencias preparadas para auditoría requieren revisión, escalado y supervisión más allá de las personas que construyeron u operaron los sistemas probados.

Proteja el sistema mientras lo prueba

Una suposición peligrosa en las pruebas de resiliencia es que probar siempre es positivo. En realidad, las pruebas intrusivas pueden provocar indisponibilidades del servicio, exponer datos sensibles, contaminar registros, activar defensas automatizadas, interrumpir sesiones de clientes o hacer que los proveedores invoquen procedimientos de emergencia.

La Política de pruebas de seguridad y red teaming de Clarysec Política de pruebas de seguridad y red teaming proporciona a las organizaciones un patrón de gobernanza para una ejecución segura. La cláusula 6.1 establece:

Tipos de pruebas: el programa de pruebas de seguridad debe 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 profesionales cualificados para identificar debilidades complejas; y (c) ejercicios de red team, consistentes en simulaciones basadas en escenarios de ataques reales, incluida ingeniería social y otras tácticas, para probar las capacidades de detección y respuesta de la organización en su conjunto.

Para TLPT, el componente de red team es evidente, pero el valor de auditoría procede del diseño del programa. Los escaneos de vulnerabilidades, las pruebas de penetración, los ejercicios de red team, los simulacros de resiliencia y la repetición de pruebas deben formar un ciclo, no una colección de pruebas desconectadas.

La cláusula 6.2 de la misma política aborda la ejecución segura:

Alcance y reglas de actuación: para cada prueba o ejercicio, el STC debe definir el alcance, incluidos los sistemas e intervalos de IP incluidos, los métodos de prueba permitidos, los objetivos, el calendario y la duración. Las reglas de actuación deben documentarse. Por ejemplo, los sistemas sensibles desde el punto de vista operativo pueden designarse como solo supervisión para evitar interrupciones, y cualquier prueba en producción debe incluir procedimientos de reversión y parada. Deben establecerse medidas de seguridad, como ventanas temporales y canales de comunicación definidos, para evitar indisponibilidades del servicio no previstas.

Esto se mapea directamente con Zenith Blueprint, fase Controles en acción, Paso 21, que se centra en el control 8.34 del Anexo A de ISO 27001, protección de los sistemas de información durante pruebas de auditoría. Zenith Blueprint advierte que las auditorías, pruebas de penetración, revisiones forenses y evaluaciones operativas pueden implicar acceso elevado, herramientas intrusivas o cambios temporales en el comportamiento del sistema. Subraya la autorización, el alcance, las ventanas temporales, la aprobación del propietario del sistema, la reversión, la supervisión y el manejo seguro de datos de prueba.

El paquete de evidencias preparado para auditoría debe incluir:

• Acta de constitución y objetivos de TLPT
• Resumen de inteligencia de amenazas y justificación del escenario
• Funciones críticas o importantes incluidas en el alcance
• Sistemas, rangos de IP, identidades, proveedores y entornos incluidos en el alcance
• Exclusiones y sistemas solo supervisión
• Reglas de actuación
• Evaluación de riesgos de pruebas en producción
• Procedimientos de reversión y parada
• Modelo de notificación al SOC, incluido qué se divulga y qué se retiene
• Aprobaciones legales, de privacidad y de proveedores
• Evidencias de creación y revocación de acceso de cuentas de prueba
• Ubicación de almacenamiento seguro para artefactos de prueba y registros

Una DORA TLPT que no pueda demostrar autorización segura y control de la actividad de prueba puede revelar deficiencias de resiliencia, pero también crea deficiencias de gobernanza.

Convierta los resultados de TLPT en tratamiento de riesgos

El fallo posterior a la prueba más habitual es el problema del informe de red team que acaba en una estantería. Se entrega un informe de alta calidad, se distribuye, se debate y luego pierde impulso lentamente. Los hallazgos permanecen abiertos. Los controles compensatorios no se documentan. Los riesgos aceptados son informales. La repetición de pruebas nunca se realiza.

La Política de pruebas de seguridad y red teaming hace que esto sea inaceptable. La cláusula 6.6 establece:

Remediación de hallazgos: todas las vulnerabilidades o debilidades identificadas deben documentarse en un informe de hallazgos con clasificación 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 deben remediarse en un plazo de 30 días y los hallazgos de severidad alta 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 hacer seguimiento del avance de la remediación. Debe realizarse una repetición de pruebas para confirmar que los problemas críticos se han resuelto o mitigado adecuadamente.

La cláusula 6.7 añade la capa de gobernanza:

Informes: al finalizar cada prueba debe emitirse un informe formal. Para las pruebas de penetración, el informe debe incluir un resumen ejecutivo, la metodología y hallazgos detallados con evidencias de soporte y recomendaciones. Para los ejercicios de red team, el informe debe detallar los escenarios, qué rutas de ataque tuvieron éxito, qué detectó el blue team y las lecciones aprendidas sobre deficiencias de detección y respuesta. El CISO debe presentar resultados resumidos y el estado de remediación a la alta dirección y, cuando proceda, incluirlos en el informe anual de seguridad al Consejo de Administración.

Esto se alinea con la guía de tratamiento de riesgos de ISO/IEC 27005:2022: seleccionar opciones de tratamiento, determinar controles del Anexo A de ISO 27001 y de requisitos sectoriales específicos, construir un Plan de Tratamiento de Riesgos, asignar personas responsables, definir plazos, realizar seguimiento del estado, obtener la aprobación del propietario del riesgo y documentar la aceptación del riesgo residual.

Todo hallazgo significativo de TLPT debe convertirse en una de cuatro cosas: una acción de remediación, una mejora de control, una aceptación formal del riesgo o un requisito de repetición de pruebas.

El objetivo no es producir más documentos. El objetivo es que cada documento explique la siguiente decisión.

Las pruebas de resiliencia deben demostrar la recuperación, no solo la detección

Una TLPT exitosa puede demostrar que el SOC detectó tráfico de mando y control, bloqueó el movimiento lateral y escaló correctamente. Eso es valioso, pero las pruebas de resiliencia de DORA van más allá. Preguntan si la organización puede continuar o recuperar servicios de negocio.

Zenith Blueprint, fase Controles en acción, Paso 23, explica el control 5.30, preparación de las TIC para la continuidad del negocio, con un lenguaje que todo CISO debería utilizar con el Consejo de Administración:

Desde el punto de vista de auditoría, este control suele probarse con una sola frase: Muéstremelo. Muéstreme el último resultado de prueba. Muéstreme la documentación de recuperación. Muéstreme cuánto tiempo tardó la conmutación por error y la vuelta atrás. Muéstreme la evidencia de que lo prometido puede entregarse.

Ese estándar de “Muéstremelo” marca la diferencia entre madurez documental y resiliencia operativa.

La Política de Continuidad del Negocio y Recuperación ante Desastres-sme de Clarysec Política de Continuidad del Negocio y Recuperación ante Desastres - SME, en la sección “Requisitos de implementación de la política”, cláusula 6.4.1, establece:

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

La sección de aplicación de la misma política, cláusula 8.5.1, explicita la responsabilidad sobre las evidencias:

El DG debe garantizar que se mantenga lo siguiente y esté preparado para auditoría:

Para una entidad financiera regulada por DORA, las pruebas anuales pueden ser el mínimo, no el objetivo. Las funciones críticas o importantes de mayor riesgo deben probarse con mayor frecuencia, especialmente tras cambios de arquitectura, migración a la nube, incidentes graves, nuevos proveedores de TIC, versiones materiales de aplicaciones o cambios en la exposición a amenazas.

Un paquete sólido de evidencias de pruebas de resiliencia debe incluir:

• análisis de impacto en el negocio que mapee la función crítica o importante
• RTO y RPO aprobados por propietarios de negocio
• mapa de dependencias del sistema, incluidos identidad, DNS, red, nube, base de datos, supervisión, copias de seguridad y servicios de terceros
• resultados de pruebas de copia de seguridad y restauración
• marcas temporales de conmutación por error y retorno al servicio principal
• evidencia de controles de seguridad operando durante la disrupción
• plantillas de comunicación a clientes, regulador e internas
• registros de participación del comandante de incidente y del equipo de crisis
• lecciones aprendidas y acciones de mejora
• evidencias de repetición de pruebas para deficiencias de recuperación anteriores

Aquí es también donde GDPR entra en juego. Los Artículos 2 y 3 de GDPR incorporan al alcance la mayor parte del tratamiento de datos personales de la UE en SaaS y fintech. El Artículo 4 define datos personales, tratamiento, responsable, encargado y brecha de seguridad de los datos personales. El Artículo 5 exige integridad, confidencialidad y responsabilidad proactiva, lo que significa que la organización debe poder demostrar el cumplimiento. Si la TLPT o las pruebas de recuperación utilizan datos personales de producción, copian registros que contienen identificadores o validan la respuesta ante brechas, las salvaguardas de privacidad deben documentarse.

Las evidencias de proveedores son el punto ciego de DORA que los auditores no ignorarán

Los servicios financieros modernos se componen de plataformas en la nube, aplicaciones SaaS, proveedores de seguridad gestionada, procesadores de pagos, plataformas de datos, proveedores de identidad, herramientas de observabilidad, equipos de desarrollo externalizado y proveedores de copias de seguridad.

El Artículo 28 de DORA exige que las entidades financieras gestionen el riesgo de terceros de TIC como parte del marco de gestión del riesgo de TIC y sigan siendo plenamente responsables incluso cuando los servicios de TIC estén externalizados. El Artículo 30 exige contratos escritos de servicios de TIC con descripciones del servicio, condiciones de subcontratación, ubicaciones de tratamiento, protección de datos, acceso y recuperación, niveles de servicio, asistencia en incidentes, cooperación con autoridades, derechos de terminación, condiciones reforzadas para funciones críticas o importantes, derechos de auditoría, medidas de seguridad, participación en TLPT cuando proceda y acuerdos de salida.

Esto significa que un escenario de TLPT no puede detenerse en el cortafuegos de la organización si la función crítica depende de un proveedor.

La Política de Seguridad de Terceros y Proveedores-sme de Clarysec Política de Seguridad de Terceros y Proveedores - SME, en la sección “Requisitos de implementación de la política”, cláusula 6.3.1, establece:

Los proveedores críticos o de alto riesgo deben revisarse al menos anualmente. La revisión debe verificar:

La Política de pruebas de seguridad y red teaming añade un requisito específico de proveedores para pruebas en la cláusula 6.9:

Coordinación de pruebas con terceros: cuando cualquier proveedor crítico o proveedor de servicios forme parte del alcance general de seguridad de la organización, de acuerdo con la Política de Seguridad de Terceros y Proveedores, la organización debe, cuando sea viable, obtener aseguramiento sobre sus prácticas de pruebas de seguridad o coordinar pruebas conjuntas. Por ejemplo, cuando se utilice un proveedor de servicios en la nube (CSP), la organización puede apoyarse en sus informes de pruebas de penetración o incluirlo en escenarios colaborativos de red team, sujeto a las disposiciones contractuales.

Para evidencias DORA preparadas para auditoría, el aseguramiento de proveedores debe vincularse al mismo escenario de riesgo que la TLPT. Si el proveedor de identidad es esencial para la recuperación de pagos, el paquete de evidencias debe incluir diligencia debida de proveedores, requisitos contractuales de seguridad, condiciones de soporte ante incidentes, coordinación de pruebas, informes de aseguramiento, evidencias de niveles de servicio, estrategia de salida y restricciones de prueba.

El Artículo 21 de NIS2 también importa para proveedores de SaaS, nube, servicios gestionados, seguridad gestionada, centros de datos, CDN, servicios de confianza, DNS, TLD, mercados en línea, búsqueda y redes sociales. Exige un enfoque multirriesgo que cubra análisis de riesgos, gestión de incidentes, continuidad del negocio, seguridad de la cadena de suministro, desarrollo seguro, evaluación de la eficacia, formación, criptografía, control de acceso, gestión de activos, MFA y comunicaciones seguras.

El resultado práctico es simple: las entidades financieras deben construir un único modelo de evidencias que satisfaga primero DORA y, después, referencie de forma cruzada las expectativas de NIS2 cuando participen proveedores, entidades del grupo o servicios digitales no financieros.

Un registro práctico de evidencias TLPT de Clarysec

Supongamos el siguiente escenario:

“Un actor de amenazas compromete una cuenta de administrador en una plataforma SaaS de soporte, pivota hacia el entorno de operaciones de pagos, modifica la configuración e interrumpe el procesamiento de transacciones”.

Cree un registro de evidencias con una fila por cada objeto de evidencia. No espere a que finalice la prueba. Complételo durante la planificación, ejecución, remediación y cierre.

A continuación, utilice el Paso 13 de Zenith Blueprint para añadir trazabilidad al Registro de Riesgos y a la Declaración de Aplicabilidad. Cada elemento de evidencia debe conectarse con un escenario de riesgo, un propietario del riesgo, un control seleccionado, un plan de tratamiento y una decisión sobre riesgo residual.

Si un hallazgo se refiere a una debilidad de software, cite los controles de desarrollo seguro y pruebas. La Política de Desarrollo Seguro-sme de Clarysec Política de Desarrollo Seguro - SME, en la sección “Requisitos de implementación de la política”, cláusula 6.5.2, exige:

Las pruebas deben documentarse con:

Si un hallazgo genera material forense, preserve la cadena de custodia. La Política de recopilación de evidencias y análisis forense-sme de Clarysec Política de recopilación de evidencias y análisis forense - SME, en la sección “Requisitos de gobernanza”, cláusula 5.2.1, establece:

Cada elemento de evidencia digital debe registrarse con:

Este es el punto que muchos equipos pasan por alto. Las evidencias no son solo informes finales. Son el registro controlado de quién aprobó, quién ejecutó, qué ocurrió, qué se detectó, qué se recuperó, qué se cambió, qué permanece expuesto y quién aceptó esa exposición.

Cómo inspeccionan los auditores las mismas evidencias de TLPT

Las evidencias de DORA TLPT se leerán de forma distinta según el perfil del auditor. Clarysec diseña paquetes de evidencias para que cada enfoque encuentre lo que necesita sin obligar a los equipos a duplicar trabajo.

COBIT 2019 aparece en la referencia de cumplimiento cruzado de Zenith Blueprint para una ejecución segura de auditorías y pruebas, incluidos DSS05.03 y MEA03.04. Lo relevante no es que COBIT sustituya a DORA o ISO 27001, sino que los profesionales de aseguramiento con enfoque ISACA buscarán ejecución controlada, supervisión, evaluación y evidencias de cumplimiento.

La narrativa para el Consejo de Administración: qué debe aprobar la dirección

Los informes al Consejo de Administración deben evitar el teatro técnico. El Consejo de Administración no necesita cargas útiles de exploits. Necesita evidencias aptas para la toma de decisiones:

• ¿Qué función crítica o importante se probó?
• ¿Qué escenario de amenazas se simuló y por qué?
• ¿Funcionó la detección?
• ¿Funcionó el escalado de respuesta?
• ¿Cumplió la recuperación los RTO y RPO?
• ¿Qué proveedores participaron o estuvieron sujetos a restricciones?
• ¿Qué debilidades materiales permanecen?
• ¿Cuál es el coste, propietario y plazo de la remediación?
• ¿Qué riesgos residuales requieren aceptación formal del riesgo?
• ¿Qué se repetirá en pruebas?

Aquí es donde la cláusula 5 de ISO 27001 cobra importancia. La alta dirección debe garantizar que la Política de Seguridad de la Información y los objetivos se establezcan, se alineen con la dirección estratégica, se integren en los procesos de la organización, cuenten con recursos, se comuniquen y se mejoren continuamente. Deben asignarse roles y responsabilidades. Los objetivos deben ser medibles cuando sea viable y tener en cuenta los requisitos aplicables y los resultados del tratamiento de riesgos.

Si la TLPT identifica que el tiempo de recuperación es de seis horas frente a una tolerancia de negocio de cuatro horas, no se trata simplemente de un elemento pendiente de la lista de infraestructura. Es una decisión de dirección que implica apetito de riesgo, presupuesto, compromisos con clientes, exposición regulatoria, contratos, arquitectura y capacidad operativa.

Fallos habituales de evidencias en pruebas de resiliencia DORA

Las revisiones de Clarysec suelen encontrar las mismas deficiencias de evidencias en entidades financieras y proveedores de servicios de TIC que se preparan para DORA.

En primer lugar, el alcance de la TLPT no se mapea con funciones críticas o importantes. La prueba puede ser técnicamente impresionante, pero no demuestra la resiliencia del proceso de negocio que preocupa a los reguladores.

En segundo lugar, las dependencias de proveedores se reconocen, pero no se evidencian. Los equipos indican que el proveedor de servicios en la nube, el SOC gestionado o la plataforma SaaS están en el alcance, pero faltan contratos, derechos de auditoría, permisos de prueba, condiciones de soporte ante incidentes y planes de salida.

En tercer lugar, las pruebas generan evidencias, pero no tratamiento. Los hallazgos permanecen en un informe de red team en lugar de convertirse en actualizaciones del Registro de Riesgos, cambios de control, propietarios, fechas, repetición de pruebas y decisiones sobre riesgo residual.

En cuarto lugar, la recuperación se asume en lugar de demostrarse. Existen políticas de copia de seguridad, pero nadie puede mostrar marcas temporales de conmutación por error, comprobaciones de integridad de restauración, validación de acceso o confirmación del propietario de negocio.

En quinto lugar, las evidencias de privacidad y forenses no están controladas. Los registros y capturas de pantalla contienen datos personales, los artefactos de prueba se almacenan en unidades compartidas, las cuentas temporales siguen activas y la cadena de custodia de evidencias está incompleta.

En sexto lugar, los informes a la dirección son demasiado técnicos. La alta dirección no puede ver si la resiliencia mejoró, si el riesgo está dentro del apetito o qué decisiones de inversión se necesitan.

Todas estas deficiencias pueden resolverse tratando DORA TLPT como un flujo de trabajo estructurado de evidencias ISO 27001.

El enfoque integrado de Clarysec para una resiliencia preparada para auditoría

El enfoque de Clarysec combina tres capas.

La primera capa es la hoja de ruta de implementación de 30 pasos Zenith Blueprint. Para este tema, el Paso 13 construye la trazabilidad del tratamiento de riesgos y de la SoA, el Paso 21 protege los sistemas durante pruebas de auditoría y el Paso 23 valida la preparación de las TIC para la continuidad del negocio. Estos pasos convierten la TLPT de un evento técnico en un ciclo de gobernanza documentado.

La segunda capa es la biblioteca de políticas de Clarysec. La Política de pruebas de seguridad y red teaming define tipos de pruebas, alcance, reglas de actuación, remediación, informes y coordinación con proveedores. La Política de Continuidad del Negocio y Recuperación ante Desastres-sme establece expectativas para pruebas anuales de BCP y DR y evidencias de continuidad preparadas para auditoría. La Política de Seguridad de Terceros y Proveedores-sme respalda el aseguramiento de proveedores. La Política de Desarrollo Seguro-sme garantiza que las pruebas de seguridad se documenten. La Política de recopilación de evidencias y análisis forense-sme respalda el registro de evidencias y la disciplina de cadena de custodia.

La tercera capa es Zenith Controls, la guía de cumplimiento cruzado de Clarysec. Ayuda a mapear los controles ISO/IEC 27002:2022 con atributos, dominios, capacidades operativas y expectativas de marcos cruzados. Para DORA TLPT, el patrón más importante no es un control concreto. Es la relación entre pruebas, continuidad, gestión de incidentes, gestión de proveedores, registro de eventos, supervisión, desarrollo seguro, revisión independiente y gobernanza.

Cuando estas capas trabajan juntas, el problema del lunes por la mañana del CISO cambia. En lugar de tres preguntas desconectadas del Consejo de Administración, el regulador y la auditoría interna, la organización tiene una única historia de evidencias:

“Identificamos la función crítica. Evaluamos el riesgo de TIC. Seleccionamos y justificamos controles. Autorizamos y ejecutamos de forma segura la TLPT. Detectamos, respondimos y recuperamos. Involucramos a proveedores cuando fue necesario. Documentamos evidencias. Remediamos hallazgos. Repetimos pruebas. La dirección revisó y aceptó el riesgo restante”.

Eso es resiliencia preparada para auditoría.

Próximos pasos

Si su programa DORA TLPT sigue organizado alrededor de informes en lugar de cadenas de evidencias, empiece con un recorrido de evidencias de Clarysec.

Utilice el Paso 13 de Zenith Blueprint Zenith Blueprint para conectar escenarios TLPT con riesgos, controles y la Declaración de Aplicabilidad. Utilice el Paso 21 para verificar autorización segura, reglas de actuación, reversión, supervisión y limpieza. Utilice el Paso 23 para demostrar la preparación de las TIC para la continuidad del negocio con evidencias de recuperación.

Después, alinee sus documentos operativos con la Política de pruebas de seguridad y red teaming de Clarysec Política de pruebas de seguridad y red teaming, la Política de Continuidad del Negocio y Recuperación ante Desastres-sme Política de Continuidad del Negocio y Recuperación ante Desastres - SME, la Política de Seguridad de Terceros y Proveedores-sme Política de Seguridad de Terceros y Proveedores - SME, la Política de Desarrollo Seguro-sme Política de Desarrollo Seguro - SME y la Política de recopilación de evidencias y análisis forense-sme Política de recopilación de evidencias y análisis forense - SME.

Por último, utilice Zenith Controls Zenith Controls para mapear de forma cruzada sus evidencias de DORA TLPT con controles de ISO 27001, NIS2, GDPR, COBIT 2019 y expectativas de auditoría.

Si quiere que su próxima prueba de resiliencia produzca algo más que hallazgos, utilice Clarysec para convertirla en una cadena de evidencias defendible. Descargue los kits de herramientas, programe una evaluación de preparación de evidencias o solicite un recorrido sobre cómo Clarysec mapea DORA TLPT con controles de ISO 27001:2022 desde la planificación hasta la aprobación por el Consejo de Administración.