Plan de continuidad del negocio: qué es, BIA, RTO y RPO

Un lunes a las 9 de la mañana el ERP no responde. Nadie sabe si el respaldo de anoche sirve, quién autoriza trabajar con planillas mientras tanto ni a quién llamar en el proveedor. Ese escenario es el que un plan de continuidad del negocio debería haber resuelto antes de que ocurra.

Esta guía explica qué es un plan de continuidad del negocio, en qué se diferencia de un plan de recuperación ante desastres y de un plan de contingencia, qué es el análisis de impacto en el negocio (BIA), qué significan RTO y RPO, qué dice la norma ISO 22301 y qué decisiones son de la dirección. Las definiciones salen de dos fuentes oficiales: la guía NIST SP 800-34 Rev. 1 y la página de ISO sobre la norma 22301.

¿Qué es un plan de continuidad del negocio?

Un plan de continuidad del negocio (BCP, por business continuity plan) es el plan que define cómo sigue operando una organización cuando una interrupción afecta sus procesos críticos. Según la guía NIST SP 800-34, el BCP se centra en sostener los procesos de negocio de la organización durante y después de una interrupción; puede escribirse para los procesos de una sola unidad de negocio o abarcar toda la organización, y puede limitarse a las funciones que se consideran prioritarias.

La misma guía aclara una confusión frecuente: la planificación de continuidad se aplica al negocio en sí —la capacidad de seguir ejecutando funciones y procesos críticos durante y después de una emergencia—, mientras que la planificación de contingencia se aplica a los sistemas de información y describe los pasos para recuperar su operación.

¿Qué diferencia hay entre plan de continuidad, DRP y plan de contingencia?

Son tres planes distintos que deben coordinarse. NIST SP 800-34 los describe así:

Plan de continuidad del negocio (BCP): sostiene los procesos de negocio durante y después de una interrupción. Es el plan de la dirección.

Plan de recuperación ante desastres (DRP): aplica a interrupciones mayores, normalmente físicas, que impiden el acceso a la instalación principal durante un periodo extendido. Es un plan centrado en los sistemas de información, diseñado para restaurar la operación del sistema, la aplicación o la infraestructura en un sitio alterno después de una emergencia.

Plan de contingencia de un sistema de información (ISCP): establece los procedimientos para evaluar y recuperar un sistema concreto tras una interrupción, con roles, inventario, procedimientos de recuperación y pruebas. A diferencia del DRP, puede activarse en la ubicación actual del sistema o en una alterna.

El BCP es del negocio; el DRP y los planes de contingencia son de tecnología. Sin el primero, los otros dos recuperan sistemas que quizá nadie necesitaba primero.

¿Qué es el análisis de impacto en el negocio (BIA)?

El análisis de impacto en el negocio es el paso que convierte la continuidad en algo medible. Según NIST SP 800-34, el propósito del BIA es relacionar el sistema con los procesos de negocio y servicios críticos que soporta y, a partir de esa información, caracterizar las consecuencias de una interrupción.

La guía describe tres pasos para hacerlo. Primero, determinar los procesos de negocio que el sistema soporta y su criticidad de recuperación, junto con los impactos de una interrupción y el tiempo de inactividad estimado, que debe reflejar el máximo que la organización puede tolerar. Segundo, identificar los recursos necesarios para reanudar esos procesos: instalaciones, personal, equipos, software, datos, componentes y registros vitales. Tercero, identificar las prioridades de recuperación de los recursos del sistema, para establecer en qué orden se recupera cada cosa.

En la práctica, el BIA es una conversación con los dueños de los procesos y la dirección, no un ejercicio del área de tecnología: son ellos quienes saben cuánto cuesta cada hora sin facturar, sin despachar o sin pagar nómina.

¿Su plan de continuidad nunca se ha probado?

Hacemos el análisis de impacto, definimos RTO y RPO con la dirección y diseñamos un plan de continuidad y de recuperación que se ensaya antes de darlo por terminado.

• BIA con procesos críticos y prioridad de recuperación
• Simulacro con un escenario real

Conocer la consultoría en continuidad del negocio

¿Qué son el RTO, el RPO y el MTD?

Del BIA salen tres medidas que NIST SP 800-34 define así:

Tiempo máximo tolerable de inactividad (MTD): el tiempo total que el dueño del sistema o la autoridad responsable está dispuesto a aceptar para una interrupción de un proceso de negocio, incluyendo todas las consideraciones de impacto.

Objetivo de tiempo de recuperación (RTO): el tiempo máximo que un recurso del sistema puede permanecer no disponible antes de que haya un impacto inaceptable en otros recursos, en los procesos de negocio que soporta y en el MTD. Como el RTO debe asegurar que no se exceda el MTD, normalmente debe ser más corto que este.

