La continuidad de negocio es la capacidad de una empresa de seguir operando cuando algo falla, y se mide en dos números por sistema: cuánta información puede perder y cuánto tiempo puede estar detenida. No es un documento ni un producto que se compre: es el resultado de cuatro capas que se construyen en orden —los datos, la infraestructura, las personas y los proveedores— y que se validan ensayándolas.
Esta guía junta lo que hemos escrito por partes y lo pone en secuencia. Si ya sabes qué buscas, cada sección liga al artículo que lo desarrolla a fondo.
¿Qué es la continuidad de negocio y qué no es?
La confusión más común es tratarla como sinónimo de respaldo. El respaldo contesta si el dato se puede recuperar. La continuidad contesta en cuánto tiempo la empresa vuelve a facturar, que es una pregunta bastante más amplia y casi siempre con una respuesta peor.
Entre una y otra hay cosas que nadie respalda porque no son datos: la configuración del firewall, las llaves de las licencias, quién tiene autoridad para declarar un incidente, el teléfono personal del proveedor del ERP. Una empresa puede tener copias impecables y estar tres días parada porque faltó una de esas piezas.
La prueba de fuego: si el servidor principal muriera esta tarde, ¿alguien en la empresa podría decir, sin consultar a nadie, en qué orden se levantan los sistemas y quién ejecuta cada paso? Si la respuesta depende de una sola persona, lo que tienes no es continuidad.
¿Cuáles son las cuatro capas de la continuidad?
Se construyen de abajo hacia arriba. Invertir en la capa tres cuando la uno está abierta es la forma más cara de no resolver nada.
| Capa | Qué asegura | Cómo se verifica |
|---|---|---|
| 1 · Datos | Que exista una copia recuperable y que al menos una no se pueda borrar | Restaurando y cronometrando |
| 2 · Infraestructura | Que haya dónde levantar los sistemas y en qué orden | Con un ensayo funcional en entorno aislado |
| 3 · Personas | Que el procedimiento lo pueda ejecutar quien no lo escribió | Pidiéndole a otra persona que lo siga |
| 4 · Proveedores | Que el tiempo de respuesta de terceros esté en el contrato | Leyendo el contrato antes del incidente |
¿Por qué no basta con tener respaldos?
Porque un trabajo de respaldo puede cerrar “exitosamente” durante meses y producir archivos de los que no se recupera nada útil. Las causas que más vemos son una copia que vive en el mismo servidor que pretende proteger, bases de datos copiadas en caliente sin el mecanismo del motor, y un alcance que incluye el ERP pero deja fuera el servidor de licencias o la configuración del firewall.
La capa uno tiene un criterio de aceptación concreto, la regla 3-2-1-1-0, y de sus cinco números el que falta casi siempre es la copia inmutable, que es justo la que decide si pagas un rescate. Todo eso está desarrollado en el respaldo que nunca se probó.
¿Cómo se mide la continuidad?
Con dos números por sistema. El RPO es cuánta información puedes permitirte perder: si respaldas a medianoche y el servidor muere a las cinco de la tarde, tu RPO real son diecisiete horas de captura. El RTO es cuánto tiempo puede estar caído ese sistema, medido desde que se declara el incidente hasta que la gente puede volver a trabajar sobre él.
Lo importante de los dos números no es definirlos en una junta, es compararlos contra la realidad. El RTO que la mayoría declara son horas; el que resulta de cronometrar una restauración completa suele ser días. Esa diferencia es el proyecto.
Para traducirlo a lenguaje de dirección: toma lo que factura la empresa en un día, divídelo entre las horas laborales y multiplícalo por el RTO real. Súmale el costo de recapturar el trabajo que cabe en tu ventana de RPO. Ese número es el presupuesto que la continuidad justifica.
¿Cómo se construye el plan?
En cuatro pasos y en este orden, porque cada uno usa la salida del anterior: un análisis de impacto al negocio para ordenar los procesos por lo que cuesta detenerlos, un RPO y un RTO por sistema, el plan escrito de forma que lo ejecute alguien que no lo redactó, y el simulacro. El procedimiento completo, con el formato del plan y los tres niveles de ensayo, está en cómo hacer un plan de continuidad de negocio.
Dos detalles que arruinan planes por completo y no cuestan nada corregir: guardar el plan únicamente en el servidor de archivos que pretende recuperar, y no nombrar un suplente para quien declara el desastre. El día del incidente se pierden horas en que nadie se atreve a tomar la decisión.
¿Qué pasa si toda la operación depende de una persona?
Entonces el RTO no lo fija la tecnología, lo fija si esa persona contesta el teléfono. Es la capa tres y es la que más se subestima, porque el riesgo se acumula sin que nadie lo decida: el que sabe resuelve más rápido, así que se le manda todo, y al año siguiente es el único que conoce la contraseña del hipervisor.
No se arregla contratando a alguien más. Se arregla documentando los accesos, sacando las credenciales de las cabezas y metiéndolas a un gestor, y repartiendo la ejecución del plan entre al menos dos personas. Está desarrollado en qué pasa cuando el que sabía de sistemas renuncia.
¿En qué orden invertir con presupuesto limitado?
Este es el orden que recomendamos cuando no se puede hacer todo el mismo año. Las primeras cuatro líneas se resuelven con orden y disciplina más que con compras.
- Averigua tu RTO real. Una restauración cronometrada en entorno aislado. Sin ese número, todo lo demás se decide a ciegas.
- Saca una copia de la red de producción. Lo que mate al original no debe poder alcanzar a la copia.
- Documenta accesos y árbol de contactos, y guárdalos fuera de la red.
- Nombra quién declara el incidente, con suplente.
- Agrega la copia inmutable. Aquí empieza el gasto, y es el que mejor se defiende ante dirección.
- Ensaya de escritorio cada seis meses y haz una prueba funcional trimestral.
- Mete el tiempo de respuesta de tus proveedores al contrato, en la siguiente renovación.
¿Cómo sé si lo que tengo hoy funciona?
- ¿Sé cuánto tarda en volver a operar mi sistema más crítico, con un número medido y no estimado?
- ¿Existe al menos una copia que no se pueda borrar con credenciales de administrador?
- ¿El plan está accesible si el servidor de archivos no responde?
- ¿Alguien distinto del que lo escribió lo ha ejecutado alguna vez?
- ¿Está definido quién declara el incidente, y su suplente?
- ¿El tiempo de respuesta de mis proveedores críticos está por contrato?
- ¿Se ensayó algo en los últimos seis meses?
Si dudaste en tres o más, lo que tienes es un plan en papel. Conviene empezar por el primer punto —el número medido— se consigue en una tarde y reordena todo lo demás, porque casi siempre resulta ser el doble o el triple de lo que la empresa suponía.
Nuestro Diagnóstico de Infraestructura y Seguridad incluye una prueba real de restauración cronometrada en entorno aislado sobre un sistema acordado contigo, más el plan de remediación por fases. Ese número es el punto de partida de las cuatro capas, no el RTO de toda la operación: ese se construye encima, sistema por sistema.