El 27 de mayo de 2017, un contratista que realizaba trabajos de mantenimiento en un centro de datos de British Airways desconectó por error la alimentación eléctrica. El fallo derribó los sistemas de check-in, equipaje y control de vuelos durante dos días, con 470 vuelos cancelados solo el primer día y otros 183 al día siguiente, cerca de 75.000 pasajeros afectados y un coste que su matriz IAG cifró en unos 58 millones de libras solo en pérdida de negocio e indemnizaciones —con reclamaciones adicionales de clientes que, según distintas estimaciones de prensa, superaron los 100 millones. Ningún firewall, ningún SIEM y ningún control de acceso hubieran evitado ese incidente: lo que faltó fue la capacidad de seguir operando —o de recuperarse rápido— cuando algo, inevitablemente, se rompe, incluido un simple error humano en un centro de datos. Esa capacidad tiene nombre técnico y marco normativo propio: continuidad de negocio, y su estándar de referencia internacional es ISO 22301.
Hasta ahora, este curso ha construido gobierno (Módulo 2), ha identificado y tratado riesgos (Módulos 3 y 4) y ha levantado un SGSI completo bajo ISO 27001/27002 (Módulos 5 a 8). Todo ese trabajo asume, implícitamente, que los controles preventivos funcionan. Este módulo aborda la pregunta que queda cuando esa asunción falla: ¿qué hace la organización en el momento —y en los días— en que un control ha fallado y el negocio está parado? La respuesta profesional no es una carpeta de PDF sin tocar desde 2022: es un sistema de gestión completo, con la misma disciplina de las cláusulas 4 a 10 que ya conoces de ISO 27001, aplicado a la resiliencia operativa.
Qué aprenderás
- Por qué la continuidad de negocio es una disciplina de GRC y de resiliencia organizativa, y cómo se relaciona con la gestión de riesgos y con la respuesta a incidentes (DFIR).
- La estructura de ISO 22301:2019 —el Sistema de Gestión de la Continuidad del Negocio (SGCN/BCMS)—, con la misma estructura de alto nivel (HLS) que ISO 27001 y su alcance certificable.
- Cómo ejecutar un Análisis de Impacto en el Negocio (BIA): identificar actividades críticas, evaluar el impacto de su interrupción en el tiempo y mapear sus dependencias.
- Los cuatro objetivos temporales que gobiernan toda estrategia de recuperación: RTO, RPO, MTPD/MTD y MBCO, y cómo se sitúan en la línea temporal de un incidente.
- Las estrategias de continuidad y recuperación disponibles: redundancia, copias de seguridad, sitios alternativos (hot/warm/cold), acuerdos con terceros y trabajo remoto.
- La diferencia real —no cosmética— entre el Plan de Continuidad de Negocio (BCP) y el Plan de Recuperación ante Desastres (DRP), con la estructura y los equipos de cada uno.
- Los tipos de prueba de continuidad, su periodicidad razonable y cómo cerrar el ciclo con lecciones aprendidas.
- Cómo el ENS, NIS2 e ISO 27002:2022 (control 5.30) exigen continuidad, y a resolver un mini-BIA de tres procesos con RTO y RPO justificados.
1. Continuidad de negocio: por qué es GRC y por qué es resiliencia
La continuidad de negocio encaja en GRC de forma directa: es la respuesta organizativa al riesgo que, pese a los controles del Módulo 4, no se ha podido reducir a cero. Ningún plan de tratamiento de riesgos elimina la posibilidad de un incendio en el CPD, un ciberataque de ransomware que cifre toda la infraestructura, la caída de un proveedor cloud crítico o una pandemia que impida el acceso físico a las oficinas. La gestión de riesgos (Módulos 3 y 4) responde a la pregunta «¿cómo reducimos la probabilidad y el impacto de que esto ocurra?»; la continuidad de negocio responde a la pregunta complementaria: «cuando ocurra de todos modos, ¿cómo seguimos operando o cómo nos recuperamos sin que el negocio colapse?».
Esta disciplina es, además, el núcleo operativo de lo que la literatura profesional llama resiliencia organizativa: la capacidad de una organización de anticipar, prepararse, responder y adaptarse a cambios incrementales y a interrupciones súbitas, para sobrevivir y prosperar. La resiliencia es un concepto más amplio que engloba la continuidad de negocio (ISO 22301), la gestión de crisis, la seguridad de la información (ISO 27001) y la gestión de riesgos (ISO 31000) como piezas de un mismo sistema; de hecho, ISO ha publicado también ISO 22316 como guía de principios de resiliencia organizativa, complementaria a ISO 22301.
1.1 La frontera con la respuesta a incidentes (DFIR)
Es habitual confundir continuidad de negocio con respuesta a incidentes, y ambas disciplinas se solapan en el terreno, pero responden a preguntas distintas y suelen activarse con procedimientos y equipos distintos:
- La respuesta a incidentes (DFIR) se centra en la causa técnica: qué ha pasado, cómo ha entrado el atacante, qué sistemas están comprometidos, cómo se contiene y se erradica la amenaza, y cómo se preserva la evidencia forense. Es una disciplina fundamentalmente técnica y forense.
- La continuidad de negocio se centra en el efecto sobre el negocio, con independencia de la causa: si el ERP no está disponible, da igual para el BCP si es por ransomware, por un fallo de hardware o por una inundación en el CPD —lo que importa es que el proceso de facturación no puede operar y hay que activar la alternativa prevista.
En un incidente de ciberseguridad grave, ambas disciplinas se activan en paralelo y deben estar coordinadas: el equipo de DFIR contiene y analiza la brecha mientras el equipo de continuidad activa el BCP para mantener las operaciones críticas con los medios alternativos previstos. Un ransomware que cifra el ERP es, a la vez, un incidente de seguridad que exige un análisis forense (ver el curso de DFIR y Respuesta a Incidentes) y una interrupción de negocio que exige activar el plan de continuidad. Organizaciones maduras integran ambos procedimientos en un mismo manual de gestión de crisis, con puntos de decisión claros sobre cuándo se activa cada uno.
2. ISO 22301:2019: el Sistema de Gestión de la Continuidad del Negocio
ISO 22301:2019 (Security and resilience — Business continuity management systems — Requirements) es el estándar internacional certificable para implantar, mantener y mejorar un Sistema de Gestión de la Continuidad del Negocio (SGCN), conocido también por su acrónimo en inglés BCMS (Business Continuity Management System). Sustituyó a la edición de 2012 y, como ISO 27001:2022 (visto en el Módulo 5), sigue la Estructura de Alto Nivel (HLS, High Level Structure) del Anexo SL, común a todas las normas ISO de sistemas de gestión modernas. Esto no es un detalle menor: significa que las cláusulas 4 a 10 de ISO 22301 tienen la misma numeración, el mismo propósito y una redacción muy paralela a las de ISO 27001, lo que permite —y en la práctica es lo habitual— integrar el SGCN dentro de un sistema de gestión ya certificado en ISO 27001, compartiendo política, comité de dirección, auditoría interna y revisión por la dirección.
2.1 Las cláusulas de ISO 22301:2019, cláusula a cláusula
- Cláusula 4 — Contexto de la organización. Comprender el contexto interno y externo, las partes interesadas y sus requisitos, y determinar el alcance del SGCN —qué productos, servicios, ubicaciones y actividades cubre.
- Cláusula 5 — Liderazgo. Compromiso de la alta dirección, política de continuidad de negocio, roles y responsabilidades, exactamente en el mismo espíritu que la cláusula 5 de ISO 27001 vista en el Módulo 2: la continuidad no es delegable en un responsable técnico sin respaldo ni presupuesto de dirección.
- Cláusula 6 — Planificación. Tratamiento de riesgos y oportunidades del propio SGCN, y establecimiento de objetivos de continuidad de negocio medibles.
- Cláusula 7 — Soporte. Recursos, competencias, toma de conciencia, comunicación e información documentada —el mismo esquema de gestión documental que ya trabajaste en el Módulo 7 al implantar el SGSI.
- Cláusula 8 — Operación. El corazón técnico de la norma: aquí se ubican el Análisis de Impacto en el Negocio (BIA) y la evaluación de riesgos de continuidad (8.2), la estrategia y soluciones de continuidad (8.3), la implantación de procedimientos de continuidad —el BCP— (8.4), y el programa de ejercicios y pruebas (8.5). Todo este módulo gira mayoritariamente en torno a esta cláusula.
- Cláusula 9 — Evaluación del desempeño. Seguimiento y medición, auditoría interna del SGCN y revisión por la dirección.
- Cláusula 10 — Mejora. No conformidades, acciones correctivas y mejora continua.
ISO 22301 es certificable por entidades acreditadas, siguiendo el mismo esquema de auditoría en dos fases que ya viste para ISO 27001 en el Módulo 8 (ISO/IEC 17021-1 e ISO 22301 Anexo relacionado con la competencia de auditores). Muchas organizaciones certificadas en ISO 27001 añaden ISO 22301 como una extensión natural de su sistema de gestión, en lugar de tratarlo como un proyecto separado desde cero.
3. El BIA: Análisis de Impacto en el Negocio
El Análisis de Impacto en el Negocio (Business Impact Analysis, BIA) es, para la continuidad de negocio, lo que el análisis de riesgos del Módulo 3 es para la seguridad: el ejercicio de diagnóstico que sustenta todas las decisiones posteriores. ISO 22301:2019, cláusula 8.2.2, exige a la organización establecer, implementar y mantener un proceso formal de BIA para determinar y priorizar los procesos y actividades que soportan sus productos y servicios. Un BCP construido sin BIA previo —y esto ocurre con más frecuencia de la deseable— es, en el mejor de los casos, una suposición razonada; en el peor, un documento que protege lo que es fácil de proteger en lugar de lo que de verdad importa para el negocio.
3.1 Qué hace el BIA, paso a paso
- Identificar las actividades que soportan los productos y servicios de la organización. No se analiza departamento a departamento, sino proceso a proceso: facturación, atención al cliente, producción, logística de última milla, procesamiento de nóminas, etc.
- Evaluar el impacto de la interrupción de cada actividad a lo largo del tiempo. El impacto no es estático: perder la facturación durante una hora es irrelevante; perderla durante dos semanas puede ser existencial. El BIA mide esta escalada temporal del impacto, típicamente en categorías como financiero directo (ingresos no facturados, penalizaciones contractuales), legal y regulatorio (incumplimiento de plazos exigidos por ley), reputacional (pérdida de confianza de clientes) y operativo (efecto en cascada sobre otras actividades dependientes).
- Priorizar las actividades críticas según ese impacto creciente, no según la percepción subjetiva de qué departamento «parece» más importante.
- Determinar los objetivos de recuperación de cada actividad crítica: RTO, RPO y MTPD, que se explican con detalle en el siguiente apartado.
- Identificar los recursos y dependencias necesarios para que la actividad pueda reanudarse: personas con competencias concretas (no solo «el equipo de X»), sistemas de TI y datos asociados, proveedores y terceros críticos, e instalaciones físicas o su alternativa.
3.2 Dependencias: el punto que más BIA hacen mal
Un BIA que solo identifica «qué se rompe» sin mapear «de qué depende para funcionar» es un BIA incompleto. Las cuatro categorías de dependencia que hay que documentar sistemáticamente para cada actividad crítica son:
- Personas. ¿Quién tiene el conocimiento crítico para ejecutar esta actividad? ¿Existe un único punto de fallo humano (la persona que «es la única que sabe hacer esto»)? ¿Hay backup de personal formado?
- Tecnología (TI). Sistemas, aplicaciones, bases de datos y la infraestructura que los soporta, incluyendo dependencias entre sistemas (el ERP depende de la base de datos, que depende del servidor, que depende de la conectividad).
- Proveedores y terceros. Un proveedor de nómina externalizado, un centro de datos en la nube, un proveedor logístico, una pasarela de pago. Esta categoría es, sistemáticamente, la más subestimada en los BIA reales —y precisamente por eso NIS2 y el ENS ponen ahora tanto foco regulatorio en la cadena de suministro, tema que se desarrolla en profundidad en el Módulo 13.
- Instalaciones. Oficinas, planta de producción, almacén, CPD propio. Incluye también recursos menos evidentes: acceso físico, suministro eléctrico, climatización de la sala de servidores.
3.3 Ficha de proceso: plantilla del BIA
La salida operativa del BIA para cada actividad crítica es una ficha estructurada. Esta es una plantilla base, adaptable al tamaño y sector de la organización:
FICHA DE PROCESO — ANÁLISIS DE IMPACTO EN EL NEGOCIO (BIA)
==================================================
1. IDENTIFICACIÓN
Nombre del proceso/actividad: <ej. Facturación a clientes>
Área/propietario del proceso: <responsable funcional>
Fecha de elaboración / revisión: <dd/mm/aaaa>
2. DESCRIPCIÓN
Descripción breve de la actividad: <qué hace, para quién>
Productos/servicios que soporta: <lista>
3. IMPACTO DE LA INTERRUPCIÓN (por horizonte temporal)
A las 4 horas: <impacto financiero/legal/reputacional>
A las 24 horas: <impacto financiero/legal/reputacional>
A las 72 horas: <impacto financiero/legal/reputacional>
A la semana: <impacto financiero/legal/reputacional>
Nivel de criticidad asignado: <Crítico / Alto / Medio / Bajo>
4. OBJETIVOS DE RECUPERACIÓN
RTO (Recovery Time Objective): <ej. 4 horas>
RPO (Recovery Point Objective): <ej. 1 hora>
MTPD/MTD (periodo máx. tolerable): <ej. 24 horas>
MBCO (nivel mínimo de continuidad): <ej. 30 % del volumen habitual>
5. DEPENDENCIAS
Personas clave / competencias críticas: <lista, incl. backup>
Sistemas TI y datos: <lista, con RTO/RPO propios>
Proveedores/terceros críticos: <lista, con nivel de SLA>
Instalaciones necesarias: <sede, CPD, alternativa>
6. DEPENDENCIAS ASCENDENTES/DESCENDENTES
Procesos que dependen de esta actividad: <lista>
Procesos de los que depende esta actividad: <lista>
7. ESTRATEGIA DE CONTINUIDAD ASOCIADA
Estrategia elegida: <ej. sitio warm + backup diario + SLA proveedor>
Referencia al BCP/DRP: <sección o procedimiento>
8. APROBACIÓN
Elaborado por: <nombre, rol>
Validado por (propietario del proceso): <nombre, rol, fecha>
4. Los objetivos temporales: RTO, RPO, MTPD/MTD y MBCO
Estos cuatro conceptos son el vocabulario técnico imprescindible de la continuidad de negocio, y su confusión —especialmente entre RTO y RPO— es el error más frecuente entre quienes se acercan por primera vez a la disciplina.
| Objetivo | Definición | Responde a la pregunta | Ejemplo |
|---|---|---|---|
| RTO (Recovery Time Objective — Objetivo de Tiempo de Recuperación) |
Tiempo máximo aceptable desde que se produce la interrupción hasta que la actividad o el sistema vuelve a estar operativo, a un nivel mínimo aceptable. | ¿Cuánto tiempo podemos tardar en volver a funcionar? | El ERP de facturación debe estar operativo de nuevo en un máximo de 4 horas tras la caída. |
| RPO (Recovery Point Objective — Objetivo de Punto de Recuperación) |
Cantidad máxima aceptable de datos que se pueden perder, medida en tiempo desde la última copia o replicación válida hasta el momento de la interrupción. | ¿Cuántos datos podemos permitirnos perder? | Con un RPO de 1 hora, tras un fallo se recupera el sistema con, como máximo, 1 hora de datos perdidos desde la última copia. |
| MTPD / MTD (Maximum Tolerable Period of Disruption / Maximum Tolerable Downtime — Periodo Máximo Tolerable de Interrupción) |
El tiempo límite absoluto que la actividad puede estar interrumpida antes de que las consecuencias se vuelvan inaceptables o irreversibles para la viabilidad de la organización. Es el «punto de no retorno» del negocio, no de un sistema en concreto. | ¿A partir de qué momento el daño deja de ser recuperable? | Si el proceso de nómina no se restablece en 5 días naturales, la organización incumple obligaciones legales de pago y sufre un daño reputacional grave e irreversible frente a la plantilla. |
| MBCO (Minimum Business Continuity Objective — Objetivo Mínimo de Continuidad de Negocio) |
El nivel mínimo de servicio, producción o rendimiento que la organización necesita mantener durante una interrupción para que la actividad se considere «en continuidad», aunque sea de forma degradada. | ¿Con cuánta capacidad reducida seguimos considerando que «seguimos operando»? | Durante una contingencia, el centro de atención al cliente puede operar en continuidad si atiende al menos el 30 % del volumen habitual de llamadas, priorizando incidencias críticas. |
La relación entre RTO y MTPD es la que más confusión genera y conviene fijar bien: el RTO siempre debe ser menor o igual que el MTPD (RTO ≤ MTPD). Si el negocio no puede tolerar más de 24 horas sin nómina (MTPD = 24h) pero el plan de recuperación real tarda 36 horas en restablecer el sistema (RTO real = 36h), existe una brecha de continuidad —el objetivo de recuperación fijado (o la capacidad real de cumplirlo) es insuficiente frente al límite que el negocio puede tolerar, y hay que invertir en acortar el RTO o aceptar formalmente el riesgo de superar el MTPD, con las mismas implicaciones de gobierno que la aceptación de riesgo residual vista en el Módulo 4.
4.1 Línea temporal del incidente: dónde se sitúan RPO y RTO
Es fundamental visualizar que RPO y RTO se miden en direcciones opuestas del eje temporal respecto al momento de la interrupción:
RPO RTO
<—————————————>|<—————————————————————>
(datos que se pueden | (tiempo hasta volver a operar)
permitir perder, |
hacia atrás en el |
tiempo desde el |
momento de fallo) |
|
------[copia]------[copia]---[FALLO]------------------[RECUPERADO]------>
de datos de datos | |
t-2h t-1h | |
| |
INTERRUPCIÓN RTO cumplido
(t = 0) (t = 0 + RTO)
Si el RPO objetivo es 1h y la última copia válida es de t-1h,
el fallo en t=0 pierde como máximo esa hora de datos: RPO cumplido.
Si el RTO objetivo es 4h, el sistema debe estar operativo
de nuevo, como muy tarde, en t = 0 + 4h.
En términos simples: el RPO mira hacia atrás desde el momento del incidente —determina la frecuencia mínima de copias de seguridad o de replicación de datos necesaria—, mientras que el RTO mira hacia delante —determina la velocidad de la estrategia de recuperación necesaria (sitio alternativo, restauración, failover). Un RPO de 15 minutos exige replicación casi continua (no basta una copia nocturna); un RTO de 2 horas exige un sitio hot o warm listo para activarse (no basta un cold site que tarda días en levantarse). Esta es la razón técnica por la que RTO y RPO agresivos son, casi siempre, mucho más caros: cuanto más cerca de cero se fijan ambos, mayor es la inversión en redundancia e infraestructura activa necesaria para cumplirlos.
5. Estrategias de continuidad y recuperación
Una vez el BIA ha fijado qué actividades son críticas y con qué RTO/RPO, la cláusula 8.3 de ISO 22301:2019 exige seleccionar e implementar estrategias y soluciones de continuidad de negocio que permitan cumplir esos objetivos. No existe una estrategia universal: la elección combina el RTO/RPO exigido, el coste, la naturaleza del riesgo y la criticidad real del proceso.
5.1 Redundancia y copias de seguridad
Es la base de casi cualquier estrategia de recuperación: sin datos ni sistemas duplicados o respaldados, no hay recuperación posible con independencia de dónde se recupere físicamente. Puntos clave que un BCP/DRP maduro debe cubrir:
- Redundancia de infraestructura: componentes duplicados (servidores, conectividad, fuentes de alimentación) que eliminan puntos únicos de fallo dentro del mismo centro o entre centros.
- Copias de seguridad: frecuencia alineada al RPO objetivo, almacenamiento en ubicación distinta a los datos originales (incluyendo copia fuera de línea o inmutable, especialmente relevante frente a ransomware, que cifra o borra activamente las copias accesibles desde la red), y pruebas de restauración periódicas y documentadas —una copia de seguridad nunca verificada no es una garantía de recuperación, es una suposición.
- Replicación de datos (síncrona o asíncrona) cuando el RPO objetivo es tan bajo que una copia periódica tradicional no puede cumplirlo.
5.2 Sitios alternativos: hot, warm y cold
Cuando la instalación o el centro de datos principal deja de estar disponible, la organización necesita un lugar —físico o en la nube— desde el que reanudar la operación. La elección del tipo de sitio alternativo está directamente condicionada por el RTO exigido y, en sentido inverso, por el presupuesto disponible:
| Tipo de sitio | Descripción | RTO típico | Coste relativo |
|---|---|---|---|
| Hot site | Réplica activa y permanentemente operativa del entorno de producción, con datos sincronizados o casi en tiempo real. La conmutación (failover) es prácticamente inmediata. | Minutos a pocas horas | Muy alto |
| Warm site | Infraestructura parcialmente configurada y disponible (hardware y conectividad listos), pero requiere restaurar datos y/o completar configuración antes de asumir la producción. | Horas a 1-2 días | Medio |
| Cold site | Espacio o infraestructura base disponible (instalación, alimentación, conectividad) pero sin sistemas desplegados; hay que instalar, configurar y restaurar todo desde cero. | Varios días a semanas | Bajo |
En la práctica actual, la computación en la nube ha difuminado bastante esta clasificación tradicional (pensada originalmente para CPD físicos): un entorno cloud con infraestructura como código y snapshots automatizados puede comportarse como un warm site muy rápido de levantar, a un coste mucho menor que un CPD físico dedicado en espera. Aun así, el marco conceptual hot/warm/cold sigue siendo el vocabulario estándar de la disciplina y el que un auditor de ISO 22301 espera encontrar documentado en la estrategia de continuidad.
5.3 Acuerdos con terceros y trabajo remoto
- Acuerdos con terceros: contratos de reciprocidad con otra organización, acuerdos de sitio alternativo gestionado por un proveedor especializado, o cláusulas contractuales de continuidad con proveedores críticos identificados en el BIA (SLA de disponibilidad, penalizaciones, plan de contingencia del propio proveedor exigido contractualmente). Este punto conecta directamente con la gestión del riesgo de terceros que se desarrolla en profundidad en el Módulo 13.
- Trabajo remoto: como estrategia de continuidad para el personal cuando la instalación física principal no está disponible pero los sistemas sí lo están (o se recuperan en un sitio alternativo). Requiere que el BIA haya identificado qué roles pueden operar en remoto, con qué equipamiento (portátiles, VPN, licencias) y con qué controles de seguridad —la pandemia de 2020 convirtió esta estrategia, antes marginal en muchos BCP, en una de las más utilizadas y probadas en la práctica.
6. El BCP frente al DRP: la diferencia que hay que dominar
Esta es, con diferencia, la confusión conceptual más extendida —y el error más señalado por auditores— en organizaciones que se acercan por primera vez a la continuidad de negocio. Ambos son necesarios, ninguno sustituye al otro, y se relacionan como el todo con una de sus partes.
6.1 BCP: Plan de Continuidad de Negocio
El BCP (Business Continuity Plan) es el plan integral, de alcance organizativo, que documenta cómo la empresa mantiene o reanuda sus operaciones críticas —no solo las de TI— durante y después de una interrupción. Cubre personas, procesos, instalaciones, comunicación con clientes y proveedores, y gestión de crisis, además de la tecnología. Su enfoque es el negocio en su conjunto: si la sede principal queda inaccesible, el BCP dice cómo se reubica al personal, cómo se comunica la situación a clientes, cómo se prioriza qué pedidos se sirven primero y quién toma esas decisiones.
6.2 DRP: Plan de Recuperación ante Desastres
El DRP (Disaster Recovery Plan) es un plan de foco específicamente técnico y de TI, centrado en restaurar la infraestructura, los sistemas, las aplicaciones y los datos tras un desastre. Es, en la práctica, un subconjunto operativo dentro del BCP —o un documento hermano estrechamente vinculado a él—: el DRP responde a «¿cómo levantamos de nuevo el servidor, la base de datos y la red?», mientras que el BCP responde a «¿cómo sigue funcionando el negocio mientras eso ocurre, y qué hacemos con las personas, los clientes y las decisiones que no son técnicas?».
6.3 La diferencia en una tabla
| Aspecto | BCP (Continuidad de Negocio) | DRP (Recuperación ante Desastres) |
|---|---|---|
| Alcance | Toda la organización: personas, procesos, instalaciones, TI, comunicación | Infraestructura, sistemas y datos de TI |
| Pregunta que responde | ¿Cómo seguimos operando el negocio durante la interrupción? | ¿Cómo restauramos los sistemas técnicos afectados? |
| Propietario habitual | Dirección general / comité de continuidad | Dirección de TI / responsable de infraestructura |
| Contenido típico | Equipos y roles de crisis, protocolos de comunicación, sedes alternativas, prioridades de negocio, relación con clientes/proveedores | Procedimientos técnicos de failover, restauración de backups, reconstrucción de servidores, runbooks de sistemas |
| Relación entre ambos | Marco general que engloba al DRP | Componente técnico ejecutado dentro del marco del BCP |
6.4 Estructura de un BCP y sus equipos
Un BCP bien construido —el que espera ver un auditor de ISO 22301— incluye, como mínimo:
- Propósito, alcance y criterios de activación: qué tipo de eventos disparan el plan y quién tiene autoridad para declarar la activación.
- Estructura de gestión de crisis: equipos con roles nombrados (no genéricos), cadena de mando y suplentes designados para cada rol crítico.
- Procedimientos de notificación y escalado: a quién se avisa, en qué orden y por qué canal (incluyendo canales alternativos si el correo corporativo no está disponible).
- Procedimientos de continuidad por actividad crítica, derivados directamente de las fichas del BIA: qué hacer, con qué recursos alternativos, hasta cumplir el RTO fijado.
- Plan de comunicación: interna (empleados), externa (clientes, proveedores, medios si procede) y regulatoria (notificaciones obligatorias, como las de NIS2 o RGPD si el incidente implica una brecha de datos).
- Referencias a los DRP técnicos que se activan como parte del plan.
- Listas de contacto y recursos, mantenidas y verificadas periódicamente —una lista de contactos desactualizada es de las causas más tontas y más frecuentes de fallo real en un ejercicio.
Los equipos y roles habituales de la estructura de gestión de crisis son:
- Equipo de gestión de crisis (Crisis Management Team): el nivel de decisión estratégica, normalmente dirección general y responsables de área, que declara la crisis, toma las decisiones de mayor impacto (por ejemplo, pagar o no un rescate de ransomware, cerrar temporalmente una línea de negocio) y autoriza recursos extraordinarios.
- Equipo de comunicación de crisis: gestiona la comunicación interna y externa, coordinado habitualmente con legal y con marketing/comunicación, para evitar mensajes contradictorios o que agraven el daño reputacional.
- Equipos de continuidad por área: uno por cada actividad crítica identificada en el BIA, responsables de ejecutar el procedimiento de continuidad específico de su proceso.
- Equipo de recuperación técnica (TI/DRP): ejecuta los procedimientos técnicos de restauración de sistemas y datos.
7. Pruebas y ejercicios de continuidad
ISO 22301:2019, cláusula 8.5, exige que la organización ejercite y ponga a prueba sus procedimientos de continuidad de negocio periódicamente, para asegurar que son coherentes con los objetivos de continuidad y que la organización puede confiar en ellos. Un plan sin probar es, en el mejor caso, teoría sin verificar; en el peor, una falsa sensación de seguridad que se descubre demasiado tarde, en mitad de un incidente real.
| Tipo de prueba | Qué implica | Objetivo principal | Periodicidad orientativa |
|---|---|---|---|
| Revisión documental | Lectura y verificación crítica del plan sin ejecutar acciones: comprobar que datos de contacto, dependencias y procedimientos siguen siendo correctos. | Detectar desactualización antes de invertir en un ejercicio más costoso | Semestral o tras cualquier cambio relevante en la organización |
| Ejercicio de mesa (tabletop) | Los equipos de crisis se reúnen y discuten verbalmente su respuesta ante un escenario simulado, sin activar sistemas reales. | Validar la toma de decisiones, la cadena de mando y el conocimiento del plan por parte de los equipos | Anual como mínimo |
| Simulacro / walkthrough | Se ejecutan partes reales del plan —convocatoria efectiva de equipos, activación de canales de comunicación alternativos— sin llegar a conmutar sistemas de producción. | Comprobar que los mecanismos de activación y comunicación funcionan en la práctica, no solo sobre el papel | Anual, alternando con el ejercicio de mesa |
| Prueba técnica / failover completo | Conmutación real a la infraestructura o sitio alternativo, restauración de sistemas desde backup y verificación de que el negocio puede operar realmente desde ahí. | Verificar en condiciones reales que el RTO y el RPO fijados son alcanzables de verdad | Anual para sistemas críticos; con mayor frecuencia si lo exige la criticidad o la regulación aplicable |
7.1 Lecciones aprendidas y mejora continua
Toda prueba —y todo incidente real que active el BCP— debe cerrarse con un informe de lecciones aprendidas: qué funcionó, qué no, qué supuestos resultaron falsos (RTO reales muy por encima del objetivo, dependencias no identificadas en el BIA, contactos desactualizados) y qué acciones correctivas se abren, con responsable y plazo, exactamente con la misma disciplina de las no conformidades vista en el Módulo 8 para el SGSI. Este ciclo alimenta directamente la cláusula 10 (Mejora) de ISO 22301 y, en la práctica, retroalimenta también el propio BIA: un ejercicio que revela que el RTO real es el doble del objetivo es una señal de que hay que invertir en la estrategia de continuidad, o de que el objetivo fijado inicialmente no era realista.
8. Cómo lo exigen otras normas: ENS, NIS2 e ISO 27002:2022
La continuidad de negocio no es un capricho de ISO 22301 en solitario: aparece, con distinta profundidad, en prácticamente todo el marco normativo que este curso ha ido cubriendo.
- ISO/IEC 27002:2022, control 5.30 (Preparación de las TIC para la continuidad del negocio). Es un control nuevo respecto a la edición de 2013, dentro de los controles organizativos, y exige planificar, implementar, mantener y probar la preparación de las TIC en base a los objetivos de continuidad de negocio y a los requisitos de continuidad TIC derivados del BIA. En esencia, es la versión «TI» del BIA y del BCP trasladada al lenguaje de ISO 27001/27002, y es exactamente el control que ya apareció referenciado en la SoA de ejemplo del Módulo 4.
- ENS (Real Decreto 311/2022). El Esquema Nacional de Seguridad, visto en el Módulo 9, exige medidas de continuidad dentro de su marco operacional, proporcionales a la categoría del sistema (básica, media, alta): desde la existencia de copias de seguridad hasta, en las categorías más exigentes, planes de continuidad formalizados y probados, alineados conceptualmente con la misma lógica de RTO/RPO que este módulo desarrolla.
- NIS2. El artículo 21.2.c de la Directiva NIS2, visto en el Módulo 11, incluye explícitamente entre las medidas de gestión de riesgos exigidas a entidades esenciales e importantes la «continuidad de negocio, como la gestión de copias de seguridad y de recuperación tras desastre, y la gestión de crisis». NIS2 no impone cifras concretas de RTO/RPO en el texto de la directiva —esos objetivos concretos los fija cada organización mediante su propio BIA—, pero exige de forma inequívoca que exista un proceso formal de continuidad, con copias de seguridad protegidas frente a manipulación (crítico frente a ransomware) y planes de recuperación probados, con responsabilidad expresa del órgano de dirección sobre su aprobación y supervisión.
El resultado práctico es que una organización que ya ha implantado el control 5.30 de ISO 27002:2022 y cumple el artículo 21.2.c de NIS2 tiene, de facto, la mayor parte del trabajo técnico hecho para una certificación completa en ISO 22301: lo que añade la certificación formal es el sistema de gestión completo —cláusulas 4 a 10, con su gobierno, su auditoría y su mejora continua— en lugar de un conjunto de medidas técnicas sueltas.
Caso práctico
Contexto: «Óptica Digital Norte, S.L.» (nombre ficticio), cadena de 12 tiendas de óptica con venta online, 90 empleados, con un ERP en la nube que gestiona inventario, ventas y citas, y un laboratorio propio de fabricación de lentes graduadas en su sede central. Tras un análisis de riesgos que reveló una dependencia crítica no gestionada del proveedor cloud del ERP, la dirección encarga un mini-BIA de tres procesos antes de encargar el BCP completo.
| Proceso | Impacto de la interrupción | RTO asignado | RPO asignado | Justificación |
|---|---|---|---|---|
| Venta y cobro en tienda física (TPV + ERP) | A las 4h: cola de clientes, pérdida de ventas puntuales, molestia reputacional local. A las 24h: pérdida de ingresos diaria significativa en 12 tiendas simultáneamente; posible incumplimiento de citas de entrega de gafas ya pagadas. | 4 horas | 15 minutos | El TPV es el proceso de mayor volumen económico diario y el de mayor visibilidad de cara al cliente; un RPO ajustado evita descuadres de caja y pérdida de pedidos ya cobrados. El coste de un sitio warm para el ERP (proveedor con SLA de alta disponibilidad) es proporcional al volumen de ingresos que protege. |
| Fabricación de lentes graduadas en el laboratorio central | A las 24h: retraso en entregas, pero absorbible reprogramando. A las 72h: incumplimiento generalizado de plazos de entrega prometidos, quejas y posibles devoluciones. A la semana: pérdida de confianza de clientes con graduaciones complejas o urgentes (posoperatorio, primera adaptación). | 48 horas | 24 horas | Es crítico pero tolera un margen mayor que la venta en tienda: hay stock de lentes estándar y se pueden derivar pedidos urgentes a un laboratorio externo subcontratado como medida puente. El RPO de 24h es aceptable porque las órdenes de fabricación se registran también en papel en el propio laboratorio como respaldo manual. |
| Marketing y publicación de contenido en la web corporativa (no transaccional) | A la semana: impacto mínimo, alguna pérdida de tráfico SEO si la caída se prolonga más de varios días. | 5 días | 24 horas | No es un proceso de venta ni de atención al cliente crítico; la web informativa puede recuperarse con calma desde la última copia diaria sin impacto significativo en el negocio. Fijar aquí un RTO agresivo desviaría presupuesto de continuidad hacia donde no aporta valor real. |
Con este mini-BIA, la dirección de Óptica Digital Norte tiene ya el argumento cuantificado para justificar ante el consejo por qué se invierte en un contrato de alta disponibilidad con el proveedor del ERP (RTO de 4h exige, como mínimo, un sitio warm gestionado por el propio proveedor cloud, con cláusula contractual de disponibilidad) y por qué, en cambio, no se justifica el mismo nivel de inversión para la web corporativa. Es exactamente el mismo razonamiento coste-beneficio que se aplicó al tratamiento de riesgos en el Módulo 4, trasladado ahora a la continuidad.
Si el escenario de fondo hubiera sido un ciberataque —por ejemplo, un ransomware que cifrara el ERP y forzara la activación de este mismo BCP—, la investigación técnica del incidente y la contención de la amenaza corresponderían al proceso de DFIR que se cubre en detalle en el curso de DFIR y Respuesta a Incidentes. Y dado que buena parte de los sistemas críticos de una organización como esta dependen de cuentas de administrador de dominio bien protegidas, el curso de Defensa de Active Directory resulta directamente relevante para reducir la probabilidad de que ese escenario llegue a materializarse.
Errores comunes
- Confundir BCP con DRP y llamar «plan de continuidad» a lo que en realidad es solo un procedimiento técnico de restauración de servidores. El resultado es que, ante una crisis real, nadie sabe cómo comunicarse con clientes, quién decide, ni cómo sigue operando el negocio mientras TI restaura los sistemas.
- Fijar RTO y RPO «a ojo», sin BIA previo. Objetivos copiados de una plantilla genérica o decididos en una reunión sin datos reales de impacto casi nunca coinciden con lo que el negocio de verdad necesita —o son excesivamente ambiciosos y caros, o peligrosamente laxos para procesos que sí son críticos.
- Un plan que se escribe una vez y nunca se prueba. Es, con diferencia, el hallazgo más repetido en auditorías de ISO 22301 y en revisiones post-incidente: el plan existe, está aprobado, tiene buena pinta, y falla en la primera activación real porque nunca se había ejecutado ni siquiera como ejercicio de mesa.
- Olvidar las dependencias de proveedores críticos. Un BIA centrado solo en sistemas y personas internas, sin evaluar qué ocurre si el proveedor cloud, el proveedor de nómina externalizado o el proveedor logístico fallan, deja fuera precisamente el tipo de dependencia que NIS2 obliga hoy a gestionar de forma explícita.
- Tratar la continuidad como un proyecto de TI en lugar de un proceso de negocio con propietario en dirección. Sin patrocinio y presupuesto de la alta dirección —exactamente el mismo principio de gobierno del Módulo 2—, el BCP se queda en un documento de buenas intenciones sin recursos reales para probarlo ni mantenerlo actualizado.
- No actualizar el BIA ni el BCP cuando cambia el negocio. Un nuevo proceso crítico, un cambio de proveedor de ERP, la apertura de una nueva sede o la migración a un nuevo entorno cloud invalidan, total o parcialmente, un BIA que no se revisa en consecuencia.
Ejercicio
Elige una organización real o plausible que conozcas bien (tu empresa, o una pyme de un sector que te resulte familiar) y realiza tu propio mini-BIA:
- Identifica tres procesos o actividades de esa organización que consideres críticos, con una frase que describa qué hacen y a quién sirven.
- Para cada uno, redacta el impacto de la interrupción en al menos dos horizontes temporales (por ejemplo, a las 24 horas y a la semana), distinguiendo impacto financiero, legal/regulatorio y reputacional.
- Asigna a cada proceso un RTO y un RPO justificados en una frase cada uno —el razonamiento importa más que el número exacto.
- Para el proceso que consideres más crítico de los tres, identifica sus dependencias en las cuatro categorías (personas, TI, proveedores, instalaciones) y señala si detectas algún punto único de fallo.
- Decide, para ese mismo proceso, qué tipo de sitio alternativo (hot/warm/cold) sería coherente con el RTO que le has asignado, y justifica por qué.
Preguntas frecuentes
¿Es obligatorio certificarse en ISO 22301, o basta con tener un BCP interno sin certificar?
No es obligatorio por defecto: depende del sector, de exigencias contractuales de clientes grandes, o de la estrategia propia de la organización. Muchas empresas implantan los principios de ISO 22301 —BIA, BCP, pruebas periódicas— sin buscar la certificación formal, especialmente si ya tienen un SGSI certificado en ISO 27001 y prefieren evitar duplicar procesos de auditoría. Dicho esto, normas como NIS2 exigen de facto la existencia de un proceso de continuidad de negocio con las mismas piezas esenciales (BIA implícito, planes de recuperación, pruebas), aunque no exijan el certificado ISO 22301 como tal, por lo que la disciplina es obligatoria en la práctica para las entidades dentro de su ámbito, aunque el sello de certificación no lo sea.
¿RTO y RPO deben ser siempre iguales para el mismo proceso?
No, y de hecho casi nunca lo son porque miden cosas distintas: el RTO es una cuestión de velocidad de recuperación (cuánto tarda el sistema en volver a estar operativo) y el RPO es una cuestión de frecuencia de respaldo (cuántos datos se pueden permitir perder). Un proceso puede tener un RTO relativamente relajado (por ejemplo, 24 horas, porque hay margen operativo) pero un RPO muy exigente (por ejemplo, 15 minutos, porque cada transacción es económicamente sensible y no se puede permitir perder ninguna venta registrada). Ambos se fijan de forma independiente en el BIA, según la naturaleza específica del impacto que cada uno mitiga.
¿Qué diferencia hay entre el MTPD y el RTO si los dos hablan de «tiempo máximo»?
El MTPD es el límite que fija el negocio de forma independiente de la capacidad técnica real: es el punto a partir del cual el daño deja de ser tolerable o reversible, con independencia de si la organización es capaz de recuperarse antes o no. El RTO es el objetivo operativo que la organización se fija —y que su estrategia de continuidad debe ser capaz de cumplir— para recuperarse dentro de ese límite, con margen de seguridad. La relación correcta es siempre RTO ≤ MTPD; si una organización descubre en una prueba que su RTO real supera el MTPD del proceso, tiene una brecha de continuidad que debe resolver con más inversión en la estrategia de recuperación, no ignorar.
¿El DRP forma parte del BCP o es un documento completamente independiente?
En la práctica profesional más habitual, el DRP se trata como un componente técnico integrado dentro del marco general del BCP, aunque muchas organizaciones lo mantienen como documento separado por su naturaleza más técnica y su propietario distinto (TI en lugar de dirección general o gestión de crisis). Lo importante no es si están en el mismo archivo o en archivos distintos, sino que estén coherentemente vinculados: el BCP debe referenciar explícitamente cuándo y cómo se activa el DRP, y el DRP debe estar diseñado para cumplir los RTO/RPO que el BIA (parte del BCP) ha fijado para los sistemas de TI. Un DRP excelente pero desconectado del BCP de negocio, o un BCP que no sabe qué puede prometer su propio DRP, son ambos síntomas de una continuidad mal integrada.
¿Con qué frecuencia hay que revisar y volver a probar el BIA y el BCP?
Como mínimo, con periodicidad anual, alineado con la revisión por la dirección de la cláusula 9.3 de ISO 22301 (el mismo ritmo que ya viste para ISO 27001 en el Módulo 2). Además de esa revisión programada, el BIA y el BCP deben revisarse siempre que se produzca un cambio material: un nuevo proceso o producto crítico, un cambio de proveedor de infraestructura o de un tercero identificado como crítico, la apertura o cierre de una sede, una reorganización que cambie roles clave del plan, o —el disparador más valioso de todos— después de cualquier incidente real o ejercicio que haya revelado que algún supuesto del plan (un contacto, una dependencia, un RTO alcanzable) ya no era correcto.
«The requirements specified in this document are generic and intended to be applicable to all organizations, or parts thereof, regardless of type, size and nature of the organization.»