TLPT bajo DORA: qué exige de verdad y cómo prepararse sin improvisar en el último minuto

La peor forma de descubrir que no entiendes una prueba de penetración basada en amenazas es pagarla, ejecutarla y comprobar después que no sirve para cumplir DORA. Está pasando. Demasiadas entidades siguen tratando las threat-led penetration tests (TLPT) como si fueran un pentest anual con un nombre más caro. No lo son.

DORA reserva las pruebas más exigentes para un perímetro concreto de entidades financieras y lo hace con una lógica muy clara: no quiere ver si tu red tiene puertos abiertos, sino si una amenaza plausible puede comprometer funciones críticas o importantes, atravesar dependencias, activar a tus equipos y dejar rastro suficiente para que supervisión entienda qué has aprendido. Ese matiz cambia el proyecto entero: alcance, patrocinio interno, selección de proveedores, reglas de interacción, gestión de terceros, evidencias y remediación.

El núcleo jurídico está en los artículos 26 y 27 del Reglamento (UE) 2022/2554, DORA. El artículo 26 obliga a establecer un programa de pruebas de resiliencia operativa digital proporcionado al tamaño, perfil de riesgo y complejidad de la entidad. El artículo 27 va más lejos: ciertas entidades financieras deberán realizar pruebas avanzadas mediante TLPT al menos cada tres años, salvo que la autoridad competente determine otra frecuencia en función del perfil de riesgo y de las circunstancias operativas. Ahí está el primer error habitual: pensar que el requisito relevante es la técnica ofensiva. No. El requisito relevante es el régimen de resiliencia, gobernanza y trazabilidad que rodea a la prueba.

Si eres CISO, responsable de resiliencia o de compliance, la pregunta útil no es si “harás una TLPT”. La pregunta es otra: ¿puedes demostrar que una TLPT cubrirá funciones críticas o importantes, incluirá dependencias externas relevantes y producirá evidencias reutilizables para DORA, incidentes, terceros ICT y auditoría? Si la respuesta hoy es tibia, aquí está el trabajo de verdad.

Lo que DORA pide y lo que muchas entidades todavía creen que pide

DORA art. 26 no crea una obligación aislada de pruebas técnicas; la inserta dentro del marco de pruebas de resiliencia operativa digital. Eso incluye evaluaciones de vulnerabilidades, análisis y escaneos, revisiones de seguridad de red, gap assessments, revisiones de seguridad física cuando proceda, pruebas de soluciones y procedimientos, pruebas de extremo a extremo y, para un subconjunto de entidades, TLPT. La arquitectura regulatoria importa porque supervisión no mirará la TLPT como una isla. La leerá contra tu marco de gestión de riesgo ICT del art. 6, tu clasificación de funciones críticas o importantes, tu gestión de incidentes del capítulo III y tu gobernanza de terceros ICT del capítulo V.

La diferencia práctica entre un pentest convencional y una TLPT bajo DORA cabe en una frase: el pentest busca fallos; la TLPT busca demostrar, en un escenario realista de amenaza, si esos fallos permiten comprometer servicios críticos, procesos de negocio y controles de respuesta sin provocar daños indebidos. Parece sutil. No lo es.

Un pentest clásico suele partir de un alcance técnico delimitado por IPs, aplicaciones o segmentos. Una TLPT parte de inteligencia de amenazas relevante para la entidad, identifica escenarios plausibles y modela cadenas de ataque con impacto potencial sobre funciones críticas o importantes. La primera tiende a medir exposición técnica. La segunda evalúa resiliencia operativa. En lenguaje menos diplomático: una encuentra grietas; la otra comprueba si la casa se cae.

El artículo 27 además no habla de cualquier entidad. Habla de entidades financieras identificadas por las autoridades competentes como significativas en términos de impacto sistémico, perfil de riesgo ICT o relevancia operativa, con participación posible de autoridades financieras y, cuando proceda, coordinación a nivel europeo. DORA no deja el detalle técnico del todo en el texto de nivel 1; parte del diseño y de la metodología se ha desarrollado mediante normas técnicas y marcos derivados. Pero la lógica base del reglamento ya bastaba para anticipar algo que en 2026 nadie debería discutir: la TLPT no se delega a Seguridad como un ejercicio aislado ni se compra como si fuera un escaneo premium.

