La resiliencia no se demuestra con una política ni con un pentest anual.
Se demuestra probando capacidades, corrigiendo debilidades y volviendo a medir.
Qué función, sistema o proceso se intenta someter a estrés y contra qué amenaza.
Cobertura, independencia, hallazgos, repetición y cierre de acciones.
Que la prueba cambia controles y que la corrección ha sido verificada.
| Clave | Qué revisar | Qué debería demostrar |
|---|---|---|
| PR-01 | Mapa de funciones y sistemas | Qué parte de la operación crítica entra en el programa. |
| PR-02 | Escenario de amenaza | Qué capacidad o control pretende validar la prueba. |
| PR-03 | Cobertura y frecuencia | Por qué se prueba esa población y con qué periodicidad. |
| PR-04 | Hallazgos | Clasificación, riesgo, propietario y medida correctiva. |
| PR-05 | Retest | Evidencia de que la corrección funciona. |
| PR-06 | Aprendizaje | Cambios en arquitectura, procedimientos o continuidad. |
| Ref. | Evidencia | Qué debería demostrar |
|---|---|---|
| DP-01 | Programa de pruebas | Alcance basado en riesgo, tipos de prueba y calendario. |
| DP-02 | Mapa de cobertura | Relación entre funciones críticas, sistemas y pruebas realizadas. |
| DP-03 | Escenarios y threat intelligence | Por qué la amenaza seleccionada es relevante. |
| DP-04 | Resultados y hallazgos | Debilidades, impacto, prioridad y responsables. |
| DP-05 | Remediación y retest | Corrección implantada y eficacia confirmada. |
| DP-06 | Lecciones y mejora | Cambios derivados en riesgo, arquitectura y procedimientos. |
Una prueba de resiliencia no debería limitarse al componente más visible. Si una función crítica depende de identidad, DNS, mensajería, almacenamiento, un tercero cloud y procedimientos manuales de recuperación, el diseño de prueba debe considerar la cadena completa. De otro modo, se valida una pieza y se deja sin probar el escenario que realmente detendría el servicio.
El programa debería combinar pruebas frecuentes y focalizadas con ejercicios de mayor profundidad. Escaneos, revisiones de configuración, restauraciones, ejercicios de crisis, pruebas de conmutación y simulaciones de ataque responden a preguntas diferentes. Ninguna sustituye automáticamente a las demás.
Antes de ejecutar, conviene definir objetivo, alcance, reglas, criterios de parada, tratamiento de datos, responsables, evidencias y condiciones de éxito. Después, cada hallazgo debe conectarse con una función, un riesgo, un propietario y una fecha de remediación. La prueba termina cuando se verifica la corrección, no cuando se entrega el informe.
| Tipo de prueba | Pregunta que responde | Evidencia esperada |
|---|---|---|
| Restauración | ¿Podemos recuperar datos y servicio dentro de los objetivos aprobados? | Logs, tiempos medidos, integridad y validación de negocio. |
| Conmutación | ¿La arquitectura secundaria funciona con capacidad y dependencias reales? | Secuencia, errores, capacidad, DNS, identidades y retorno controlado. |
| Tabletop | ¿Las personas toman decisiones coordinadas bajo presión? | Cronología, decisiones, comunicaciones y brechas de procedimiento. |
| TLPT | ¿Un adversario realista puede comprometer funciones críticas a través de personas, procesos y tecnología? | Inteligencia de amenazas, narrativa, evidencias técnicas y remediación. |
Una simulación madura no necesita cifrar producción. Puede evaluar la cadena completa: robo de credenciales, acceso remoto, movimiento lateral, desactivación de controles, intento de acceso a copias, detección, aislamiento y recuperación. El objetivo es comprobar si los controles y decisiones funcionan juntos.
El equipo debería medir tiempo hasta detección, tiempo hasta contención, cuentas comprometidas, sistemas alcanzables, capacidad para proteger las copias y tiempo real de restauración. También debería comprobar si negocio sabe priorizar servicios, si legal identifica obligaciones y si comunicación puede operar con información incompleta.
El valor aparece cuando los resultados cambian arquitectura, configuración, procedimientos o inversión. Repetir la misma prueba un año después permite verificar si la resiliencia mejoró o si solo se cerraron hallazgos documentalmente.
Que un pentest no encuentre una vía crítica no demuestra que la organización pueda contener, continuar y recuperar una función ante una disrupción severa.
El plan anual debería mostrar por qué se prueba cada función, qué riesgo cubre y qué técnica se utiliza. Repetir siempre los mismos pentests sobre los mismos activos indica comodidad, no cobertura basada en riesgo.
Revisaría si los escenarios incluyen dependencias de terceros, fallos simultáneos, errores humanos y degradación parcial. También si existen criterios de parada, protección de datos, restauración del entorno y gestión de hallazgos críticos durante la prueba.
La medida más útil es la evolución. El programa debería demostrar que disminuyen tiempos de detección y recuperación, que las remediaciones se verifican y que las lecciones cambian arquitectura y procedimientos. Un informe cerrado sin retest es evidencia de actividad, no de mejora.
La forma más útil de trabajar este tema es convertirlo en una cadena verificable de decisiones, responsables y evidencias. No basta con afirmar que existe un control: hay que poder reconstruir qué se decidió, con qué información, quién lo ejecutó y cómo se comprobó después.
En Pruebas de resiliencia y TLPT: DORA quiere evidencia en producción, el análisis debería cubrir al menos población, periodo, muestra, criterio, corroboración y conclusión. Esto exige coordinar a Dirección, Riesgo TIC, Continuidad, Seguridad, Operaciones, Compras, Legal y propietarios del servicio y trabajar sobre servicios, funciones TIC, contratos, proveedores, subcontratistas, ubicaciones, datos, dependencias y estrategias de salida. Cuando cada área conserva una parte distinta de la información, se retrasan decisiones, se duplican controles y se aceptan excepciones sin una visión completa.
Una forma práctica de evitarlo es utilizar un expediente único por servicio, sistema, proceso o decisión relevante. Puede ser una herramienta GRC, un repositorio documental controlado o un registro estructurado. Lo importante es conectar alcance, propietario, riesgo, control, evidencia, excepción y acción, con fecha, fuente y estado.
Ese expediente debe mantenerse durante la operación ordinaria. Si solo se completa antes de una auditoría, la organización obtiene una fotografía preparada, pero no una visión fiable del control. La actualización debería activarse ante cambios de arquitectura, proveedor, alcance, responsables, requisitos, incidentes o resultados de pruebas. También conviene definir una revisión periódica para detectar documentación formalmente vigente pero materialmente obsoleta.
La revisión debe separar cuatro preguntas: si el control está bien diseñado, si se ha implantado en todo el alcance, si funciona de forma sostenida y si reduce realmente el riesgo o cumple el objetivo. Mezclar estas preguntas lleva a conclusiones débiles: una política aprobada puede no haberse desplegado, una herramienta instalada puede no cubrir toda la población y una actividad ejecutada puede no producir el efecto esperado.
| Dimensión | Qué debe quedar definido | Evidencia esperada |
|---|---|---|
| Alcance | Procesos, servicios, sistemas y terceros incluidos en «Pruebas de resiliencia y TLPT: DORA quiere evidencia en producción». | Alcance aprobado, inventario y exclusiones justificadas. |
| Responsabilidad | Quién decide, ejecuta, valida y acepta desviaciones. | RACI, actas, aprobaciones y propietarios nominativos. |
| Operación | Actividades repetibles, entradas, salidas, plazos y escalados. | Procedimiento, tickets, registros, alertas y métricas. |
| Eficacia | Cómo se comprueba que el control cambia el riesgo o el resultado. | Pruebas, tendencias, incidencias, muestreo y acciones. |
Una captura demuestra un estado puntual. Un expediente completo demuestra el proceso, el criterio, la trazabilidad y la capacidad de corregir.
El objetivo no es generar más documentación, sino conservar la documentación que permite gobernar, operar y demostrar. La madurez aparece cuando las evidencias nacen del proceso ordinario y no de una campaña previa a la auditoría.