Objetivo de punto de recuperación (RPO): el punto en el tiempo, anterior a la interrupción, hasta el que se pueden recuperar los datos del proceso de negocio con la copia de respaldo más reciente. A diferencia del RTO, no forma parte del MTD: es una medida de cuánta pérdida de datos tolera el proceso.

La guía añade una idea útil para la dirección: cuanto más corto es el RTO, más costosas son las soluciones de recuperación. Un sistema que debe recuperarse de inmediato exige redundancia y sitios alternos; uno de bajo impacto con un RTO largo puede resolverse con un respaldo sencillo. El punto de equilibrio entre el costo de la interrupción y el costo de recuperar es distinto para cada organización y cada sistema.

¿Qué dice la norma ISO 22301?

ISO 22301:2019 es la norma internacional de sistemas de gestión de continuidad del negocio (BCMS). Según la página oficial de ISO, proporciona un marco para que las organizaciones planifiquen, establezcan, implementen, operen, monitoreen, revisen, mantengan y mejoren continuamente un sistema de gestión documentado que proteja contra incidentes disruptivos, reduzca su probabilidad y asegure la recuperación. Su segunda edición se publicó en octubre de 2019 y tiene una enmienda de 2024.

Certificarse no es obligatorio. Tiene sentido cuando un cliente, un banco o el sector lo exige. Lo que sí conviene, en nuestro criterio, es construir el plan con la lógica de un sistema de gestión —responsables, documentación, pruebas y revisión periódica— aunque la empresa nunca se certifique.

Las soluciones del plan, sin comisiones de fabricantes

Si el plan exige respaldo, alta disponibilidad o un sitio alterno, seleccionamos proveedores con criterios definidos antes de ver propuestas.

• Cuatro criterios: funcional, técnico, económico y sostenible
• Implementación gobernada por la PMO

Hablar con nuestro equipo

¿Cómo se hace un plan de continuidad del negocio, paso a paso?

NIST SP 800-34 describe un proceso de siete pasos para la planificación de contingencia de sistemas, que sirve como estructura también para el plan de continuidad:

1. Definir la política: objetivos, alcance, roles y responsabilidades, y la frecuencia de pruebas y mantenimiento.

2. Hacer el análisis de impacto en el negocio (BIA): procesos críticos, impactos, recursos y prioridades de recuperación.

3. Identificar controles preventivos: medidas que reducen los efectos de una interrupción antes de que ocurra.

4. Crear las estrategias de contingencia: respaldos, sitios alternos, roles y consideraciones de costo, integradas a la arquitectura.

5. Desarrollar el plan: documentar la estrategia de recuperación con procedimientos detallados.

6. Probar, capacitar y ejercitar: ensayar el plan, entrenar al personal y hacer simulacros.

7. Mantener el plan: revisarlo y actualizarlo cuando cambian los sistemas, los procesos o la organización.

Un plan de continuidad que no se ha probado no es un plan. El simulacro muestra en horas lo que el documento no muestra en meses.

¿Qué debe decidir la dirección?

Hay decisiones que no puede tomar el área de tecnología sola. Qué procesos son críticos y en qué orden se recuperan. Cuánto tiempo tolera cada uno sin operar (MTD y RTO) y cuántos datos puede perder (RPO). Cuánto está dispuesta la empresa a invertir en redundancia frente al costo de la interrupción. Quién activa el plan, quién comunica a clientes y autoridades, y quién decide volver a la normalidad. Y con qué frecuencia se ensaya.

Lo que sí es de tecnología es el DRP: qué sistemas se restauran, con qué respaldos, en qué sitio y con qué procedimientos. Las dos partes deben encajar: el DRP recupera lo que el BIA dijo que era crítico, en el orden y los tiempos que la dirección fijó.

Cómo podemos ayudarle

En Cyrrus prestamos consultoría en continuidad del negocio: identificamos los procesos críticos, hacemos el análisis de impacto, definimos RTO y RPO con la dirección y diseñamos el plan de continuidad y el de recuperación, que se ensaya con un escenario real antes de darlo por terminado.

Si el plan exige nuevas soluciones de respaldo, alta disponibilidad o un sitio alterno, las seleccionamos con nuestra consultoría de infraestructura tecnológica, sin comisiones de fabricantes, y la implementación la gobierna la Gerencia de Proyectos. Para preparar al equipo directivo, Leadership Academy ofrece un taller de continuidad de negocio y DRP.

Para profundizar en temas relacionados: cómo elegir una consultoría de ciberseguridad y qué es la estrategia de TI.