Penetration Testing para el cumplimiento de DORA: Lo que las entidades financieras de la UE deben saber

La Ley de Resiliencia Operacional Digital (Digital Operational Resilience Act, DORA) representa el cambio más significativo en la regulación de la ciberseguridad que ha visto el sector financiero de la UE. Y en su núcleo, junto con los marcos de gestión de riesgos de las TIC y las obligaciones de notificación de incidentes, hay un conjunto de requisitos de pruebas que transforma el "Penetration Testing" de un ejercicio voluntario a una actividad legalmente obligatoria con frecuencias definidas, reglas de alcance, cualificaciones de los "testers" y supervisión regulatoria.

Si usted es un banco, aseguradora, institución de pago, empresa de inversión o cualquier otra entidad regulada por la legislación de servicios financieros de la UE, esto le afecta. Si es sistémicamente importante, la situación se vuelve aún más intensa. Y si usted es un proveedor tercero de servicios de las TIC que presta servicios a esas entidades, tampoco se libra.

Esta guía le explica todo lo que necesita entender: qué exige DORA, quién está dentro del alcance, la diferencia entre las pruebas anuales estándar y el régimen avanzado de "Threat-Led Penetration Testing" (TLPT), y cómo construir un programa de pruebas que le mantenga en cumplimiento sin ahogarse en la complejidad regulatoria.

¿Qué es DORA y por qué existe?

La Ley de Resiliencia Operacional Digital (Reglamento de la UE 2022/2554) fue adoptada por el Consejo Europeo en diciembre de 2022, entró en vigor el 16 de enero de 2023 y se hizo aplicable el 17 de enero de 2025. A diferencia de una Directiva, que requiere la transposición al derecho nacional, DORA es un Reglamento, lo que significa que es directamente aplicable en todos los Estados miembros de la UE sin modificación.

DORA existe porque el sector financiero de la UE tenía un problema de heterogeneidad. Antes, los diferentes países aplicaban diferentes requisitos de ciberseguridad a sus instituciones financieras. Algunos tenían marcos de pruebas sólidos (los Países Bajos tenían TIBER-NL, Alemania tenía TIBER-DE), mientras que otros tenían requisitos técnicos mínimos. Un banco transfronterizo podría enfrentarse a tres regímenes de pruebas diferentes en función de la jurisdicción que lo examinara.

Mientras tanto, el sector financiero dependía cada vez más de la infraestructura digital y de los proveedores terceros de servicios de las TIC. Una única interrupción en la nube o un ciberataque podrían extenderse en cascada a través de instituciones, fronteras y mercados. DORA fue diseñado para crear un marco armonizado que garantice que todas las entidades financieras de la UE puedan resistir, responder y recuperarse de las interrupciones relacionadas con las TIC.

El reglamento se basa en cinco pilares: gestión de riesgos de las TIC, gestión y notificación de incidentes relacionados con las TIC, pruebas de resiliencia operacional digital, gestión de riesgos de terceros de las TIC e intercambio de información. El "Penetration Testing" se incluye en el tercer pilar, cubierto en el Capítulo IV (Artículos 24 a 27) del reglamento, y es el pilar con los dientes más afilados para los equipos de seguridad del día a día.

¿Quién está dentro del alcance?

DORA se aplica ampliamente en todo el sector financiero. Las entidades sujetas a sus requisitos incluyen las entidades de crédito (bancos), las entidades de pago, las entidades de dinero electrónico, las empresas de inversión, las compañías de seguros y reaseguros, los proveedores de servicios de criptoactivos en virtud de MiCA, los depositarios centrales de valores, los centros de negociación, los registros de operaciones, las sociedades de gestión de fondos, las agencias de calificación crediticia y los proveedores de servicios de "crowdfunding", entre otros.

En términos prácticos: si su organización está regulada por la legislación de servicios financieros de la UE, es casi seguro que está dentro del alcance de DORA. El reglamento establece deliberadamente una amplia red para garantizar que la resiliencia operacional digital sea coherente en todo el sector.

Hay una excepción que vale la pena señalar. Las microempresas, definidas como entidades con menos de 10 empleados y un volumen de negocios anual o un balance inferior a 2 millones de euros, se enfrentan a un régimen de pruebas más ligero. Todavía deben aplicar un enfoque basado en el riesgo a las pruebas de las TIC, pero los requisitos se adaptan proporcionalmente. Para todos los demás, se aplican todas las obligaciones de prueba.

