¿La continuidad de los servicios de tecnología de la información (TI) solo implica la existencia de un plan de contingencia? No, esa es una pequeña parte. Nos referimos a poder recuperar y mantener los servicios acordados cuando ocurre una interrupción, mientras preservamos los niveles de calidad, seguridad, etc., según las necesidades del negocio y los compromisos del servicio. De acuerdo con el apartado 8.7.2 de la norma ISO/IEC 20000-1 la capacidad no es demostrable sin la conexión entre riesgo, requisitos de continuidad, planes de continuidad y pruebas. El estándar exige evaluar y documentar riesgos, determinar requisitos, tener planes, probarlos, registrar resultados, revisar deficiencias, y mejorar.

En las siguientes líneas ahondaremos en las 7 claves para entender la continuidad del servicio de la manera más didáctica y clara posible:

Clave 1: empieza por el servicio, no por el desastre

Lo usual es comenzar con escenarios catastróficos como ransomware o caída del datacenter. Pero si nos fijamos en las directrices de la norma ISO/IEC 20000-1 veremos la importancia de partir de los requisitos del servicio: qué resultado debe preservarse, qué nivel de servicio es aceptable durante la contingencia y qué dependencias son necesarias para recuperarlo.

Para cada servicio crítico conviene responder, al menos:

• ¿Qué resultado entrega al cliente o usuario?
• ¿Qué interrupción máxima es aceptable para el negocio?
• ¿Qué niveles de servicio deben mantenerse durante la contingencia?
• ¿Qué aplicaciones, infraestructura, datos, personas y proveedores lo soportan?
• ¿Qué secuencia de recuperación permite restablecer el servicio?

Clave 2: convierte el riesgo en requisitos de recuperación

La evaluación de riesgos no termina con una valoración de probabilidad e impacto. También conviene precisar qué escenarios se deben considerar para preparar a la organización a hacer frente a esos escenarios.

Clave 3: haz un plan que indique qué hacer bajo presión

El plan de continuidad necesita ser accionable y permitir tomar decisiones, coordinar recursos y recuperar el servicio en condiciones anormales. No importa que el documento sea corto, lo que se requiere es que sea claro y concreto. 

Clave 4: diseña la continuidad para cuando lo habitual no funciona

La cláusula 8.7.2 de ISO/IEC 20000-1 incorpora un detalle particularmente práctico: los planes de continuidad deben estar disponibles cuando no se pueda acceder al sitio habitual. Esto evita depender precisamente del recurso que puede haber quedado afectado.

Clave 5: prueba para aprender y no nada más para cumplir

La norma requiere probar los planes a intervalos planificados y después de cambios significativos. Una prueba de continuidad amerita producir evidencia suficiente para determinar si las personas, procedimientos, tecnología y dependencias funcionan como se espera.

Clave 6: trata los cambios como disparadores de revalidación

La continuidad pierde vigencia cuando el servicio cambia y el plan permanece igual. Migraciones a cloud, sustitución de enlaces, nuevas versiones, cambios de proveedor, reorganizaciones de turnos, incorporación de nuevos centros de datos o cambios relevantes en la arquitectura pueden alterar las dependencias y la recuperación. Por eso, pregúntate: ¿este cambio modifica riesgos, dependencias, tiempos de recuperación, contactos o procedimientos del plan de continuidad? Si la respuesta es sí, hay que someter a revisión el plan y sus pruebas.

Clave 7: después de una prueba o una interrupción real, cierra el ciclo

ISO/IEC 20000-1 exige revisar los planes después de las pruebas y tomar acciones sobre las deficiencias identificadas. Cuando el plan se lleva a cabo, también es necesario reportar la causa, el impacto y la recuperación.

Cuando de verdad entendemos la continuidad de los servicios de TI dejamos de preguntarnos si tenemos un plan, para interrogarnos sobre si podemos demostrar que el servicio puede mantenerse o recuperarse bajo condiciones adversas. La respuesta dependerá de la trazabilidad entre riesgos, requisitos, dependencias, planes, pruebas y mejora. Y si la organización es madura conocerá qué servicios son críticos, qué se necesita para recuperarlos, quién actúa, qué nivel mínimo debe preservar, cómo prueba su capacidad y cómo aprende después de cada ejercicio o interrupción real. Esa es la continuidad que puede gestionarse, auditarse y mejorar.