El verdadero alcance: funciones críticas o importantes, no activos sueltos

Aquí suele empezar el choque entre el mapa regulatorio y la realidad interna. DORA utiliza el concepto de funciones críticas o importantes en varios puntos, y ese concepto condiciona la TLPT. Si tu inventario sigue centrado en activos tecnológicos pero no en servicios de negocio, personas, procesos y terceros que sostienen esas funciones, llegarás a la prueba con una foto incompleta. Y una TLPT con una foto incompleta produce una conclusión muy cara: “la entidad probó algo, pero no necesariamente lo que importaba”.

La selección del alcance debería construirse en este orden:

1. Identificación de funciones críticas o importantes y de los procesos que las soportan.
2. Mapeo técnico y de terceros que intervienen en esos procesos.
3. Identificación de dependencias únicas, concentraciones y puntos de fallo relevantes.
4. Selección de escenarios de amenaza plausibles con base en inteligencia.
5. Definición de objetivos de ejercicio y de límites operativos para evitar daño desproporcionado.

Suena obvio. Lo sorprendente es cuántas entidades todavía lo hacen al revés: empiezan por el proveedor de pentesting, luego piden una lista de IPs y acaban diciendo que ya “cubrieron DORA”. No, cubrieron un contrato.

Hay tres errores de alcance que aparecen una y otra vez.

El primero es excluir a terceros ICT críticos de facto por comodidad contractual. DORA art. 28 y siguientes convierten la gestión de terceros en una pieza central del régimen. Si una función crítica depende de un proveedor de nube, un MSP, una plataforma de pagos, un servicio de autenticación, un SOC externo o un integrador con privilegios elevados, dejar esa dependencia fuera de la prueba por pura fricción comercial vacía de sentido el ejercicio. Otra cosa es cómo incluirla sin romper acuerdos, SLAs o restricciones del proveedor. Pero excluirla sin más no resuelve el problema; solo lo disimula.

El segundo error es definir un alcance puramente perimetral. Las amenazas de 2026 no respetan la nostalgia por el firewall. La cadena de ataque relevante puede arrancar en identidad, desarrollarse mediante abuso de APIs, aprovechar una configuración débil en SaaS, pivotar a través de herramientas de administración remota o explotar credenciales de un tercero. Si la TLPT no refleja cómo se ataca hoy a una entidad financiera concreta, será una representación teatral con factura regulatoria.

El tercero es ignorar los procesos manuales y de contingencia. DORA no se obsesiona solo con la capa técnica. Busca resiliencia operativa digital. Si una caída o intrusión afecta una función crítica, ¿existe un procedimiento operativo viable? ¿Está probado? ¿Depende de una persona concreta? ¿Se activa dentro del tiempo de tolerancia que el negocio ha aprobado? Una TLPT bien diseñada puede poner a prueba precisamente esos puntos de transición entre tecnología y operación, que son donde más fallan las organizaciones que creen que “tener playbooks” es lo mismo que poder ejecutarlos.

Frecuencia: el mínimo legal son tres años, pero ese dato por sí solo engaña

DORA art. 27 fija que las entidades sujetas a TLPT deberán realizarla al menos cada tres años. Ese es el mínimo regulatorio. No es una recomendación de cadencia óptima ni una excusa para aparcar el asunto hasta el siguiente ciclo presupuestario.

En la práctica, el trabajo preparatorio serio empieza mucho antes de la ventana formal de prueba. Primero, porque una TLPT depende de un programa continuo de pruebas del art. 26: escaneos, evaluaciones, revisiones de arquitectura, pruebas de continuidad, ejercicios de respuesta, validación de controles. Segundo, porque la remediación posterior rara vez cabe en un trimestre si el ejercicio destapa problemas de segmentación, identidad privilegiada, logging, procedimientos de crisis o dependencia opaca de terceros. Tercero, porque la autoridad competente puede modular la exigencia en función del perfil de riesgo. Nadie sensato quiere llegar a una conversación supervisora con la defensa de que “la ley decía cada tres años”. La ley también exige gestionar el riesgo mientras tanto.