Y, de manera crítica, el alcance de DORA se extiende más allá de las propias entidades financieras. Los proveedores terceros de servicios de las TIC (plataformas en la nube, proveedores de "SaaS", proveedores de servicios gestionados, empresas de análisis de datos) están sujetos al marco de supervisión de DORA, especialmente si se consideran críticos para la estabilidad del sector financiero. Si usted es un proveedor de tecnología que presta servicios a instituciones financieras de la UE, las obligaciones DORA de sus clientes se están convirtiendo rápidamente en su problema.

Los dos niveles de pruebas DORA

DORA establece un enfoque de dos niveles para las pruebas de resiliencia. La comprensión de esta estructura es esencial porque los requisitos, la frecuencia y la complejidad difieren significativamente entre los niveles.

Nivel 1: "Penetration Testing" anual en virtud de los artículos 24 y 25

El requisito de pruebas de referencia se aplica a toda entidad financiera regulada por DORA que no sea una microempresa. El artículo 24 exige a las entidades financieras que establezcan, mantengan y revisen un programa integral de pruebas de resiliencia operacional digital como parte de su marco de gestión de riesgos de las TIC.

El artículo 24(6) es la cláusula crítica: las entidades financieras deben garantizar que se realicen pruebas apropiadas en todos los sistemas y aplicaciones de las TIC que soporten funciones críticas o importantes al menos una vez al año.

A continuación, el artículo 25 enumera los tipos de pruebas que debe incluir el programa de pruebas. El reglamento no exige que todas las entidades ejecuten todos los tipos de pruebas (se aplica el principio de proporcionalidad), pero los ejemplos dan una idea clara de lo que esperan los reguladores. Entre ellas se encuentran las evaluaciones y los escaneos de vulnerabilidades, los análisis de código abierto, las evaluaciones de seguridad de la red, los análisis de carencias, las revisiones de seguridad física, las revisiones de código fuente (cuando sea factible), las pruebas basadas en escenarios, las pruebas de compatibilidad, las pruebas de rendimiento, las pruebas de extremo a extremo y el "Penetration Testing".

Para la mayoría de las entidades financieras con una infraestructura de las TIC significativa, el "Penetration Testing" será un componente central de su programa anual. El reglamento es claro: debe demostrar que sus sistemas pueden resistir las técnicas de ataque del mundo real, no solo que han sido escaneados en busca de vulnerabilidades conocidas.

Qué significan "Funciones críticas o importantes"

DORA define una función crítica o importante como aquella cuya interrupción perjudicaría materialmente el rendimiento de la entidad financiera, la solidez o la continuidad de sus servicios, o su cumplimiento continuo de las obligaciones regulatorias. En términos prácticos, esto cubre sus operaciones comerciales principales: procesamiento de pagos, plataformas de negociación, portales de cara al cliente, sistemas de toma de decisiones de crédito, plataformas de reclamaciones de seguros, infraestructura de liquidación y los sistemas de "backend" que los soportan.

La identificación de estas funciones es el primer paso para definir el alcance de su programa de pruebas. Si un sistema soporta una función crítica o importante, directamente o a través de dependencias, está dentro del alcance de las pruebas anuales.

Proporcionalidad: ajuste de las pruebas a su perfil de riesgo

DORA reconoce explícitamente que no todas las entidades financieras tienen el mismo tamaño ni se enfrentan al mismo perfil de riesgo. El artículo 4(2) establece un principio de proporcionalidad: la profundidad y la frecuencia de sus pruebas deben ajustarse al tamaño y la complejidad de su entidad, al perfil de riesgo general, a la criticidad de los sistemas de las TIC que se están probando, a la exposición a través de la externalización o las dependencias de la nube, a los cambios materiales en su infraestructura de las TIC y a la gravedad y los resultados de los incidentes anteriores.

Esto significa que no se espera que una pequeña empresa "fintech" con un producto específico e infraestructura limitada iguale el programa de pruebas de una institución sistémicamente importante a nivel mundial (G-SII). Pero también significa que no puede utilizar la proporcionalidad como una excusa general para realizar pruebas mínimas. El principio escala la profundidad de las pruebas, no la obligación de realizar pruebas.

Nivel 2: "Threat-Led Penetration Testing" (TLPT) en virtud de los artículos 26 y 27

Si las pruebas anuales estándar son la línea de base de DORA, TLPT es el nivel avanzado, y es una bestia fundamentalmente diferente.

