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
Auditoría de Ciberseguridad: Qué Te Entregan Realmente y Cuándo la Necesitas
MFA no es infalible: 4 formas en que los hackers lo saltan (y cómo blindar tu ciberseguridad)
SIM Swapping en Colombia: Cómo te vacían Nequi sin robarte el celular (y cómo protegerte)
Comentarios (0)
Sé el primero en comentar.