La mejor manera de leer el plazo trienal es como un hito formal dentro de un ciclo de validación más amplio. Si tu entidad aún no tiene:

• un inventario limpio de funciones críticas o importantes,
• una cartografía actualizada de terceros y subcontratistas relevantes,
• registros de incidentes clasificables con trazabilidad,
• telemetría suficiente para reconstruir actividad adversaria,
• y criterios internos sobre tolerancia a disrupciones,

Entonces no estás a “tres años” de una TLPT. Estás a varios programas previos de poder hacerla con sentido.

La inteligencia de amenazas no es decoración metodológica

El adjetivo threat-led no está ahí para adornar la portada del proyecto. Marca la diferencia entre una prueba avanzada y una colección de técnicas ofensivas sin narrativa de riesgo. Una TLPT debe apoyarse en inteligencia de amenazas pertinente para la entidad: actores, técnicas, vectores, motivaciones, campañas y patrones de compromiso plausibles para su perfil operativo.

Operativamente, eso exige al menos cuatro decisiones que no conviene improvisar.

La primera es qué fuentes de inteligencia vas a usar y cómo justificarás su relevancia. No basta con un informe genérico de cibercrimen de 80 páginas. La entidad debe poder explicar por qué un conjunto de TTPs, familias de acceso inicial o rutas de abuso son plausibles para su modelo de negocio, geografía, exposición, stack tecnológico y ecosistema de terceros. En banca minorista quizá pesen campañas de fraude, secuestro de sesión, abuso de identidad y compromiso de proveedores. En infraestructuras de mercado o seguros, el mapa cambia. La TLPT que sirve a todos, en realidad, no sirve a nadie.

La segunda es traducir inteligencia a objetivos de prueba. Saber que un actor usa living-off-the-land, abuso de MFA fatigue o explotación de edge appliances no convierte automáticamente eso en un escenario testable. Hace falta transformarlo en hipótesis operativas: qué intentará el equipo rojo, qué detectores deberían saltar, qué acciones están prohibidas, qué evidencia validará el objetivo y qué impacto máximo se tolera. Ahí es donde se separa un proyecto serio de un festival de técnicas.

La tercera es decidir cuánto sabe el equipo defensor. Una TLPT puede incorporar distintos grados de conocimiento y coordinación para medir detección y respuesta de forma realista. La cuestión no es teatralizar el secretismo, sino diseñar un ejercicio que aporte verdad sin provocar ruido interno inútil ni riesgo no controlado. Si tu SOC está completamente informado, medirás menos capacidad real de detección. Si nadie está coordinado, puedes provocar interrupciones absurdas. Hay que hilar fino.

La cuarta es actualizar el escenario cuando el entorno cambia. Y en 2026 cambia deprisa. Nuevas dependencias SaaS, fusiones, cambios en autenticación, externalización de operaciones, migraciones a nube, exposición de APIs o campañas activas pueden volver irrelevante el guion definido meses antes. Una TLPT basada en una amenaza que dejó de ser plausible sirve, como mucho, para aprender sobre burocracia.

Proveedores: no basta con que “hagan pentesting”

DORA exige que las pruebas avanzadas se lleven a cabo por testers con la idoneidad adecuada. El artículo 27 apunta tanto a testers internos como externos, aunque en la práctica muchas entidades recurren a proveedores especializados por razones de independencia, experiencia y capacidad. El problema es que el mercado está lleno de proveedores que venden “red teaming”, “adversary simulation” o “purple team” como si fueran equivalentes regulatorios. No lo son.

Al evaluar proveedores para una TLPT bajo DORA, hay al menos siete preguntas que deberían hacerse por escrito.

