Cómo calcular el RTO y el RPO en un análisis de impacto (BIA): paso a paso, con un ejemplo y una plantilla

La respuesta corta: el RTO y el RPO no se eligen, se deducen del análisis de impacto. Primero mides, proceso a proceso, cuánto daño hace una parada de 1 hora, 4, 8, 24 y 72. El máximo de parada tolerable (MTPD) es el primer momento en que ese daño se vuelve inaceptable. El RTO es el plazo en que te comprometes a volver a funcionar, como mínimo, y va antes del MTPD y con margen. El RPO es cuántos datos, medidos en tiempo, puedes perder sin que el proceso deje de ser viable, y lo fija lo que el negocio no puede reconstruir, no la frecuencia de tus copias de seguridad.

El resto del artículo es el método completo en seis pasos, aplicado a un caso con números, los errores que más veo y una plantilla para hacer el tuyo.

RTO, RPO y MTPD en una tabla

Las definiciones de RTO, RPO y MTPD están en la norma de vocabulario ISO 22300. La ISO 22301 no impone números: pide determinar, para cada actividad, el plazo a partir del cual el impacto de no reanudarla se vuelve inaceptable, y fijar dentro de ese plazo los tiempos para reanudarla a una capacidad mínima aceptable. Eso son el MTPD y el RTO.

La regla que no se puede romper: RTO < MTPD. Si tu RTO es igual o mayor que tu máximo de parada, no tienes un plan de continuidad; tienes la esperanza de recuperarte justo a tiempo.

Paso 1. Lista procesos, no sistemas

El BIA se hace sobre lo que la organización hace, como vender, servir pedidos o pagar nóminas, no sobre los servidores. Los sistemas vienen después, en el paso 6, y heredan los objetivos de los procesos que sostienen.

Para cada proceso, apunta:

• un responsable de negocio, que es quien decidirá sus objetivos;
• de qué sistemas, personas, ubicaciones y proveedores depende;
• sus picos de calendario: el cierre de mes, el día de la nómina, la campaña de Navidad. Un proceso puede aguantar una semana parado en agosto y ni un día el 28.

Paso 2. Fija una escala de impacto y unos horizontes

Sin escala, cada responsable dirá que su proceso es crítico. La escala hace comparables los procesos. Una de cinco niveles y cinco dimensiones basta:

Si tu actividad lo requiere, añade una quinta dimensión: la seguridad y la salud de las personas. Los importes son de una empresa mediana; ajústalos a la tuya, pero que la dirección los apruebe antes de empezar, no después de ver los resultados.

Los horizontes, los mismos para todos los procesos: 1 h, 4 h, 8 h, 24 h, 72 h y 1 semana.

Paso 3. Mide el impacto de cada proceso en cada horizonte

Con el responsable del proceso delante, rellena una fila por dimensión: si este proceso se para ahora, en el peor momento razonable del año, ¿qué nivel de daño hay a la hora? ¿Y a las 4 horas? ¿Y a las 8?

Dos reglas para rellenarla:

• El impacto nunca baja con el tiempo. Si a las 8 horas es grave, a las 24 no puede ser moderado.
• Cada nivel con su porqué. «A las 8 horas, 40 000 € en pedidos que se van a la competencia» se puede defender ante un auditor. «Un 3, porque sí», no.

Paso 4. El MTPD es el primer horizonte inaceptable

Mira la fila de cada dimensión y busca el primer horizonte en que alguna llega al nivel 4. Ese es el máximo de parada tolerable del proceso. No se promedian las dimensiones: basta con que una se vuelva inaceptable.

Paso 5. El RTO va antes del grave, y el RPO sale de lo que no se puede reconstruir

El RTO. Mi regla: el RTO es el último horizonte antes de que alguna dimensión llegue a grave (nivel 3). Así hay margen entre el momento en que te comprometes a volver y el momento en que el daño ya no tiene vuelta atrás, y ese margen es el que te come la realidad: la detección tarda, decidir activar el plan tarda, y la primera restauración casi nunca sale a la primera.