TLPT es un ejercicio de "red team" a gran escala, impulsado por inteligencia y realizado en sistemas de producción en vivo, en secreto para los equipos de defensa de la organización, que imita las tácticas, técnicas y procedimientos que los actores de amenazas del mundo real utilizarían contra la entidad. No es un escaneo de vulnerabilidades con un nombre elegante. Es un ciberataque controlado diseñado para probar si su institución (su tecnología, sus procesos y su personal) puede resistir y detectar una intrusión sofisticada y dirigida.

TLPT es obligatorio solo para ciertas entidades financieras identificadas por sus autoridades competentes en función de la importancia sistémica, el perfil de riesgo y la madurez de las TIC. Las entidades con más probabilidades de ser designadas incluyen los bancos sistémicamente importantes a nivel mundial (G-SII) y otras instituciones sistémicamente importantes (O-SII), las instituciones de pago más grandes (aquellas que procesan más de 150.000 millones de euros en transacciones totales durante cada uno de los dos años anteriores), las grandes compañías de seguros y reaseguros, las contrapartes centrales y los depositarios centrales de valores, y los principales centros de negociación.

Si su autoridad competente le designa para TLPT, debe llevar a cabo pruebas avanzadas al menos cada tres años. La autoridad también puede aumentar o disminuir esta frecuencia en función de su perfil de riesgo y sus circunstancias operativas.

Cómo funciona TLPT: las seis fases

Las Normas Técnicas Regulatorias sobre TLPT (Reglamento Delegado de la Comisión UE 2025/1190, publicado en junio de 2025) definen un proceso estructurado que implica varias fases distintas.

La fase de preparación comienza cuando la autoridad competente (su autoridad TLPT) notifica a su entidad que debe realizar un TLPT. Usted reúne un equipo de control (un grupo pequeño y de confianza dentro de su organización que gestiona la prueba) e identifica las funciones críticas que se van a probar. El alcance se presenta a continuación a la autoridad TLPT para su validación.

La fase de inteligencia de amenazas implica que un proveedor de inteligencia de amenazas elabore un informe de inteligencia de amenazas dirigido específicamente a su institución. Este informe analiza los actores de amenazas con más probabilidades de atacar a su entidad, sus tácticas y técnicas conocidas, y los escenarios de ataque más relevantes para su modelo de negocio, su pila de tecnología y su geografía. Esta inteligencia impulsa toda la prueba, garantizando que refleje las amenazas del mundo real, no los manuales de ataque genéricos.

La fase de pruebas del "red team" es la ejecución. El "red team", trabajando a partir de la inteligencia de amenazas, lleva a cabo una campaña ofensiva sostenida contra sus sistemas de producción en vivo. A diferencia del "pentesting" estándar, la prueba se ejecuta durante un período prolongado (normalmente de tres a cuatro meses), el "blue team" (sus defensores) no está informado y el objetivo es simular una amenaza persistente avanzada genuina.

La fase de cierre incluye un ejercicio obligatorio de "purple teaming", que es una diferencia clave con respecto al marco anterior TIBER-EU, donde el "purple teaming" solo se recomendaba. Durante el "purple teaming", el "red team" y el "blue team" trabajan juntos para repasar los escenarios de ataque, revisar lo que se detectó y lo que se pasó por alto, e identificar colaborativamente las mejoras. Esto garantiza que la prueba genere aprendizaje, no solo hallazgos.

Por último, la fase de notificación y remediación produce documentación que se presenta a la autoridad competente para su validación y certificación. La autoridad confirma que el TLPT se realizó de acuerdo con los requisitos de DORA y emite una certificación formal.

TLPT vs. "Pentesting" estándar: comprensión de la diferencia

La distinción entre TLPT y el "Penetration Testing" estándar es uno de los conceptos más importantes para el cumplimiento de DORA, y uno de los más comúnmente incomprendidos.

Un "Penetration Testing" estándar normalmente se dirige a un sistema o aplicación específica: una aplicación web, una API, un segmento de red. Se ejecuta de una a tres semanas. El equipo de seguridad sabe que está sucediendo. El alcance es limitado y acordado de antemano. El "tester" busca vulnerabilidades técnicas, intenta explotarlas y elabora un informe con hallazgos y orientación sobre la remediación. Es una evaluación técnica de una superficie definida.

