Un plan de continuidad de negocio (BCP, Business Continuity Plan) es el conjunto documentado de procedimientos que permite a una organización seguir prestando sus servicios críticos, o restaurarlos dentro de un plazo tolerable, después de una interrupción grave: un ransomware, la caída de un centro de datos, un incendio, la pérdida de un proveedor cloud o una crisis sanitaria. No es un documento de estantería ni un anexo de la póliza de seguro. Es un sistema de gestión que se diseña, se prueba y se mejora de forma continua. Esta guía explica qué es un plan de continuidad de negocio, en qué se diferencia del plan de recuperación ante desastres (DRP), cómo se construye a partir de un análisis de impacto (BIA), cómo se fijan los objetivos de recuperación RTO y RPO, y cómo la norma ISO 22301 ordena todo el ciclo y se articula con ISO 27001, NIS2 y DORA.
Qué es un plan de continuidad de negocio (BCP)
El BCP responde a una pregunta incómoda: si mañana perdemos algo esencial, ¿cómo seguimos operando? Su objetivo no es evitar el incidente (eso corresponde a los controles preventivos) sino garantizar que la organización sobrevive a él con un impacto acotado. Un BCP maduro cubre personas, procesos, tecnología, instalaciones y proveedores, y define roles, umbrales de activación, canales de comunicación y estrategias de recuperación para cada servicio crítico.
La continuidad de negocio se apoya en tres capacidades que conviene no confundir:
- Resiliencia: capacidad de absorber el impacto sin caer (redundancia, alta disponibilidad, diversidad de proveedores).
- Continuidad: capacidad de seguir operando con recursos alternativos mientras dura la interrupción.
- Recuperación: capacidad de volver al estado normal una vez controlado el incidente.
BCP vs DRP: en qué se diferencian
Es el punto donde más organizaciones se equivocan. El DRP (Disaster Recovery Plan, plan de recuperación ante desastres) es un subconjunto técnico del BCP centrado en restaurar la infraestructura TI: servidores, redes, bases de datos y copias de seguridad. El BCP es más amplio y opera a nivel de negocio.
| Dimensión | BCP | DRP |
|---|---|---|
| Alcance | Toda la organización (personas, procesos, sedes, TI, proveedores) | Infraestructura TI y datos |
| Objetivo | Mantener las funciones de negocio críticas | Restaurar sistemas y datos |
| Responsable | Dirección y responsable de continuidad | CISO y equipo de sistemas |
| Métricas | MTPD, MBCO, RTO de servicio | RTO y RPO técnicos |
| Ejemplo | Cómo factura el equipo si cae el ERP | Cómo se restaura el ERP desde backup |
Regla práctica: el DRP contesta "cómo recupero el sistema"; el BCP contesta "cómo sigue funcionando el negocio mientras el sistema no está". Un DRP excelente con un BCP inexistente deja a la organización con los servidores restaurados pero sin saber quién hace qué durante las horas críticas.
BIA: análisis de impacto en el negocio
El BIA (Business Impact Analysis, análisis de impacto en el negocio) es la base sobre la que se construye todo el plan. Es el ejercicio que identifica las funciones de negocio, las prioriza según el daño que causaría su interrupción y determina sus objetivos de recuperación. Sin BIA, los RTO y RPO se fijan a ojo y casi siempre mal.
Un BIA riguroso produce, por cada función o servicio:
- Impacto en el tiempo: cómo crece el daño (financiero, legal, reputacional, de seguridad de las personas) conforme pasan las horas de caída.
- MTPD (Maximum Tolerable Period of Disruption): tiempo máximo que la función puede estar caída antes de que el daño sea inaceptable.
- RTO y RPO derivados de ese umbral (el RTO siempre debe ser menor que el MTPD).
- MBCO (Minimum Business Continuity Objective): nivel mínimo de servicio aceptable durante la contingencia, por ejemplo procesar el 40% de los pedidos de forma manual.
- Dependencias: aplicaciones, datos, proveedores, personas clave e instalaciones de las que depende la función.
El BIA se nutre de entrevistas con los responsables de cada área y se contrasta con datos objetivos: facturación por hora, penalizaciones contractuales, obligaciones regulatorias y compromisos de nivel de servicio con clientes.
Cómo fijar RTO y RPO por servicio crítico
RTO y RPO son las dos métricas que gobiernan el diseño técnico de la recuperación:
- RTO (Recovery Time Objective): tiempo máximo aceptable entre la interrupción y la restauración del servicio. Responde a "¿cuánto podemos estar sin esto?".
- RPO (Recovery Point Objective): máxima pérdida de datos tolerable, medida en tiempo. Responde a "¿cuánto trabajo podemos permitirnos perder?". Un RPO de 15 minutos exige replicación casi continua; un RPO de 24 horas se cubre con una copia diaria.
| Nivel | Servicio típico | RTO | RPO | Diseño |
|---|---|---|---|---|
| Tier 0 | Pasarela de pago, autenticación | < 1 h | < 5 min | Activo-activo, replicación síncrona |
| Tier 1 | ERP, CRM productivo | 4 h | 1 h | Sitio alternativo, replicación asíncrona |
| Tier 2 | Portales internos | 24 h | 12 h | Backup y restauración |
| Tier 3 | Archivo, documentación | 72 h | 24 h | Backup diario |
Cuanto más exigentes son los objetivos, más caro es el diseño (replicación síncrona, sedes activo-activo, sistemas duplicados). Por eso se calibran con el BIA: se invierte en velocidad de recuperación solo donde el negocio lo justifica y no en todo por igual.
ISO 22301: ciclo PDCA, requisitos y certificación
ISO 22301:2019 (Security and resilience, Business continuity management systems, Requirements) es la norma internacional certificable para un sistema de gestión de continuidad de negocio (SGCN). Comparte la estructura de alto nivel (Annex SL) con ISO 27001, lo que facilita integrar ambas en un único sistema.
Requisitos de la norma (cláusulas 4 a 10)
- 4. Contexto: partes interesadas y alcance del SGCN.
- 5. Liderazgo: compromiso de la dirección, política de continuidad y roles.
- 6. Planificación: objetivos de continuidad y tratamiento de riesgos.
- 7. Apoyo: recursos, competencia, concienciación, comunicación e información documentada.
- 8. Operación: aquí vive el núcleo, el BIA, la evaluación de riesgos, las estrategias de continuidad, los planes y el programa de pruebas.
- 9. Evaluación del desempeño: seguimiento, medición, auditoría interna y revisión por la dirección.
- 10. Mejora: no conformidades, acciones correctivas y mejora continua.
Ciclo PDCA
ISO 22301 aplica el ciclo PDCA (Plan, Do, Check, Act): planificar (contexto, política, BIA, estrategia), hacer (implantar planes y controles), verificar (ejercicios, auditorías y métricas) y actuar (corregir y mejorar). La continuidad no es un proyecto con fecha de fin, es un ciclo que se repite.
Cómo se articula con ISO 27001
ISO 27001 incluye la continuidad dentro del Anexo A, en los controles A.5.29 (seguridad de la información durante la disrupción) y A.5.30 (preparación de las TIC para la continuidad de negocio) de la versión 2022. ISO 22301 desarrolla esa exigencia en profundidad. Muchas organizaciones certifican ISO 27001 y utilizan ISO 22301 como el marco detallado de su SGCN. Puedes ampliar en ISO 27001 explicada y en la complementariedad entre ISO 27001 y NIS2.
La certificación la realiza una entidad acreditada (ENAC en España) mediante una auditoría en dos fases, con auditorías de seguimiento anuales y recertificación a los tres años.
Backups como base de la recuperación: regla 3-2-1 e inmutabilidad
No hay recuperación sin copias que se puedan restaurar. La regla 3-2-1 es el mínimo exigible: 3 copias de los datos, en 2 tipos de soporte distintos, con 1 fuera de las instalaciones. Frente al ransomware moderno, que busca y cifra los backups accesibles antes de detonar, la regla se extiende a 3-2-1-1-0: 1 copia offline o inmutable (air-gap, WORM, S3 Object Lock, retención bloqueada) y 0 errores tras una restauración verificada.
La inmutabilidad es determinante: un backup que el atacante puede borrar o cifrar no protege frente a ransomware. Tienes el detalle completo en qué es un backup y la regla 3-2-1. Y conviene recordar la regla de oro: un backup que nunca se ha restaurado en un entorno limpio no cuenta como backup, cuenta como una esperanza.
Gestión de crisis y ejercicios tabletop
Un plan sin probar es una hipótesis. El programa de pruebas valida que el BCP funciona antes de necesitarlo. Estos son los tipos, de menor a mayor realismo:
- Tabletop (de mesa): el comité recorre un escenario sobre el papel. Es barato y funciona como mínimo anual imprescindible.
- Walkthrough o simulación: se ejecutan pasos reales en un entorno controlado.
- Prueba en paralelo: se levanta el sitio alternativo sin apagar producción para comprobar que responde.
- Conmutación real (full interruption): se corta producción y se opera desde recuperación. Máximo realismo y máximo riesgo, reservado a organizaciones maduras.
La gestión de crisis añade la capa humana: comité de crisis, árbol de llamadas, portavoces, y comunicación con clientes, reguladores (con los plazos de notificación de NIS2 y DORA) y medios. Un ejercicio tabletop anual como mínimo es la práctica recomendada, y varias normas lo exigen de forma explícita.
Plantilla y checklist de un plan de contingencia
Un BCP operativo debería contener, como mínimo:
- Alcance, objetivos y política de continuidad aprobada por la dirección
- BIA con funciones críticas, MTPD, RTO y RPO
- Estrategias de continuidad y de recuperación por servicio
- DRP técnico con procedimientos de restauración detallados
- Inventario de dependencias (aplicaciones, datos, proveedores, personas)
- Estrategia de backup 3-2-1-1-0 con copias inmutables
- Roles del comité de crisis y árbol de llamadas actualizado
- Plan de comunicación (interna, clientes, reguladores, medios)
- Umbrales de activación y procedimiento de escalado
- Sedes alternativas y recursos de contingencia
- Calendario de pruebas (tabletop anual como mínimo)
- Registro de lecciones aprendidas y mejora continua
Marco regulatorio: NIS2, DORA y ENS
La continuidad ya no es voluntaria para muchos sectores:
- NIS2: el artículo 21.2(d) exige medidas de continuidad de negocio, gestión de copias de seguridad, recuperación ante desastres y gestión de crisis. Detalles en cómo cumplir NIS2 en España.
- DORA: exige política de continuidad TIC, planes de recuperación y RTO/RPO por función crítica en el sector financiero. Ampliación en la guía de cumplimiento DORA.
- ENS: la dimensión de continuidad (op.cont.1 análisis de impacto, op.cont.2 plan de continuidad, op.cont.3 pruebas periódicas y op.cont.4 medios alternativos) impone continuidad al sector público. Ver ENS para pymes.
La continuidad es, en el fondo, el objetivo último de cualquier evaluación de resiliencia cibernética.
Preguntas frecuentes
¿Cuál es la diferencia entre BCP y DRP?
El BCP (plan de continuidad de negocio) cubre toda la organización y busca mantener operativas las funciones de negocio críticas durante una interrupción. El DRP (plan de recuperación ante desastres) es un subconjunto técnico centrado en restaurar la infraestructura TI y los datos. El DRP es una pieza dentro del BCP, no un sustituto.
¿Qué diferencia hay entre RTO y RPO?
El RTO es el tiempo máximo aceptable para restaurar un servicio tras la caída. El RPO es la cantidad máxima de datos, medida en tiempo, que la organización puede permitirse perder. El RTO mira hacia adelante (cuándo vuelvo a estar operativo); el RPO mira hacia atrás (hasta qué punto de datos puedo recuperar).
¿ISO 22301 sustituye a ISO 27001?
No. ISO 27001 gestiona la seguridad de la información y ISO 22301 gestiona la continuidad de negocio. Son complementarias y comparten estructura de alto nivel, por lo que muchas organizaciones las integran en un único sistema de gestión.
¿Cada cuánto hay que probar el plan de continuidad?
La práctica recomendada, y lo que exigen normas como el ENS y esperan NIS2 y DORA, es al menos un ejercicio tabletop anual, además de pruebas técnicas de restauración periódicas. Todo cambio relevante en sistemas o procesos debería disparar una prueba adicional.
¿Es obligatorio tener un plan de continuidad de negocio?
Depende del sector. Para las entidades esenciales e importantes bajo NIS2, las entidades financieras bajo DORA y los organismos del sector público sujetos al ENS, la continuidad de negocio es una obligación legal. Para el resto es una buena práctica que reduce drásticamente el impacto de un incidente grave.
Diseña tu continuidad de negocio con Secra
En Secra ayudamos a construir y probar planes de continuidad alineados con ISO 22301, NIS2, DORA y el ENS: BIA, definición de RTO y RPO por servicio, estrategia de backup inmutable y ejercicios tabletop dirigidos.
Sobre el autor
Equipo de Secra Solutions
Ethical hackers certificados OSCP, OSEP, OSWE, CRTO, CRTL y CARTE, con más de 7 años de experiencia en ciberseguridad ofensiva. Autores de los CVE-2025-40652 y CVE-2023-3512.