La continuidad depende de relaciones que no siempre aparecen en el organigrama.
Un fallo fuera de la empresa
Una organización no puede autenticar a sus usuarios porque un proveedor de identidad sufre una interrupción. Sus servidores siguen encendidos y la base de datos está intacta, pero la actividad queda paralizada. El incidente muestra que la disponibilidad efectiva depende de servicios externos y de condiciones de integración.
Dependencia crítica y dependencia invisible
No todos los proveedores merecen el mismo tratamiento. Conviene identificar qué función presta cada uno, qué procesos se interrumpirían, qué alternativas existen y durante cuánto tiempo puede tolerarse la falla. Un componente gratuito o aparentemente secundario puede transformarse en un punto único de fallo si controla el acceso a lo demás.
Prepararse sin duplicarlo todo
La redundancia puede ser adecuada, pero también introduce complejidad, costos y posibilidades de inconsistencias. A veces sirve contar con acceso de emergencia, un procedimiento manual, una cola de operaciones o comunicación alternativa. La solución depende del servicio y debe probarse antes del incidente, no improvisarse con usuarios afectados.
La dependencia también puede ser informativa. Una entidad quizá mantenga operativos sus sistemas principales, pero pierda la posibilidad de comprobar el estado de un trámite, enviar avisos o consultar la identidad de un usuario. En esos casos puede existir una continuidad degradada: prestar funciones limitadas y registrar operaciones para conciliarlas después. Esa alternativa solo es segura si se conoce cómo evitar duplicidades, alteraciones de permisos y decisiones basadas en información desactualizada. Lo que parece una solución manual requiere diseño y pruebas.
Contratos y capacidades reales
Los compromisos de disponibilidad del proveedor no garantizan que la aplicación propia pueda recuperarse en el mismo plazo. Es útil verificar qué cubren los acuerdos, qué información ofrece el tercero durante incidentes, cómo se gestionan cambios y si es posible extraer datos o migrar funciones.
La respuesta operativa
Ante una caída, distinguir síntomas de causa ayuda a evitar cambios internos innecesarios. Un registro de decisiones, avisos a usuarios, medidas de contingencia y criterios de vuelta a la normalidad contribuye a una recuperación ordenada. También es importante evaluar el impacto generado por los propios intentos de solución.
Conclusión práctica
La continuidad no se compra únicamente mediante un SLA. Se construye entendiendo dependencias, ensayando alternativas y definiendo cómo se presta un servicio degradado de forma segura.
Referencias para ampliar: NIST Cybersecurity Framework 2.0