"¿Tienen respaldos?" "Sí." Esa conversación tranquiliza a mucha gente que no debería estar tranquila. Porque tener backups no es tener continuidad. Un respaldo que nunca se probó restaurar es una esperanza, no un plan.
Bajo un marco de compliance, la continuidad y la recuperación ante desastres (DR) dejan de ser "tenemos backups" y se vuelven un control probado y evidenciado. Ahí está la diferencia que importa.
De la promesa a la prueba
SOC 2 e ISO 27001 no te preguntan si respaldas — te piden evidencia de que puedes recuperarte. Eso significa: objetivos definidos de RPO (cuántos datos puedes perder) y RTO (en cuánto tiempo vuelves a operar), y pruebas de restauración documentadas que demuestran que esos objetivos se cumplen. La promesa "tenemos backups" no pasa una auditoría; la prueba "restauramos en X horas, aquí está la bitácora" sí.
La regla que sostiene todo
El estándar sigue siendo 3-2-1: tres copias de tus datos, en dos medios distintos, con una fuera de sitio (idealmente inmutable, para que un ransomware no la toque). Pero el 3-2-1 sin pruebas de restauración periódicas es media solución — el control de compliance es el ciclo completo: respaldar, replicar, y verificar que restauras.
¿Qué piden SOC 2 e ISO 27001 en concreto?
- SOC 2, criterio de disponibilidad: el A1.2 pide procesos de respaldo e infraestructura de recuperación; el A1.3 pide probar los procedimientos del plan de recuperación. No basta con describirlos.
- ISO 27001:2022: el control 8.13 cubre los respaldos de información, el 5.29 la seguridad de la información durante una interrupción, y el 5.30 la preparación de las TIC para la continuidad del negocio.
En los dos marcos el auditor busca lo mismo: objetivos definidos, un plan escrito y evidencia de que se probó.
¿Qué tipo de prueba de recuperación hacer?
No todas las pruebas son iguales, y conviene combinarlas a lo largo del año:
- Ejercicio de escritorio. El equipo recorre un escenario, por ejemplo ransomware un lunes a las 7 de la mañana, y valida quién hace qué, con qué contactos y en qué orden. No toca sistemas, pero descubre huecos en el plan.
- Restauración parcial. Recuperar una base de datos, un servidor o un buzón en un entorno aislado y verificar que funciona, no solo que el archivo existe.
- Recuperación completa de un sistema crítico. Levantar el servicio desde cero y medir el tiempo real contra el RTO comprometido.
- Conmutación al sitio alterno, cuando existe, para confirmar que la operación corre desde ahí.
La práctica mínima razonable es probar la recuperación de los sistemas críticos al menos una vez al año, y cada vez que cambie la infraestructura que los soporta.
¿Qué evidencia guardar de cada prueba?
- Fecha, alcance y sistemas incluidos.
- Quién participó y quién aprobó.
- Tiempo real de recuperación contra el RTO objetivo, y punto de recuperación obtenido contra el RPO.
- Qué falló o tardó más de lo esperado.
- Acciones correctivas, con responsable y fecha, y su cierre.
Una prueba que falla no es un mal resultado: es exactamente para lo que sirve. Lo que no pasa una auditoría es no haber probado. Si quieres profundizar en los objetivos, lee RPO y RTO en cristiano; para la verificación de respaldos, el backup que nunca se probó no es un backup.
¿Qué debe contener el plan para que sirva el día del desastre?
El plan se escribe con calma, pero se usa bajo presión y tal vez sin acceso a los sistemas de siempre. Por eso necesita, como mínimo:
- El orden de recuperación. Primero lo que todo lo demás necesita: red, DNS y directorio; después los sistemas críticos del negocio; al final lo que puede esperar.
- Los criterios para declarar el desastre y quién tiene la autoridad para hacerlo.
- Contactos y escalamiento, incluidos proveedores, aseguradora y asesoría legal, disponibles fuera de los sistemas afectados.
- Credenciales de emergencia resguardadas fuera de línea. Si el directorio cayó, las contraseñas guardadas en él no sirven.
- Dónde están los respaldos y cómo llegar a ellos si el sitio principal no está disponible.
- El plan de comunicación a empleados, clientes y, si aplica, autoridades.
El detalle completo está en qué debe contener un plan de recuperación ante desastres, y la estrategia de copias que lo sostiene, en 3-2-1-1-0.
Por qué conviene verlo así
Porque el día que de verdad lo necesites —un ransomware, una falla de hardware, un error humano— no vas a querer descubrir que el respaldo no servía. El control de compliance te obliga a probarlo antes de la emergencia. Es, una vez más, la lógica del andamiaje: el proceso que te acredita es el mismo que te salva.
No lo rechaces por no tener quién lo opere. Tú lo vendes y conservas a tu cliente; nosotros ponemos la ingeniería, con nuestro nombre junto al tuyo.
Conoce BehindITarrow_forwardPreguntas frecuentes
help ¿Tener respaldos es lo mismo que tener continuidad?
No. Un respaldo que nunca se probó restaurar es una esperanza, no un plan. La continuidad exige objetivos de recuperación (RPO/RTO) y pruebas de restauración documentadas que demuestren que puedes volver a operar.
help ¿Qué es la regla 3-2-1?
Tres copias de tus datos, en dos medios distintos, con una fuera de sitio (idealmente inmutable). Es el estándar de respaldo, pero solo funciona como control si se acompaña de pruebas de restauración periódicas.
help ¿Qué evidencia de DR pide una auditoría de compliance?
Objetivos definidos de RPO y RTO, y bitácoras de pruebas de restauración que demuestren que esos objetivos se cumplen. No basta con afirmar que respaldas: hay que comprobar que restauras.
Rubén Espinoza es fundador y Director Técnico de IT Experts de México. Trabaja en la industria de TI desde 1998: diseña y opera soluciones de infraestructura, ciberseguridad, continuidad, automatización y tecnología OT para entornos empresariales e industriales. Escribe desde proyectos reales y sistemas en producción.
Ver perfil y todos sus artículos →