Recuerda que el RTO se cuenta desde la interrupción, no desde que alguien decide activar el plan. Si tardas una hora en darte cuenta y otra en decidir, esas dos horas son parte de tu RTO.

El RPO. No se calcula con la tabla de impacto, sino con una pregunta al responsable del proceso: si perdemos los datos de la última hora, ¿podemos reconstruirlos? ¿Y los de las últimas 4? ¿De dónde, a qué coste y en cuánto tiempo? El RPO es el punto a partir del cual la respuesta pasa a ser «no» o «sí, pero a un coste inaceptable».

Hay datos que se reconstruyen solos: un pedido web suele dejar rastro en la pasarela de pago y en el correo de confirmación. Otros no dejan ninguno: un pedido tomado por teléfono y tecleado en el ERP solo existe en el ERP.

Paso 6. Pasa de los procesos a los sistemas, y compara con la realidad

Un sistema que sostiene varios procesos hereda el RTO y el RPO más exigentes de todos ellos. Después, compara cada objetivo con lo que de verdad tienes:

• frente al RPO: cada cuánto se copian los datos, y si la copia está fuera del alcance de un ransomware;
• frente al RTO: cuánto tarda restaurar esa copia, medido en una prueba, no estimado; y, si el sistema es de un proveedor, qué tiempo de recuperación tiene firmado en el contrato.

Cada diferencia es una brecha. Cada brecha se cierra con más inversión, se acepta con la firma de la dirección o se replantea si el objetivo estaba mal. Lo que no puede pasar es que nadie la haya visto.

Un ejemplo completo: el proceso de pedidos de ACME

ACME es una distribuidora que vende por web y por teléfono. Su proceso de gestión de pedidos depende del ERP, que está en sus servidores, y de la tienda web, que es un servicio en la nube de un proveedor. Mueve unos 5 000 € de pedidos por hora laborable, y su almacén prepara lo que entra hasta las 18:00 para que salga al día siguiente.

La responsable de operaciones rellena la tabla de impacto:

Y el porqué de cada salto:

• A las 4 horas, unos 10 000 € de pedidos se han ido a la competencia (nivel 2), y el almacén empieza a quedarse sin trabajo para la tarde.
• A las 8 horas, son unos 40 000 € (nivel 3), las 30 personas del almacén están paradas (nivel 3) y no saldrá nada al día siguiente.
• A las 24 horas, ACME incumple los plazos de entrega de sus tres grandes clientes, que representan un tercio de la facturación, y no puede servir a nadie más (operativo, nivel 4).

El MTPD es de 24 horas: es el primer horizonte en que una dimensión, la operativa, llega al nivel 4.

El RTO es de 4 horas: el primer nivel 3 aparece a las 8 horas, y el último horizonte antes de eso es el de 4. Entre el RTO y el MTPD quedan 20 horas de margen.

El RPO es de 1 hora. Los pedidos web se pueden reconstruir desde la pasarela de pago, pero los telefónicos solo están en el ERP: nadie recuerda qué le pidió un cliente hace tres horas. La responsable acepta perder, como mucho, la última hora y volver a llamar a esos clientes.

Ahora, el paso 6. El ERP sostiene también la facturación (RPO de 24 horas) y la nómina (RPO de 24 horas), así que hereda el más exigente: RTO de 4 horas y RPO de 1 hora. Y aquí aparecen las brechas:

Ninguna de las tres brechas se veía mirando solo el ERP o solo la tienda. Salen de cruzar lo que necesita el negocio con lo que tienen la tecnología y los contratos. Y la tercera es la que más se olvida: tu RTO no puede ser mejor que el del proveedor del que dependes, salvo que tengas un plan B que no dependa de él.

Mi criterio para los casos que la norma deja abiertos

Ninguna norma te dice cómo convertir el impacto en un RTO. Estas son las reglas que aplico:

