Introducción
En toda junta directiva hay un momento en el que alguien pregunta: "¿Cuánto tiempo estaríamos sin sistemas si ocurre algo grave?" La respuesta correcta no depende de la tecnología, sino de dos indicadores que muchos directivos desconocen: RTO y RPO.
Recovery Time Objective (RTO) y Recovery Point Objective (RPO) son la brújula que orienta toda inversión en continuidad operativa, backup y disaster recovery. Entenderlos no es tarea exclusiva de TI: es una responsabilidad gerencial porque definen cuánto se pierde y cuánto se recupera ante un incidente. En este artículo los explicamos sin jargon, con ejemplos concretos para empresas mexicanas.
Qué son RTO y RPO en lenguaje directivo
Ambos indicadores miden el impacto de una interrupción, pero en dimensiones distintas. Piensa en un corte de luz prolongado, un ataque de ransomware o un error humano que deja inoperante un sistema crítico.
RTO — Recovery Time Objective
El tiempo máximo que un sistema puede estar caído sin causar un daño inaceptable al negocio. Responde a: ¿en cuánto tiempo necesitamos volver a operar? Se mide en minutos, horas o días.
RPO — Recovery Point Objective
La cantidad máxima de datos que se pueden permitir perder desde el último punto de recuperación. Responde a: ¿cuánto retrocedemos en el tiempo? Se mide en segundos, minutos u horas de información perdida.
Un ejemplo simple: si un ERP tiene un RTO de 4 horas y un RPO de 1 hora, significa que la empresa acepta que el sistema tarde hasta 4 horas en recuperarse y que pierda, como máximo, la información generada en la última hora antes del incidente.
Diferencias clave que toda dirección debe entender
RTO y RPO no son intercambiables. Se confunden a menudo porque ambos hablan de tiempo, pero miden cosas distintas:
Una empresa puede tener un RTO de minutos para su plataforma de ventas online, pero un RPO de 24 horas para su sistema de archivos interno. Esa distinción es lo que permite invertir con inteligencia.
Cómo determinar RTO y RPO por sistema
No se eligen a priori. Se definen desde el negocio hacia la tecnología. En HB Systems utilizamos una metodología de cuatro pasos con los directivos de cada cliente:
1. Calcular el impacto financiero por hora
Identificar ingresos detenidos, costos fijos operativos y sanciones contractuales asociados a cada sistema. Esto da una cifra tangible que la dirección entiende de inmediato.
2. Evaluar el impacto reputacional y regulatorio
Algunos sistemas no generan ingresos directos, pero una falla expone a la empresa ante clientes, auditorías o reguladores. Ese riesgo también se traduce en costo.
3. Clasificar sistemas por criticidad
Categorizar en crítico, alto, medio y bajo según el impacto combinado. Cada categoría recibe un RTO/RPO distinto y, por tanto, una inversión de recuperación diferente.
4. Validar con escenarios realistas
Probar los objetivos en simulacros: no basta con que el plan diga 4 horas, hay que demostrar que se cumplen en condiciones de estrés.
Ejemplos de RTO y RPO por industria
Cada sector tiene un perfil de riesgo distinto. Estos son ejemplos representativos de objetivos que solemos documentar en HB Systems:
Retail / e-commerce
RTO: 30 minutos; RPO: 15 minutos. Cada minuto sin ventas online impacta ingresos directos y reputación de marca.
Manufactura
RTO: 2-4 horas; RPO: 1 hora. Una línea de producción dependiente del ERP puede detener planta y embarques.
Logística y transporte
RTO: 1 hora; RPO: 30 minutos. Sistemas de ruta y entrega afectan operación en tiempo real y cumplimiento de entregas.
Servicios profesionales
RTO: 4 horas; RPO: 2 horas. El impacto principal es productividad del personal y continuidad de proyectos facturables.
Salud y finanzas
RTO: 15 minutos; RPO: casi cero. Regulación y continuidad de atención exigen los niveles más altos de resiliencia.
Estos valores son referencias. Lo importante es que cada empresa defina los suyos basándose en su operación, sus clientes y sus obligaciones regulatorias, no en supuestos genéricos del área de TI.
Relación entre RTO/RPO y costo de inversión
A menor RTO y RPO, mayor inversión en infraestructura de recuperación. Esa curva es la base para tomar decisiones financieras informadas:
- Backups nocturnos y restauración manual: cumplen RPO de 24 horas y RTO de horas o días. Es la opción más económica pero también la más vulnerable.
- Replicación continua a sitio secundario: permite RPO de minutos y RTO de minutos a horas. Requiere inversión en arquitectura y licenciamiento.
- Arquitectura activa-activa en la nube: ofrece RPO cercano a cero y RTO de segundos. Es la solución más robusta, ideal para sistemas críticos de alto impacto.
La decisión correcta no es la más rápida ni la más barata: es aquella en la que el costo de inactividad supera claramente el costo de la protección. El trabajo de la dirección es asegurar que esa conversión se haga con números reales.
Cómo comunicar RTO y RPO a la dirección
Los directivos de TI a menudo fracasan al presentar estos indicadores porque usan lenguaje técnico. La recomendación de HB Systems es traducir cada objetivo a tres cosas que la dirección entiende:
Cuando RTO y RPO se presentan como decisiones de negocio —no como configuraciones de backup— la aprobación de presupuesto y la priorización de proyectos se vuelven mucho más naturales.
Conclusión
RTO y RPO son mucho más que siglas técnicas: son el lenguaje que conecta la operación de TI con la estrategia del negocio. Definirlos bien permite saber qué proteger, cuánto invertir y cómo responder cuando un incidente ocurra.
En HB Systems ayudamos a directivos de empresas mexicanas a traducir sus sistemas críticos en objetivos de recuperación claros, con simulacros, arquitectura a la medida y planes que realmente funcionan bajo presión. Si necesitas alinear TI y negocio con cifras concretas, comenzamos con una evaluación de continuidad sin compromiso.