Un TLPT cubre toda la organización. Se dirige a funciones empresariales críticas, no a sistemas específicos. Se ejecuta durante meses, no semanas. El equipo de defensa no es consciente en absoluto. La prueba está impulsada por inteligencia de amenazas a medida, no por una metodología genérica. Los "testers" simulan el ciclo de vida completo de un ataque real: reconocimiento, acceso inicial, persistencia, movimiento lateral, escalada de privilegios y exfiltración de datos o interrupción operativa. Y no solo prueba la tecnología, sino también a las personas (¿el personal cae en el "phishing"?) y los procesos (¿el SOC detecta la intrusión? ¿El plan de respuesta a incidentes realmente funciona?).

Piénselo de esta manera: un "pentest" pregunta "¿puede alguien entrar en esta habitación?" TLPT pregunta "¿puede un adversario sofisticado entrar en nuestro edificio, encontrar la bóveda, abrirla, tomar lo que quiere y marcharse sin que nadie se dé cuenta?"

Proveedores terceros de servicios de las TIC: no se libran

Una de las innovaciones más significativas de DORA es su tratamiento del riesgo de terceros de las TIC como una preocupación sistémica en lugar de una cuestión contractual bilateral. Si usted es un proveedor de la nube, un proveedor de "SaaS", un servicio de seguridad gestionado o cualquier otra empresa de tecnología que preste servicios a instituciones financieras de la UE, DORA le alcanza de varias maneras importantes.

En primer lugar, las entidades financieras deben exigir contractualmente a sus proveedores terceros de servicios de las TIC que participen y cooperen con TLPT cuando esos proveedores estén incluidos en el alcance de la prueba. El artículo 30(3)(d) de DORA lo establece explícitamente. Si su plataforma en la nube aloja la infraestructura de procesamiento de pagos de un banco y ese banco está designado para TLPT, el banco debe garantizar su participación en la prueba, y usted debe facilitarla.

En segundo lugar, los proveedores de las TIC considerados críticos para la estabilidad del sector financiero serán designados como Proveedores Terceros Críticos (CTPP) por las Autoridades Europeas de Supervisión (AES). Los CTPP están sujetos a la supervisión directa de las AES, incluidos los requisitos específicos en torno a las pruebas de seguridad, la gestión de riesgos y la resiliencia operacional. Se espera la primera oleada de designaciones de CTPP en 2025, tras las evaluaciones de criticidad realizadas por las AES.

En tercer lugar, incluso si no está designado como CTPP, DORA se está convirtiendo rápidamente en un filtro de adquisición. Las entidades financieras que evalúen a los proveedores de tecnología exigirán cada vez más pruebas de programas sólidos de pruebas de seguridad, la capacidad de soportar simulaciones dirigidas por el cliente y la preparación para pruebas operacionales conjuntas. El incumplimiento no solo significará riesgo regulatorio, sino que significará la pérdida de acceso a los clientes financieros europeos.

Si usted presta servicios a entidades financieras reguladas por la UE, el consejo práctico es sencillo: prepárese para soportar los requisitos de pruebas DORA de sus clientes, ofrezca entornos de prueba aislados cuando sea apropiado y esté preparado para demostrar su propia resiliencia operacional a través de programas de pruebas documentados.

¿Quién puede realizar las pruebas?

DORA establece requisitos de cualificación específicos para los "testers", en particular para TLPT.

Pruebas estándar (Artículos 24-25)

Para el programa de pruebas anual, DORA permite que las pruebas sean realizadas por equipos internos independientes o por proveedores externos cualificados. El requisito clave es la independencia: los "testers" no deben tener conflictos de intereses y no deben tener un interés personal en los resultados. Si utiliza "testers" internos, se requiere una separación organizativa adecuada.

El reglamento no exige certificaciones específicas para las pruebas estándar, pero sí exige que los "testers" posean las habilidades y la experiencia necesarias. En la práctica, las autoridades competentes esperan que los "testers" tengan cualificaciones profesionales reconocidas y experiencia demostrable en los tipos de pruebas que se están realizando.

TLPT (Artículos 26-27)

Para TLPT, los requisitos son considerablemente más estrictos. El reglamento exige que los "testers" tengan la idoneidad y la reputación más altas, posean capacidades técnicas y organizativas con experiencia específica en inteligencia de amenazas, "Penetration Testing" o pruebas de "red team", estén certificados por un organismo de acreditación en un Estado miembro o se adhieran a códigos de conducta formales o marcos éticos y, para los "testers" externos, tengan un seguro de responsabilidad profesional contra los riesgos de mala conducta.

