Guía para Gerentes: Cómo calcular RTO y RPO en un DRP

Capacitación y Educación en TI
16 Feb 2026, 11:40 a.m. Por admin 💬 0
Guía para Gerentes: Cómo calcular RTO y RPO en un DRP

Cuando una empresa habla de Continuidad de Negocio y entra en el tema de DRP (Plan de Recuperación ante Desastres), normalmente aparecen dos siglas que definen todo el presupuesto, la tecnología y el riesgo:

• RTO (Recovery Time Objective): tiempo máximo que el negocio puede estar caído. • RPO (Recovery Point Objective): cantidad máxima de información que la empresa está dispuesta a perder (en tiempo).

Dicho simple:

• RTO = cuánto tiempo puedo estar sin operar • RPO = cuánto tiempo de datos puedo perder

1) Antes de calcular: define qué procesos son “críticos”

No se calcula RTO/RPO “para toda la empresa” en una sola cifra. Se calcula por proceso o sistema clave, por ejemplo:

• Facturación y cartera • ERP / inventario • E-commerce / plataforma de pedidos • Correo corporativo • Atención al cliente / call center • Nómina (por ventana de pago)

✅ Acción: lista los 5–10 procesos que más afectan ingresos, operación, cumplimiento o reputación.

📍Agenda una evaluación de continuidad

y define tus RTO/RPO con impacto real en ingresos y operación.

2) Cómo calcular RTO (en términos gerenciales)

El RTO se define con una pregunta brutalmente sencilla:

¿Cuánto tiempo puedo estar detenido antes de que el daño sea inaceptable?

Para calcularlo, estima el costo por hora de interrupción y define el punto de “dolor máximo”.

Fórmula gerencial práctica

Costo por hora de caída = (Ingresos por hora perdidos) + (Costos extra por hora) + (Penalidades por hora) + (Impacto reputacional estimado) RTO será el tiempo máximo antes de superar un umbral que la empresa considera inaceptable.

Checklist para estimar el costo por hora

• Ventas no realizadas por hora (promedio real) • Producción/operación detenida (costos fijos + desperdicio) • Horas-hombre improductivas o re-procesos • Multas o cláusulas contractuales (SLA) • Impacto en clientes (cancelaciones / churn) • Riesgo regulatorio (si aplica)

✅ Ejemplo rápidoSi tu empresa pierde aprox:

• 6.000.000 COP/h en ventas • 1.500.000 COP/h en horas-hombre + operación detenida

Y además hay riesgo contractual de 10.000.000 COP si la caída supera 4 horas, Entonces el gerente podría decir: “Mi RTO objetivo debe ser menor a 4 horas” (porque después se dispara el impacto contractual).

👉 Resultado: RTO recomendado: 2–4 horas (dependiendo del margen de seguridad).

Descarga la plantilla de BIA + RTO/RPO

y prioriza tus procesos críticos en menos de 1 hora.

3) Cómo calcular RPO (lo que puedes perder sin quebrar el proceso)

El RPO responde a:

¿Cuál es el máximo de datos que puedo perder sin que el negocio colapse o se vuelva caótico?

Se mide en tiempo porque depende de cada cuánto cambian los datos.

Método simple para gerentes (por proceso/sistema)

• Si pierdo la información de las últimas X horas, ¿puedo reconstruirla? ¿Cuánto me cuesta?

• El RPO debe ser menor que esa X.

✅ Ejemplos muy típicos

• E-commerce / pedidos: RPO 5–15 min (perder pedidos es crítico) • ERP / inventario: RPO 15–60 min (reconstrucción es costosa) • Correo: RPO 1–4 h (depende del negocio) • Nómina: RPO 4–24 h (si se maneja por lotes, puede tolerar más)

Preguntas clave para fijar RPO sin tecnicismos

• ¿Se puede reingresar manualmente lo perdido? • ¿Cuánto tarda y cuántas personas requiere? • ¿Existe registro alterno (pasarela de pagos, WhatsApp, formularios, logs)? • ¿La pérdida afecta cumplimiento o auditoría?

👉 Si reconstruir 2 horas de datos implica 2 días de caos y reclamos, tu RPO no puede ser 2 horas.

4) Tabla rápida para decidir (útil en comité)

Usa esta lógica para clasificar cada sistema:

• Muy crítico (core del negocio): RTO 1–4 h | RPO 5–15 min • Crítico (operación diaria): RTO 4–8 h | RPO 15–60 min • Importante: RTO 8–24 h | RPO 4–12 h • Soporte: RTO 24–72 h | RPO 12–24 h

(No es una regla universal, pero sirve para arrancar con criterio ejecutivo.)

5) El error más común: poner RTO/RPO “ideal” sin presupuesto real

RTO y RPO no son deseos. Son decisiones de negocio que implican costo:

• RTO muy bajo → requiere alta disponibilidad, redundancia, automatización • RPO muy bajo → requiere backup continuo, replicación, arquitectura adecuada

✅ Recomendación gerencial:Define RTO/RPO por niveles y prioriza el Top 20% de sistemas que sostienen el 80% del negocio.

Un DRP serio empieza por números, no por herramientas.

Si un gerente define RTO y RPO con base en impacto real (dinero, clientes, cumplimiento), el plan deja de ser “TI” y se vuelve estrategia de continuidad.

También te puede interesar

Comentarios (0)

Sé el primero en comentar.