El 10 de agosto de 2026 un sismo fuerte se sintió en buena parte de Colombia. En cuestión de minutos, cientos de gerentes se hicieron la misma pregunta: "si esto hubiera tumbado el servidor, ¿en cuánto tiempo volvíamos a operar?". La mayoría no tenía respuesta. No porque les faltara tecnología, sino porque nunca escribieron un plan.
Esperar que no pase no es una estrategia. Un incendio, una inundación, un ransomware o un simple daño de disco pueden dejar a una empresa sin operar por días. La diferencia entre las que vuelven en horas y las que pierden clientes —o cierran— casi nunca es el tamaño: es si tenían un plan de continuidad y disaster recovery, probado y actualizado. Esta guía explica los conceptos que todo gerente debería manejar antes de que llegue el día en que los necesite.
Continuidad, disaster recovery y contingencia: no son lo mismo
Estos tres términos se usan como sinónimos y no lo son. Entenderlos evita comprar lo que no es.
Plan de Continuidad del Negocio (BCP, Business Continuity Plan) — es el paraguas. Responde: ¿cómo sigue operando el negocio —completo, no solo TI— ante una interrupción grave? Cubre personas, procesos, proveedores, sedes y tecnología. Es un plan de negocio, no un plan técnico.
Disaster Recovery (DR) — es la parte tecnológica del BCP. Responde: ¿cómo recuperamos sistemas, datos y servicios de TI después de un desastre? Aquí viven los backups, la replicación, los sitios alternos y los tiempos de recuperación.
Plan de contingencia — es el término más ambiguo. En seguridad y salud en el trabajo suele referirse a emergencias físicas (evacuación, incendios, sismos). En TI, "plan de contingencia informático" es prácticamente sinónimo de disaster recovery. Cuando alguien pide un "plan de contingencia", lo primero es aclarar si habla de la emergencia física o de la recuperación de TI: son proyectos distintos, con dueños distintos.
En resumen: el BCP contiene al DR, y el DR es lo que en TI a veces llaman contingencia. Este artículo se centra en la continuidad y el disaster recovery de TI, que es donde una empresa de soporte tecnológico marca la diferencia.
RPO y RTO: las dos métricas que definen todo
No se puede diseñar un plan sin fijar primero dos números. Todo lo demás —presupuesto, tecnología, proveedor— se deriva de ellos.
RPO (Recovery Point Objective) — ¿cuántos datos puedes permitirte perder? Si tu RPO es de 24 horas, la última copia buena es de ayer y todo lo capturado hoy se pierde si el desastre ocurre ahora. Sistemas transaccionales (facturación, ERP) suelen exigir un RPO de minutos.
RTO (Recovery Time Objective) — ¿cuánto tiempo puedes estar sin operar? Un RTO de 8 horas significa que en 8 horas la empresa debe estar funcionando de nuevo —no que el backup tarda 8 horas—. Incluye preparar el entorno, restaurar, validar y devolver el acceso a los usuarios.
Estos dos números no son técnicos: son decisiones de negocio. Cuanto más bajos (menos pérdida, menos tiempo caído), más cuesta la solución. El trabajo del plan es equilibrar el costo de la caída contra el costo de prevenirla. Si quieres profundizar en cómo se aterrizan RPO y RTO en la estrategia de copias, mira nuestra guía de backup empresarial, que trata la regla 3-2-1, la retención y la inmutabilidad en detalle.
Las fases de un plan de continuidad
Un plan de continuidad no es un documento que se escribe una vez: es un ciclo que se mantiene vivo. Estas son sus fases.
- Análisis de impacto (BIA, Business Impact Analysis). Se identifican los procesos críticos y cuánto duele que cada uno se detenga (por hora, por día). De aquí salen los RPO y RTO por sistema.
- Evaluación de riesgos. Qué amenazas son realistas para tu empresa y sede: ransomware, falla de hardware, corte eléctrico prolongado, inundación, sismo, error humano.
- Diseño de estrategias de recuperación. Para cada sistema crítico, cómo se recupera: backup inmutable, replicación a otra sede o a la nube, sitio alterno, procedimientos manuales temporales.
- Documentación del plan. Roles, responsables, contactos, pasos exactos de recuperación, orden de prioridad de sistemas. Un plan que solo vive en la cabeza de una persona no es un plan.
- Pruebas. Simulacros y restauraciones reales. Un plan sin probar es una hipótesis.
- Mantenimiento y mejora. Cada cambio de infraestructura, cada nuevo sistema y cada prueba fallida alimenta la siguiente versión del plan.
La estructura mínima de un plan documentado incluye: alcance, procesos críticos con sus RPO/RTO, roles y cadena de mando, procedimientos de recuperación por sistema, directorio de contactos (interno y proveedores), y calendario de pruebas.
ISO 22301 e ISO 27001: los marcos de referencia
Dos normas internacionales ordenan este trabajo, y aparecen cada vez más en licitaciones y requisitos de clientes grandes en Colombia.
ISO 22301 es la norma de Sistemas de Gestión de Continuidad de Negocio (SGCN). Define cómo estructurar, operar y mejorar la continuidad de forma sistemática. Es la referencia cuando la pregunta es "¿qué norma internacional establece un sistema de gestión de continuidad?".
ISO 27001 es la norma de seguridad de la información. No es de continuidad, pero se traslapa: su dominio de continuidad exige planes de recuperación, y una buena estrategia de DR es evidencia directa de cumplimiento.
No hace falta certificarse para beneficiarse. Usar estas normas como checklist —aunque no busque el sello— ya eleva el nivel del plan y facilita responder a clientes que sí las exigen. En Colombia, además, la Ley 1581 de protección de datos personales obliga a medidas de seguridad y disponibilidad que un plan de DR ayuda a sustentar.
Cómo se prueba un plan (y los errores más comunes)
El error número uno es no probar. El número dos es "probar" solo verificando que el backup corrió, sin restaurar nada. Un backup que nunca se restauró es un backup que no sabe si sirve.
Una prueba real incluye: restaurar un sistema en un entorno aislado, medir cuánto tardó (¿cumplió el RTO?), verificar que los datos estén completos y consistentes (¿cumplió el RPO?), y documentar qué falló para corregirlo. Lo mínimo razonable es una prueba de restauración mensual de los sistemas críticos y un simulacro completo al menos una vez al año.
Otros errores frecuentes: backups conectados a la misma red que producción (el ransomware los borra junto con todo lo demás), planes desactualizados que apuntan a servidores que ya no existen, y depender de una sola persona que "sabe cómo se hace".
Cuánto cuesta en Colombia
Rangos estimados en COP —cada caso es particular—. Un plan de continuidad documentado con su BIA, para una PYME, suele costar del orden de varios millones de setup según la complejidad. La parte de disaster recovery —replicación, backup inmutable, sitio alterno en la nube— tiene un componente mensual que para una empresa mediana (500 GB a algunos TB, con M365) suele ubicarse en el orden de 1 a 3 millones de COP al mes, según los RPO y RTO que exijas. Tómalo como referencia, no como cotización: el número real depende de tus sistemas críticos y tiempos de recuperación.
Si alguien te ofrece "continuidad" o "disaster recovery" por mucho menos, pregunta qué incluye: casi siempre falta la parte más importante —las pruebas de restauración y la inmutabilidad—, que es justo lo que hace que el plan funcione el día que lo necesita.
El plan que no se prueba no existe
Continuidad y disaster recovery no son un producto que se compra una vez: son una capacidad que se construye y se mantiene. Empieza por dos números —cuánto dato puede perder y cuánto tiempo puede estar caído— y de ahí se diseña todo lo demás.
En mitecni ayudamos a empresas en Colombia a diseñar, implementar y probar su plan de disaster recovery y continuidad: BIA, RPO/RTO por sistema, backup inmutable y simulacros de restauración reales. Si quieres saber en cuánto tiempo volvería a operar tu empresa hoy, conoce nuestro servicio de Disaster Recovery o solicita un diagnóstico gratuito.