He revisado más de un plan de continuidad que en realidad es un dosier de contratos. Firma, SLA, cláusula de penalización — todo en orden y todo perfecto. Lo único que no está perfecto es que nadie ha probado qué pasa cuando el problema es del proveedor cloud, el proveedor de identidad o el que te proporcioar el runbook y no tuyo.
El ejercicio de recuperación existe, pero termina en el momento exacto en que el servidor arranca — como si arrancar fuera lo mismo que recuperar el servicio. Cuando esa falla se descubre, no es en un simulacro. Es en el incidente real, con el cliente esperando y el proveedor «gestionando internamente».
Cómo evitar que la dependencia de proveedores comprometa tu recuperación
Uno de los errores más peligrosos que se cometen es confundir tener un proveedor contratado con tener resiliencia probada, y ese error no se detecta hasta que el proveedor también está afectado.
Esa falsa tranquilidad la puedes detectar en el registro y el contrato:
- El registro de proveedores críticos lista cláusulas de penalización y tiempos de respuesta contractuales, pero no qué ocurre si el propio proveedor está gestionando su propio incidente a la vez que tú.
- Nadie le ha preguntado nunca al proveedor cloud o de identidad qué papel juega en tu plan de continuidad. Se asume que «está ahí» porque paga la factura cada mes.
Esto es algo que pudimos vivir los que llevamos tiempo en esto con el ataque de WannaCry en 2017.
Si revisas el alcance de tus pruebas:
- El simulacro de recuperación se considera pasado cuando el servidor arranca, no cuando el servicio completo responde a un usuario real.
- Existe una versión del plan para «fallo interno» y ninguna para fallo combinado — tu incidente y el del proveedor, a la vez.
- La última prueba documentada tiene más de doce meses, y nadie sabe si el proveedor ha cambiado de arquitectura o el proceso de escalado desde entonces.
Lo que ve el negocio:
- El comité de riesgos aprueba el plan revisando el documento, sin pedir evidencia de que se ha ejecutado el escenario que incluye al proveedor.
- Preguntas «¿y si el proveedor de identidad cae contigo?» y la respuesta es un silencio, o un «eso no debería pasar» — no un procedimiento.
El fallo está principalmente en que el plan de continuidad se diseña mirando hacia dentro: qué sistemas tienes, qué copias guardas, quién descuelga el teléfono, cómo se debe actuar. El proveedor entra en el documento como cláusula, no como actor del escenario. La prueba hereda el mismo punto ciego — valida tu infraestructura, da por bueno el servicio de terceros porque «tiene SLA», y cierra el ejercicio cuando el sistema responde ping, no cuando el negocio puede operar con normalidad. El fallo no aparece en la prueba porque la prueba nunca incluyó la posibilidad de que el proveedor también esté comprometido, saturado o simplemente ilocalizable a las tres de la madrugada.
Pero, ¿cuánto le cuesta esto a tu organización?
El tiempo de recuperación real puede duplicar o triplicar el RTO documentado en cuanto el proveedor deja de ser una constante y pasa a ser variable. A eso se suma el coste contractual: un incidente prolongado por dependencia no probada activa penalizaciones frente a tus clientes que no puedes repercutir al proveedor, porque su contrato cubre su disponibilidad, no la tuya. Y hay un tercer coste, más lento pero igual de real — el comité que aprobó el plan como «hecho» pierde autoridad la primera vez que el escenario real no se parece en nada al documentado.
Para saber cómo puede impactar en tu negocio, revisa:
- ¿La última prueba de recuperación incluyó un escenario con el proveedor cloud o de identidad inaccesible? Sí/No.
- ¿El criterio de «recuperado» en el runbook exige verificación funcional por un usuario real, no solo arranque de servidor? Sí/No.
- ¿Existe un procedimiento documentado — no solo una cláusula contractual — para el fallo combinado? Sí/No.
- ¿El comité de riesgos ha visto evidencia de ejecución en los últimos 12 meses, no solo el documento? Sí/No.
Si te impacta, puedes intervenir de tres maneras diferentes:
- Seguir como está y aceptar el riesgo de que el primer fallo combinado sea el primero que se descubre en producción.
- Exigir al proveedor una prueba conjunta documentada, con fecha y evidencia, como parte del contrato de servicio.
- Diseñar tú un ejercicio interno que simule al proveedor caído — más lento de montar, pero no depende de que el proveedor acepte participar.
Mi recomendación es que optes por diseñar tu la simulación del proveedor caído. Puede ser que tu proveedor quiera colaborar y puedes hacer la prueba conjunta, pero si no, yo optaría por forzar esa prueba.
Eso sí, recuerda siempre tener un dueño de este ejercicio y fijar una fecha del primer borrador de este escenario.
Si además quieres anticiparte a este escenario, incluye al proveedor crítico como parte explícita del escenario de prueba, no como nota al pie. Cambia el criterio de «recuperado» en el runbook de «el sistema arranca» a «el usuario puede completar la operación de negocio». Y revisa el registro de proveedores una vez al año preguntando específicamente qué pasaría si ese proveedor sufriera su propio incidente el mismo día que tú.
Piensa que el coste de no actuar lo tendrás el día en que necesites recuperar el servicio y descubres, en directo, que la pieza que faltaba probar era precisamente la que no controlas.
Por esto te propongo que esta semana:
- Revisa el criterio de «recuperado» en tu runbook actual y comprueba si exige verificación funcional o solo arranque técnico.
- Identifica quién es, hoy, el dueño de diseñar un escenario de prueba que incluya al proveedor cloud o de identidad como variable caída.
- Fija una fecha — no un «lo vemos» — para el primer borrador de ese escenario.
¿Has probado ya qué pasa cuando tu proveedor cloud está caído?
P.S.: Esto que estamos tratando para el proveedor cloud puedes ampliarlo a cualquier otro proveedor que tengas.