Un SLA de disponibilidad del 99,9% suena tranquilizador hasta que haces los cálculos: esa cifra permite casi nueve horas de tiempo de inactividad no planificado a lo largo de un año completo. Lo que no te dice es cuánto dura cada interrupción individual, en qué plazo está tu proveedor contractualmente obligado a restaurar tus sistemas, ni si “restaurado” significa que tus datos están intactos. Para organizaciones del sector financiero, sanitario y energético, esas omisiones no son letra pequeña. Son la diferencia entre un incidente recuperable y una infracción regulatoria.
La distinción entre garantías de disponibilidad y capacidad de recuperación real ha pasado de ser un detalle de contratación a un tema de agenda para los consejos de administración, impulsada por obligaciones que tratan el tiempo de recuperación como una métrica concreta y no como una aspiración del proveedor. Entender qué cubre realmente tu SLA, y qué deja fuera deliberadamente, es el punto de partida.
Qué miden realmente los SLA de disponibilidad
La disponibilidad es un agregado: el porcentaje del total de horas de un período durante el cual un servicio estuvo nominalmente operativo. Una garantía del 99,9% permite aproximadamente 8,7 horas de inactividad al año; el 99,99% reduce eso a unos 52 minutos. Ambas cifras se calculan sobre la ventana de medición completa, lo que significa que una interrupción de seis horas puede absorberse dentro de un SLA del 99,9% sin activar ninguna penalización.
El problema estructural es que la disponibilidad no dice nada sobre ningún evento individual. No especifica con qué rapidez debe comenzar a responder el proveedor, cuánto puede durar la restauración ni en qué estado se encuentran tus datos cuando el servicio vuelve. Un proveedor puede cumplir su compromiso de disponibilidad mientras te deja sin servicio durante horas, siempre que el agregado anual se mantenga por encima del umbral.
Las cláusulas de exclusión del SLA agravan esto. La mayoría de los contratos de servicios gestionados excluyen las ventanas de mantenimiento programado, los incidentes atribuidos a la configuración del propio cliente, los fallos de redes de terceros y los eventos de fuerza mayor. Cada exclusión reduce el denominador de horas del que el proveedor es realmente responsable, a menudo sin que el cliente se dé cuenta de cuánta cobertura ha desaparecido.
RTO frente a SLA de disponibilidad: una pregunta completamente distinta
Un Recovery Time Objective define la duración máxima aceptable entre una interrupción y la restauración completa de una función determinada. Es un compromiso sobre un incidente concreto, no sobre una media anual. Un SLA de disponibilidad y un RTO pueden coexistir en un contrato, pero responden a preguntas completamente diferentes, y un proveedor que solo ofrece el primero no está respondiendo a la que más importa cuando algo falla.
La disponibilidad te dice con qué frecuencia está operativo un sistema. El RTO te dice con qué rapidez vuelve. Confundir ambos conceptos es la forma en que las organizaciones descubren, en pleno incidente, que su SLA cubría la métrica equivocada.
La misma lógica se aplica a los Recovery Point Objectives. Un RPO define cuánta pérdida de datos es tolerable: la antigüedad máxima de la copia de seguridad que puede usarse para restaurar un sistema. Sin un RPO explícito en el contrato, un proveedor puede restaurar desde una copia de seguridad de 24 horas de antigüedad y seguir cumpliendo plenamente con todos los términos del SLA, aunque tus datos transaccionales desaparezcan.
Por qué los reguladores han dejado de tratar esto como algo opcional
DORA, el Reglamento (UE) 2022/2554, hace que la conversación sobre RTO y RPO sea legalmente obligatoria para las entidades financieras. El artículo 12(6) exige que los objetivos de tiempo de recuperación y de punto de recuperación se establezcan y documenten para cada función, distinguiendo entre cargas de trabajo críticas y no críticas. Las RTS sobre Gestión del Riesgo TIC (2024/1774) amplían esto para exigir estrategias de recuperación ante múltiples escenarios de fallo, incluidos ciberataques y fallos técnicos, y obligan a realizar pruebas anuales de los planes de continuidad en escenarios realistas. DORA es aplicable a todas las entidades financieras cubiertas desde el 17 de enero de 2025.
De forma crítica, los artículos 28 a 30 de DORA establecen que la externalización a un proveedor de servicios gestionados no transfiere la responsabilidad regulatoria. Las entidades financieras siguen siendo plenamente responsables del cumplimiento aunque la infraestructura esté en manos de un tercero. Esto significa que el RTO que tu proveedor promete de manera informal, pero sin compromiso contractual, no te ofrece ninguna protección regulatoria. Tus contratos con terceros proveedores de TIC deben incluir SLA explícitos que cubran estándares de rendimiento, gestión de incidentes y disposiciones de continuidad de negocio.
NIS2, la Directiva (UE) 2022/2555, aplica la misma lógica de forma más amplia. El artículo 21(2)(c) exige medidas de continuidad de negocio que incluyan la gestión de copias de seguridad y la recuperación ante desastres, y la directiva sitúa la responsabilidad explícitamente a nivel de consejo de administración. La alta dirección es directamente responsable de la creación, implementación y supervisión de los planes de continuidad y recuperación. Las sanciones para las entidades esenciales pueden alcanzar los 10 millones de euros o el 2% de la facturación global. NIS2 no prescribe umbrales numéricos de RTO universales como hace DORA para el sector financiero, pero la obligación de definir, documentar y probar las capacidades de recuperación es igualmente vinculante, y los planes deben revisarse al menos cada dos años o tras incidentes significativos.
El Recovery Time Objective en la nube en la práctica
Al evaluar un servicio gestionado para cargas de trabajo con peso regulatorio, las preguntas que hay que hacer son más específicas que “¿cuál es tu SLA de disponibilidad?”. Entre ellas: ¿cuál es el RTO contractualmente comprometido para este nivel de servicio, por función? ¿Cuál es el RPO y qué frecuencia de copia de seguridad implica? ¿Cómo se definen las cláusulas de exclusión y un ciberataque se considera fuerza mayor? ¿Cómo es el proceso de respuesta a incidentes del proveedor y en qué momento comienza la escalada hacia tu equipo?
Para cargas de trabajo en bare metal, el plazo de sustitución del hardware forma parte del cálculo del RTO. Si un nodo falla y aprovisionar un repuesto lleva cuatro horas, esas cuatro horas pertenecen a tu planificación de recuperación independientemente de que el SLA del proveedor las reconozca. Para los servicios de bases de datos gestionadas, el RPO depende completamente de la frecuencia con que se toman los snapshots y de dónde se almacenan. Una instancia de MongoDB gestionada con snapshots diarios almacenados en una única región tiene un perfil de riesgo muy diferente al de una con replicación continua hacia un sitio geográficamente separado.
Operamos MongoDB gestionado y Redis gestionado en nuestra infraestructura con cadencias de copia de seguridad explícitas y procedimientos de recuperación documentados, porque nuestros clientes del sector financiero y energético no pueden tratar esos detalles como suposiciones. El SLA que firman cubre la disponibilidad; la conversación sobre recuperación ocurre antes de que se firme el contrato, no después de un incidente.
Qué debe contener realmente un contrato
Un contrato de servicios gestionados que tome en serio el Recovery Time Objective en la nube debe incluir: un RTO definido por nivel de servicio o categoría de función, no una cifra única aplicada a todo el entorno; un RPO definido con la frecuencia de copia de seguridad y la política de retención que lo sustenta; plazos explícitos de respuesta a incidentes, incluido el momento en que el proveedor notifica al cliente y la ruta de escalada a partir de ese punto; claridad sobre qué escenarios de fallo quedan excluidos de los cálculos del SLA y si los ciberataques reciben un tratamiento diferente al de los fallos de hardware; y derechos de auditoría que te permitan verificar que los procedimientos de recuperación han sido realmente probados.
El requisito de notificación de incidentes en 24 horas bajo NIS2 significa que mientras tu equipo técnico trabaja en la restauración, alguien más debe estar presentando las notificaciones regulatorias. Ese traspaso de responsabilidad debe estar definido en el contrato, no improvisarse durante el incidente. Las disposiciones de respuesta a incidentes en servicios gestionados que se limitan a “restauraremos el servicio” dejan toda la carga de la notificación regulatoria en tus manos, a menudo en el peor momento posible.
La conversación del consejo de administración que compras sigue aplazando
Tanto bajo DORA como bajo NIS2, la responsabilidad de la planificación de recuperación recae en la alta dirección, no en el equipo de compras que firmó el contrato original de servicios gestionados. Esto significa que la brecha entre un SLA de disponibilidad y un compromiso de recuperación real es, en última instancia, un riesgo a nivel de consejo de administración, aunque haya sido creada por una línea en un acuerdo con un proveedor.
La implicación práctica es clara: revisa cada contrato de servicios gestionados frente al RTO y el RPO que tu organización ha documentado realmente para cada función. Cuando el contrato guarda silencio sobre la recuperación, ese silencio es una posición de riesgo que tus reguladores no aceptarán en tu nombre. La disponibilidad es una línea de base. La recuperación es la obligación.
