DRP: cómo definir RTO y RPO con números simples para proteger tu operación

¿Qué es un DRP y por qué importa tanto?

Cuando una empresa habla de continuidad operacional, muchas veces piensa en respaldos, antivirus o en tener “todo en la nube”. Sin embargo, eso no equivale necesariamente a estar preparada para una interrupción real. Un DRP (Disaster Recovery Plan), o plan de recuperación ante desastres, es el conjunto de estrategias, procedimientos, responsables y tecnologías que permiten recuperar sistemas, datos y servicios críticos después de un incidente.

Ese incidente puede ser muy distinto según la organización: una caída eléctrica prolongada, un error humano, un ransomware, una falla de infraestructura, una mala actualización, la indisponibilidad del proveedor cloud o incluso un problema físico en la oficina o datacenter. Lo importante es entender que el DRP no se diseña para “evitar todo”, sino para recuperarse con rapidez y con pérdidas controladas.

Aquí aparecen dos conceptos fundamentales: RTO y RPO. Son dos siglas muy usadas en continuidad de negocio y ciberseguridad, pero a menudo se definen de forma abstracta. El problema de eso es que, si no se traducen a números simples, el plan queda en teoría. Y un DRP teórico suele fallar justo cuando más se necesita.

Este artículo explica cómo definir RTO y RPO de manera práctica, con ejemplos fáciles de entender, para que cualquier empresa pueda tomar decisiones realistas sobre respaldo, recuperación y continuidad.

RTO y RPO: la base de cualquier DRP

Antes de hablar de herramientas o arquitectura, conviene aterrizar ambos conceptos.

RTO: Recovery Time Objective

El RTO es el tiempo máximo aceptable que un sistema puede estar fuera de servicio después de un incidente.

Dicho de forma simple: ¿cuánto tiempo puedes estar caído antes de que el impacto sea inaceptable?

Si tu sitio de ventas puede estar fuera de línea solo 1 hora, entonces su RTO es de 1 hora. Si un sistema interno puede esperar hasta el día siguiente, su RTO podría ser de 8 o 12 horas.

RPO: Recovery Point Objective

El RPO es la cantidad máxima de datos que la empresa está dispuesta a perder, medida en tiempo.

Dicho de forma simple: si ocurre un incidente, ¿hasta qué momento anterior necesitas recuperar la información?

Si haces respaldos cada 24 horas, tu RPO real podría ser de hasta 24 horas. Eso significa que podrías perder todo lo ingresado desde el último respaldo hasta el momento del incidente. Si eso no es aceptable, necesitas una estrategia mejor.

Una forma fácil de recordarlo

• RTO = cuánto tiempo puedo estar sin operar
• RPO = cuánta información puedo perder

Aunque suenan parecidos, responden a preguntas distintas. Una empresa puede necesitar volver a operar rápido, pero tolerar perder pocos minutos de datos. Otra puede aceptar una recuperación más lenta, pero no perder ningún registro crítico.

Por qué muchas empresas definen mal el RTO y el RPO

Uno de los errores más comunes es fijar objetivos sin relacionarlos con el negocio. Por ejemplo:

• “Queremos recuperación inmediata.”
• “No podemos perder nada.”
• “Todo es crítico.”

Estas frases son comprensibles, pero no ayudan a diseñar un DRP viable. Recuperación inmediata y pérdida cero son objetivos costosos, complejos y, en algunos casos, innecesarios. Si todo se clasifica como crítico, al final nada se prioriza correctamente.

Otro error frecuente es copiar valores desde una política corporativa o desde un proveedor tecnológico sin validar si esos números reflejan la realidad operativa. El resultado suele ser uno de estos dos escenarios:

1. Se invierte de más en soluciones sobredimensionadas.
2. Se invierte de menos y el plan no soporta una crisis real.

Definir bien RTO y RPO exige mirar procesos, impacto económico, dependencia tecnológica y expectativas del negocio. No es solo una decisión de TI.

Cómo definir RTO con números simples

La mejor forma de definir un RTO es dejar de pensar en servidores y empezar por el impacto del servicio.

Paso 1: identifica el servicio o proceso

No partas por “la base de datos” o “la VM”. Parte por algo que el negocio entienda, por ejemplo:

• Plataforma de e-commerce
• ERP de facturación
• Sistema de atención al cliente
• Correo corporativo
• Portal interno de RR. HH.

Paso 2: pregunta cuánto tiempo puede detenerse

Haz una pregunta concreta:

Si este servicio deja de funcionar ahora, ¿cuánto tiempo podemos tolerarlo antes de que el daño sea serio?

Para responder, conviene usar tramos simples:

• 15 minutos
• 1 hora
• 4 horas
• 8 horas
• 24 horas
• 48 horas

Evita respuestas ambiguas como “lo antes posible”. Obliga a elegir un número.

Paso 3: calcula el impacto por hora

Aunque no siempre se necesita una fórmula compleja, sí ayuda estimar el costo de la interrupción. Por ejemplo:

• Ventas no realizadas por hora
• Multas o incumplimientos
• Horas improductivas del equipo
• Pérdida de atención a clientes
• Daño reputacional

Ejemplo simple

Una tienda online vende en promedio $1.200.000 CLP por hora en horario peak.

Si el sitio cae:

• 1 hora = pérdida estimada de $1.200.000
• 4 horas = pérdida estimada de $4.800.000
• 8 horas = pérdida estimada de $9.600.000

Si además el equipo de soporte y ventas queda detenido, el costo real sube aún más. En ese caso, un RTO de 1 hora puede ser razonable. Un RTO de 8 horas probablemente no lo sea.

Paso 4: valida si ese tiempo es técnica y económicamente viable

Aquí aparece la realidad. Tal vez el negocio quiere 15 minutos de RTO, pero la infraestructura actual solo permite 6 horas. Eso no significa que el ejercicio esté mal. Significa que ya tienes una brecha concreta entre necesidad y capacidad.

Esa brecha es justamente lo que permite decidir:

• si mejorar respaldos,
• si implementar replicación,
• si mover cargas a cloud,
• si automatizar recuperación,
• o si aceptar el riesgo actual.

Cómo definir RPO con números simples

El RPO suele ser más difícil de visualizar porque habla de datos, no de disponibilidad. Pero se puede aterrizar con una pregunta igual de simple:

Si ocurre un incidente, ¿cuántos minutos u horas de información podríamos perder sin afectar gravemente el negocio?

Paso 1: identifica qué datos genera el proceso

No todos los sistemas tienen el mismo valor informacional. Algunos ejemplos:

• Pedidos de clientes
• Pagos aprobados
• Facturas emitidas
• Tickets de soporte
• Registros clínicos
• Inventario actualizado
• Documentos internos

Paso 2: mide la frecuencia de cambio

Si un sistema cambia una vez al día, un RPO de 12 horas podría ser suficiente. Pero si registra transacciones cada minuto, un RPO de 24 horas es demasiado alto.

Paso 3: traduce la pérdida de datos a un caso real

Ejemplo simple 1: sistema de ventas

Una empresa registra 20 pedidos por hora.

Si su RPO es de 4 horas, en un incidente podría perder hasta:

• 80 pedidos

Si cada pedido promedia $35.000 CLP, la pérdida potencial sería:

• 80 x $35.000 = $2.800.000 CLP

Y eso sin contar reclamos, reprocesos ni conciliación manual.

Ejemplo simple 2: sistema de RR. HH.

Un portal interno recibe pocas actualizaciones al día: solicitudes, documentos y cambios administrativos.

Si el volumen es bajo, un RPO de 24 horas podría ser aceptable, porque la información perdida se puede reconstruir con esfuerzo razonable.

Paso 4: compara el RPO deseado con el método de respaldo actual

Aquí suele aparecer otra brecha importante.

• Si haces backup diario a las 2:00 AM, tu RPO difícilmente será menor a 24 horas.
• Si replicas cada 15 minutos, tu RPO puede acercarse a 15 minutos.
• Si tienes sincronización continua, el RPO puede ser casi cero, aunque con mayor costo y complejidad.

La relación entre RTO, RPO y presupuesto

RTO y RPO no son solo métricas técnicas. Son decisiones de negocio con impacto directo en inversión.

En general, mientras más exigentes sean los objetivos:

• más automatización se necesita,
• más redundancia debes implementar,
• más monitoreo debes tener,
• y mayor será el costo de operación.

Regla práctica

• RTO alto + RPO alto: menor costo, mayor tolerancia al riesgo
• RTO bajo + RPO bajo: mayor costo, menor tolerancia al riesgo

No existe un valor “correcto” universal. Lo correcto es que el número refleje lo que el negocio realmente necesita y está dispuesto a financiar.

Ejemplos simples de RTO y RPO por tipo de sistema

A continuación, una tabla conceptual con valores orientativos. No son estándares fijos, pero sirven para iniciar conversaciones.

La clave no es copiar esta tabla, sino usarla como punto de partida para clasificar servicios según criticidad.

