Cuando un servicio digital se interrumpe, no todos los procesos sufren las mismas consecuencias ni pueden esperar el mismo tiempo para recuperarse. Tampoco es igual perder unos minutos de información que perder un día de operaciones. Por eso, definir objetivos de recuperación requiere conectar las necesidades del negocio con las capacidades técnicas, en lugar de asignar una cifra uniforme a todas las aplicaciones.
Dos medidas ayudan a expresar esas necesidades: el RTO, que establece cuánto tiempo puede permanecer interrumpido un proceso antes de que el impacto resulte inaceptable, y el RPO, que define cuánta pérdida de datos, expresada como tiempo, se puede tolerar. Son objetivos acordados, no garantías automáticas. Para que sirvan, deben ser comprensibles, viables y comprobables.
RTO y RPO responden a preguntas distintas
El RTO, u objetivo de tiempo de recuperación, responde a: ¿cuánto tiempo podemos estar sin este proceso? Se mide desde la interrupción hasta que el proceso vuelve a un nivel operativo acordado. No basta con que un servidor arranque: el servicio debe poder realizar las funciones que justifican su recuperación.
El RPO, u objetivo de punto de recuperación, responde a: ¿hasta qué momento deben estar disponibles los datos recuperados? Si el RPO acordado es de una hora, el negocio acepta, como máximo, recuperar datos cuyo estado corresponda a una hora antes del incidente. No indica cuánto se tarda en restaurarlos; eso corresponde al RTO.
Ambas medidas se complementan, pero no se sustituyen. Un sistema puede recuperar rápidamente una copia que contiene datos demasiado antiguos, o conservar datos recientes y tardar demasiado en reanudar la operación. La decisión debe contemplar ambos escenarios y precisar qué significa «recuperado»: qué usuarios, transacciones o funciones tienen que estar disponibles.
Definir objetivos por proceso, no por aplicación
Una aplicación puede dar soporte a varios procesos con impactos diferentes. A la inversa, un proceso suele depender de varias aplicaciones, datos, proveedores y tareas operativas. Por eso, empezar por la lista de sistemas y asignarles una prioridad técnica puede ocultar lo que realmente necesita proteger el negocio.
Conviene comenzar identificando procesos concretos, como aceptar pedidos, registrar pagos o atender solicitudes. Para cada uno, el responsable de negocio debe describir las consecuencias de una interrupción y de la pérdida de datos. Después, tecnología puede trazar las aplicaciones y dependencias necesarias para sostenerlo. Si una misma plataforma sirve a procesos con objetivos distintos, hay que comprobar si es posible recuperarlos de forma diferenciada o si comparten una limitación que debe hacerse explícita.
Esta mirada también ayuda a detectar dependencias olvidadas: identidad y acceso, comunicaciones, integraciones, bases de datos, información de configuración, personal con conocimientos específicos y proveedores externos. Recuperar la aplicación principal no restablece el proceso si una dependencia crítica sigue caída.
Estimar el impacto a lo largo del tiempo
El impacto no siempre aparece de golpe. Una interrupción breve puede tener una consecuencia asumible y, pasado cierto umbral, provocar acumulación de trabajo, incumplimiento de compromisos o pérdida de capacidad para operar. El análisis debe describir cómo cambia el daño con el tiempo, no limitarse a etiquetar un sistema como «crítico».
Para hacerlo de forma práctica, el equipo puede preguntar:
- Qué se detiene: operaciones, canales o decisiones que dependen del proceso.
- A quién afecta: clientes, empleados, socios u otros equipos.
- Qué se acumula: pedidos pendientes, casos sin atender o información que ya no se registra.
- Cuándo deja de ser tolerable: el momento en que el impacto supera el umbral aceptado por el negocio.
- Qué datos podrían perderse: su importancia, frecuencia de actualización y posibilidad de reconstruirlos.
Las estimaciones deben incluir condiciones relevantes, como periodos de alta actividad o cierres operativos. Si no hay datos suficientes, es preferible documentar la incertidumbre y acordar una hipótesis revisable antes que presentar una cifra aparentemente exacta sin fundamento.
Acordar objetivos que puedan ejecutarse
El responsable de negocio propone qué pérdida y qué demora son tolerables; tecnología evalúa qué medios y procedimientos harían falta para cumplir esos límites. Operaciones aporta cómo se detecta el incidente, quién decide activar la recuperación y qué tareas deben ejecutarse. La decisión final exige conversación entre estas funciones: fijar un RTO ambicioso sin recursos ni capacidad comprobada no reduce el riesgo.
Un acuerdo útil define, como mínimo, el proceso, el RTO, el RPO, el alcance de la recuperación, las dependencias, los responsables y la evidencia que demostrará el cumplimiento. También especifica supuestos: por ejemplo, qué funciones se recuperan primero o qué procedimientos manuales pueden sostener temporalmente la actividad. Una alternativa manual puede reducir el impacto, pero debe tener responsables, instrucciones y límites claros; no debe suponerse disponible por defecto.
Al comparar la necesidad con la capacidad actual, pueden aparecer brechas. La respuesta no siempre es adquirir tecnología. Puede implicar simplificar dependencias, mejorar procedimientos, reforzar la captura de datos, priorizar una función esencial o aceptar formalmente un nivel de riesgo distinto. La elección depende del impacto y de las opciones operativas reales.
Comprobar dependencias, arquitectura y operación
El objetivo acordado debe contrastarse con el recorrido completo de recuperación. Para el RTO, se consideran la detección, la toma de decisiones, el acceso a personas y sistemas, la restauración, la verificación y la reanudación del proceso. Si alguna etapa queda fuera del plan, el tiempo previsto puede ser poco realista.
Para el RPO, hay que revisar cómo se generan y conservan los datos recuperables, con qué frecuencia se actualizan y qué información queda fuera de ese mecanismo. Una copia de seguridad es una pieza de la estrategia, no una demostración de que se puede recuperar dentro de los objetivos. Hay que comprobar que los datos son utilizables y que el procedimiento no depende de supuestos no validados.
También es importante identificar dependencias compartidas. Si varios procesos necesitan la misma identidad, red o proveedor, recuperarlos en paralelo puede competir por recursos o requerir un orden específico. Registrar esas relaciones permite establecer prioridades de restauración y entender qué objetivo puede alcanzarse bajo distintas condiciones.
Probar, revisar y corregir los objetivos
Las pruebas convierten los objetivos en evidencia. Un ejercicio puede recorrer el procedimiento de principio a fin, medir el tiempo hasta recuperar funciones acordadas y verificar el estado de los datos restaurados. No basta con comprobar que una copia existe o que una instancia inicia: el responsable del proceso debe confirmar que el resultado permite operar.
Los ejercicios pueden empezar con una revisión de procedimientos y avanzar hacia escenarios técnicos más completos, según el riesgo y la capacidad del equipo. En cada prueba conviene registrar:
- Qué proceso, escenario y dependencias se probaron.
- Cuándo comenzó la interrupción y cuándo se recuperaron las funciones acordadas.
- Qué punto de los datos se recuperó y qué pérdida se observó.
- Qué pasos fallaron, qué supuestos no se cumplieron y quién corregirá cada brecha.
Si el resultado supera el RTO o el RPO, hay que decidir si se mejora la capacidad, se modifica el proceso o se revisa el objetivo con el negocio. Repetir una prueba sin resolver sus hallazgos no aporta confianza. Los objetivos también deben revisarse cuando cambian el proceso, la arquitectura, el volumen de actividad o las dependencias.
Errores frecuentes y plantilla de decisión
Entre los errores más habituales están asignar el mismo objetivo a todo el inventario, confundir RTO con RPO, asumir que una copia de seguridad equivale a recuperación y fijar metas sin participación del negocio. También es arriesgado medir solo la disponibilidad técnica, ignorar las tareas de coordinación o considerar una prueba exitosa sin validar los datos y las funciones del proceso.
Una ficha sencilla ayuda a mantener las decisiones trazables. Puede incluir los siguientes campos:
- Proceso y responsable de negocio: qué actividad se protege y quién acepta el impacto.
- Impacto por duración y pérdida de datos: consecuencias y umbrales tolerables.
- RTO y RPO acordados: objetivos y alcance de la recuperación.
- Aplicaciones y dependencias: componentes, equipos y proveedores necesarios.
- Procedimiento y alternativa manual: pasos, prioridades, responsables y límites.
- Última prueba y evidencia: resultado observado, brechas y acciones pendientes.
Definir RTO y RPO por proceso no consiste en elegir números ideales, sino en acordar límites que reflejen el impacto, comprobar si la organización puede cumplirlos y actuar sobre las brechas. La revisión periódica mantiene esos objetivos alineados con el servicio real y evita confundir una expectativa documentada con una capacidad demostrada.