Plan de continuidad de negocio para NIS2: cómo integrar el BCP, el análisis de riesgos y los simulacros de crisis

Un plan de continuidad de negocio orientado a NIS2 no puede ser un procedimiento aislado bajo la responsabilidad exclusiva de TI. Debe partir del análisis de impacto en el negocio y del análisis de riesgos, establecer las prioridades de recuperación de los procesos y validarse mediante ejercicios periódicos. Su eficacia no se demuestra con declaraciones, sino con la capacidad real de la organización para tomar decisiones, activar soluciones alternativas, alcanzar un nivel mínimo de operación y volver de forma segura a la actividad ordinaria.

La continuidad de negocio es una decisión de la dirección

Un plan de continuidad de negocio no comienza con una plantilla de procedimiento ni con un inventario de sistemas informáticos. El punto de partida son los servicios, productos y procesos cuya interrupción podría comprometer el cumplimiento de obligaciones, la seguridad, la conformidad con los requisitos aplicables o la estabilidad financiera de la empresa. El alcance del plan debe derivarse del análisis de impacto en el negocio. Es necesario determinar cómo aumentan las consecuencias con el paso del tiempo, cuándo superan el nivel aceptado por la dirección y en qué orden deben recuperarse las capacidades operativas.

El tiempo máximo tolerable de interrupción y el nivel de pérdidas aceptable no deben ser definidos unilateralmente por TI. Estos parámetros deben ser aprobados por la dirección a partir de la información aportada por los propietarios de los procesos y por las áreas financiera, de cumplimiento, seguridad y tecnología. El propietario del proceso establece las necesidades de continuidad, mientras que el responsable del plan coordina la preparación y el mantenimiento de la solución. Si ambas funciones no están conectadas mediante un mecanismo común de decisión, TI protege la infraestructura, operaciones responde de la prestación y la dirección no recibe una visión coherente de las prioridades de recuperación ni de las interrupciones admisibles.

En una planta industrial, recuperar el sistema de planificación o control no significa necesariamente reanudar las expediciones. La producción puede seguir detenida por falta de datos técnicos, operadores autorizados, suministro eléctrico, conectividad proporcionada por un proveedor o un procedimiento aprobado para trabajar en modo alternativo. La resiliencia operativa solo existe cuando el plan cubre toda la cadena de dependencias del proceso, y no únicamente los recursos controlados por TI.

También es necesario diferenciar entre continuidad de negocio, recuperación de recursos informáticos, respuesta ante incidentes y gestión de crisis. La primera se ocupa de mantener o reanudar los procesos; la segunda, de recuperar la tecnología y los datos; la tercera, de contener y gestionar los efectos del incidente; y la cuarta, de tomar decisiones ante una alteración grave. Estos mecanismos deben compartir escenarios, umbrales de escalado y criterios de responsabilidad, pero no son intercambiables.

Solo después de definir este modelo operativo puede contrastarse con las obligaciones derivadas de NIS2 y de la normativa nacional aplicable en materia de gestión de riesgos, continuidad de negocio, gestión de incidentes y responsabilidad de la dirección, teniendo en cuenta si la organización se encuentra dentro de su ámbito de aplicación. El artículo NIS2 para empresas industriales: a quién afecta, qué obligaciones introduce y cómo preparar la organización sin reducir la cuestión exclusivamente a TI ofrece un contexto más amplio.

El riesgo debe traducirse en escenarios

El registro de riesgos solo orienta el plan de continuidad cuando muestra la relación entre amenaza, vulnerabilidad, activo, proceso y consecuencia para el negocio. Una simple lista de ciberamenazas no explica cómo mantener la actividad. Por tanto, los escenarios deben construirse en torno a los efectos de la interrupción, como la indisponibilidad de un sistema de control, la pérdida de datos, el corte de las comunicaciones, la falta de personal o la indisponibilidad de un proveedor. Causas diferentes pueden producir el mismo estado operativo y exigir una estrategia de continuidad idéntica.

El análisis de impacto en el negocio y el análisis de riesgos cumplen funciones distintas, aunque complementarias. El primero determina la relevancia de la interrupción, la velocidad con la que aumentan las pérdidas y el momento en que se supera el nivel aceptado por la dirección. El segundo permite identificar las posibles causas del suceso, las vulnerabilidades y la eficacia de los controles existentes. El método y la escala de evaluación adoptados deben facilitar la comparación entre escenarios y la aceptación consciente del riesgo residual conforme al apetito de riesgo.