Cómo priorizar si no todo puede tener el mismo nivel de recuperación

En la práctica, casi ninguna organización puede darle a todos sus sistemas el mismo nivel de protección. Por eso conviene clasificarlos.

Nivel 1: crítico

Si falla, detiene ventas, atención, facturación o cumplimiento regulatorio.

• RTO sugerido: 15 minutos a 2 horas
• RPO sugerido: 0 a 30 minutos

Nivel 2: importante

Afecta productividad y operación, pero no paraliza completamente el negocio.

• RTO sugerido: 4 a 8 horas
• RPO sugerido: 1 a 4 horas

Nivel 3: soporte

Puede esperar más tiempo y la pérdida de datos es recuperable manualmente.

• RTO sugerido: 24 a 48 horas
• RPO sugerido: 12 a 24 horas

Esta clasificación ayuda a evitar un error muy común: tratar el sistema de archivos históricos igual que la plataforma de ventas en línea.

Qué información necesitas para definir bien estos objetivos

Para fijar RTO y RPO de forma responsable, conviene levantar al menos estos datos:

1. Qué proceso soporta el sistema
2. Cuántos usuarios dependen de él
3. Qué pasa si se cae 1 hora, 4 horas o 1 día
4. Qué datos se perderían si se restaura desde el último respaldo
5. Cuánto cuesta la interrupción
6. Qué dependencias tiene
7. Qué controles actuales existen
8. Cuánto tiempo tarda hoy una recuperación real

Este último punto es clave. Muchas empresas creen tener un buen DRP porque hacen backups, pero nunca han medido cuánto demoran realmente en restaurar un servicio completo.

DRP no es solo backup

Tener respaldos es importante, pero un DRP va mucho más allá. Un respaldo sin pruebas, sin responsables y sin tiempos definidos no garantiza continuidad.

Un DRP maduro suele incluir:

• Inventario de sistemas críticos
• Priorización por impacto
• RTO y RPO definidos por servicio
• Procedimientos de recuperación documentados
• Roles y responsables claros
• Canales de comunicación en crisis
• Ambientes alternativos o redundantes
• Pruebas periódicas
• Revisión y mejora continua

En otras palabras, el backup es una pieza del rompecabezas, no el plan completo.

Cómo influye la nube en el cumplimiento de RTO y RPO

Las plataformas de cloud computing como AWS, Azure o Google Cloud pueden facilitar estrategias de recuperación más robustas, pero no resuelven todo por sí solas.

La nube permite, por ejemplo:

• replicar datos entre zonas o regiones,
• automatizar despliegues,
• restaurar infraestructura como código,
• escalar recursos bajo demanda,
• y reducir tiempos de recuperación frente a entornos manuales.

Sin embargo, si no defines primero tus objetivos, puedes terminar pagando por capacidades que no necesitas o, al revés, quedarte corto frente al riesgo real.

La pregunta correcta no es “¿estamos en la nube?”, sino “nuestra arquitectura actual permite cumplir el RTO y RPO que el negocio necesita?”

Errores frecuentes al construir un DRP

1. Definir RTO y RPO sin participación del negocio

TI puede proponer, pero el impacto lo conoce el negocio. Sin esa conversación, los números suelen quedar mal calibrados.

2. Asumir que el proveedor se encarga de todo

En cloud existe responsabilidad compartida. El proveedor asegura parte de la infraestructura, pero la estrategia de respaldo, replicación y recuperación de tus aplicaciones sigue siendo tu responsabilidad.

3. No probar el plan

Un DRP no probado es una hipótesis. Las pruebas revelan tiempos reales, dependencias ocultas y pasos faltantes.

4. No considerar aplicaciones dependientes

A veces se recupera el servidor principal, pero no el DNS, la VPN, la autenticación, la base de datos o las integraciones externas. El servicio sigue caído aunque “el servidor ya volvió”.

5. Querer pérdida cero sin justificar el costo

Un RPO de cero puede requerir replicación continua, alta disponibilidad y arquitecturas complejas. Puede ser necesario en algunos casos, pero no en todos.

Un método práctico para empezar esta semana

Si tu empresa aún no tiene un DRP formal, puedes iniciar con un ejercicio simple de una tarde.

Paso 1: lista tus 10 sistemas más importantes

No pienses en detalle técnico todavía. Solo enumera los servicios que sostienen la operación.

Paso 2: asigna criticidad

Clasifícalos en:

• Crítico
• Importante
• Soporte

Paso 3: define un RTO preliminar