Una: ¿puede el proveedor demostrar experiencia en ejercicios sobre funciones críticas financieras, no solo en entornos TI genéricos? Un proveedor brillante rompiendo laboratorios puede ser decepcionante navegando dependencias reales, restricciones operativas, ventanas de cambio y sensibilidad de negocio.

Dos: ¿qué capacidad tiene para construir inteligencia específica de la entidad y convertirla en escenarios trazables? Si te enseña una lista de TTPs estándar y la llama “threat-led”, mala señal.

Tres: ¿cómo gestiona reglas de enfrentamiento, kill switch, validación previa de técnicas destructivas y coordinación de crisis? Este punto importa más que el marketing. Una TLPT mal gobernada puede producir indisponibilidad real o efectos colaterales en terceros.

Cuatro: ¿cómo documenta la cadena de ataque, los artefactos utilizados, la evidencia de impacto y la remediación requerida? Si el entregable final es un PDF con severidades CVSS y capturas de pantalla, estás comprando otra cosa.

Cinco: ¿qué hará con los terceros de tu cadena operativa? Muchos ejercicios naufragan porque el proveedor no está preparado para coordinar notificaciones, autorizaciones y límites técnicos con nube, telecoms, MSPs o procesadores.

Seis: ¿cómo asegura independencia y manejo de información sensible? La TLPT puede revelar rutas de compromiso extraordinariamente valiosas para un atacante. El gobierno del dato generado por el ejercicio es parte del riesgo.

Siete: ¿está dispuesto a vincular hallazgos a controles concretos, propietarios internos y evidencias de cierre? Si no, la organización acabará con una lista de sustos y poca capacidad de demostrar progreso.

La ironía aquí es conocida: algunas entidades han sofisticado mucho sus cláusulas de contratación tecnológica, pero siguen comprando pruebas avanzadas con procesos de selección pensados para un escaneo externo. Luego llegan las sorpresas.

La relación con el registro de información y los terceros ICT: donde la TLPT deja de ser un ejercicio técnico

La guía operativa realmente madura sobre TLPT bajo DORA no puede ignorar el registro de información sobre acuerdos contractuales con terceros ICT. Aunque el registro responde a obligaciones del capítulo V y a sus actos de desarrollo, su utilidad para una TLPT es inmediata: permite saber quién participa realmente en la prestación de una función crítica, dónde hay subcontratación en cascada, qué servicios soportan procesos esenciales, qué jurisdicciones intervienen y qué restricciones contractuales podrían impedir o condicionar una prueba.

Si el registro está incompleto, la TLPT nacerá coja. No porque el regulador exija meter una hoja Excel en el informe ofensivo, sino porque el ejercicio necesita visibilidad real de la cadena operativa.

Hay una conexión menos obvia y más interesante. DORA art. 28 exige gestionar el riesgo derivado de terceros ICT, y artículos posteriores detallan elementos contractuales, estrategias de salida y seguimiento. Una TLPT bien diseñada puede revelar que la concentración de privilegios, la opacidad de un subprocesador o la incapacidad contractual para testar determinados componentes no son “temas de procurement”, sino riesgos materiales sobre la resiliencia de funciones críticas. Traducido: la prueba puede destapar que tu problema no es una vulnerabilidad, sino una dependencia mal gobernada.

Esto afecta de lleno a nube y servicios gestionados. Si una función crítica descansa sobre un proveedor cloud, un entorno SaaS clave y un MSP con acceso privilegiado, la entidad necesita aclarar antes de la prueba tres cosas: qué está autorizado testar, qué requerirá coordinación previa y qué evidencias puede obtener sin violar límites contractuales o poner en riesgo a otros clientes del proveedor. No es glamuroso. Es decisivo.

El registro de información, además, sirve para otra tarea ingrata pero imprescindible: identificar puntos donde el ejercicio podría terminar en un callejón sin salida por falta de derecho de auditoría, falta de cooperación técnica o ausencia de contactos de escalado. Mejor descubrir eso en planificación que el día en que el equipo rojo necesite validar un escenario y medio ecosistema responda con un “abra un ticket”.

Incidentes, detección y reporting: si tu SOC no aprende nada, la TLPT ha fallado

