RTO, RPO y lo que la copia cumple

MTPD: cuánto tiempo puede estar parado un proceso antes de que el daño sea inaceptable (lo fija el negocio). RTO (objetivo de tiempo de recuperación): en cuánto tiempo se promete tener de vuelta un sistema o un proceso; debe ser menor que el MTPD, con margen, porque el reloj del negocio empieza en la caída y no cuando alguien declara la recuperación. RPO (objetivo de punto de recuperación): cuánto dato se tolera perder, medido hacia atrás desde la caída; lo cumple la frecuencia de la copia o de la replicación, no la rapidez de la restauración.

Quien mezcla RTO y RPO no entiende el dato que mira: uno habla de tiempo hasta volver y el otro de datos perdidos.

En el registro de sistemas de Mirador, cada sistema declara su RTO y los procesos que sostiene. Cruza cada fila con el MTPD del proceso en el BIA, y si un sistema sostiene varios, cuenta el más exigente. Un RTO mayor que el MTPD es una promesa que, aunque se cumpla, llega tarde: el daño inaceptable ya ocurrió. No hace falta que alguien lo haya roto; basta que el papel de TI no cuadre con el papel del negocio.

El RPO prometido solo es cierto si la copia ocurre al menos con esa frecuencia. En la última columna del registro está lo que se mide hoy: una replicación con su retraso, una copia cada cierto tiempo, o una copia a cargo de un proveedor con su contrato. Compara cada frecuencia con el RPO de su fila. Una copia a cargo de un tercero se acepta solo si el contrato lo fija, y eso está escrito en la misma celda.

Ya tienes el hueco entre el MTPD del negocio y el RTO de TI. GRC no lo cierra: lo documenta como hallazgo con evidencia y pide una decisión, porque cerrarlo cuesta (más recursos, otra arquitectura) y quien paga es el dueño del proceso. Las salidas legítimas son dos: reforzar la recuperación hasta que el RTO quepa dentro del MTPD, o que el negocio reconozca por escrito que acepta el riesgo y revise su MTPD. Lo que no es legítimo es subir el MTPD en el papel para que cuadre sin que el negocio lo haya decidido.