Cuando una empresa pierde acceso a sus sistemas, existen dos preguntas que la gerencia debe poder responder con claridad: ¿cuánto tiempo puede permanecer detenida la operación y cuánta información puede perderse sin provocar consecuencias inaceptables?
Estas preguntas se expresan mediante dos objetivos fundamentales para la continuidad operativa: RTO y RPO.
El RTO establece cuánto tiempo puede permanecer interrumpido un sistema antes de que el impacto sea inaceptable. El RPO determina cuántos minutos u horas de información puede perder la empresa al recuperar sus datos.
Aunque ambos conceptos suelen tratarse como términos técnicos, las decisiones que representan pertenecen a la gerencia. El equipo de tecnología puede configurar respaldos, servidores y mecanismos de recuperación, pero no debería decidir por sí solo cuánto tiempo puede detenerse facturación, cuántas transacciones pueden reconstruirse o qué consecuencias tendría perder los cambios realizados durante una jornada.
Comprender el RPO y el RTO permite establecer expectativas realistas, identificar los procesos más críticos y seleccionar soluciones proporcionales al riesgo. También ayuda a evitar una de las equivocaciones más frecuentes en las pequeñas y medianas empresas: asumir que tener un respaldo significa que la operación puede recuperarse rápidamente y sin pérdida de información.
¿Qué es el RTO?
RTO significa Recovery Time Objective u objetivo de tiempo de recuperación.
Representa el tiempo máximo aceptable que puede transcurrir desde la interrupción de un sistema hasta que su servicio debe estar nuevamente disponible.
Si el sistema de facturación de una empresa tiene un RTO de cuatro horas, la organización está indicando que una interrupción superior a ese periodo produciría un impacto que ya no considera aceptable.
El RTO no indica necesariamente cuánto tardará actualmente la recuperación. Indica cuánto debería tardar como máximo de acuerdo con las necesidades de la empresa. Posteriormente, la infraestructura, el personal y los procedimientos deben diseñarse y comprobarse para cumplir ese objetivo.
Algunas preguntas que ayudan a definirlo son:
- ¿Cuánto tiempo puede trabajar el personal sin este sistema?
- ¿Qué procesos se detendrían?
- ¿Cuántos clientes resultarían afectados?
- ¿Existe una alternativa manual temporal?
- ¿En qué momento comenzarían a acumularse pérdidas importantes?
- ¿Existen obligaciones contractuales o regulatorias?
- ¿Cuánto tardaría la empresa en ponerse al día después de recuperar el servicio?
Microsoft define el RTO como la duración máxima aceptable de una interrupción, mientras que AWS lo describe como la demora máxima aceptable entre la interrupción y la restauración de un servicio. Ambas definiciones enfatizan que el objetivo debe responder a la tolerancia operativa de la organización.
¿Qué es el RPO?
RPO significa Recovery Point Objective u objetivo de punto de recuperación.
Representa la cantidad máxima de información, medida en tiempo, que la empresa puede aceptar perder después de una interrupción.
Supongamos que el sistema contable se respalda cada cuatro horas. Si ocurre una falla a las 3:55 p. m. y el último respaldo utilizable se realizó al mediodía, podrían perderse casi cuatro horas de registros. En ese escenario, el RPO sería de hasta cuatro horas.
Por lo tanto, el RPO ayuda a definir con qué frecuencia deben protegerse o replicarse los datos.
Un RPO de:
- 24 horas podría implicar respaldos diarios.
- 4 horas requeriría varios puntos de recuperación durante el día.
- 1 hora demandaría una protección más frecuente.
- Pocos minutos podría requerir replicación continua o casi continua.
- Cercano a cero necesitaría una arquitectura de alta disponibilidad considerablemente más compleja.
AWS explica el RPO como la cantidad de pérdida de datos que una aplicación puede tolerar o, visto de otra manera, qué tan antiguos pueden ser los datos cuando se recupera el sistema.
La definición no debe reducirse a la pregunta “¿Tenemos backup?”. La pregunta correcta es: “Si debemos utilizar ese backup, ¿hasta qué momento podremos recuperar la información y qué tendremos que reconstruir manualmente?”.
La diferencia entre RPO y RTO
Aunque ambos se expresan mediante unidades de tiempo, miden consecuencias diferentes.
| Objetivo | Pregunta que responde | Qué controla |
|---|---|---|
| RPO | ¿Cuánta información podemos perder? | Pérdida de datos |
| RTO | ¿Cuánto tiempo podemos estar detenidos? | Duración de la interrupción |
Imagine que una falla ocurre a las 3:00 p. m. y el último respaldo disponible corresponde a la 1:00 p. m. La empresa consigue restaurar el sistema a las 7:00 p. m.
En este caso:
- La pérdida potencial de dos horas de información está relacionada con el RPO.
- Las cuatro horas necesarias para recuperar el servicio están relacionadas con el RTO.
Es posible cumplir uno de los objetivos e incumplir el otro. Una empresa podría recuperar datos muy recientes, pero tardar demasiado en ponerlos nuevamente en funcionamiento. También podría restaurar rápidamente un sistema utilizando información desactualizada.
Por eso, los dos objetivos deben evaluarse juntos.
El RPO y el RTO son decisiones de negocio
El departamento de tecnología puede explicar qué soluciones existen, cuánto cuestan y qué capacidades ofrecen. Sin embargo, la gerencia debe determinar qué nivel de interrupción y pérdida es aceptable.
Finanzas debe explicar qué sucedería si faltaran transacciones. Operaciones debe identificar cuánto tiempo puede trabajar manualmente. Ventas debe indicar cómo se afectaría la atención a clientes. Recursos Humanos debe evaluar la sensibilidad de los expedientes y la nómina.
La definición de los objetivos debería comenzar con el impacto empresarial y no con las características de una herramienta.
NIST incorpora el RPO y el RTO dentro del análisis de impacto al negocio y la planificación de contingencias. El RTO se establece a partir del tiempo durante el cual un recurso puede permanecer indisponible antes de generar un impacto inaceptable.
Esta evaluación permite responder:
- Qué procesos son indispensables.
- Qué aplicaciones los sostienen.
- Qué personas y proveedores participan.
- Qué información utilizan.
- Qué dependencias deben recuperarse primero.
- Cuánto cuesta cada hora de interrupción.
- Qué efectos aparecerían después de varias horas o días.
Sin esta conversación, es frecuente que la empresa compre una solución técnicamente correcta que no corresponda con su verdadera necesidad.
No todos los sistemas necesitan los mismos objetivos
Asignar un único RPO y RTO para toda la empresa puede generar gastos innecesarios o dejar procesos críticos insuficientemente protegidos.
Un sistema de facturación puede requerir un RPO de una hora y un RTO de cuatro horas. Un archivo histórico que se consulta ocasionalmente podría tolerar un RPO de 24 horas y una recuperación durante el siguiente día hábil.
Un ejemplo inicial podría ser:
| Sistema o proceso | RPO de referencia | RTO de referencia | Justificación |
|---|---|---|---|
| Facturación y ventas | 1 hora | 2 horas | La interrupción afecta ingresos y atención |
| Correo empresarial | 4 horas | 4 horas | La comunicación puede continuar temporalmente por otros medios |
| Archivos operativos | 4 horas | 8 horas | Algunos equipos pueden utilizar copias locales o procesos temporales |
| Nómina | 24 horas | 8 horas | La criticidad aumenta cerca de la fecha de pago |
| Archivo histórico | 24 horas | 48 horas | No sostiene la operación inmediata |
Estos valores son solamente ilustrativos. Cada empresa debe establecer los suyos según su operación, contratos, capacidad manual y consecuencias financieras.
La criticidad también puede variar según el momento. El sistema de nómina quizá tolere una interrupción amplia durante buena parte del mes, pero se vuelve prioritario en los días de procesamiento y pago.
Objetivos más exigentes implican mayor inversión
Un RPO o RTO cercano a cero puede parecer la opción ideal, pero requiere más infraestructura, automatización, replicación, monitoreo, personal especializado y pruebas.
Reducir el RPO puede exigir respaldos más frecuentes o replicación continua. Reducir el RTO puede necesitar sistemas alternos preparados para activarse, capacidad duplicada o procedimientos automáticos de recuperación.
AWS organiza las estrategias de recuperación desde respaldar y restaurar hasta configuraciones activas en diferentes ubicaciones. A medida que se reducen el RPO y el RTO, aumenta normalmente la complejidad y el costo de la solución.
La pregunta gerencial no debería ser “¿Cuál es el RPO más bajo que podemos conseguir?”, sino “¿Qué nivel de protección justifica el impacto económico y operativo de este proceso?”.
Si una hora de interrupción cuesta Q500, quizá no resulte razonable pagar una infraestructura costosa para recuperar el servicio en segundos. Si una hora detenida impide procesar operaciones por decenas de miles de quetzales, una recuperación lenta puede resultar mucho más cara que la prevención.
Tener respaldos no garantiza cumplir el RTO
Un respaldo es una copia de información. No representa automáticamente una operación lista para continuar.
Para restablecer un sistema puede ser necesario:
- Localizar una copia válida.
- Obtener acceso al almacenamiento.
- Preparar un servidor o equipo.
- Instalar aplicaciones.
- Restaurar bases de datos.
- Recuperar configuraciones y permisos.
- Verificar la integridad de la información.
- Conectar usuarios y dispositivos.
- Probar los procesos.
- Confirmar que el sistema puede volver a producción.
Si la empresa nunca ha medido este procedimiento, no conoce realmente su tiempo de recuperación.
También debe considerarse si las copias están protegidas frente al mismo incidente que afectó al entorno principal. Un ransomware, una eliminación accidental o una cuenta administrativa comprometida podría alcanzar tanto la información original como respaldos mal protegidos.
La estrategia debe incluir copias aisladas o protegidas, controles de acceso, historial de versiones, monitoreo y pruebas periódicas de restauración.
El proveedor de nube no sustituye la planificación interna
Utilizar Microsoft 365, Google Workspace, un sistema contable en línea o cualquier servicio en la nube reduce ciertas responsabilidades de infraestructura, pero no elimina la necesidad de continuidad.
La empresa todavía debe conocer:
- Qué disponibilidad ofrece el proveedor.
- Qué datos protege y durante cuánto tiempo.
- Qué opciones de restauración están incluidas.
- Qué errores del usuario pueden revertirse.
- Qué ocurre si una cuenta administrativa queda comprometida.
- Cómo se exportaría o recuperaría la información.
- Qué aplicaciones e integraciones dependen del servicio.
- Qué procedimientos alternativos existen durante una interrupción.
Un acuerdo de nivel de servicio tampoco equivale necesariamente al RTO de la empresa. La disponibilidad contractual del proveedor puede establecer compensaciones por una interrupción, pero no garantiza que todos los procesos internos vuelvan a funcionar dentro del tiempo requerido.
Cómo establecer el RPO y el RTO
Una PYME puede comenzar con un proceso estructurado y comprensible.
1. Identificar los procesos críticos
Se deben enumerar los procesos que permiten operar: ventas, facturación, cobros, atención al cliente, inventario, comunicaciones, producción, nómina y administración.
2. Relacionar cada proceso con sus sistemas
La empresa debe identificar qué aplicaciones, datos, equipos, conexiones, proveedores y personas sostienen cada proceso.
3. Evaluar el impacto de una interrupción
Conviene analizar qué ocurriría después de 15 minutos, una hora, cuatro horas, un día y varios días. El impacto puede ser financiero, operativo, contractual, reputacional o regulatorio.
4. Determinar cuánta información puede reconstruirse
Si un equipo puede volver a ingresar manualmente una hora de transacciones, el RPO podría admitir esa pérdida. Si reconstruir los datos es imposible o peligroso, se necesitará un objetivo más exigente.
5. Establecer el orden de recuperación
No todo puede recuperarse simultáneamente. La organización debe decidir qué sistema vuelve primero y qué dependencias necesita.
6. Comparar los objetivos con la capacidad actual
Después de definir lo necesario, el equipo técnico debe medir si las soluciones existentes pueden cumplirlo. La diferencia entre el objetivo y la capacidad real representa un riesgo que debe atenderse.
7. Diseñar y probar la estrategia
El plan debe asignar responsables, procedimientos, contactos, accesos, infraestructura y criterios para declarar que la recuperación fue exitosa.
La recuperación debe probarse
Un plan no comprobado contiene supuestos. Una restauración exitosa realizada hace dos años no demuestra que las copias actuales funcionen, que las contraseñas estén disponibles ni que el personal conozca el procedimiento.
Las pruebas pueden comenzar con ejercicios controlados:
- Restaurar un archivo eliminado.
- Recuperar una carpeta completa.
- Restaurar una base de datos en un entorno separado.
- Verificar el acceso de los usuarios.
- Medir el tiempo real de cada actividad.
- Simular la indisponibilidad de un proveedor.
- Ejecutar un ejercicio de mesa con gerencia y responsables.
- Documentar los problemas y repetir la prueba.
AWS enfatiza que una estrategia de recuperación debe evaluarse y probarse regularmente para confirmar que puede alcanzar sus objetivos.
La prueba debe medir dos resultados: hasta qué punto se recuperaron los datos y cuánto tiempo tomó devolver el servicio. Es decir, debe comprobar tanto el RPO como el RTO.
Errores frecuentes al definir RPO y RTO
Las empresas suelen debilitar su planificación cuando:
- Confunden respaldo con recuperación.
- Utilizan una sola cifra para todos los sistemas.
- Permiten que el proveedor técnico defina por sí solo la tolerancia del negocio.
- Establecen objetivos cercanos a cero sin considerar el costo.
- Ignoran aplicaciones, licencias, configuraciones y dependencias.
- Guardan los respaldos junto al sistema principal.
- No asignan responsables.
- No protegen las credenciales necesarias para recuperar el entorno.
- No incluyen proveedores externos.
- No realizan pruebas.
- No actualizan el plan cuando cambia la operación.
Otro error consiste en medir solamente cuándo vuelve a encenderse un sistema. La recuperación no está completa hasta que las personas pueden utilizarlo, los datos son confiables y el proceso empresarial funciona nuevamente.
Preguntas que la gerencia debería hacer
La dirección no necesita conocer cada detalle técnico, pero sí debe exigir respuestas claras:
- ¿Cuáles son nuestros procesos más críticos?
- ¿Qué sistemas los sostienen?
- ¿Cuál es el RPO y el RTO de cada uno?
- ¿Nuestra capacidad actual cumple esos objetivos?
- ¿Cuándo se realizó la última restauración de prueba?
- ¿Cuánto tiempo tomó?
- ¿Qué información podría perderse?
- ¿Dónde están almacenados los respaldos?
- ¿Quién puede acceder a ellos?
- ¿Qué sucede si el proveedor principal no está disponible?
- ¿Quién dirige la recuperación?
- ¿Cómo se comunicará la empresa durante la interrupción?
- ¿Qué riesgos siguen sin resolverse?
Si las respuestas dependen de una sola persona, no están documentadas o nunca se han probado, existe un riesgo de continuidad aunque la empresa tenga respaldos.
RPO y RTO convierten la continuidad en una decisión medible
Comprender el RPO y el RTO permite que gerencia y tecnología hablen de continuidad mediante resultados concretos.
El RPO establece cuánta información puede perderse. El RTO determina cuánto tiempo puede permanecer interrumpido un servicio. Juntos ayudan a priorizar sistemas, definir la frecuencia de protección, seleccionar estrategias de recuperación y justificar inversiones.
Estos objetivos no deben copiarse de otra empresa ni establecerse únicamente a partir de lo que ofrece una herramienta. Deben surgir del impacto que una interrupción tendría sobre los clientes, los ingresos, las obligaciones y la capacidad de continuar operando.
Una empresa no necesita comenzar con una infraestructura compleja. Puede iniciar identificando sus procesos críticos, documentando dependencias, estableciendo objetivos realistas y comprobando si sus respaldos pueden restaurarse dentro del tiempo esperado.
Axentio puede ayudar a su empresa a evaluar los sistemas y procesos críticos, definir objetivos de recuperación, revisar la estrategia de respaldos y establecer un plan de continuidad proporcional a su operación. El objetivo no es adquirir tecnología innecesaria, sino saber qué debe recuperarse, hasta qué punto y en cuánto tiempo para evitar que una interrupción se convierta en una crisis empresarial.