• El RPO lo firma el negocio, nunca Sistemas. Si lo decide Sistemas, el RPO acaba siendo la frecuencia de la copia que ya existe, y la brecha desaparece por definición.
• Ni el MTPD ni el RTO se redondean a cifras bonitas. Si el BIA dice 4 horas, el objetivo es 4 horas, no «el mismo día».
• Una brecha que no se va a cerrar se acepta por escrito. Con el riesgo, el coste de cerrarla y la firma de quien lo acepta. Un supervisor o un auditor entiende que no todo se puede pagar; no entiende que nadie lo supiera.
• El BIA se rehace cuando cambia el negocio, no solo una vez al año: un proveedor nuevo, un sistema nuevo o un cliente que pasa a pesar un tercio de la facturación cambian los números.

Qué piden las normas

Los errores más frecuentes

1. Hacer el BIA por sistemas. El resultado es una lista de servidores con su RTO, sin saber por qué.
2. Confundir el RPO con la frecuencia de la copia. La copia es la realidad; el RPO, el objetivo. Si son iguales por definición, nunca verás la brecha.
3. Medir el RTO sin restaurar nunca. Una copia horaria que tarda 10 horas en restaurarse no cumple un RTO de 4.
4. Olvidar a los proveedores. El tiempo de recuperación del proveedor de la nube es tu suelo, salvo que tengas un plan alternativo.
5. Rellenar el impacto en un día tranquilo. El BIA se hace para el peor momento razonable: el cierre de mes, la campaña, el día de la nómina.
6. Un RTO mayor que el MTPD. Ocurre más de lo que parece cuando cada cifra la pone una persona distinta.
7. Un BIA sin aprobar. Sin la firma de la dirección, los objetivos son una opinión, y los recursos para cumplirlos no llegan.

Plantilla para hacer el tuyo

Una fila por proceso y dimensión, con estas columnas:

Puedes descargarla en CSV, con el ejemplo de ACME ya relleno, y abrirla con Excel o con LibreOffice.

Cómo dejarlo resuelto

Un BIA en una hoja de cálculo se queda viejo el día que cambia algo, y la brecha entre el RPO y la copia del ERP solo se ve si alguien cruza dos documentos a mano.

En Almenara, el módulo de Continuidad hace el BIA con un asistente que explica cada concepto, propone el MTPD, el RTO y el RPO a partir del impacto que rellenas, y te deja corregirlos con su porqué. Los objetivos pasan a los sistemas y a los proveedores del inventario, y las brechas aparecen solas. Si prefieres hacerlo con nosotros, el taller de análisis de impacto te deja el BIA hecho y aprobado. Y en la guía de DORA tienes el resto de obligaciones de continuidad.

Preguntas frecuentes

¿Cuál es la diferencia entre RTO y RPO?

El RTO es tiempo de parada: en cuánto tiempo tienes que volver a funcionar. El RPO es pérdida de datos: cuántas horas de información puedes perder. Un proceso puede tener un RTO de 24 horas y un RPO de 0, si puede esperar un día pero no puede perder ni un dato.

¿Cuál es la diferencia entre RTO y MTPD?

El MTPD es el límite a partir del cual el daño es inaceptable; el RTO es tu compromiso de recuperación, y siempre va antes. Entre los dos queda el margen para lo que sale mal durante la recuperación.

¿Quién debe fijar el RTO y el RPO?

El responsable de negocio del proceso, con el impacto delante, y la dirección los aprueba. Sistemas aporta lo que cuesta cumplirlos y lo que se cumple hoy, pero no decide el objetivo.

¿Se puede tener un RPO de cero?

Sí, con replicación síncrona a un segundo centro, pero cuesta mucho más que una copia periódica. Reserva el RPO de cero para los datos que de verdad no se pueden reconstruir, como las operaciones financieras en firme.

¿El RTO empieza a contar desde el incidente o desde que se activa el plan?

Desde la interrupción. El tiempo que tardas en detectarla y en decidir activar el plan forma parte del RTO, y por eso conviene dejar margen hasta el MTPD.

¿Cada cuánto hay que revisar el BIA?

Al menos una vez al año y cada vez que cambie algo importante: un proceso, un sistema, un proveedor o el peso de un cliente. DORA obliga a probar los planes de continuidad al menos una vez al año, y una prueba con un BIA desactualizado prueba el plan equivocado.