Un plan de continuidad del negocio se arma respondiendo con la gerencia tres preguntas: qué procesos no pueden detenerse, cuánto tiempo pueden estar detenidos y cuánta información se puede perder. Con esas respuestas se definen roles, copias de seguridad verificadas con una copia fuera de la empresa y un plan de recuperación de sistemas que se prueba con simulacros.
¿Qué diferencia hay entre un BCP y un DRP?
El BCP (plan de continuidad del negocio) define cómo sigue operando la empresa cuando algo grave falla: personas, procesos, proveedores y comunicación. El DRP (plan de recuperación ante desastres) es la parte tecnológica: qué sistemas se restauran primero, quién lo hace y en cuánto tiempo.
El DRP vive dentro del BCP. Una empresa puede recuperar sus servidores en cuatro horas y aun así perder clientes si nadie sabía cómo facturar a mano mientras tanto, o si nadie les avisó qué estaba pasando. Al revés también ocurre: un BCP muy bien redactado no sirve si la base de datos no se puede restaurar.
| Aspecto | BCP (continuidad del negocio) | DRP (recuperación ante desastres) |
|---|---|---|
| Pregunta que responde | ¿Cómo seguimos atendiendo clientes si algo grave falla? | ¿Cómo volvemos a poner en marcha los sistemas? |
| Alcance | Procesos, personas, sedes, proveedores, comunicación | Servidores, aplicaciones, bases de datos, redes, copias de seguridad |
| Dueño natural | Gerencia general con los líderes de proceso | Responsable de tecnología (interno o externo) |
| Cómo se prueba | Ejercicios de escritorio y simulacros de operación alterna | Restauraciones reales, cronometradas frente al tiempo objetivo |
¿Cómo se hace el análisis de impacto en una empresa mediana?
El análisis de impacto se hace respondiendo con la gerencia tres preguntas: qué procesos no pueden detenerse, cuánto tiempo pueden estar detenidos y cuánta información se puede perder. Las respuestas definen qué es crítico, cuánto invertir y en qué orden recuperar cada sistema.
Así lo aplico en mi trabajo y así está descrito en el caso de 99,9 % de disponibilidad con DRP en la Fundación Socya: primero las preguntas de negocio, después la tecnología. En una empresa de 20 a 200 colaboradores, los procesos críticos suelen ser pocos: facturación y recaudo, nómina, atención a clientes, despachos u operación principal. Lo importante es que los defina la gerencia, no el área de sistemas.
RTO y RPO en lenguaje de gerencia
El RTO (Recovery Time Objective, tiempo objetivo de recuperación) es cuánto tiempo puede estar detenido un proceso antes de que el daño sea inaceptable: «si la facturación se cae, tenemos máximo cuatro horas». El RPO (Recovery Point Objective, punto objetivo de recuperación) es cuánta información se puede perder: «podemos volver a digitar las ventas de una hora, no las de un día».
Ambos números tienen precio. Un RTO de minutos exige redundancia y sistemas duplicados; uno de un día se cubre con buenas copias y un procedimiento claro. Por eso la decisión es de la gerencia: es un balance entre lo que cuesta proteger y lo que cuesta estar detenido.
¿Quién hace qué cuando se activa el plan?
Un plan de continuidad necesita roles con nombre propio y un suplente para cada uno: quién declara la crisis, quién coordina la recuperación técnica, quién opera los procesos de forma alterna y quién comunica. Si esos roles no están escritos, la crisis se gestiona con improvisación.
- Líder de crisis: normalmente el gerente general o quien él designe. Decide activar el plan y autoriza gastos de emergencia.
- Responsable de recuperación tecnológica: ejecuta el DRP y reporta avances con horarios fijos.
- Líderes de proceso: activan la operación alterna de su área (formatos manuales, sede alterna, trabajo remoto).
- Responsable de comunicación: informa a empleados, clientes, proveedores y, si aplica, a las autoridades.
En una crisis aguda, el mando debe ser directo. Cuento en Liderazgo sin maquillaje que, el día que un ransomware cifró parte de los servidores de archivos en una organización donde trabajé, por fortuna con respaldos probados, no hubo deliberación: aislar la red, activar el plan de recuperación e informar a la gerencia cada treinta minutos. La reflexión colectiva llegó después, en la revisión del incidente.
Hay un punto que casi nadie mira: el conocimiento de las personas. Cuando diseñamos los planes de recuperación, lo más difícil de proteger no fue el hardware, sino el saber de quienes podían restaurar cada sistema. Si una sola persona sabe hacerlo, el plan tiene un punto único de falla.
¿Bastan las copias de seguridad para estar protegido?
No. Una copia de seguridad que nunca se ha restaurado no prueba nada; solo una restauración real demuestra que la información se recupera completa y a tiempo. Además, debe existir al menos una copia fuera de la empresa y separada de la red principal, para resistir un incendio, un robo o un ransomware.
Una regla práctica muy difundida es la 3-2-1: tres copias de la información, en dos medios distintos, con una fuera de la sede. Más allá de la regla, la gerencia debe exigir evidencia: cuándo fue la última restauración de cada sistema crítico, quién la hizo y cuánto tardó.
Lo aprendí de la manera difícil, y lo cuento en el capítulo 14 de Liderazgo sin maquillaje: una falla eléctrica un viernes en la noche dañó la base de datos de un sistema crítico. Había copias, pero la última restauración completa se había hecho casi dos años antes, quien la hizo ya no trabajaba con nosotros y el procedimiento estaba desactualizado. Restablecer el servicio tomó casi un día. Esa noche entendí que un respaldo sin probar no es un respaldo: es una esperanza.
¿Cada cuánto hay que hacer simulacros de continuidad?
Para una empresa mediana es razonable restaurar los sistemas críticos varias veces al año, hacer al menos un simulacro completo anual con la gerencia y repetir la prueba después de cualquier cambio importante: un sistema nuevo, un cambio de proveedor o una reorganización.
Los simulacros no tienen que ser complicados. Un ejercicio de escritorio de dos horas, en el que el equipo directivo recorre un escenario («hoy amanecimos sin el sistema contable»), revela vacíos de roles y de comunicación. Las pruebas técnicas sí deben ser reales: restaurar en un ambiente aparte y cronometrar. La métrica que más me sirve es el tiempo real de recuperación de cada sistema frente a su RTO. Un plan sin pruebas medidas es un documento, no una capacidad.
Como escribo en Tendencias Digitales 2027, la velocidad de respuesta no se improvisa el día del incidente: se diseña, se prueba y se ensaya antes. Lo que se ensaya con calma sale mejor el día que toca hacerlo de verdad.
¿Cuáles son los errores más frecuentes?
El error más común es confundir «tenemos copias de seguridad» con tener un plan. Los otros se repiten en casi todas las empresas: un documento que nadie ha probado, roles sin suplentes, dependencia de una sola persona y un plan que no se actualiza cuando cambia la operación.
- Delegarlo todo a sistemas. Sin la gerencia no hay prioridades de negocio, y el DRP termina protegiendo lo técnicamente fácil, no lo importante.
- Escribir un manual de cien páginas. En una crisis nadie lo lee. Funcionan mejor guías cortas por rol y por escenario.
- Olvidar a los proveedores. Si su software o su nube están en manos de un tercero, su plan depende del de ellos. Pregunte cómo se recuperan y en cuánto tiempo.
- No reconocer la fragilidad. Diseñar un plan exige admitir en voz alta que lo actual es frágil, y eso en muchas juntas directivas cuesta. Es el primer paso.
¿Cómo dimensionar el plan para una pyme sin gastar de más?
Un plan proporcional protege muy bien unos pocos procesos críticos en lugar de proteger a medias todo. Para una empresa de 20 a 200 colaboradores suele bastar con un BCP corto, un DRP para los sistemas que sostienen esos procesos y un calendario de pruebas que se cumpla.
El tamaño lo dictan el RTO y el RPO que defina la gerencia. Si un proceso aguanta un día detenido, no necesita infraestructura duplicada; necesita copias verificadas, un procedimiento claro y alguien entrenado. Reserve la redundancia para lo que no puede detenerse ni unas horas. En el servicio de continuidad del negocio describo cómo combino el análisis de impacto, el BCP, el DRP, las copias verificadas con una copia fuera de la empresa y los simulacros con métricas de efectividad.
¿Qué papel juega la norma ISO 22301?
La ISO 22301 es la norma internacional para sistemas de gestión de la continuidad del negocio. Sirve como referencia de buenas prácticas aunque la empresa no busque certificarse: ordena el trabajo en entender el impacto, definir estrategias, documentar planes, ejercitarlos y mejorarlos de forma continua.
Para una pyme, mi recomendación es usarla como lista de verificación, no como meta de certificación. La certificación tiene sentido cuando un cliente grande, un contrato o un regulador la exige. También conviene conectar la continuidad con la seguridad de la información (ISO/IEC 27001) y, si se manejan datos personales, con las obligaciones de la Ley 1581 de 2012.
¿Por dónde empezar el lunes?
Empiece con una reunión de dos horas con la gerencia para responder las tres preguntas clave y con una pregunta incómoda al área de tecnología: ¿cuándo fue la última vez que restauramos de verdad cada sistema crítico, quién lo hizo y cuánto tardó?
- Liste con la gerencia los cinco procesos que no pueden detenerse y asigne a cada uno un RTO y un RPO en horas.
- Identifique qué sistemas, proveedores y personas sostienen cada proceso.
- Pida evidencia de la última restauración real de cada sistema crítico y verifique que exista una copia fuera de la empresa.
- Nombre los roles de crisis, con un suplente para cada uno, y escriba una guía corta por rol.
- Programe una restauración de prueba en los próximos 30 días y un ejercicio de escritorio con la gerencia en los próximos 90.
- Compare los tiempos reales con los objetivos y ajuste el plan.
Si prefiere un punto de partida externo, el Diagnóstico de Madurez Digital y Riesgo TI incluye una prueba de continuidad que responde en concreto si su empresa puede recuperarse si los sistemas fallan mañana, y en cuánto tiempo.