--- title: "Resiliencia “explicable”: cuando ya no basta con recuperarse, hay que demostrarlo" description: "Durante años, la resiliencia tecnológica se midió con dos números: RTO (cuánto tarda la empresa en volver a operar) y RPO (cuánta información se puede perder). Hoy, esa métrica se queda corta. La pres..." url: https://revistacloud.com/resiliencia-explicable-cuando-ya-no-basta-con-recuperarse-hay-que-demostrarlo/ date: 2026-02-02 modified: 2026-01-29 author: "Antonio" image: https://revistacloud.com/wp-content/uploads/2024/01/transformacion-tecnologica.jpg categories: ["Guías y recursos"] tags: ["certificación", "resiliencia"] type: post lang: es --- # Resiliencia “explicable”: cuando ya no basta con recuperarse, hay que demostrarlo Durante años, la resiliencia tecnológica se midió con dos números: **RTO** (cuánto tarda la empresa en volver a operar) y **RPO** (cuánta información se puede perder). Hoy, esa métrica se queda corta. La presión regulatoria —y también la de clientes, auditores y ciberaseguradoras— está empujando a un nuevo estándar: **recuperar rápido ya no es suficiente; hay que poder explicar, con trazabilidad y evidencias, qué pasó con los datos, qué controles actuaron y cómo se reanudó el servicio sin “manchas” en los registros**. A ese giro se le puede poner nombre: **resiliencia basada en la explicabilidad**. Es, en la práctica, una resiliencia con “modo auditoría” incorporado: procesos repetibles, registros limpios, evidencias automatizadas y una cadena de custodia del dato que aguante preguntas incómodas. ### El detonante: regulación + riesgo + confianza El cambio no viene solo de Europa. Se está viendo un patrón global: - **Reguladores** que piden controles verificables, gestión del riesgo de terceros, pruebas periódicas y notificación de incidentes. - **Clientes enterprise** que exigen garantías contractuales (y cada vez más, cuestionarios de seguridad con requisitos de evidencias). - **Aseguradoras** que quieren menos promesas y más “pruebas de vida”: copias inmutables, tests de restauración, inventarios de activos, y procedimientos documentados. Europa ha puesto la quinta con marcos como **DORA**, aplicable desde el **17 de enero de 2025**, que estandariza obligaciones de resiliencia digital en el sector financiero y su cadena de proveedores. En paralelo, marcos de referencia como **NIST Cybersecurity Framework 2.0** (muy usado como lenguaje común en auditorías y programas de seguridad) refuerzan la idea de gobernanza y evidencia, añadiendo la función **Govern** al núcleo del framework. Y en EE. UU., incluso cuando no se habla de “resiliencia” en abstracto, se exige **divulgación formal**: la SEC obliga a reportar incidentes materiales en un **Form 8-K** en un plazo de **4 días hábiles** desde que la empresa determina su materialidad. ### ¿Qué es exactamente “resiliencia explicable”? No es un producto. Es un enfoque. Se parece más a pasar de “hacer copias” a **operar un sistema de recuperación verificable**. Incluye, como mínimo: 1. **Trazabilidad del dato (data lineage):** poder reconstruir el recorrido: origen → transformaciones → accesos → almacenamiento → backups → restauración. 2. **Auditabilidad por diseño:** logs coherentes, centralizados, con retención definida, integridad y control de cambios. 3. **Recuperación repetible:** runbooks, automatización, y pruebas periódicas con resultados almacenados como evidencia. 4. **Controles demostrables:** identidad, mínimos privilegios, segmentación, cifrado, gestión de claves, y un modelo claro de responsabilidades con terceros. La diferencia clave con el “DR clásico” es que aquí la pregunta no es solo “¿volvimos?”, sino: - **¿Qué datos se vieron afectados?** - **¿Qué controles evitaron (o no) la propagación?** - **¿Qué evidencia demuestra que la restauración fue íntegra y sin manipulación?** - **¿Cómo se justifica ante auditoría que el negocio volvió a un estado confiable?** --- ## Tabla rápida de normativas y marcos: dónde aplican y qué piden en la práctica | Norma / marco | Dónde aplica | Resumen (lo que termina exigiendo en resiliencia y evidencias) | | --- | --- | --- | | **DORA (UE)** | Entidades financieras y parte relevante de su cadena TIC en la UE | Gestión del riesgo TIC, respuesta e **informes de incidentes**, consideraciones fuertes sobre **terceros**, y pruebas de resiliencia con documentación verificable. | | **NIS2 (UE)** | Sectores esenciales e importantes (incluye proveedores digitales como cloud, DC, etc., según desarrollo normativo) | Refuerza medidas de gestión del riesgo y umbrales de incidentes “significativos”; impulsa disciplina de controles y reporting. | | **RGPD (UE)** | Tratamiento de datos personales en la UE | Seguridad del tratamiento, minimización, control de acceso, y capacidad de demostrar cumplimiento (accountability). *(Amplifica la necesidad de trazabilidad y evidencias).* | | **NIST CSF 2.0 (EE. UU. y global)** | Marco voluntario muy adoptado (empresas, sector público, supply chain) | Lenguaje común para programas de ciberseguridad: ahora incluye **Govern**, consolidando gobernanza, métricas y evidencia como parte del “core”. | | **SEC – divulgación ciber (EE. UU.)** | Empresas cotizadas en EE. UU. | Obliga a **reportar incidentes materiales** y a describir gobernanza/gestión del riesgo: empuja a tener procesos de evaluación, trazabilidad y registro. | | **PDPA (Singapur)** | Organizaciones que tratan datos personales en Singapur | Obligaciones de protección y, con el régimen de notificación de brechas, necesidad de procesos y evidencias para evaluación, contención y comunicación. | | **Privacy Act + APP (Australia)** | Organizaciones cubiertas por la Privacy Act; principios APP | Principios de manejo de información personal + obligaciones prácticas (incluyendo respuesta ante incidentes y notificaciones bajo esquemas aplicables): eleva el listón de registros y control. | > Nota práctica: además de “la ley”, muchas industrias añaden capas (financiero, salud, infra crítica) con guías y estándares sectoriales que, en auditoría, se vuelven casi tan exigentes como una norma. --- ## La parte incómoda: la evidencia se convierte en “producto” En una auditoría moderna, o en un incidente serio, la empresa no compite solo con tecnología. Compite con su **capacidad de demostrar** que opera con control. En la práctica, los equipos terminan necesitando un “paquete” de evidencias recurrentes: - **Inventario vivo** de sistemas, datos y dependencias (incluye SaaS y terceros). - **Mapa de flujos**: qué datos viajan, a dónde y por qué. - **Pruebas de restauración** con actas: cuándo se hicieron, qué se recuperó, cuánto tardó, qué falló y cómo se corrigió. - **Inmutabilidad real** en copias críticas (y evidencia de que no se puede borrar “por accidente”). - **Cadena de custodia** en incidentes: quién accedió, qué cambió, y cuándo. - **Control de cambios** (infraestructura y configuración) con trazabilidad. La clave es que estas evidencias no deberían “fabricarse” a mano tras el susto. Deben **salir solas** del sistema operativo de la organización. --- ## Cómo diseñar una estrategia de resiliencia desde el cumplimiento ### 1) Empezar por el dato, no por la infraestructura La pregunta inicial no es “¿qué backup usamos?”, sino: - ¿Qué datos son **críticos**, cuáles son **personales**, cuáles son **regulados**? - ¿Qué conjuntos de datos sostienen procesos vitales (facturación, ERP, identidad, operaciones)? - ¿Qué dependencias externas pueden romper la recuperación (DNS, IdP, repositorios, licencias, APIs)? Esto lleva a una clasificación útil para resiliencia: **criticidad + sensibilidad + dependencia**. ### 2) Definir “recuperación confiable”, no solo “recuperación rápida” Una restauración que reanuda el servicio pero deja dudas (integridad, manipulación, inconsistencias) puede ser un problema legal y reputacional. Aquí ayudan tres controles “anti-discusión”: - **Restauraciones verificadas** (checks de integridad, validaciones de aplicaciones, reconciliación de datos). - **Entornos de cuarentena** para restaurar sin reinfectar (ransomware y movimientos laterales). - **Runbooks con puntos de control** (qué validar antes de declarar el servicio “OK”). ### 3) Hacer de los logs un activo regulatorio Si los logs son incompletos, dispersos o no confiables, la empresa se queda sin relato. Buenas prácticas típicas en resiliencia explicable: - Centralización (SIEM / logging) con **retención definida**. - **Integridad** (sellado, WORM o mecanismos equivalentes). - Correlación con identidad (quién hizo qué). - Evidencia de alertas y respuesta (qué se detectó, qué se contuvo, qué se aprendió). ### 4) Tratar a los terceros como parte del perímetro DORA, NIS2 y el mundo real convergen aquí: si una parte crítica depende de un proveedor, su resiliencia es tu resiliencia. Esto implica: - Contratos con **SLA de recuperación** y requisitos de evidencias. - Derecho a auditoría / informes (SOC, ISO, etc.). - Plan de salida (portabilidad, recuperación alternativa). ### 5) Convertir las pruebas en rutina (y guardar el “examen”) El test anual “para cumplir” ya no vale. Lo que está funcionando mejor en organizaciones serias es: - Pruebas pequeñas y frecuentes (por sistemas). - Un test “realista” periódico (simulación de pérdida, ransomware, caída de proveedor). - Almacenar resultados como evidencia: tiempos, fallos, acciones correctivas. --- ## El mensaje final: resiliencia es confianza verificable El mundo se está moviendo hacia un modelo en el que **la continuidad del negocio se audita**. No solo se ejecuta. Y esa es la esencia de la resiliencia explicable: diseñar para recuperarse, sí, pero sobre todo **para poder demostrar que la recuperación fue correcta, íntegra y gobernada**.