Usa estas opciones cerradas:

• 15 min
• 1 hora
• 4 horas
• 8 horas
• 24 horas
• 48 horas

Paso 4: define un RPO preliminar

Usa estas opciones:

• 0 min
• 15 min
• 1 hora
• 4 horas
• 12 horas
• 24 horas

Paso 5: compara con tu realidad actual

Pregúntate:

• ¿Cada cuánto respaldamos?
• ¿Cuánto tardamos en restaurar?
• ¿Quién ejecuta la recuperación?
• ¿Está documentado?
• ¿Se ha probado?

Paso 6: detecta brechas

Ejemplo:

• RTO deseado: 1 hora

• Tiempo real de recuperación: 6 horas

• Brecha: 5 horas

• RPO deseado: 15 minutos

• Backup actual: cada 24 horas

• Brecha: 23 horas y 45 minutos

Con eso ya tienes una base concreta para priorizar mejoras.

Un ejemplo completo y fácil de entender

Imaginemos una empresa de distribución que depende de tres sistemas:

1. Plataforma de pedidos
2. ERP de facturación
3. Portal interno de documentos

Plataforma de pedidos

• Genera 30 pedidos por hora
• Cada pedido promedia $40.000 CLP
• Si cae, ventas y atención se frenan de inmediato

Definición:

• RTO: 1 hora
• RPO: 15 minutos

Justificación:

• Más de una hora caída genera pérdida comercial relevante
• Perder más de 15 minutos de pedidos obliga a reprocesos complejos

ERP de facturación

• Se usa durante toda la jornada
• Si cae, se puede operar parcialmente por un corto tiempo con contingencia manual

Definición:

• RTO: 4 horas
• RPO: 1 hora

Justificación:

• La operación aguanta un margen acotado, pero no todo el día
• Perder una hora de registros es manejable con conciliación controlada

Portal interno de documentos

• Uso administrativo
• No afecta ventas directas

Definición:

• RTO: 24 horas
• RPO: 12 horas

Justificación:

• La indisponibilidad afecta productividad, pero no paraliza el negocio
• La información puede recuperarse o reconstruirse con menor impacto

Este ejemplo muestra algo importante: no todos los sistemas necesitan el mismo nivel de protección. Y eso está bien.

Cómo documentar estas decisiones

Una vez definidos los objetivos, conviene dejar registro en una matriz simple. Por ejemplo:

Esta tabla ayuda a alinear negocio, TI y dirección. También facilita justificar inversiones con datos concretos.

La importancia de probar y ajustar

Definir RTO y RPO no es el final del trabajo. Es el comienzo.

Un DRP útil debe probarse periódicamente porque cambian:

• las aplicaciones,
• la infraestructura,
• los volúmenes de datos,
• los proveedores,
• y las prioridades del negocio.

Una prueba puede revelar que el RTO teórico de 1 hora en realidad toma 3 horas y media. O que el RPO prometido de 15 minutos no se cumple por una integración que no estaba considerada. Es mejor descubrirlo en una simulación que en una crisis real.

Conclusión

Definir RTO y RPO no tiene por qué ser un ejercicio complejo ni reservado solo para especialistas. Cuando se traducen a preguntas simples —cuánto tiempo puedo estar caído y cuánta información puedo perder— se vuelven herramientas muy poderosas para tomar decisiones realistas.

Un buen DRP no busca la perfección absoluta, sino una recuperación alineada con el impacto del negocio. Eso implica priorizar, poner números concretos, medir brechas y elegir tecnologías acordes al riesgo.

Si una empresa no sabe cuánto tarda en recuperarse ni cuántos datos podría perder, en realidad no tiene una estrategia de recuperación: tiene suposiciones. En cambio, cuando define RTO y RPO con criterios claros, puede construir un plan de continuidad más sólido, justificar inversiones y responder mejor ante incidentes operativos o de ciberseguridad.

La mejor forma de empezar es simple: listar servicios críticos, asignar tiempos y pérdidas aceptables, comparar con la capacidad actual y cerrar brechas paso a paso. Ese ejercicio, aunque parezca básico, puede marcar la diferencia entre una interrupción controlada y una crisis mayor.

Si tu empresa necesita definir un DRP realista, medir brechas de recuperación o mejorar su estrategia de respaldo y continuidad, en HDTI te ayudamos a traducir el riesgo en decisiones concretas y viables. Evaluamos tus sistemas críticos, definimos RTO y RPO alineados al negocio e implementamos soluciones acordes a tu operación.

Solicita una asesoría