DORA dedica su capítulo III a la gestión, clasificación y notificación de incidentes relacionados con las TIC. Aunque una TLPT no es un incidente real, su valor regulatorio y operativo aumenta cuando se usa para poner a prueba si los mecanismos de detección, escalado y decisión funcionarían ante una intrusión plausible.

Ese vínculo con incidentes importa por tres razones.

La primera es la visibilidad. Muchas entidades descubren en ejercicios avanzados que su capacidad de logging y correlación es mucho más pobre de lo que sugerían sus cuadros de mando. Una cadena de ataque realista no se detecta por la existencia abstracta de un SIEM. Se detecta porque las fuentes correctas están activadas, retenidas, normalizadas y cubiertas por reglas útiles, y porque alguien puede interpretar la señal sin perderse entre ruido.

La segunda es el gobierno. DORA obliga a contar con procesos para registrar, clasificar y tratar incidentes. Una TLPT debería permitir observar si los umbrales de escalado interno, las rutas de decisión y la coordinación entre seguridad, tecnología, negocio, legal, compliance y comunicación funcionarían bajo presión. Si la entidad tarda horas en identificar quién puede autorizar una contención agresiva sobre una función crítica, el problema no es técnico: es de gobernanza.

La tercera es la evidencia de aprendizaje. Aunque DORA no convierte cada prueba en un pseudo-incidente regulatorio, la disciplina de documentar detecciones, tiempos de respuesta, decisiones de contención, brechas de telemetría y remediaciones ayuda a demostrar madurez. También alimenta algo que demasiadas organizaciones siguen tratando como mundos separados: el circuito entre pruebas, gestión de vulnerabilidades, incidentes, continuidad y riesgo de terceros.

Si quieres una pregunta incómoda que merece hacerse antes de lanzar una TLPT, aquí va: si el equipo rojo compromete una cuenta privilegiada y exfiltra datos simulados de una función crítica sin activar alertas útiles, quién en tu entidad puede demostrar qué falló exactamente? Si la respuesta es difusa, no necesitas solo una prueba. Necesitas una arquitectura mínima de verdad operacional.

Qué evidencias van a pedirte de facto, aunque la norma no te dé una plantilla cerrada

DORA no proporciona una lista universal y mágica de anexos documentales para cada TLPT, pero quien crea que bastará con el informe final confunde cumplimiento con fe. La autoridad competente, auditoría interna o segunda línea querrán ver trazabilidad. Y la trazabilidad se construye antes, durante y después del ejercicio.

La evidencia útil suele agruparse en cinco bloques.

1. Gobierno y decisión

Debería existir constancia del patrocinio del ejercicio, la aprobación del alcance, los objetivos, las funciones críticas o importantes afectadas, las reglas de enfrentamiento, los límites operativos, los criterios de suspensión y la asignación de roles. Si la entidad tiene comité de riesgo tecnológico, comité de resiliencia o estructuras equivalentes, la decisión debería reflejarse ahí. No por liturgia. Porque una TLPT puede tocar procesos sensibles y requiere respaldo inequívoco.

2. Base metodológica y de inteligencia

Aquí entran el racional del escenario, las fuentes de inteligencia, el mapeo de amenazas a activos y procesos, y la justificación de por qué el ejercicio es representativo para la entidad. Es la pieza que más diferencia una TLPT seria de un red team genérico. Sin este bloque, el adjetivo threat-led se cae solo.

3. Evidencia de ejecución

Incluye bitácoras, cronologías, técnicas utilizadas, puntos de entrada, movimientos laterales, controles evadidos, hitos de impacto y mecanismos de seguridad activados o fallidos. Si hubo coordinación con terceros, tickets, autorizaciones y registros de interacción también deberían preservarse. Una línea temporal limpia vale más que veinte capturas dispersas.

4. Detección, respuesta y decisiones

Logs, alertas, tiempos de triage, escalados, decisiones de contención, falsas pistas, gaps de cobertura y actuaciones manuales. Este bloque es oro para el SOC, para la segunda línea y para auditoría. También es el que más vergüenzas saca a la superficie, que en realidad es buena noticia si luego se corrigen.

