La perspectiva de Cyber Academy
RTO es la duración máxima aceptable durante la cual un proceso de negocio puede permanecer inactivo antes de causar daños inaceptables. RPO es la pérdida máxima de datos medida en tiempo anterior a la interrupción. Ambos se derivan del BIA. Los valores que el CIO escribe en el BCP sin consultar al negocio son los valores que fallan bajo presión.
Dos relojes que miden cosas diferentes
El RTO y el RPO son los dos objetivos de recuperación que convierten una promesa vaga de resiliencia en cifras comprobables. Es fácil confundirlos porque ambos se expresan en unidades de tiempo, pero miden cosas diferentes y apuntan a soluciones diferentes. El recovery time objective trata de cuánto tiempo puedes estar caído. El recovery point objective trata de cuántos datos puedes permitirte perder. Si los confundes, comprarás la arquitectura de recuperación equivocada.
Imagina la interrupción como un único instante en una línea de tiempo. El RTO mira hacia adelante desde ese instante: es la ventana máxima entre el corte y el momento en que el proceso vuelve a ser utilizable, antes de que el daño resulte inaceptable. El RPO mira hacia atrás desde ese instante: es la antigüedad máxima de la última copia válida de datos a la que puedes recuperar, lo que equivale a los datos más recientes que estás dispuesto a perder. Un RTO de cuatro horas con un RPO de quince minutos significa que el servicio debe restablecerse en menos de cuatro horas y no puede perder más de quince minutos de transacciones.
| RTO | RPO | |
|---|---|---|
| Mide | Tiempo de inactividad aceptable | Pérdida de datos aceptable |
| Dirección en la línea de tiempo | Hacia adelante desde la interrupción | Hacia atrás desde la interrupción |
| Pregunta que responde | ¿Con qué rapidez debemos restablecernos? | ¿Cuántos datos podemos perder? |
| Determinado principalmente por | Proceso de recuperación, conmutación por error, personal | Frecuencia de copia de seguridad y replicación |
| Fuente | Análisis de impacto en el negocio | Análisis de impacto en el negocio |
De dónde salen las cifras y por qué importa la responsabilidad
Ambos objetivos son resultados del análisis de impacto en el negocio, no conjeturas hechas en la sala de servidores. El BIA estudia cada actividad crítica, mide cómo crece con el tiempo el daño de un corte y produce objetivos de recuperación que el responsable del proceso valida. Esa responsabilidad es precisamente el punto clave. Un RTO y un RPO que un equipo técnico fija de forma aislada describen lo que la infraestructura puede hacer, no lo que el negocio necesita, y la brecha entre ambos solo aflora durante un incidente real, que es el peor momento para descubrirla.
Los objetivos también deben conciliarse con el coste. Llevar un RPO hacia cero implica replicación continua o síncrona. Llevar un RTO hacia los minutos implica capacidad de respaldo en caliente que permanece inactiva. Ambos son costosos, así que el BIA fuerza una conversación honesta sobre qué procesos justifican realmente ese gasto y cuáles pueden tolerar una ventana más larga. Escalonar las actividades por niveles es normal: el motor de pagos y el sitio de marketing rara vez merecen los mismos objetivos.
Cómo encajan el RTO y el RPO en las normas
Estos objetivos son vocabulario fundamental en los marcos de continuidad y resiliencia. ISO 22301, la norma internacional para los sistemas de gestión de la continuidad del negocio, trata los recovery time y recovery point objectives como resultados del análisis de impacto que impulsan la estrategia y las soluciones de continuidad. Fluyen directamente al diseño de la recuperación ante desastres, los calendarios de copias de seguridad y la elección de los sitios de recuperación.
En los sectores regulados se examinan cada vez más en lugar de darse por supuestos: el Reglamento de Resiliencia Operativa Digital de la UE (DORA) fija expectativas de continuidad y prueba para las entidades financieras, y la Directiva NIS 2 exige medidas de continuidad del negocio y de copia de seguridad a las entidades esenciales e importantes.
Los profesionales hacen tres cosas con estas cifras. Las derivan del BIA junto con los responsables de negocio. Diseñan la copia de seguridad, la replicación y la conmutación por error para que la arquitectura pueda cumplirlas realmente. Luego lo demuestran mediante pruebas, porque un RTO no probado es una aspiración. El objetivo solo gana confianza una vez que un ejercicio de recuperación ha demostrado que el equipo puede alcanzarlo en condiciones realistas.
Frequently asked questions
01¿Cuál es la diferencia entre el RTO y el RPO?
El RTO es el tiempo máximo que un proceso puede estar caído antes de que el daño sea inaceptable, medido hacia adelante desde la interrupción. El RPO es la pérdida máxima de datos que puedes tolerar, medida hacia atrás desde la interrupción como la antigüedad de la última copia recuperable. Uno determina la velocidad de recuperación, el otro la frecuencia de copia de seguridad.
02¿De dónde provienen los valores de RTO y RPO?
Son resultados del análisis de impacto en el negocio. El BIA clasifica cada actividad según cómo crece con el tiempo el daño de una interrupción y produce objetivos que el responsable del proceso valida, en lugar de cifras fijadas por TI de forma aislada.
03¿Un RPO bajo requiere copias de seguridad continuas?
Por lo general, sí. El RPO no puede ser más corto que el intervalo entre copias recuperables, de modo que un RPO cercano a cero necesita una replicación frecuente o continua. Reducir el RPO aumenta por tanto el coste, razón por la cual el BIA reserva los objetivos más estrictos para las actividades que los justifican.
04¿Qué ocurre si nuestra recuperación tarda más que el RTO?
Tienes una brecha de resiliencia. El RTO es el objetivo tolerable; el tiempo que la recuperación tarda realmente es el recovery time achieved, medido en una prueba. Si el tiempo logrado supera el objetivo, cierras la brecha mejorando el proceso de recuperación o aceptas un riesgo documentado, pero no aflojas la meta en silencio.
05¿El RTO y el RPO solo se refieren a los sistemas informáticos?
Se aplican con mayor frecuencia a los datos y los servicios de TI, pero pertenecen a los procesos de negocio. Un proceso puede tener sus sistemas restablecidos dentro del RTO y aun así ser incapaz de operar si faltan las personas, las instalaciones o un proveedor crítico, razón por la cual los objetivos se validan frente a la actividad en su conjunto, y no solo frente a la aplicación.