Planes de continuidad frente a planes de respuesta

El plan de respuesta a incidentes responde a «qué está pasando y cómo lo contengo, lo investigo y lo erradico». El plan de continuidad responde a «cómo sigo cumpliendo lo esencial mientras dura la interrupción», aunque la causa aún se esté investigando. El plan de recuperación de TI, a su vez, responde a «cómo vuelven los sistemas, y en qué orden».

No se sustituyen. Un incidente de seguridad suele activar los tres a la vez, y los conflictos entre ellos son lo que hay que resolver antes del incidente, no durante.

La norma ISO 22301 pide ejercitar y probar los planes de continuidad a intervalos planificados, y mejorar a partir de los resultados. Un plan sin probar es una hipótesis: puede estar desactualizado, y lo normal es que lo esté.

Abre planes y mira la última columna.

Cuando los dos planes se contradicen, alguien con autoridad tiene que decidir qué se sacrifica, y esa persona debe estar nombrada antes del incidente. Decidir a las tres de la mañana quién decide es la forma más cara de resolver un conflicto de planes.

Abre decisiones_cruzadas y revisa quién decide cada situación.

El plan de continuidad no se activa con la alerta de seguridad sino con una regla sobre la interrupción: cuando se consume cierta parte del tiempo que el proceso aguanta, se pasa al modo alternativo, porque esperar a que la restauración termine ya no cabe en el RTO.

Abre umbrales_de_activacion y calcula la hora de activación sumando a la hora de inicio la parte del RTO que fija la regla.

Cuando la respuesta pide aislar un sistema que la continuidad necesita, no gana ninguno de los dos planes por defecto. La decisión pesa el riesgo de dejar el sistema comprometido en red frente al impacto de apagarlo, y busca una opción intermedia si la hay, como aislarlo de internet sin cortar su función local. Quién decide, con qué datos y cuándo se revisa queda en el registro.