Luke Bird ha estado pensando en el tema de las pruebas de escenarios dentro de la resiliencia operativa. En este artículo Luke analiza el camino a seguir en esta área y averigua si las prácticas actuales de gestión de la continuidad del negocio pueden ofrecer un punto de partida.
A raíz de algunas conversaciones sobre esto recientemente, decidí reflexionar un poco más sobre las pruebas de escenarios de resiliencia operativa:
«¿Cómo desarrollo un escenario severo pero plausible para probar que tengo el umbral de tolerancia correcto para un servicio de negocio clave y también para demostrar que puedo operar dentro de esa tolerancia?»
Esta es una pregunta cargada de muchas desconocidas. Como, por ejemplo, ¿qué define un proceso de negocio clave, sin importar cómo establecer una tolerancia para él? Pero trabajemos sobre la base de que las personas ya tienen esos dos bits resueltos y están sentados pensando: ‘está bien, entonces, ¿cómo pruebo esto’?
Mi cerebro comenzó a dispararse para pensar en cómo los umbrales de tolerancia para los servicios de negocio claves podrían probarse de manera significativa. Me preocupa, por ejemplo, que el profesional de la continuidad del negocio pueda mirar su programa de ejercicios y pensar «hecho». Sin embargo, creo que esto llega mucho más ampliamente a todo el negocio.
¿Pero ya probamos un montón de cosas?
Ya hay muchas maneras que una organización puede probar para proporcionar a la administración comodidad sobre un montón de cosas, tales como:
- Pruebas de estrés de liquidez: por ejemplo – Guía de Basilea
- Pruebas de control de riesgos: por ejemplo, pruebas de control SOX
- Pruebas de garantía de calidad de sistemas y software: por ejemplo, – ISO 25010
- Pruebas de continuidad del negocio: ISO 22398
Estos son los que se me ocurren justo ahora, pero estoy seguro de que hay aún más. No pretendo ser un experto en todo lo anterior, pero han sido parte de mis experiencias en mi carrera hasta ahora cuando pienso en las pruebas.
Esta lista tampoco incluye cosas como las pruebas de failover de TI por error, pero puede recogerse en las pruebas de garantía de calidad para sistemas y software (como el stress test, las alertas y el failover por error). Sin embargo, estas pruebas ya demuestran que existen métodos muy robustos y completos utilizados en todo el negocio para diferentes dominios. Así que la pregunta es: ¿realmente necesitamos crear algo nuevo para probar una tolerancia definida?
Prueba de escenarios: madura como un buen vino…
Las regulaciones de resiliencia operativa en el Reino Unido se están acercando a la fecha límite de marzo de 2022 para el cumplimiento y, como dije en un artículo anterior, en términos simples, se espera que la organización tenga:
- Sus servicios empresarial claves identificados
- Los umbrales de tolerancia para esos servicios empresarial claves identificados
- Comenzar a elaborar cómo podría probar esas tolerancias.
Los pongo simplemente porque cada uno de esos puntos puede explotar en un número gigantesco de páginas. Sin embargo, diré esto:
¿Sabemos por qué existimos? La forma en que la organización decide lo que es importante es extraña de considerar. Esto se debe principalmente a que es más difícil de hacer de lo que la gente podría imaginar, pero aún así es muy posible.
Como ejemplo, PwC ha cubierto ampliamente el desarrollo de la resiliencia operativa en los últimos años. Publicaron un documento corto pero realmente útil sobre cómo definir ampliamente sus servicios empresarial claves. Discute cómo el proceso de identificación se dejará a las organizaciones como una «cuestión de juicio». El documento también señala una trampa potencial en la que uno podría caer al no diferenciar entre un servicio interno, un servicio comercial y un proceso transversal.
El gerente de continuidad del negocio, por ejemplo, apuntaría inmediatamente al análisis de impacto en el negocio (BIA) porque enumera todas las funciones que, si se interrumpen, afectarían a la organización y / o al cliente. Creo que el BIA debería usarse como un punto de datos clave, pero no debería usarse para decidir exclusivamente sobre un servicio clave del negocio. El servicio empresarial clave tiene que ser un resultado tangible para un participante identificable. Creo que el BIA por sí solo confundiría el proceso de identificación. Escribí sobre esto brevemente en mi artículo de BCI sobre el documento del Banco de Inglaterra para la resiliencia operativa.
Uno podría pensar que decidir qué es un servicio empresarial clave debería ser bastante intuitivo, ¿no? Digo esto porque seguramente constituyen las razones clave por las que existe la organización. Si no proporcionamos x a y, entonces estamos fuera del juego (eventualmente). Tal vez estoy simplificando demasiado, pero supongamos que los bancos ya han descubierto esto.
Conocemos nuestros umbrales y puntos débiles – en términos generales, y a un nivel muy simplificado, la historia de la organización, la dirección estratégica, las finanzas y algunos de los incidentes / cuasi accidentes que pueden haber ocurrido pueden ayudar a dar una idea vaga de las tolerancias que podrían definirse.
Las regulaciones del Banco de Inglaterra están buscando puntos de datos, es decir, número de clientes afectados, volúmenes de transacciones interrumpidas, etc. Cada organización tendrá que trazar una línea en la que piensen que podrían tolerar cada uno de estos tipos de métricas antes de que se vuelvan inviables.
De todos modos, con el que estoy teniendo problemas en este momento es ¿cómo se prueban esas tolerancias?
Pruébalo…
De acuerdo, su organización ha definido sus procesos empresarial claves y ha establecido tolerancias con ellos. Tienes una justificación sólida y documentada para explicar cómo llegaste a esas decisiones. ¿Ahora está buscando demostrar que las tolerancias son correctas probándolas contra escenarios severos pero plausibles?
¡Aquí es donde corro el riesgo de emocionarme y tratar de desarrollar algún tipo de máquina de escenario híbrida, de siguiente nivel, entre dominios y basada en datos! Creo que necesito aprender a caminar antes de poder correr…
Palabra clave – madurez
No nos adelantemos, la normativa quiere que empecemos por esto con vistas a madurarlo con el tiempo. La realidad es que, como ya he mencionado anteriormente, ya probamos y hacemos ejercicio en muchas cosas.
¿Es esto más un ejercicio de mapeo y unificación que un nuevo requisito?
BC Managers – ¡Ensambla! *
*¡Dicho con mi mejor voz de Marvel!
Creo que este es un espacio (y una oportunidad) para que el programa de pruebas y ejercicios del gerente de continuidad del negocio realmente ayude a satisfacer las necesidades de este nuevo requisito. Un ejercicio de escritorio, por ejemplo, ya es un evento incrustado que el liderazgo entiende que debe hacerse (les guste o no). La mayoría de las organizaciones lo tienen en su cultura, por lo que la parte difícil está hecha. Ya tiene una medida para facilitar los requisitos.
Sin embargo, se podría argumentar que el enfoque actual de los ejercicios de escritorio no cubre completamente la pregunta del examen. ¿Su evento de medio día / dos horas con liderazgo una vez al año realmente cubre fallas específicas impulsadas por datos, como pérdidas de transacciones hasta un punto específico de inviabilidad? Si lo hace, entonces bien hecho: pero no he visto esto hecho en ninguna medida madura.
Para los propósitos de este artículo, me senté y traté de pensar qué podría adaptarse dentro de lo que entiendo que es el programa de pruebas y ejercicios del gerente de continuidad del negocio. Desde mi experiencia, realizar un ejercicio es lo suficientemente difícil logísticamente, ¡sin mencionar el tema de la aceptación! Dicho esto, logré sacar algunos pensamientos:
- Los puntos de datos de tolerancia deben estar entretejidos en el tejido del ejercicio (y documentados) para que pueda demostrar que al menos está tratando de cumplir con el requisito. No lo lograrán con respuestas teóricas amplias a escenarios de incidentes de alto nivel. Aquí para mí es donde se va a llevar a cabo el trabajo para madurar.
- Reduzca el escenario al contexto de la organización y a la tolerancia específica. Las organizaciones complejas deben tener en cuenta los objetivos estratégicos del sector / brazo de servicio / jurisdicción / etc.
- Como sugieren las regulaciones, inicialmente adopte un enfoque basado en el riesgo para los escenarios más severos pero plausibles que podrían llevarlo a las tolerancias de mayor impacto más rápidamente.
Observaciones finales
En última instancia, este elemento específico del requisito aún se está resolviendo. Los reguladores están dejando que las organizaciones comiencen. Yo diría que ya hacemos mucho de esto y, como mencioné anteriormente:
- Esto se siente más como un ejercicio de mapeo y unificación para que los puntos de datos clave se entretejan en la estructura del ejercicio de escritorio.
- El programa de pruebas y ejercicios del gerente de continuidad del negocio está en una posición ideal para facilitar y madurar frente a este requisito.
El autor
Luke Bird FBCI CRISC es un profesional global galardonado de continuidad y resiliencia con 12 años de experiencia en gestión de riesgos en el sector público y servicios financieros. Actualmente se está centrando en la tecnología. Lea el blog de Luke en https://resiliencerewire.co.uk
Tolerance testing for operational resilience: what’s the scenario? (continuitycentral.com)