5. Remediación verificable y retesting

Hallazgos sin propietario y sin fecha son literatura. La entidad necesita convertir resultados en acciones con responsable, prioridad, dependencia presupuestaria cuando exista, criterio de cierre y validación posterior. En hallazgos estructurales —segmentación, IAM, privilegios de terceros, logging insuficiente, arquitectura plana— conviene distinguir entre mitigación inmediata y solución definitiva. Mezclar ambas cosas solo maquilla el problema.

Checklist de evidencias para auditoría

Esta es una de las pocas listas que sí merece existir, porque evita el clásico desenlace de “hicimos la prueba, ahora a ver qué nos piden”. Si tu entidad debe defender una TLPT ante supervisión, auditoría interna o segunda línea, estas evidencias suelen marcar la diferencia:

• Documento de alcance vinculado a funciones críticas o importantes y a activos/procesos/terceros asociados.
• Aprobación formal por el órgano o comité interno competente.
• Reglas de enfrentamiento, ventanas de prueba, límites operativos y criterios de parada.
• Justificación de la inteligencia de amenazas utilizada y de la plausibilidad del escenario.
• Due diligence del proveedor o justificación de idoneidad del equipo interno/externo tester.
• Autorizaciones contractuales o técnicas de terceros ICT incluidos en el alcance.
• Cronología completa del ejercicio con técnicas, hitos y artefactos relevantes.
• Registros de detección y respuesta del SOC o de equipos equivalentes.
• Lista de hallazgos con criticidad, impacto sobre funciones críticas y control afectado.
• Plan de remediación con responsables nominativos y fechas objetivo.
• Retesting o validación de cierre de las remediaciones prioritarias.
• Lecciones aprendidas incorporadas al marco de riesgo ICT, continuidad e incidentes.

Nótese el detalle incómodo: varias de estas evidencias dependen de procurement, legal, continuidad, negocio y terceros. Precisamente por eso la TLPT no puede quedarse encerrada en Seguridad.

Qué suele salir mal en la práctica

Las entidades que fracasan en la preparación de una TLPT rara vez fallan por falta de entusiasmo técnico. Fallan por cuestiones mucho más prosaicas.

Mapas desactualizados. El negocio cree que una función crítica depende de tres sistemas; la realidad son nueve, dos SaaS, un proveedor de autenticación y un proceso manual de excepción que solo conoce Operaciones. Cuando el ejercicio empieza, el alcance “real” ya no coincide con el documental.

Telemetría insuficiente. Hay EDR, SIEM, IAM y mil siglas más, pero faltan logs clave, la retención es corta o la normalización impide reconstruir la secuencia. El resultado es una moraleja repetida: teníamos herramientas, no visibilidad.

Gobierno difuso. Nadie tiene claro quién aprueba una contención que pueda afectar una función crítica, quién comunica con un tercero durante la prueba o quién decide suspender una técnica si el riesgo operativo aumenta. Ese vacío convierte un ejercicio controlado en una negociación caótica.

Contratos mudos. La entidad descubre tarde que no tiene cláusulas adecuadas para coordinar pruebas con ciertos terceros, ni derechos de cooperación suficientes, ni un contacto operativo creíble. Cuando DORA insiste en terceros ICT no está rellenando papel. Está hablando de esto.

Remediación sin dientes. El informe identifica problemas serios, pero nadie ata presupuesto, plazos y propietarios. Se cierran hallazgos “administrativamente” mientras la causa estructural sigue intacta. Luego, claro, llega el siguiente ejercicio y repite el diagnóstico.

Demasiado secreto o demasiado teatro. Si ocultas todo a todos, arriesgas daño operativo innecesario. Si avisas tanto que conviertes el ejercicio en una coreografía, pierdes valor. Diseñar el grado de conocimiento interno es una decisión de gobierno, no un detalle logístico.

Implicaciones para entidades financieras españolas