Un matiz importante: DORA permite que los "testers" internos realicen el componente de "red team" de TLPT, pero con dos limitaciones críticas. La inteligencia de amenazas siempre debe ser proporcionada por un tercero externo, y cada tercer TLPT debe ser realizado por un proveedor externo de "red team". En la práctica, esto significa que, incluso si crea una capacidad interna de "red team", necesitará "testers" externos para al menos uno de cada tres ciclos de TLPT.

Remediación, notificación y certificación

DORA no trata las pruebas como una actividad independiente, sino que están integradas en un ciclo de mejora continua. El reglamento exige a las entidades financieras que establezcan procedimientos y políticas para priorizar, clasificar y solucionar todos los problemas revelados a través de las pruebas, y para garantizar que todas las vulnerabilidades y deficiencias identificadas se aborden por completo.

Para las pruebas anuales estándar, se espera que su programa de pruebas genere hallazgos documentados, que estos hallazgos se clasifiquen por gravedad, que la remediación se rastree y se complete, y que los resultados se reintegren en su marco de gestión de riesgos de las TIC. Su documentación debe estar a disposición de las autoridades competentes bajo petición.

Para TLPT, los requisitos son más formales. Una vez que concluye la prueba, incluido el ejercicio obligatorio de "purple teaming", la entidad financiera y los "testers" externos proporcionan documentación a la autoridad competente confirmando que el TLPT se realizó de acuerdo con los requisitos de DORA. La autoridad competente valida esta documentación y emite una certificación. Esta certificación puede compartirse con otras autoridades competentes para permitir el reconocimiento mutuo, lo que reduce la necesidad de realizar pruebas duplicadas en todas las jurisdicciones.

El mecanismo de reconocimiento mutuo es una de las innovaciones más prácticas de DORA. Si usted es una institución transfronteriza que opera en varios Estados miembros de la UE, una única certificación TLPT puede satisfacer los requisitos de supervisión en todas las jurisdicciones, lo que supone una mejora significativa con respecto al panorama anterior a DORA, donde los marcos de pruebas nacionales separados requerían pruebas separadas.

Cronogramas clave

El cronograma importa estratégicamente. Si usted es un candidato para la designación TLPT, se esperan las primeras notificaciones en 2026. El plazo de seis meses desde la notificación hasta la presentación del alcance es ajustado para las organizaciones que no han sentado las bases. Comience la asignación de funciones, identifique al jefe de su equipo de control y evalúe sus opciones de proveedor antes de recibir la carta.

Construcción de su programa de pruebas DORA

Tanto si es una institución de pago de tamaño medio que construye un programa de pruebas desde cero como si es una G-SII que alinea un programa existente con los requisitos de DORA, aquí tiene un marco práctico.

Paso 1: Mapee sus funciones críticas e importantes

Antes de poder probar algo, necesita saber qué importa. Identifique todas las funciones cuya interrupción perjudicaría materialmente el rendimiento de su entidad, la continuidad del servicio o el cumplimiento regulatorio. A continuación, mapee los sistemas de las TIC, las aplicaciones y las dependencias de terceros que soportan cada función. Este mapeo se convierte en la base de su alcance de pruebas y alimenta directamente su marco de gestión de riesgos de las TIC.

Paso 2: Establezca un programa de pruebas basado en el riesgo

Diseñe un programa de pruebas que cubra todos los sistemas de las TIC que soporten funciones críticas o importantes, incorpore los tipos de pruebas enumerados en el artículo 25 (ajustado a su perfil de proporcionalidad), opere al menos en un ciclo anual y se adapte en función de los cambios materiales en su infraestructura, los resultados de las pruebas anteriores y la evolución de la inteligencia de amenazas.

Documente formalmente el programa. DORA exige que su programa de pruebas esté documentado, revisado y mantenido como parte de su marco de gestión de riesgos de las TIC. Esta documentación debe estar a disposición de su autoridad competente bajo petición.

Paso 3: Contrate proveedores de pruebas cualificados

Para la mayoría de las entidades, los proveedores externos de "Penetration Testing" entregarán el componente de pruebas anual. Seleccione proveedores que tengan experiencia demostrada en el sector financiero, que entiendan los requisitos específicos de DORA y que puedan elaborar informes que cumplan con las expectativas regulatorias. Asegúrese de que los contratos de compromiso aborden los requisitos de independencia, las obligaciones de confidencialidad y el proceso de alineación del alcance.

Si usted es un candidato para TLPT, también deberá identificar a los proveedores de inteligencia de amenazas y a los proveedores de "red team" que cumplan con las estrictas cualificaciones descritas en el artículo 27 y las RTS de TLPT. Comience esta evaluación con anticipación: el grupo de proveedores cualificados de TLPT es más pequeño que el mercado general de "pentest", y las ventanas de programación se llenan rápidamente.

