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:
- Trazabilidad del dato (data lineage): poder reconstruir el recorrido: origen → transformaciones → accesos → almacenamiento → backups → restauración.
- Auditabilidad por diseño: logs coherentes, centralizados, con retención definida, integridad y control de cambios.
- Recuperación repetible: runbooks, automatización, y pruebas periódicas con resultados almacenados como evidencia.
- 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.