Para entidades españolas, DORA no llega a un terreno virgen. Llega a un ecosistema que ya conoce inspección tecnológica, exigencias de continuidad, outsourcing crítico, guías del supervisor y una sensibilidad creciente por la resiliencia operacional. Pero la TLPT introduce una presión distinta: obliga a conectar piezas que muchas organizaciones todavía gestionan en silos bastante cómodos.

En bancos, aseguradoras, entidades de pago y proveedores relevantes del mercado español, hay tres implicaciones concretas.

La primera afecta al modelo de relación entre CISO, continuidad, riesgo operacional y compliance. Si esas funciones siguen viéndose solo en comités trimestrales y cada una mantiene su propio inventario de dependencias, la preparación de una TLPT revelará la fragmentación con una eficacia casi cruel. No por mala voluntad, sino porque el ejercicio exige una verdad compartida sobre procesos críticos, tolerancias, terceros y respuesta.

La segunda toca a las filiales de grupos internacionales. Muchas dependen de plataformas, SOCs, identidades o servicios centralizados fuera de España. Eso complica el alcance, la autorización y la evidencia de una TLPT. La filial regulada necesita poder demostrar cómo participa en decisiones, qué activos y procesos propios están cubiertos, qué terceros intragrupo intervienen y cómo se obtendrá cooperación efectiva. “Eso lo lleva el grupo” no impresiona especialmente a un supervisor cuando lo que está en juego es una función crítica local.

La tercera tiene que ver con proveedores. El mercado español está muy externalizado en determinadas capas: servicios gestionados, integradores, centros de operación, herramientas antifraude, comunicaciones, plataformas de atención y, por supuesto, nube. Cuanto más externalizada esté la función, más valor tendrá un registro de información bien trabajado y más difícil será fingir que el riesgo se acaba en el límite del contrato.

Hay además una interacción práctica con GDPR que no conviene minusvalorar. Una TLPT no debería usar datos personales reales más allá de lo estrictamente necesario y controlado; tampoco debería generar tratamientos accesorios sin base organizativa clara. Si la prueba incluye sistemas con datos sensibles, legal y privacidad deben revisar minimización, seudonimización cuando proceda, acceso del proveedor y retención de artefactos. El regulador de resiliencia y el de protección de datos no siempre hablan entre sí, pero el incidente operativo que mezclara ambos mundos sí llegaría a dos mesas distintas.

Cómo prepararse de forma inteligente, sin convertir la TLPT en un proyecto infinito

La preparación útil no consiste en lanzar un “programa TLPT” ornamental durante dieciocho meses. Consiste en resolver, en secuencia, las dependencias que bloquean un ejercicio serio.

Empieza por una decisión elemental: elegir una o dos funciones críticas o importantes candidatas y reconstruir su cadena operativa completa. No en PowerPoint; en un mapa vivo con procesos, identidades privilegiadas, aplicaciones, datos, flujos, terceros, subcontrataciones conocidas, procedimientos manuales y dependencias de continuidad. Si este mapa ya existe y está bien mantenido, enhorabuena: vas por delante de media industria. Si no existe, todo lo demás será una aproximación simpática.

Después, cruza ese mapa con tres capas de realidad.

La primera es la inteligencia de amenazas específica. ¿Qué técnicas y vectores son plausibles contra esa función? ¿Dónde están los accesos iniciales probables? ¿Qué dependencias ofrecen rutas indirectas? ¿Qué activos expuestos o credenciales privilegiadas podrían facilitar el camino?

La segunda es la telemetría. ¿Podrías detectar la progresión de un atacante en los puntos críticos de la cadena? No basta con responder “tenemos EDR”. Revisa logs de identidad, administración remota, correo, SaaS clave, red interna, APIs, actividad privilegiada, exfiltración y trazas de terceros gestionados. La TLPT suele castigar duramente el optimismo en esta materia.

La tercera es el gobierno operativo. Define antes del ejercicio quién aprueba, quién sabe, quién no sabe, quién coordina con el proveedor, quién habla con terceros, quién puede parar una técnica, quién registra decisiones y quién convierte hallazgos en acciones obligatorias. Si eso se improvisa, el informe final describirá tus carencias organizativas con un detalle poco halagador.