Paso 4: Construya el bucle de remediación

Probar sin remediación es rendimiento sin propósito. Establezca un flujo de trabajo documentado que lleve los hallazgos desde la identificación hasta la remediación y la verificación. Clasifique los hallazgos por gravedad, asigne la propiedad, defina los plazos de respuesta y rastree el cierre. Cada remediación debe verificarse, ya sea mediante una nueva prueba o mediante la implementación de controles validados.

Reintegre los resultados de sus pruebas en su marco de gestión de riesgos de las TIC. DORA considera las pruebas como una aportación a una imagen de resiliencia más amplia, no como un ejercicio de cumplimiento independiente.

Paso 5: Prepárese para TLPT (si procede)

Si es probable que su entidad sea designada para TLPT, la preparación debe comenzar mucho antes de que llegue la notificación. Identifique a un jefe de equipo de control, alguien lo suficientemente sénior como para gestionar la prueba a través de las fronteras de la organización y con la suficiente confianza como para mantener el secreto del "blue team". Mapee las funciones críticas que probablemente estarán dentro del alcance. Evalúe las dependencias de terceros que puedan necesitar ser incluidas. Revise sus acuerdos contractuales con los proveedores de las TIC para garantizar que las cláusulas de participación cumplan con DORA.

Errores comunes en el cumplimiento de las pruebas DORA

Tratar las pruebas como una casilla de verificación

Toda la filosofía de DORA es la resiliencia, no el teatro de cumplimiento. Los reguladores diseñaron los requisitos de las pruebas para garantizar que las entidades financieras puedan resistir genuinamente los ciberataques, no solo para elaborar informes que digan que lo intentaron. Si su programa de pruebas genera hallazgos que nunca se remedian, cubre los sistemas fáciles mientras evita los complejos, o elabora informes que se guardan en un cajón hasta la próxima auditoría, está perdiendo el punto y el regulador se dará cuenta.

Confundir el escaneo de vulnerabilidades con el "Penetration Testing"

El artículo 25 enumera tanto las evaluaciones y los escaneos de vulnerabilidades como el "Penetration Testing" como componentes de un programa de pruebas. Estas son actividades distintas. El escaneo automatizado de vulnerabilidades identifica las debilidades conocidas a escala. El "Penetration Testing" implica que un "tester" humano cualificado intente activamente explotar esas debilidades, encadenarlas y evaluar el impacto en el mundo real. Ejecutar un escaneo de Nessus y llamarlo "Penetration Testing" no satisfará a DORA.

Ignorar las dependencias de terceros

Si sus funciones críticas dependen de proveedores terceros de las TIC (y en los servicios financieros modernos, casi con toda seguridad lo hacen), su programa de pruebas debe tener en cuenta esas dependencias. Para las pruebas estándar, esto significa evaluar la postura de seguridad de sus conexiones e interfaces de terceros. Para TLPT, significa garantizar contractualmente que sus proveedores participarán en la prueba. Las entidades financieras que ignoran el riesgo de terceros en su alcance de pruebas crean exactamente el tipo de punto ciego que DORA fue diseñado para eliminar.

Asumir que TLPT es solo un "Pentest" más grande

Lo hemos dicho antes, pero vale la pena repetirlo. TLPT es una actividad fundamentalmente diferente del "Penetration Testing". Está impulsada por inteligencia, se lleva a cabo en sistemas de producción en vivo, se ejecuta en secreto para sus equipos de defensa, se ejecuta durante meses en lugar de semanas, requiere un "purple teaming" obligatorio y es validada y certificada por su autoridad competente. Abordar TLPT con una mentalidad de "pentest" (alcance limitado, cronograma corto, enfoque solo técnico) dará como resultado una prueba que no cumple con los requisitos regulatorios y no ofrece información significativa sobre la resiliencia.

Esperar la notificación

Si usted es una institución sistémicamente importante, esperar a que su autoridad competente le notifique formalmente antes de prepararse para TLPT es un error estratégico. El plazo entre la notificación y el alcance es de aproximadamente seis meses, y la preparación requerida (asignación de funciones, selección de proveedores, negociación de contratos, formación del equipo de control, adquisición de inteligencia de amenazas) es sustancial. Las organizaciones que comiencen temprano ejecutarán pruebas más fluidas, generarán mejores resultados y demostrarán a sus supervisores que se toman en serio la resiliencia operacional.