Un plan de continuidad de negocio es el documento que define cómo sigue operando la empresa cuando un sistema se cae: qué procesos se sostienen primero, quién decide, en qué orden se levantan los sistemas y en cuánto tiempo. Se construye en cuatro pasos —análisis de impacto al negocio, un RPO y un RTO por sistema, el plan escrito y el simulacro— y el paso que casi todos se saltan es el último, que es justamente el que lo vuelve real.
Hay una diferencia práctica entre tener respaldos y tener continuidad. El respaldo responde “¿puedo recuperar el dato?”. El plan de continuidad de negocio responde una pregunta más incómoda: “¿en cuánto tiempo vuelvo a facturar?”.
Una empresa puede tener respaldos impecables y aun así estar tres días detenida, simplemente porque nadie decidió de antemano en qué orden levantar los sistemas, quién autoriza qué, o dónde están las llaves de las licencias.
¿Cuál es la diferencia entre un plan de continuidad y un DRP?
Los dos términos se usan como sinónimos y no lo son del todo. El DRP —plan de recuperación ante desastres— cubre la parte tecnológica: cómo se restauran los sistemas y en cuánto tiempo. El plan de continuidad de negocio es más amplio: incluye a las personas, a los proveedores, la comunicación con clientes y cómo sigue operando el negocio mientras la tecnología vuelve.
En una empresa mediana no vale la pena separarlos en dos documentos. Lo que sigue es un solo plan, en cuatro pasos, y el orden no es negociable: cada paso usa la salida del anterior.
Paso 1 · ¿Cuánto te cuesta cada hora de paro?
El error más común es empezar por los servidores. Un plan útil empieza por un análisis de impacto al negocio —BIA, por sus siglas en inglés—, que es más simple de lo que suena: sentarse con los responsables de cada área y responder tres preguntas por proceso.
- ¿Qué pasa si este proceso se detiene una hora? ¿Un día? ¿Una semana?
- ¿Cuánto cuesta esa detención, en dinero, en multas o en clientes perdidos?
- ¿De qué sistemas, personas y proveedores depende para funcionar?
El resultado es una lista de procesos ordenada por criticidad real, no por lo que TI cree que es importante. Siempre hay sorpresas: descubres que la facturación depende de un servicio que nadie consideraba crítico, o que el proceso más ruidoso puede esperar dos días sin consecuencias.
Regla útil: si todo es crítico, nada es crítico. Un plan que declara los quince sistemas como prioridad máxima no se puede ejecutar, porque el día del incidente no hay manos para atender quince frentes a la vez.
Paso 2 · ¿Qué RPO y qué RTO lleva cada sistema?
Con el BIA en la mano, cada sistema recibe dos objetivos. RPO es cuánta información puedes permitirte perder; RTO, cuánto tiempo puede estar caído. Un ejemplo de cómo suele quedar en una empresa mediana:
| Sistema | RPO objetivo | RTO objetivo | Implicación técnica |
|---|---|---|---|
| ERP / facturación | 15 minutos | 4 horas | Respaldo continuo y equipo alterno listo |
| Correo | 1 hora | 4 horas | Servicio en nube con retención |
| Servidor de archivos | 24 horas | 1 día | Respaldo diario con copia externa |
| Sitio web institucional | 1 semana | 3 días | Respaldo semanal |
Este cuadro es la conversación de presupuesto más honesta que puedes tener con dirección: bajar el RTO del ERP de tres días a cuatro horas cuesta dinero, y ahora se ve exactamente qué se compra con ese dinero.
Paso 3 · ¿Cómo se escribe un plan que pueda ejecutar alguien más?
Un plan que sirve cabe en pocas páginas y se puede seguir bajo presión, por alguien que no lo escribió:
- Quién declara el desastre. Con nombre y suplente. Sin esto, se pierden horas en que nadie se atreve a tomar la decisión.
- Árbol de contactos. Personal clave, proveedores, seguros, soporte de fabricantes. Con teléfonos personales: si cae el correo corporativo, el directorio interno no sirve.
- Orden de recuperación. Qué se levanta primero y de qué depende cada cosa. El orden habitual: red y autenticación, luego bases de datos, luego aplicaciones, al final estaciones de trabajo.
- Procedimientos concretos. Pasos de restauración por sistema, con rutas, credenciales de emergencia resguardadas y dependencias.
- Plan de comunicación. Qué se le dice a clientes, empleados y —si hubo datos personales comprometidos— a la autoridad.
- Criterios de retorno a la normalidad. Cómo se decide que ya se salió del incidente.
Detalle que arruina planes: guardar el plan únicamente en el servidor de archivos que pretende recuperar. Debe existir una copia fuera de línea y accesible desde fuera de la red: impresa, en un teléfono o en un servicio independiente.
Paso 4 · ¿Cómo se ensaya el plan?
Un plan sin ensayar tiene el mismo valor que un respaldo sin restaurar. Hay tres niveles, y conviene subirlos en orden:
- De escritorio. Dos horas, en una sala. Se plantea un escenario y cada responsable explica qué haría. Detecta huecos de proceso a costo casi cero.
- Funcional. Se restaura de verdad un sistema en un entorno aislado y se cronometra. Valida que la tecnología responde.
- Completo. Se simula la caída de la sede y se opera desde el sitio alterno. Es el más caro y el que más aprendizajes deja.
Para una empresa mediana, un simulacro de escritorio semestral más una prueba funcional trimestral es un ritmo sostenible y suficiente para mantener el plan vivo.
¿Qué errores aparecen con más frecuencia?
- Plan escrito por un proveedor y jamás leído por el cliente. El día del incidente, nadie dentro sabe ejecutarlo.
- Depender de una sola persona. Si la recuperación solo la sabe hacer una persona, tu RTO depende de que esa persona conteste el teléfono.
- Ignorar a los proveedores. Si tu ERP lo opera un tercero, su tiempo de respuesta es parte de tu RTO. Debe estar en el contrato, no en la buena voluntad.
- No actualizarlo. Un plan que no refleja el sistema que migraste a la nube el año pasado describe una empresa que ya no existe.
- Olvidar a las personas. Si el desastre impide llegar a la oficina, ¿desde dónde trabaja la gente y con qué equipos?
¿Qué se puede hacer esta semana?
No hace falta un proyecto de seis meses para dar el primer paso útil:
- Lista tus cinco procesos más críticos y pon un costo por hora de paro a cada uno.
- Escribe el RPO y el RTO que hoy realmente tienes, no el deseado.
- Arma el árbol de contactos y guárdalo fuera de la red.
- Define quién declara el desastre, con suplente.
- Agenda un simulacro de escritorio de dos horas.
Con eso ya tienes más continuidad real que la mayoría de las empresas de tu tamaño. Lo demás se construye encima.
Como parte de nuestro diagnóstico medimos el tiempo real de recuperación de un sistema acordado contigo —lo restauramos en un entorno aislado y cronometramos— y entregamos el plan de remediación por fases. Ese número es tu punto de partida, no el RTO de toda la operación: ese se construye encima, sistema por sistema. Si quieres además revisar tu exposición legal en el manejo de datos personales, el autodiagnóstico LFPDPPP toma cinco minutos.