Casi ninguna pyme cae por un ciberataque de película. Cae por lo aburrido: un servidor que se apaga y no vuelve, un ransomware que cifra la carpeta compartida un viernes por la tarde, una tubería rota sobre el rack, un proveedor de nube con una caída de seis horas. La pregunta que de verdad importa no es si pasará, sino cuántas horas puede estar tu empresa sin facturar, sin producir o sin atender a clientes antes de que el daño sea irreversible. Un plan de continuidad de negocio para pyme es exactamente la respuesta a esa pregunta, por escrito y probada.
Y no, no hace falta un manual de 200 páginas ni un presupuesto de multinacional. Hace falta saber qué procesos no pueden parar, cuánto aguantas realmente y qué tres cosas haces en la primera hora. El resto es adorno. Vamos a lo concreto.
Continuidad vs. recuperación: qué es un BCP y qué es un DRP
Se confunden constantemente, y esa confusión es cara. El BCP (Business Continuity Plan) responde a «cómo sigue funcionando mi negocio mientras algo está roto». El DRP (Disaster Recovery Plan) responde a «cómo recupero la tecnología que se ha caído». Uno mira al negocio; el otro, a los sistemas.
Un ejemplo: se te cae el ERP. El DRP dice cómo restauras la base de datos desde la copia y en qué servidor la levantas. El BCP dice cómo el equipo de facturación sigue emitiendo albaranes en una plantilla temporal mientras tanto, para que el almacén no se pare. El DRP arregla la máquina; el BCP mantiene el dinero entrando por la puerta. Necesitas los dos, y necesitas que hablen entre sí.
Recuperar el sistema en dos días no sirve de nada si tu negocio se muere en cuatro horas sin él.
El error clásico de la pyme es tener (con suerte) un trozo de DRP —las copias de seguridad— y ni rastro de BCP. Tienes backups, sí, pero nadie sabe quién decide activar la recuperación, a quién se avisa, cómo se atiende a los clientes mientras tanto ni cuánto tiempo es «demasiado». Eso no es un plan: es una carpeta de ficheros y un cruce de dedos.
Qué procesos no pueden parar y cuánto aguantas: RTO y RPO en cristiano
Todo plan serio arranca por lo mismo: no todo importa igual. Si intentas proteger cada sistema con la misma urgencia, ni terminas ni te lo puedes pagar. Haz una lista honesta de tus procesos —facturar, producir, atender pedidos, pagar nóminas, dar soporte— y clasifícalos por lo que pasa si se detienen una hora, un día, una semana. Los que duelen en horas son tus procesos críticos. Esos mandan.
Sobre esa lista aparecen dos siglas que suenan técnicas pero son de puro sentido común:
- RTO (tiempo objetivo de recuperación): cuánto tiempo puede estar caído un proceso antes de que el daño sea grave. Es tu «reloj». Si tu tienda online no puede estar más de 2 horas sin vender, tu RTO es 2 horas.
- RPO (punto objetivo de recuperación): cuántos datos puedes permitirte perder, medido en tiempo. Si haces copia cada 24 horas, tu RPO es de un día: ante un desastre, pierdes hasta un día de trabajo. Para un ERP de facturación eso suele ser inaceptable.
La magia está en cruzar ambos con la realidad. Si tu proceso crítico exige un RTO de 2 horas pero tu única copia está en un disco USB que alguien se lleva a casa los viernes, tu capacidad real de recuperación es de días, no de horas. Ahí tienes el agujero, medido y con números. Y con esos números ya puedes decidir dónde invertir: replicación en la nube, copias más frecuentes, un servidor secundario. No por miedo, sino por criterio.
Un consejo que ahorra dinero: ajusta el RTO y el RPO al valor del proceso, no a tu ansiedad. El servidor de archivos de marketing puede tolerar un RPO de 24 horas sin drama. La base de datos de pedidos, no. Proteger todo como si fuera crítico es la forma más rápida de reventar el presupuesto y no terminar el plan.
Un plan sencillo que sí vas a usar
El mejor plan de continuidad no es el más completo: es el que tu equipo puede ejecutar a las 3 de la madrugada, con adrenalina, sin el informático de guardia localizable. Eso significa corto, claro y accionable. Un documento de dos o tres páginas bien hechas vale más que un tomo que nadie ha abierto.
Lo mínimo que debe contener:
- Procesos críticos y sus RTO/RPO: la lista del punto anterior, priorizada. Qué se recupera primero y qué puede esperar.
- Quién decide y quién ejecuta: nombres y suplentes. Quién declara el incidente, quién autoriza la recuperación, quién habla con clientes. Sin roles, hay parálisis.
- Contactos clave fuera del sistema: teléfonos del equipo, del proveedor IT, del banco, del seguro. Impresos o en el móvil, porque si se cae la red no tendrás acceso al Drive.
- Dónde están las copias y cómo se restauran: ubicación, credenciales de acceso controladas y el procedimiento paso a paso. Una copia que nadie sabe restaurar no es una copia.
- El plan B manual: cómo sigue operando cada proceso crítico sin su sistema. Facturar en plantilla, tomar pedidos por teléfono, lo que sea que mantenga el negocio vivo esas horas.
Fíjate en lo que no está: jerga, diagramas de arquitectura preciosos, escenarios improbables. El plan describe qué hacer en la primera hora de las tres o cuatro caídas que de verdad te pueden pasar. Todo lo demás sobra hasta que este núcleo funcione. Empieza pequeño, ponlo por escrito hoy y mejóralo después.
Cómo probarlo para que funcione de verdad
Un plan sin probar es una hipótesis. Y en continuidad, las hipótesis se caen justo cuando más las necesitas. La copia que «se hacía sola» llevaba tres meses fallando en silencio; el procedimiento de restauración tardaba ocho horas en vez de dos porque nadie lo había cronometrado. Estas cosas no se descubren leyendo el plan: se descubren ejecutándolo.
No hace falta simular un incendio. Prueba por capas:
- Restauración real de copias: coge un backup y recupéralo en un entorno aparte. Cronométralo. ¿Cumple tu RTO? ¿Están todos los datos? Esto se hace cada trimestre, no una vez en la vida.
- Simulacro de mesa: reúne al equipo una hora, plantea «son las 9:00 y el ERP no arranca» y que cada uno diga qué hace. Afloran los huecos sin tocar un solo sistema.
- Prueba del plan B manual: pasa medio día facturando o tomando pedidos como si el sistema no existiera. Descubrirás qué falta antes de necesitarlo de verdad.
Cada prueba deja tareas: actualizar un contacto, corregir un backup, aclarar un paso confuso. Ese ciclo —probar, encontrar el fallo, arreglarlo— es lo que convierte un documento en una capacidad real. Y aquí la monitorización juega un papel silencioso pero decisivo: si vigilas los sistemas y las copias en tiempo real, muchos incidentes se detectan y contienen antes de que se conviertan en un desastre que active todo el plan. Prevenir sale mucho más barato que recuperar.
Cómo lo prepara MagicBoxDesk
Todo esto —clasificar procesos, fijar RTO y RPO realistas, montar copias que de verdad se restauran, escribir el plan y probarlo cada trimestre— es trabajo especializado y continuo. Es exactamente lo que hacemos cuando externalizamos el departamento IT de una empresa: no vendemos un PDF y desaparecemos, sino que dejamos montada la capacidad real de aguantar un golpe y seguir facturando. Diseñamos el BCP y el DRP a la medida de tu operación, con monitorización 24/7 que detecta los problemas antes de que te tumben y con copias verificadas de forma automática, no «en teoría».
Damos soporte remoto y presencial en toda España, con la experiencia de quien ha levantado sistemas caídos un domingo por la noche más veces de las que le gustaría. Si no sabes cuántas horas aguanta tu negocio sin sus sistemas, ese es justo el punto de partida. Pide presupuesto sin compromiso y te decimos, con números, dónde está tu riesgo real y qué necesitas de verdad para dormir tranquilo.
