Casi todas las organizaciones tienen copias de seguridad. Muy pocas saben cuánto tardarían de verdad en volver a operar tras una interrupción grave, ni qué procesos hay que levantar primero. Esa diferencia, entre tener respaldos y tener continuidad, es exactamente lo que ordena ISO 22301. En este artículo le explico qué exige la norma, cómo se hace un análisis de impacto que sirva para decidir, qué significan RTO y RPO cuando hay dinero de por medio, por qué un plan que nunca se ha probado no cuenta, y cómo encaja todo esto con lo que ya le exigen ISO 27001, NIS2 y DORA.
Qué es ISO 22301 y qué problema resuelve
ISO 22301:2019 es la norma internacional de sistemas de gestión de la continuidad de negocio. No es un manual de recuperación informática: es un marco para que una organización identifique qué actividades no puede permitirse perder, durante cuánto tiempo, y qué tiene preparado para sostenerlas cuando algo falla.
La diferencia con un plan de recuperación ante desastres es de alcance y de propósito. La recuperación mira a los sistemas; la continuidad mira al negocio: personas, instalaciones, proveedores, procesos y datos. Un centro de datos replicado no sirve de nada si el equipo que opera el proceso crítico no puede trabajar y nadie ha decidido quién declara la crisis.
Como el resto de normas de sistemas de gestión, sigue la estructura de alto nivel del Anexo SL, con sus cláusulas de contexto, liderazgo, planificación, soporte, operación, evaluación del desempeño y mejora. Si su organización ya trabaja con ISO 27001, el esqueleto le resultará familiar y buena parte del sistema es reutilizable.
El BIA: donde se decide todo lo demás
El análisis de impacto en el negocio, o BIA por sus siglas en inglés, es la pieza que sostiene el resto de la norma. Es donde se responde a una pregunta incómoda: si esta actividad se detiene, qué pasa y a partir de cuándo empieza a doler.
Un BIA que sirve para decidir mide el impacto a lo largo del tiempo, no en un único momento. La misma parada de un servicio de facturación puede ser irrelevante durante dos horas, incómoda a las ocho y grave a los tres días, cuando entran los vencimientos. Ese perfil temporal es el que después fija las prioridades y el presupuesto.
De un BIA bien hecho salen tres cosas que se usarán en todo lo demás: las actividades priorizadas, el periodo máximo tolerable de interrupción de cada una, y los recursos mínimos que hacen falta para sostenerlas, incluidos los proveedores de los que depende sin haberlo escrito nunca.
El error más frecuente que veo en proyectos es hacer el BIA por departamentos y no por actividades. Un departamento no se interrumpe: se interrumpe un proceso, que casi siempre atraviesa varios departamentos y algún proveedor externo.
RTO y RPO, explicados con un caso
Son los dos números que gobiernan la inversión, y se confunden constantemente. Conviene fijarlos con un ejemplo.
Imagine una gestoría que emite nóminas. El RTO, objetivo de tiempo de recuperación, es cuánto puede estar caído el servicio antes de que el daño sea inaceptable: pongamos ocho horas laborables. El RPO, objetivo de punto de recuperación, es cuántos datos puede permitirse perder medidos en tiempo: si la copia es nocturna, el RPO es de veinticuatro horas, y eso significa que un fallo a las seis de la tarde borra un día entero de trabajo que habrá que rehacer a mano.
La consecuencia práctica es directa: bajar el RPO cuesta dinero en tecnología (replicación, copias más frecuentes) y bajar el RTO cuesta dinero en preparación (entornos alternativos, procedimientos ensayados, personas formadas). Poner los dos a cero es una fantasía cara, y ponerlos sin BIA es adivinar.
Hay un tercer número que se olvida y decide si los otros dos son creíbles: el periodo máximo tolerable de interrupción. Si el RTO que ha fijado es mayor que ese máximo, el plan no protege nada, solo documenta cuándo va a fallar.
De la estrategia al plan que alguien ejecuta
Con los objetivos fijados, la norma pide elegir estrategias de continuidad y convertirlas en procedimientos concretos. Las opciones habituales son sostener la actividad en otro sitio, degradarla a un modo manual acordado, trasladarla a un tercero, o aceptar el riesgo de forma explícita y documentada.
Aceptar el riesgo es una respuesta legítima, y conviene decirlo, porque el miedo a escribirla lleva a inventar planes que nadie va a ejecutar. Lo que no es legítimo es no haberlo decidido.
Del lado del plan, lo que distingue a uno útil de uno decorativo es que responda a cuatro preguntas sin que nadie tenga que interpretar nada: quién decide que se activa, a quién se avisa y por qué canal cuando el correo corporativo es justo lo que está caído, qué se hace en las primeras dos horas, y cómo se vuelve a la normalidad, que es la parte que casi siempre falta.
¿Quiere certificarse como ISO 22301 Lead Implementer?
Formación oficial PECB con un consultor en activo, a su ritmo o con coaching 1-a-1.
Un plan sin probar no es un plan
Aquí es donde se separan los sistemas de gestión que funcionan de los que solo existen en una carpeta. La norma exige un programa de ejercicios y pruebas, y no por formalismo: un plan que no se ha ejecutado nunca contiene, sin excepción, supuestos falsos.
Los ejercicios van de menos a más y no hace falta empezar por el más caro: revisión sobre el papel, ejercicio de mesa con los responsables reales, simulacro de un componente concreto, y por último prueba con conmutación real. Cada nivel destapa cosas distintas.
El valor del ejercicio no es aprobarlo. Es la lista de lo que salió mal, con un responsable y una fecha detrás.
La continuidad no se demuestra el día del incidente: se demuestra el día del ejercicio. Quien solo tiene el documento descubre sus supuestos falsos en el peor momento posible, y con clientes delante.
Cómo encaja con ISO 27001, NIS2 y DORA
Esta es la parte que más interesa a quien ya está en un proyecto de cumplimiento, porque evita pagar dos veces por el mismo trabajo.
Con ISO/IEC 27001 el solape es notable: comparten la estructura de alto nivel, el análisis de contexto, la gestión documental, la auditoría interna y la revisión por la dirección. Lo que ISO 27001 trata como un control, la continuidad, ISO 22301 lo desarrolla como sistema completo.
NIS2 lo exige de forma expresa: entre las medidas de su artículo 21 figura la continuidad de negocio, incluyendo gestión de copias, recuperación ante desastres y gestión de crisis. Un sistema conforme a ISO 22301 es la manera más ordenada de acreditar ese bloque ante una autoridad.
Y para entidades financieras, DORA va más lejos todavía: exige una política de continuidad de las TIC, planes de respuesta y recuperación, y pruebas periódicas con resultados documentados. Los conceptos son los mismos y el trabajo se reutiliza casi entero.
En un proyecto real, esto significa que el BIA que haga para ISO 22301 le sirve para justificar decisiones en los otros tres marcos. Merece la pena hacerlo bien una vez.
Formarse y certificarse
Si quiere dar el paso a la certificación oficial PECB, hay tres niveles según lo que necesite. ISO 22301 Foundation para conocer el marco y el vocabulario. Lead Implementer si va a montar el sistema de gestión. Lead Auditor si va a auditarlo, por cuenta propia o de un organismo de certificación.
Los tres se pueden cursar en autoestudio, con el material oficial de PECB y a su ritmo, o con acompañamiento en sesiones individuales conmigo si prefiere resolver las dudas sobre su caso concreto y no sobre un ejemplo de manual.