Hay una diferencia práctica entre tener respaldos y tener continuidad. El respaldo responde “¿puedo recuperar el dato?”. El plan de recuperación ante desastres —DRP— responde una pregunta mucho 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.
Primero el negocio, después la tecnología
El error más común es empezar por los servidores. Un DRP útil empieza por un análisis de impacto al negocio (BIA), 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. Casi 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 DRP que declara los quince sistemas como prioridad máxima es un DRP que no se puede ejecutar, porque el día del incidente no hay manos para atender quince frentes a la vez.
Traducir criticidad a RPO y RTO por 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.
Qué debe contener el plan para ser ejecutable
Un DRP 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. Casi siempre: 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 DRP únicamente en el servidor de archivos que el plan 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.
El simulacro: lo que separa un plan real de un PDF
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 PyME, un simulacro de escritorio semestral más una prueba funcional trimestral es un ritmo sostenible y suficiente para mantener el plan vivo.
Los errores que más vemos
- 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 es un plan que miente.
- Olvidar a las personas. Si el desastre impide llegar a la oficina, ¿desde dónde trabaja la gente y con qué equipos?
Por dónde empezar 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.