Una vez hechas esas tareas, ya tiene sentido seleccionar proveedor y diseñar el escenario. Antes, no. Antes solo estarías comprando incertidumbre premium.

La objeción habitual: “ya hacemos red teaming, así que estamos cubiertos”

No necesariamente. Un programa interno de red teaming puede ser excelente y, aun así, no cubrir por sí solo lo que DORA espera de una TLPT. La objeción tiene parte de verdad: muchas capacidades necesarias para TLPT ya existen en organizaciones maduras. Equipos morados, emulación adversaria, ejercicios de crisis, pruebas de continuidad y validación de detección aportan muchísimo. Pero DORA añade algo que no siempre está presente: encuadre regulatorio, foco en funciones críticas o importantes, articulación con terceros ICT, trazabilidad de gobierno y capacidad de demostrarlo todo de forma coherente.

Por eso el debate útil no es “TLPT versus red teaming”. El debate útil es si tu práctica actual puede alinearse y evidenciarse conforme al estándar exigible por DORA. A veces la respuesta será sí, con ajustes de alcance, documentación y gobernanza. Otras veces habrá que rediseñar bastante más. Fingir equivalencia automática solo ahorra tiempo hasta que llega la revisión.

Lo que deberías poder responder antes de decir que estás listo

Antes de afirmar internamente que la entidad está preparada para una TLPT bajo DORA, intenta responder de forma documental —no verbal, no aspiracional— a estas preguntas:

• ¿Qué funciones críticas o importantes se van a probar y por qué esas?
• ¿Qué terceros ICT participan materialmente en esas funciones y qué límites contractuales o técnicos condicionan la prueba?
• ¿Qué escenario de amenaza se considera plausible para la entidad y con qué inteligencia se sustenta?
• ¿Qué técnicas están permitidas, cuáles prohibidas y quién puede suspender el ejercicio?
• ¿Qué capacidad de detección y respuesta se espera del SOC y cómo se medirá?
• ¿Qué evidencias exactas se preservarán para supervisión, auditoría y remediación?
• ¿Cómo se priorizarán hallazgos que afecten a identidad, segmentación, terceros o continuidad?
• ¿Qué mecanismo obliga al negocio y a tecnología a cerrar de verdad lo descubierto?

Si alguna de esas respuestas depende de “ya lo veremos con el proveedor”, todavía no estás listo. El proveedor puede ejecutar una parte crítica del ejercicio. No puede sustituir el conocimiento que la entidad debe tener sobre sí misma.

La conclusión incómoda: DORA usa la TLPT para medir madurez institucional, no solo seguridad técnica

La lectura superficial de DORA convierte la TLPT en una obligación periódica para entidades significativas. La lectura correcta la sitúa como una prueba de madurez institucional. El reglamento no quiere saber solo si te pueden comprometer. Asume que, con suficiente tiempo y realismo, probablemente podrán acercarse bastante. Lo que quiere medir es algo más serio: si entiendes tus funciones críticas, si conoces tus dependencias, si gobiernas a tus terceros, si detectas actividad adversaria, si decides bajo presión y si aprendes con disciplina trazable.

Eso explica por qué las TLPT generan tanto nerviosismo y tantas simplificaciones de pasillo. Son caras, complejas y políticamente delicadas dentro de la organización. También son, bien hechas, de las pocas pruebas capaces de derribar la ficción de que resiliencia equivale a tener herramientas desplegadas y políticas publicadas.

A estas alturas de 2026, la discusión ya no debería ser si DORA “aprieta” demasiado con las pruebas avanzadas. La discusión seria es otra: cuántas entidades siguen descubriendo demasiado tarde que su mayor debilidad no era un exploit, sino la distancia entre sus diagramas de control y la forma real en que operan sus servicios críticos.

Ese es el quid. Y precisamente por eso conviene preparar la TLPT como lo que es: una evaluación de resiliencia operativa con consecuencias de gobierno, no un pentest con esteroides y una factura más larga.