Conviene limitar el número de escenarios a efectos diferenciados que exijan decisiones, recursos o secuencias de recuperación distintas. Analizar por separado cada variante técnica no suele mejorar la utilidad del plan y dificulta tanto su mantenimiento como su aplicación bajo presión.

Para cada escenario deben definirse el tiempo máximo tolerable de interrupción, el nivel mínimo de operación, los recursos necesarios, el orden de recuperación y la persona autorizada para activar el plan. Estos parámetros deben basarse en los tiempos reales de parada y recuperación registrados durante incidentes, averías y ejercicios, así como en los requisitos contractuales relativos a disponibilidad, plazos de prestación y notificación de interrupciones. A partir de estos datos pueden medirse el tiempo de decisión, el tiempo necesario para alcanzar el nivel mínimo y el tiempo de recuperación completa.

El análisis debe contemplar las dependencias reales del proceso respecto de aplicaciones, datos, infraestructura, emplazamientos, suministros, competencias clave, proveedores de TI, integradores y subcontratistas. Si la estrategia depende del apoyo de un tercero, deben verificarse su disponibilidad, tiempos de respuesta, canales de escalado y soluciones alternativas, en lugar de limitarse a lo indicado en el contrato. Esta cuestión se desarrolla en NIS2 y seguridad de la cadena de suministro: cómo evaluar a proveedores de TI, integradores y subcontratistas.

El plan debe guiar a la organización durante la interrupción

Un plan de continuidad útil no intenta describir todos los sucesos posibles; guía a los responsables a través de las decisiones que deben tomar. Debe establecer quién identifica la situación, quién declara el modo de continuidad, qué procesos deben mantenerse en el nivel mínimo, en qué orden se recuperan las capacidades, cómo se gestiona la comunicación de crisis y con qué criterios se cierra el modo extraordinario.

El nivel de detalle es adecuado cuando reduce la necesidad de interpretar bajo presión, sin sustituir las instrucciones técnicas y operativas. En organizaciones de mayor tamaño, una solución práctica consiste en disponer de un plan marco que defina el mando, el escalado y las reglas comunes de actuación, complementado con planes específicos para cada proceso.

El procedimiento de activación requiere criterios medibles. Una indicación como «en caso de avería grave» traslada la discusión sobre el significado de «grave» al peor momento posible. El criterio puede ser la superación del tiempo tolerable de interrupción, la pérdida de fiabilidad de los datos, la imposibilidad de trabajar con seguridad, la indisponibilidad de personas clave o la previsión de que el proceso caerá por debajo del nivel mínimo aprobado por su propietario. Cada desviación debe vincularse con una actuación, una persona autorizada para decidir, un plazo de escalado y un registro obligatorio. Una lógica similar, aunque aplicada a otro nivel operativo, se explica en Plan de reacción en el plan de control: cómo definir las actuaciones cuando el proceso sale de los límites.

Las responsabilidades deben asignarse a funciones, y no únicamente a personas concretas. La matriz de responsabilidades debe incluir suplencias, niveles de autoridad, disponibilidad y canales de contacto principales y alternativos. La lista nominal de contactos puede mantenerse como anexo controlado, de modo que un cambio de personal no obligue a revisar todo el plan.

La dirección debe intervenir en las decisiones que excedan el marco operativo aprobado, incluidas la aceptación de riesgos significativos para el negocio, la activación de medidas extraordinarias o una comunicación con relevancia estratégica. En cambio, la decisión de pasar a un modo alternativo previamente aprobado debe situarse lo más cerca posible del proceso.

Tras la caída del sistema de pedidos, la persona de guardia puede confirmar la indisponibilidad y el tiempo estimado de interrupción; el propietario del proceso puede activar el registro alternativo; y el coordinador de continuidad puede escalar el incidente cuando se alcance el umbral establecido. El plan debe definir las limitaciones de esta solución: capacidad operativa, tiempo máximo de uso, protección e integridad de los datos, conciliaciones manuales necesarias y método para incorporar posteriormente los registros al sistema.

La vuelta a la operativa habitual solo puede producirse después de confirmar la estabilidad de la solución, la integridad de los datos y la conciliación de las operaciones realizadas manualmente. Los registros generados deben permitir evaluar los tiempos de decisión, de consecución del nivel mínimo y de recuperación completa.

El mayor coste aparece en las interfaces entre planes

