La planificación de la continuidad del negocio suele fallar no durante una crisis, sino durante la evaluación previa. Las organizaciones realizan análisis de impacto empresarial, documentan objetivos de tiempo de recuperación, elaboran manuales de recuperación exhaustivos y, en el peor momento posible, descubren que un servicio de autenticación heredado, aparentemente no crítico, es un punto único de fallo para toda su plataforma de comercio electrónico; que el programa por lotes COBOL, que todos asumían de baja prioridad, alimenta el servicio de validación de pagos en tiempo real; o que dos aplicaciones con el mismo nivel de recuperación tienen una dependencia no documentada que imposibilita la recuperación secuencial. La puntuación se realizó, pero las dependencias no.
La puntuación de criticidad de las aplicaciones consiste en asignar una medida cuantitativa o escalonada de importancia a cada aplicación en el portafolio de una organización. Esta medida determina su prioridad de recuperación, su nivel de inversión en redundancia, sus requisitos de control de cambios y su posición en la secuencia de recuperación ante desastres. Cuando esta puntuación se basa únicamente en encuestas de impacto empresarial y entrevistas con los responsables de las aplicaciones, refleja la percepción que se tiene de ellas. Sin embargo, cuando se fundamenta en un análisis estructural de las funciones reales de las aplicaciones (quién llama a quién, qué flujos de datos atraviesan qué programas y qué componentes compartidos se encuentran en la ruta crítica de múltiples sistemas de mayor prioridad), refleja la realidad operativa.
La brecha entre la creencia y la realidad es donde fallan los planes de continuidad del negocio.
Secuencias de recuperación que reflejan dependencias reales
SMART TS XL Identifica todos los programas que forman parte de la ruta crítica de sus aplicaciones de Nivel 1, en todos los idiomas de su cartera.
DESCUBRE MÁS…¿Qué mide realmente la puntuación de criticidad de las aplicaciones?
La criticidad no es una dimensión única. Para determinar la puntuación de criticidad de una aplicación empresarial, se puede tener en cuenta la opinión de los usuarios para evaluar su criticidad o importancia, incluyendo el mayor impacto en las necesidades estratégicas del negocio, los impactos en los socios comerciales, las interacciones con los clientes y los impactos en otras aplicaciones empresariales. Cada una de estas dimensiones abarca un aspecto diferente de lo que significa "crítico".
Impacto empresarial : lo que la organización pierde por cada hora de inactividad. La pérdida de ingresos es la dimensión más visible: un sistema de procesamiento de pagos que maneja 10 millones de dólares por hora tiene un costo cuantificable por minuto de interrupción. Pero el impacto empresarial va más allá de los ingresos e incluye la exposición regulatoria (¿qué obligaciones de cumplimiento genera la interrupción?), el daño a la reputación (¿se ven afectados directamente los clientes?) y las penalizaciones contractuales (¿los acuerdos de nivel de servicio (SLA) activan cláusulas de penalización?).
Dependencia operativa : cuántos otros sistemas o procesos dependen de esta aplicación. Una aplicación con bajo impacto directo en el negocio puede tener alta criticidad porque se encuentra en la ruta de dependencia de aplicaciones con alto impacto directo. El servicio de autenticación que habilita todas las demás aplicaciones de cara al cliente es más crítico de lo que su propia función sugiere.
La complejidad de la recuperación indica la dificultad y el tiempo que requiere restaurar la aplicación. Una aplicación con un impacto moderado en el negocio y un tiempo de recuperación de 48 horas puede requerir una mayor inversión en redundancia que una aplicación con un mayor impacto en el negocio y un tiempo de recuperación de 2 horas, debido a que el riesgo total de inactividad es mayor.
Obligación regulatoria : ¿qué aplicaciones están sujetas a requisitos de continuidad regulatoria? Las instituciones financieras sujetas a DORA deben demostrar que las funciones críticas o importantes pueden soportar escenarios de interrupción específicos. Las organizaciones de atención médica sujetas a HIPAA deben proteger la disponibilidad de los sistemas que contienen información de salud protegida. La dimensión regulatoria puede prevalecer sobre la puntuación de impacto empresarial para aplicaciones específicas.
La puntuación de criticidad es una combinación de las cuatro dimensiones, ponderada por la tolerancia al riesgo específica de la organización, el entorno regulatorio y el modelo de negocio.
Los niveles de criticidad estándar
La mayoría de las carteras de aplicaciones empresariales utilizan un modelo de criticidad de cuatro niveles. Las categorías de criticidad en una matriz de criticidad de aplicaciones son: Misión Crítica, Negocio Crítico, Operaciones de Negocio y Administración. Las definiciones que se presentan a continuación reflejan las prácticas actuales del sector, alineadas con la norma ISO 22301 (Sistemas de Gestión de la Continuidad del Negocio) y las Directrices de Buenas Prácticas del Business Continuity Institute:
Nivel 1: Aplicaciones de misión crítica cuya falla detiene de inmediato las operaciones comerciales principales o crea un riesgo inaceptable para la seguridad o la regulación. Objetivo de tiempo de recuperación (RTO): generalmente de 0 a 4 horas. Objetivo de punto de recuperación (RPO): generalmente de 0 a 1 hora. Ejemplos: procesamiento central de transacciones bancarias, sistemas de negociación en tiempo real, sistemas de despacho de emergencias, interfaces de control industrial, sistemas de autorización de pagos. Estas aplicaciones justifican la mayor inversión en infraestructura: redundancia activa-activa, replicación con RPO cero, conmutación por error automatizada y el control de cambios más riguroso.
Nivel 2: Aplicaciones críticas para el negocio cuyo fallo afecta significativamente a las operaciones, pero no las interrumpe de inmediato. Objetivo de tiempo de recuperación: normalmente de 4 a 24 horas. Objetivo de punto de recuperación: normalmente de 1 a 4 horas. Ejemplos: sistemas CRM, módulos ERP, gestión de pedidos, sistemas de RR. HH. durante los periodos de nómina, sistemas de informes durante los plazos de presentación de informes regulatorios. Estas aplicaciones justifican una infraestructura de alta disponibilidad, una conmutación por error probada periódicamente y una secuencia de recuperación prioritaria.
Nivel 3: Aplicaciones operativas empresariales que dan soporte a las operaciones comerciales, pero cuya indisponibilidad temporal puede gestionarse mediante soluciones manuales. Objetivo de tiempo de recuperación: normalmente de 24 a 72 horas. Objetivo de punto de recuperación: normalmente de 4 a 24 horas. Ejemplos: herramientas de colaboración interna, informes no orientados al cliente, portales administrativos, plataformas de formación. Se aplican procedimientos estándar de copia de seguridad y recuperación.
Nivel 4: Aplicaciones administrativas que dan soporte a funciones administrativas sin impacto operativo directo. Objetivo de tiempo de recuperación: normalmente 72 horas o más. Objetivo de punto de recuperación: 24 horas o más o desde la última copia de seguridad. Ejemplos: wikis de documentación interna, herramientas de desarrollo no esenciales, informes históricos. Restaurar desde la copia de seguridad de forma ocasional.
La asignación de niveles no es permanente. Una aplicación que se encuentra en el Nivel 3 durante la mayor parte del año puede pasar al Nivel 2 durante el cierre financiero de fin de mes, los períodos de presentación de informes regulatorios o las temporadas de mayor actividad comercial. La criticidad dinámica, donde la asignación de niveles cambia según el calendario operativo, es un perfeccionamiento que las organizaciones con programas de continuidad del negocio (BCP) maduros implementan después de establecer la estructura de niveles de referencia.
Metodología de puntuación: Traduciendo dimensiones en números
Una metodología de puntuación estructurada convierte las cuatro dimensiones de criticidad en una puntuación numérica que determina la asignación de niveles de forma objetiva, en lugar de dejarse influir por las políticas organizativas. El enfoque que se describe a continuación genera una puntuación compuesta de 0 a 100 utilizando criterios ponderados:
Dimensión 1: Impacto en el negocio (ponderación: 35%)
| Impacto en los ingresos por hora de inactividad | Puntuación |
|---|---|
| Más de 1 millón de dólares por hora | 35 |
| Entre 100 y 1 de dólares por hora. | 28 |
| Entre 10 y 100 dólares por hora | 21 |
| Entre 1 y 10 dólares por hora | 14 |
| < $1 por hora | 7 |
| Sin impacto directo en los ingresos | 0 |
El impacto normativo (obligaciones de cumplimiento de DORA, HIPAA, PCI-DSS y SOX derivadas de una interrupción del servicio) añade hasta 10 puntos adicionales a esta dimensión.
Dimensión 2: Dependencia operativa (peso: 30%)
| Entrada de ventilador: Aplicaciones que dependen de esta aplicación | Puntuación |
|---|---|
| > 20 aplicaciones dependientes | 30 |
| 10-20 aplicaciones dependientes | 24 |
| 5-9 aplicaciones dependientes | 18 |
| 2-4 aplicaciones dependientes | 12 |
| 1 aplicación dependiente | 6 |
| Sin dependencias (independiente) | 0 |
El recuento de dependencias internas se refiere al número de aplicaciones que llaman a esta aplicación, leen sus resultados o dependen de sus datos, no al número de usuarios ni a la importancia percibida. Esta dimensión es la que con mayor frecuencia se calcula erróneamente en las encuestas, ya que los propietarios de las aplicaciones desconocen a todos sus consumidores finales.
Dimensión 3: Complejidad de la recuperación (ponderación: 20%)
| Tiempo estimado de recuperación sin recuperación ante desastres preconfigurada | Puntuación |
|---|---|
| > 72 horas | 20 |
| 24-72 horas | 16 |
| 8-24 horas | 12 |
| 2-8 horas | 8 |
| <2 horas | 4 |
| Conmutación por error automatizada < 15 minutos | 0 |
Dimensión 4: Sensibilidad de los datos y obligación regulatoria (ponderación: 15%)
| Clasificación de datos y requisitos reglamentarios | Puntuación |
|---|---|
| Información de identificación personal (PII) / información de salud protegida (PHI) / datos de salud civil (CHD) regulados con obligación explícita de tiempo de recuperación. | 15 |
| Datos regulados sin obligación de plazo de recuperación específico | 12 |
| Datos internos sensibles (secretos comerciales, registros financieros) | 9 |
| Datos operativos internos | 6 |
| Datos internos no sensibles | 3 |
| No hay datos almacenados | 0 |
Asignación de puntuación compuesta a niveles:
| Puntuacion compuesta | Asignación de nivel |
|---|---|
| 75-100 | Nivel 1, misión crítica |
| 50-74 | Nivel 2, Crítico para el Negocio |
| 25-49 | Nivel 3, Operaciones comerciales |
| 0-24 | Nivel 4, Administrativo |
El problema de la dependencia: por qué la puntuación basada en encuestas resulta errónea.
La dimensión de dependencia operativa es la que tiene más probabilidades de ser mal calculada, y es la que tiene mayores consecuencias cuando se equivoca. Un servicio de autenticación heredado, aparentemente no crítico, puede convertirse en un punto único de fallo para toda una plataforma de comercio electrónico, y su fallo podría paralizar todas las transacciones generadoras de ingresos. Este proceso va más allá de las amenazas abstractas y tiene impactos concretos y medibles en los acuerdos de nivel de servicio.
Los responsables de las aplicaciones conocen sus dependencias directas ascendentes, es decir, los sistemas a los que llaman. Sin embargo, rara vez conocen sus dependencias descendentes completas, es decir, los sistemas que las llaman. Un servicio interno de autenticación de usuarios puede considerarse de baja criticidad por su responsable (no genera ingresos, es sencillo y rara vez falla), mientras que doce aplicaciones orientadas al cliente, todas de nivel 1, dependen de él. La criticidad real del servicio de autenticación es de nivel 1, no por su propia función, sino por su posición en el gráfico de dependencias de los sistemas de nivel superior.
La evaluación de criticidad basada en encuestas genera este error de forma sistemática. Una encuesta dirigida al propietario de la aplicación pregunta: "¿Qué tan crítica es esta aplicación?". El propietario del servicio de autenticación responde "de baja a media" según la función del servicio. Los doce propietarios de aplicaciones dependientes no responden a esta encuesta sobre el servicio de autenticación, sino sobre sus propias aplicaciones. La relación de dependencia nunca se registra.
La consecuencia se manifiesta en la secuencia de recuperación: el plan de continuidad del negocio (BCP) define el orden de recuperación según las puntuaciones de criticidad obtenidas mediante el análisis, y el servicio de autenticación se programa para la recuperación de nivel 3. Durante un incidente real, las aplicaciones de nivel 1, que deberían recuperarse primero, no pueden hacerlo porque el servicio de autenticación del que dependen no se ha restaurado. La secuencia de recuperación falla en el punto de su dependencia más crítica.
Tres tipos de dependencia que las encuestas suelen pasar por alto:
Componentes compartidos ocultos. Un programa COBOL interno que gestiona la conversión de divisas para tres procesos de negocio distintos, ninguno de los cuales fue identificado por el estudio como compartido por un componente, constituye una dependencia oculta que afecta a la recuperación de los tres. Si el programa de conversión de divisas es de Nivel 3 y cualquiera de los tres procesos de negocio es de Nivel 1, la criticidad efectiva del programa de conversión de divisas es de Nivel 1.
Dependencias en la canalización de datos. Las aplicaciones que consumen datos procesados por lotes de otras aplicaciones tienen una dependencia temporal, no en tiempo real. El riesgo no radica en un fallo simultáneo, sino en uno secuencial: la aplicación receptora se recupera, pero su fuente de datos no se ha restaurado al mismo punto de recuperación, lo que da la impresión de que los datos obsoletos funcionan correctamente. Este tipo de dependencia no aparece en los mapas de topología de red ni en el análisis de grafos de llamadas, a menos que se rastree el flujo de datos.
Dependencias de configuración y esquema compartidos. Las aplicaciones que comparten esquemas de bases de datos, servicios de configuración o proveedores de identidad tienen una dependencia implícita, incluso si nunca se comunican directamente entre sí. Un cambio de esquema en una base de datos compartida puede afectar a varias aplicaciones. Recuperar una aplicación tras una corrupción de esquema sin recuperar todas las aplicaciones que comparten dicho esquema genera un estado inconsistente en todo el conjunto de aplicaciones.
Integración del Plan de Continuidad del Negocio: Cómo las puntuaciones de criticidad influyen en las decisiones de recuperación
La puntuación de criticidad es el dato de entrada para seis decisiones específicas de diseño del BCP:
1. Definición de la secuencia de recuperación. Las aplicaciones se recuperan en orden de criticidad: Nivel 1 antes que Nivel 2 y luego Nivel 3. Sin embargo, dentro de cada nivel, el grafo de dependencias determina la secuencia. Las aplicaciones sin dependencias entrantes (ninguna otra aplicación depende de ellas) pueden recuperarse en cualquier orden dentro de su nivel. Las aplicaciones con alta probabilidad de entrada deben recuperarse antes que sus dependientes, independientemente de su puntuación relativa dentro del nivel. Por lo tanto, la secuencia de recuperación es: el orden de los niveles aplicado a la subsecuencia con restricciones de dependencia dentro de cada nivel.
2. Establecimiento de objetivos de RTO y RPO. La puntuación de criticidad calibra los objetivos de RTO y RPO. El Tiempo Máximo de Inactividad Tolerable (MTD) y el Objetivo de Punto de Recuperación (RPO) para cada aplicación de producción constituyen la base técnica de toda la estrategia de continuidad. El MTD es el tiempo máximo que la empresa puede tolerar que una aplicación no esté disponible. El RTO debe ser inferior al MTD. El margen entre el RTO y el MTD es el margen de seguridad. Las aplicaciones de Nivel 1 con un alto impacto en el negocio por hora de inactividad tienen márgenes MTD/RTO estrechos y requieren una infraestructura diseñada para una recuperación automatizada rápida.
3. Calibración de la inversión en infraestructura. Los índices de criticidad influyen directamente en las decisiones de inversión en infraestructura de recuperación ante desastres (DR). Las aplicaciones de nivel 1 justifican la redundancia multirregional activa-activa. Las aplicaciones de nivel 2 justifican la redundancia activa-pasiva con conmutación por error probada. Las aplicaciones de nivel 3 justifican las copias de seguridad periódicas con procedimientos de restauración documentados. Las aplicaciones de nivel 4 pueden basarse en políticas de copia de seguridad estándar. Sin índices de criticidad, las decisiones de inversión en infraestructura tienden a una sobreinversión uniforme (costosa) o a una subinversión uniforme (arriesgada).
4. Requisitos de control de cambios. Las aplicaciones con mayor criticidad requieren un control de cambios más riguroso: periodos de congelación de cambios más prolongados, mayor número de aprobadores obligatorios, pruebas previas al cambio más exhaustivas y procedimientos de reversión más conservadores. Aplicar el control de cambios de Nivel 1 a aplicaciones de Nivel 4 supone una pérdida de tiempo para el equipo de ingeniería. Aplicar el control de cambios de Nivel 4 a aplicaciones de Nivel 1 genera un riesgo inaceptable.
5. Frecuencia de pruebas y validación. El Plan de Continuidad del Negocio (BCP) requiere pruebas periódicas de los procedimientos de recuperación, simulacros de mesa, pruebas de conmutación por error a nivel de componentes y simulaciones completas de recuperación ante desastres. La frecuencia de las pruebas se determina según la puntuación de criticidad: las aplicaciones de Nivel 1 requieren pruebas de recuperación ante desastres trimestrales; las aplicaciones de Nivel 4 requieren pruebas anuales. Probar todas las aplicaciones con la misma frecuencia no es práctico ni necesario.
6. Requisitos del SLA del proveedor. Para las aplicaciones que dependen de servicios de terceros, el nivel de criticidad determina los requisitos del SLA que deben incluirse en los contratos con los proveedores. Una aplicación de nivel 1 con un RTO de 4 horas requiere un SLA de terceros que garantice una disponibilidad acorde con dicho RTO. Una aplicación de nivel 4 no lo requiere.
La complicación del sistema heredado
Los sistemas heredados complican la evaluación de la criticidad de maneras que los marcos modernos de gestión de carteras de aplicaciones no abordan adecuadamente. La evaluación de criticidad estándar presupone que los propietarios de las aplicaciones saben qué hacen sus aplicaciones y quién depende de ellas. Para los sistemas heredados, los programas COBOL que han sido mantenidos por varias generaciones de desarrolladores, los flujos de trabajo JCL cuyas dependencias se documentaron por última vez en 2008, y los programas RPG que generan archivos de salida consumidos por procesos que nadie que trabaje actualmente en la organización escribió, esta suposición no se cumple.
La estructura de dependencias real de un sistema heredado solo es visible en el código mismo. Un programa COBOL que escribe en un conjunto de datos que leen doce programas posteriores tiene doce dependencias posteriores, pero este hecho puede ser desconocido para el propietario del programa COBOL, quien solo ve la función del programa (procesar transacciones diarias) en lugar de su función estructural (producir el conjunto de datos que permite el funcionamiento de otros doce procesos).
Para los sistemas heredados, la dimensión de dependencia de la puntuación de criticidad requiere análisis de código en lugar de encuestas a los propietarios. El número de entradas de un programa COBOL solo se puede obtener examinando todos los demás programas del entorno y determinando cuáles hacen referencia a los conjuntos de datos de salida, las convenciones de llamada o los copybooks compartidos del primer programa. Este análisis es el que proporcionan las plataformas de análisis estructural de código, y sin él, la dimensión de dependencia de cualquier puntuación de criticidad asignada a un programa heredado es, en el mejor de los casos, una estimación fundamentada.
La consecuencia de subestimar la criticidad de las aplicaciones heredadas es particularmente grave, ya que los sistemas heredados suelen ser altamente críticos (a menudo contienen lógica empresarial central acumulada durante décadas) y, al mismo tiempo, reciben puntuaciones bajas (sus responsables no pueden definir con precisión qué depende de ellos, por lo que les asignan puntuaciones conservadoras). El resultado son programas heredados clasificados como de Nivel 3 que, en realidad, forman parte de la ruta crítica de procesos empresariales de Nivel 1, el mismo modo de fallo que se observa en los fallos de la secuencia de recuperación durante incidentes reales.
Cómo SMART TS XL Proporciona la evidencia de dependencia para la puntuación de criticidad.
SMART TS XL Aborda directamente la dimensión de dependencia de la puntuación de criticidad de las aplicaciones, para la clase de aplicaciones en las que los enfoques basados en encuestas son los menos fiables.
La capacidad de mapeo de dependencias de la aplicación crea el gráfico de dependencias completo en todos los lenguajes del entorno: cada programa COBOL que llama a cualquier otro, cada paso de trabajo JCL que produce datos consumidos por programas posteriores, cada copybook compartido que crea una dependencia implícita entre programas que nunca se llaman directamente, cada conjunto de datos que fluye entre programas productores y consumidores. Este gráfico constituye la base estructural de la evidencia para la dimensión de dependencia de la puntuación de criticidad, los recuentos de fan-in, las identificaciones de componentes compartidos y las dependencias ocultas de la canalización de datos que las encuestas no pueden capturar de forma fiable.
La capacidad de análisis de impacto permite consultar el gráfico de dependencias para la planificación de la continuidad del negocio (BCP): para cualquier aplicación del portafolio, se enumeran todas las demás aplicaciones que dependen de ella, directa o indirectamente, y que, por lo tanto, heredan su requisito de disponibilidad. Un programa COBOL con tres dependientes directos y veinte dependientes transitivos (programas que dependen de los dependientes directos) tiene una criticidad efectiva que refleja los veintitrés programas de los que forma parte de la ruta crítica, no solo su propia función.
La capacidad de análisis de código estático revela las métricas de complejidad estructural que informan la dimensión de complejidad de recuperación: complejidad ciclomática, métricas de acoplamiento, porcentaje de código muerto e indicadores de deuda técnica que predicen cuánto tiempo y qué tan riesgosa será la recuperación de cada aplicación. Una aplicación con alta complejidad y acoplamiento denso es más costosa de restaurar, y su puntuación de complejidad de recuperación en la Dimensión 3 es mayor, que una aplicación de función equivalente con una arquitectura limpia.
La función de búsqueda empresarial permite consultar el inventario completo de dependencias durante todo el ciclo de vida del BCP: permite encontrar todos los programas que acceden a un conjunto de datos específico (identificando todos los programas que dependen de su disponibilidad), todos los programas que comparten un archivo de copia específico (identificando todos los programas afectados por su disponibilidad) y todos los trabajos JCL que se ejecutan en una ventana de procesamiento por lotes específica (identificando todos los programas que deben recuperarse antes de que comience la ventana). Esta función de búsqueda respalda la revisión anual de la puntuación de criticidad, el proceso de actualización que mantiene las puntuaciones al día a medida que evoluciona el portafolio de aplicaciones.
Para las organizaciones que realizan modernización heredada programas junto con el desarrollo del BCP, SMART TS XLEl análisis de [nombre del análisis] cumple ambos propósitos simultáneamente: el mapa de dependencias que informa la puntuación de criticidad también determina la secuencia de migración, y las métricas de complejidad que informan la puntuación de complejidad de la recuperación también determinan la estimación del esfuerzo de modernización.
Mantener los resultados actualizados: El ciclo de revisión anual
Una evaluación de la madurez de la continuidad del negocio debería ayudarle a lograr tres cosas: comprender su situación actual, identificar las brechas más importantes y diseñar un plan de mejora realista. Esto es lo que convierte la evaluación de la madurez en un programa más eficaz.
Las puntuaciones de criticidad de las aplicaciones se desvían de la realidad a medida que las organizaciones cambian. Se añaden nuevas aplicaciones. Las antiguas se retiran, pero no se desmantelan por completo. Se crean integraciones entre aplicaciones que antes no tenían dependencia entre sí. Los procesos de negocio cambian y, con ellos, las aplicaciones de las que dependen. Los requisitos normativos evolucionan e imponen nuevas obligaciones de recuperación.
El ciclo de revisión anual de las puntuaciones de criticidad debe incluir:
Reanálisis estructural. Vuelva a ejecutar el mapeo de dependencias para identificar las nuevas dependencias surgidas desde la última revisión. Las aplicaciones que antes eran independientes ahora pueden tener dependencias que aumentan su criticidad. Las aplicaciones de las que dependían muchos usuarios pueden haber migrado a sistemas más recientes, lo que reduce su criticidad.
Reevaluación del impacto en el negocio. Las cifras de ingresos e impacto operativo cambian a medida que el negocio crece y su cartera de aplicaciones evoluciona. Una aplicación que generaba 1 dólares de valor comercial por hora hace tres años, ahora puede generar diez veces esa cantidad tras el crecimiento del negocio.
Incorporación de los resultados de las pruebas de recuperación. Las pruebas de recuperación revelan discrepancias entre la complejidad de recuperación supuesta y la real. Una aplicación que obtuvo una puntuación baja en complejidad de recuperación en la evaluación inicial puede haber tenido un rendimiento deficiente en un ejercicio de simulación, lo que sugiere una revisión al alza de la puntuación.
Revisión de cambios normativos. Las nuevas regulaciones o las modificaciones a las existentes pueden imponer nuevas obligaciones de tiempo de recuperación para aplicaciones específicas. Por ejemplo, los requisitos de resiliencia operativa del Reglamento DORA para las instituciones financieras de la UE han impuesto obligaciones específicas de tiempo de recuperación para "funciones críticas o importantes" que podrían no haberse reflejado en las puntuaciones de criticidad previas a la entrada en vigor de DORA.
Las organizaciones con programas de continuidad del negocio (BCP) maduros consideran la puntuación de criticidad no como un ejercicio puntual, sino como un proceso continuo: las puntuaciones se actualizan cuando se producen cambios significativos en las dependencias de las aplicaciones, el impacto en el negocio o las obligaciones regulatorias, y se validan anualmente mediante una revisión estructurada.
La puntuación es tan buena como la evidencia de su dependencia.
La puntuación de criticidad de las aplicaciones resulta más valiosa cuando su dimensión de dependencia se basa en evidencia estructural en lugar de encuestas. Las dimensiones de impacto empresarial y obligación regulatoria pueden evaluarse de forma fiable mediante entrevistas y análisis de procesos empresariales. La dimensión de dependencia operativa no, ya que requiere conocer qué depende de cada aplicación, y los responsables de las aplicaciones suelen subestimar sistemáticamente a sus usuarios finales.
El modo de fallo es predecible: una secuencia de recuperación basada en puntuaciones de criticidad derivadas de encuestas falla en las dependencias ocultas. Un servicio de autenticación heredado se restaura tarde. Un programa de conversión de moneda COBOL está fuera de línea cuando las aplicaciones que dependen de él intentan recuperarse. Un esquema de base de datos compartida se encuentra en un punto de recuperación diferente al de las aplicaciones que leen de ella. Cada uno de estos fallos se puede prevenir con la evidencia de dependencia que proporciona el análisis estructural, y cada uno resulta costoso cuando ocurre durante un incidente real en lugar de durante un ejercicio de simulación.
La metodología de puntuación está establecida. Los marcos de referencia existen. La brecha que presentan la mayoría de las organizaciones no radica en el marco de puntuación, sino en la base de evidencia para su dimensión más relevante. Es necesario subsanar esa brecha mediante un análisis estructural antes de que el próximo incidente requiera la intervención del Plan de Continuidad del Negocio (BCP).
