Casi todas las empresas tienen copias de seguridad. Muy pocas tienen un plan de continuidad de negocio, y la diferencia se descubre siempre en el mismo momento, cuando algo se para y nadie sabe quién decide, qué se recupera primero ni cuánto va a tardar. Esta guía explica qué es un plan de continuidad, qué tiene que incluir en una pyme, cómo se prueba y por qué no hace falta certificarse en la norma ISO 22301 para tener uno que funcione.
Qué es un plan de continuidad de negocio
Un plan de continuidad de negocio (BCP, por sus siglas en inglés) es el documento y el conjunto de medidas que permiten a una empresa seguir operando, aunque sea de forma reducida, cuando falla algo esencial: un servidor, el proveedor de internet, la oficina, un empleado clave o un ciberataque. No es un documento técnico, es un acuerdo de la dirección sobre qué es imprescindible y cuánto tiempo puede faltar.
Se diferencia del plan de recuperación ante desastres (disaster recovery) en el alcance. El disaster recovery es la parte tecnológica, cómo se recuperan sistemas y datos. La continuidad de negocio abarca todo lo demás, cómo se sigue vendiendo, atendiendo y cobrando mientras la tecnología vuelve. Una pyme puede empezar por la parte técnica, que es la más concreta, y crecer desde ahí.
Qué incluye un plan de continuidad en una pyme
Un plan útil para una empresa de 10 a 200 personas cabe en diez páginas. Lo que no puede faltar:
1. Análisis de impacto: qué duele y cuánto
Se listan los procesos del negocio (vender, servir, facturar, atender, producir) y para cada uno se estima cuánto cuesta una hora parado y cuántas horas se aguantan antes de que el daño sea grave. De ahí salen dos cifras por proceso, el tiempo máximo de parada tolerable y la pérdida de datos tolerable, que los técnicos traducen a RTO y RPO por sistema. Este análisis lo hace negocio con apoyo técnico, no al revés.
2. Inventario de dependencias
Qué sistemas, proveedores, personas y ubicaciones sostienen cada proceso. Es donde aparecen las sorpresas, el ERP que solo sabe administrar una persona, la pasarela de pago que depende de una cuenta de correo personal, el servidor «temporal» que lleva seis años en producción. Sin este inventario, el plan protege lo que se ve y falla por lo que no se ve.
3. Estrategias de continuidad por escenario
No hacen falta cien escenarios. Con cinco se cubre casi todo lo que le pasa a una pyme: caída del servidor principal, ransomware o borrado masivo, pérdida de conectividad o de la oficina, fallo de un proveedor crítico (hosting, nube, SaaS) y ausencia de una persona clave. Para cada uno se decide de antemano la respuesta, restaurar desde copia en otra ubicación, trabajar en remoto, usar un procedimiento manual provisional, activar un proveedor alternativo.
4. Procedimientos de recuperación
Las instrucciones paso a paso para volver a operar, escritas para que las pueda seguir alguien que no las escribió. Incluyen el orden de recuperación (primero red e identidad, luego bases de datos, luego aplicaciones), dónde están las copias y las credenciales de emergencia, y qué se comprueba antes de dar un sistema por recuperado. Esta es la parte que se apoya en el servicio de backup y continuidad.
5. Personas y comunicación
Quién declara la crisis, quién decide, quién ejecuta y quién comunica a clientes y equipo. Con teléfonos personales, porque el correo corporativo suele ser lo primero que deja de funcionar. Y un mensaje base ya redactado para clientes, que en mitad de un incidente nadie tiene la cabeza para escribirlo bien.
6. Calendario de pruebas y revisión
Fecha de la próxima prueba, quién la organiza y dónde se anotan los resultados. Un plan que no se prueba caduca en seis meses, porque la infraestructura cambia y las personas también.
Cómo se prueba un plan de continuidad
La prueba es lo que separa un plan de un documento. Hay tres niveles y una pyme debería hacer los tres a lo largo del año:
- Revisión de mesa (una hora, cada seis meses). Los responsables leen el plan ante un escenario concreto y comprueban que sigue siendo cierto: que las personas siguen en la empresa, que los sistemas listados son los actuales, que los contactos funcionan.
- Prueba técnica de restauración (media jornada, cada trimestre o automatizada cada mes). Se restaura de verdad un sistema desde copia en un entorno aislado y se mide cuánto tarda y qué datos faltan. Es la única forma de conocer el RTO y el RPO reales, no los del papel.
- Simulacro completo (un día, una vez al año). Se declara un incidente ficticio y el equipo ejecuta el plan de principio a fin, incluida la comunicación. Sale caro en horas y es la prueba que más enseña.
Lo que suele fallar en la primera prueba es siempre pequeño y siempre decisivo. La copia está, pero la clave de cifrado la tenía alguien que ya no está. El procedimiento dice «restaurar la base de datos» sin decir en qué máquina. El proveedor de la nube tarda cuatro horas en atender un ticket que se creía inmediato. Descubrirlo en un simulacro cuesta una mañana. Descubrirlo en un incidente cuesta días.
Un escenario típico: cuando el plan estaba en la cabeza de una persona
Una empresa de distribución de unas cuarenta personas, con el ERP y el almacén en un servidor propio y las copias en un disco externo que el responsable de informática se llevaba a casa cada viernes. El plan de continuidad, no escrito, era él. Coincidieron una baja suya de tres semanas y una actualización del sistema operativo que dejó el ERP sin arrancar un lunes a primera hora.
El proveedor de mantenimiento restauró el servidor desde la copia del viernes anterior en unas ocho horas, tras localizar el disco y la contraseña de la copia. Se perdió medio día de pedidos, que se rehicieron a mano con los correos de los clientes, y el almacén trabajó con albaranes en papel durante la jornada. Nada dramático. Pero la empresa pasó ese día sin saber si iba a recuperar los datos, y esa incertidumbre es exactamente lo que un plan elimina.
Lo que cambió después cabe en una página. Copias automáticas a un segundo repositorio fuera de la oficina con prueba de restauración mensual, credenciales de emergencia en un gestor compartido con dos responsables, un procedimiento escrito de recuperación del ERP con el orden de pasos y los teléfonos de proveedor, y una revisión de mesa cada seis meses. El coste fue una tarde de trabajo conjunto y una cuota mensual de copias. La siguiente incidencia, un disco que falló un año después, se resolvió en dos horas sin que nadie de dirección tuviera que intervenir.
ISO 22301: ¿hace falta certificarse?
La ISO 22301 es la norma internacional de gestión de la continuidad de negocio. Define un sistema completo, con política, análisis de impacto, estrategias, planes, pruebas y mejora continua. Certificarse implica auditorías externas anuales y una carga documental pensada para organizaciones grandes o reguladas.
Para una pyme la respuesta corta es que no hace falta certificarse, pero sí conviene copiarle la estructura. Los seis apartados de esta guía siguen el esquema de la norma reducido a lo que una empresa pequeña puede mantener. La certificación tiene sentido cuando un cliente grande o un contrato público la exigen, o cuando la empresa opera en un sector regulado (salud, finanzas, infraestructuras críticas). En ese caso, haber trabajado ya con esta estructura acorta el camino.
Errores habituales
- Confundir tener backup con tener plan. El backup es una pieza. Sin orden de recuperación, responsables y pruebas, la copia sirve de poco el día que hace falta.
- Poner objetivos de recuperación de cero para todo. Recuperar en minutos sin perder nada existe, pero cuesta lo que cuesta. Cada sistema tiene su tolerancia y el plan debe reflejarla.
- Escribirlo y guardarlo. Un plan sin fecha de próxima prueba es un plan caducado.
- Guardar el plan solo en el sistema que puede caer. Una copia impresa o en un lugar independiente, con las credenciales de emergencia accesibles a dos personas.
- Dejar fuera al negocio. Si lo hace solo el departamento técnico, protegerá los sistemas que conoce y no los procesos que importan.
Por dónde empezar
Con una tarde y las personas adecuadas en la sala sale la primera versión: lista de procesos con su tolerancia a la parada, inventario de dependencias y los cinco escenarios con su respuesta. La parte técnica, copias verificadas, restauración probada y procedimientos escritos, es lo que cubre nuestro servicio de backup y continuidad de negocio, y el punto de partida habitual es revisar el plan actual, si existe, con una prueba de restauración real. Si quieres saber si el tuyo aguantaría un lunes como el del ejemplo, cuéntanos tu caso.