La magnitud de la pérdida no depende únicamente de la causa de la avería. La interrupción también se prolonga por la espera de autorizaciones, una clasificación ambigua del incidente, prioridades de recuperación contradictorias o el desconocimiento de las dependencias entre procesos, sistemas y proveedores. El plan de respuesta ante incidentes sirve principalmente para detectar, evaluar, contener y gestionar el suceso. El plan de continuidad, por su parte, debe mantener la actividad en un nivel aceptado. Ambos mecanismos deben establecer puntos comunes para transferir información y decisiones: quién determina que la continuidad está amenazada, quién activa el modo alternativo y quién autoriza la vuelta a la operativa habitual.

La prioridad de recuperación técnica debe derivarse de la prioridad del proceso, pero no puede ser una reproducción automática de esta. El sistema que soporta el proceso más importante puede requerir la recuperación previa de servicios de identidad, red, bases de datos o integración. Además, deben preservarse la integridad de los datos, la secuencia correcta de arranque y los mecanismos de seguridad. La coherencia entre las prioridades empresariales y técnicas se verifica comparando la disponibilidad exigida por el proceso con los resultados reales de las pruebas de restauración de copias de seguridad, la pérdida de datos admisible y las dependencias de la infraestructura.

Operaciones puede exigir que se restablezca la recepción de pedidos antes que la facturación, mientras TI prevé recuperar primero esta última porque contiene el registro central de clientes. Si esta dependencia no se ha acordado previamente, la decisión se toma bajo presión y la solución manual puede generar datos imposibles de conciliar de manera segura. El caso debe evaluarse con los tiempos reales de detección, escalado, decisión y recuperación, además de las pruebas que confirmen la integridad y la totalidad de los datos.

Una brecha similar aparece en los límites de responsabilidad del proveedor. Un compromiso contractual de disponibilidad no sustituye una ruta de escalado asignada a personas o funciones, unos parámetros de recuperación acordados, el acceso a información sobre la evolución de la interrupción ni la obligación de colaborar en los ejercicios. Las necesidades de los procesos críticos deben compararse con las condiciones contractuales y con las capacidades reales del proveedor. Solo entonces puede decidirse de forma consciente si se mantiene una solución de respaldo, se acepta la interrupción o se recurre a recursos propios o a un servicio externo.

El presupuesto debe responder a brechas de capacidad, no financiar la producción de documentos. Las inversiones pueden destinarse a redundancia adicional, reducción de los tiempos de decisión, pruebas de recuperación más frecuentes, modificación de las condiciones contractuales o implantación de un método alternativo para ejecutar el proceso. El artículo Cuánto cuesta implantar NIS2 y la uKSC: cómo preparar el presupuesto de auditoría, documentación, formación y controles sin errores costosos desarrolla una forma de estructurar estos costes.

Los ejercicios deben poner a prueba las decisiones

Un ejercicio de continuidad no puede limitarse a leer el procedimiento ni a confirmar la asistencia de los participantes. Debe validar una hipótesis formulada con claridad, por ejemplo: si la organización puede activar un proceso alternativo sin el sistema principal, mantener el control sobre los datos introducidos y conciliarlos de forma segura después de recuperar el servicio.

Conviene desarrollar el programa de ejercicios de forma gradual: desde la revisión de funciones y los ejercicios de mesa, pasando por la prueba de un procedimiento concreto o una recuperación, hasta un ejercicio técnico y operativo que incluya la colaboración entre negocio, TI, dirección y proveedores. El alcance debe aumentar en función del riesgo, la relevancia del proceso y el grado de preparación de la organización.

El escenario debe obligar a tomar decisiones en condiciones próximas a una interrupción real. Para ello pueden introducirse información incompleta, presión de tiempo, conflictos entre prioridades o la indisponibilidad de una dependencia relevante, como la persona autorizada para aprobar, un servicio del proveedor o una lista actualizada de contactos. Sin embargo, el ejercicio no debe convertirse en una trampa para los participantes. Se evalúa el sistema —la distribución de responsabilidades, la calidad de la información, la viabilidad de los procedimientos y la capacidad de escalado—, no el desempeño individual de los empleados.

La participación de la dirección es necesaria cuando el escenario exige aceptar un riesgo, modificar prioridades o activar una solución alternativa con un coste significativo. El proveedor debe participar cuando su respuesta condicione la continuidad del proceso.

Un ejercicio puede comenzar con la indisponibilidad del sistema de gestión de pedidos. A continuación, el facilitador comunica que la copia de los datos está incompleta y que el proveedor tarda en responder. El equipo debe decidir si activa el proceso manual, qué pedidos acepta y cómo identifica los registros para evitar duplicidades y pérdidas de integridad después de recuperar el servicio.

Durante el ejercicio deben medirse los tiempos de identificación de la interrupción, escalado, activación del modo de continuidad, consecución del nivel mínimo de operación y recuperación. Al mismo tiempo, se evalúan la calidad del flujo de información y de los registros, el uso de datos de contacto obsoletos, los escalados ineficaces y los pasos del plan que no pudieron ejecutarse. Los tiempos obtenidos deben compararse con los objetivos de continuidad aprobados.

La frecuencia y el tipo de ejercicio deben depender del riesgo, los cambios en los procesos, los resultados de pruebas anteriores y la relevancia de las dependencias, no solo de un calendario anual. Un ejercicio anunciado facilita el aprendizaje y la coordinación de funciones. Uno no anunciado permite valorar mejor la preparación real, pero exige controlar el riesgo operativo. El uso de un sistema de producción solo resulta razonable cuando el alcance, las salvaguardas y la posibilidad de detener la prueba han sido aprobados de forma consciente; en los demás casos es preferible un entorno de pruebas.

Cada ejercicio debe concluir con acciones que tengan un responsable, una fecha límite, un criterio de eficacia y una decisión sobre su nueva comprobación. El porcentaje de acciones cerradas en plazo es un indicador útil, pero el estado «realizada» no demuestra por sí solo una mejora. La evidencia decisiva es el resultado de una nueva prueba. El enfoque descrito en Cómo crear una biblioteca de formatos de calidad: FMEA, Control Plan, 8D, auditoría, CAPA y KPI puede ayudar a estructurar escenarios, actas, acciones correctivas e indicadores.

Cierre el ciclo con evidencias y revisión

Disponer de procedimientos completos no demuestra la capacidad de mantener la actividad. Una cadena de evidencias fiable debe conectar los supuestos aprobados del análisis de riesgos y continuidad, las decisiones de los propietarios de los procesos, los registros de las pruebas, los resultados de los ejercicios, las no conformidades detectadas, las acciones correctivas y la evaluación de su eficacia. El historial de versiones del plan de continuidad debe indicar no solo la fecha y el autor de cada cambio, sino también el suceso, la decisión o el resultado del análisis que lo justificó.

La frecuencia de revisión del plan debe adaptarse a la criticidad de los procesos y a la variabilidad del riesgo. Una fecha periódica no es suficiente. La revisión también debe activarse después de un incidente, un ejercicio o un cambio relevante en el proceso, la tecnología, el emplazamiento, el proveedor, la estructura organizativa o el perfil de riesgo. Los criterios de aceptación del ejercicio deben definirse antes de iniciarlo para evitar que la evaluación se reduzca a una valoración subjetiva de que la organización «se desenvolvió bien».

El seguimiento mensual puede mostrar que el programa de ejercicios se ha ejecutado según el calendario, pero también que un proceso no alcanzó el tiempo de recuperación exigido y que sigue sin existir una alternativa para un servicio crítico prestado por un proveedor. Este resultado no debe quedar oculto en un informe técnico. La dirección debe recibir información sobre los procesos que no alcanzan la capacidad requerida, las discrepancias todavía no aceptadas, los riesgos asumidos conscientemente y las inversiones o decisiones organizativas necesarias. La revisión por la dirección debe finalizar con decisiones documentadas, no con una mera toma de conocimiento.

La auditoría interna debe comprobar la coherencia entre lo declarado y la práctica: si un proceso clasificado como crítico participa realmente en los ejercicios, si los objetivos técnicos de recuperación responden a las necesidades operativas y si las acciones derivadas de las pruebas se han cerrado y se ha verificado su eficacia. Ante un auditor o una autoridad supervisora debe poder presentarse una secuencia de registros que muestre el recorrido desde el riesgo identificado, pasando por la decisión y la prueba, hasta la mejora verificada. Entre los indicadores de apoyo se encuentran el grado de ejecución del programa de ejercicios aprobado, el cierre puntual de acciones correctivas y el número de discrepancias no aceptadas entre la capacidad de continuidad requerida y la capacidad confirmada.

La lista final de actuaciones puede integrarse en el calendario general descrito en Implantación de NIS2 tras la inscripción en el registro KSC: plan de actuación hasta el 3 de abril de 2027. No obstante, los plazos, el alcance de las obligaciones y las medidas aplicables deben verificarse en cada caso conforme a la normativa vigente, la situación de la organización dentro del sistema nacional de ciberseguridad correspondiente y su perfil real de riesgo.