En este artículo se analiza qué cambió en la saga de estándares ISO 27002 respecto de la continuidad de negocio.

Introducción

En este artículo se aborda el posible solape entre 2 disciplinas bastante relacionadas entre sí, aunque cada una con su área específica: la seguridad de la información y la continuidad de negocio. En particular, se analiza el grado en que los 2 estándares de referencia (ISO 27001 e ISO 22301) están, o no, solapados.

En un artículo aparte trataré las áreas de confluencia de ambos mundos y cómo puede llevarse a cabo la implantación de ambos estándares sin caer en redundancias innecesarias.

La razón de escribir este artículo se debe a que, en no pocas ocasiones, me han manifestado cosas como:

• “Si tengo un SGSI certificado, entonces ya tengo continuidad de negocio”
• “Para que una organización cumpla con los controles del capítulo 17 de la ISO 27002, basta con que tenga hecho un BIA y disponga de un DRP”

[Read more…]

En el post anterior, se nos ponía en contexto sobre la importancia de la realización de pruebas tras el diseño e implementación de un Plan de Continuidad de Negocio (en adelante, PCN).

Pero ¿en serio es tan importante la realización de pruebas? Pensamientos como éste pueden ser comunes: “Hemos pasado meses planificando y diseñando el PCN, involucrando a personal de distintas áreas de la organización y contando con la ayuda de expertos en la materia, ¿cómo va a fallar? Es posible que haya que probarlo dentro de un tiempo, pero de momento vamos a dejarnos de jaleos”. Me gustaría matizar que ese “tiempo” suele traducirse en años.
[Read more…]

En el pasado hemos hablado en diferentes ocasiones de Continuidad de Negocio. Concretamente, hemos tratado de los aspectos a tener en cuenta al abordar un proyecto de Continuidad de Negocio, de la valoración de tiempos en el Análisis de Impacto sobre el Negocio (I y II) y hemos comentado (y dejado a medias) por qué son necesarias las pruebas de continuidad de negocio. En general, siempre en el ámbito tecnológico, es decir en el marco de los Planes de Contingencia TIC.

Sin embargo, desde hace un tiempo, a medida que tomo parte en diferentes proyectos y accedo a foros “especializados”, empiezo a tener la sensación de que poca gente tiene una concepción clara de cómo es (o debe ser) un Plan de Continuidad de Negocio, un Plan de Recuperación ante Desastres, un Plan de Contingencia TIC o como quieran ustedes llamarlo. Por ello, entrar a tratar en cierta profundidad los factores que intervienen en los cálculos del BIA es como explicar métodos de optimización de código a alguien que apenas sabe cómo programar. Dicho esto, vamos a comenzar por el principio y a lo largo de una serie de entradas veremos si hemos aclarado algo.

La denominación es nuestro primer escollo. Plan de Continuidad de Negocio, Plan de Continuidad de Negocio TIC, Plan de Contingencias, Plan de Recuperación ante Desastres, y alguna denominación más que seguramente se me ha escapado. Aunque esto no es una ciencia exacta, podemos distinguir básicamente tres niveles, donde cada uno de ellos es una limitación del alcance del superior.

En el nivel superior tenemos el padre de todos ellos, el Plan de Continuidad de Negocio (PCN). Éste es el marco común para la continuidad de una organización desde múltiples perspectivas: infraestructura TIC, recursos humanos, mobiliario, sistemas de comunicación, logística, sistemas industriales, infraestructuras físicas, etc. A su vez, cada una de esas dimensiones de una organización tendrá su propio plan de continuidad, que se referenciarán desde el PCN. Si se hunde la zona de carga y descarga de la compañía, habrá que activar unos planes y no otros. Si se inunda el CPD, habrá que activar unos planes y otros sólo parcialmente. Y así, el resto. Nótese que un Plan de Continuidad de Negocio que abarque todas las posibles contingencias es un proyecto multidisciplinar en el que se evalúan no sólo sistemas, sino también infraestructuras físicas, transporte, ubicaciones físicas para el personal, etc. Por lo habitual, únicamente grandes multinacionales requieren disponer de este tipo de planes.

En el segundo nivel tenemos el Plan de Continuidad TIC o el Plan de Contingencia TIC (que llamaremos PCTIC), que no es otra cosa que el Plan de Continuidad de Negocio específico de los Sistemas de Información. Es decir, es sólo uno de los múltiples planes que veíamos anteriormente y con frecuencia el que se implementa, ya sea por la dependencia que existe en las empresas de los sistemas de información, por el coste, o por cualquiera otras razones. En este caso, mientras que un PCN evalúa todos los elementos implicados en una potencial contingencia desde múltiples perspectivas, un PCTIC se limita al ámbito tecnológico (a lo sumo, podría extenderse a la disponibilidad del personal técnico).

Sea por ejemplo una empresa cuyo negocio es la mensajería, y cuyo proceso crítico es la entrega de paquetes. Mientras que un PCN debe evaluar todos los aspectos que pueden afectar y garantizar la continuidad de dicho proceso ante una crisis, tales como infraestructura TIC, transporte, recursos humanos, proveedores, suministros o rutas de entrega, etc., un PCTIC sólo garantiza que los sistemas, aplicaciones, y dispositivos que dan soporte al proceso estarán disponibles dentro de los parámetros establecidos. Si luego hay un problema con los vehículos de reparto, eso es algo que no contempla el PCTIC.

Hay que tener en cuenta que aunque evidentemente el alcance de un PCN es por lo general superior al de un PCTIC (y más idéntico a medida que mayor presencia tiene la tecnología en los procesos), la profundidad del análisis vertical y las fases de su elaboración son básicamente las mismas. Tanto el PCN como el PCTIC presentan una fase de conocimiento de la organización, una fase de análisis, una fase de estrategias de recuperación, una fase de implementación y por último una fase de mantenimiento y prueba. Lo que cambia entre uno y otro principalmente son el tipo de procesos y recursos que se analizan, así como las soluciones ofrecidas.

Bien. Pasemos al tercer nivel. En este nos encontramos con una versión reducida del PCTIC, que suele denominarse Plan de Recuperación ante Desastres (que abreviaremos como PRD). Su principal diferencia con el PCTIC es que la fase de análisis suele ser menos profunda, limitando los interlocutores al personal técnico, y por tanto la elaboración, desarrollo e implementación de los aspectos más técnicos de la continuidad adquieren por comparación un mayor peso. Mientras que en el desarrollo de un PCTIC la fase de implementación va precedida de una fase de análisis importante en duración y relevancia, en un PRD esta fase es más liviana y por tanto los aspectos más prácticos entran en escena antes (nótese que en un PCTIC también se abordan).

Resumiendo, dentro del concepto de la continuidad de negocio podemos encontrar tres proyectos diferentes: (a) un Plan de Continuidad de Negocio, que abarca todas las perspectivas de la continuidad, (b) un Plan de Continuidad TIC, que se limita al ámbito TIC, y un (c) Plan de Recuperación ante Desastres, que se centra en los aspectos más relacionados con la implementación.

Evidentemente, el mundo en el que vivimos no es discreto sino continuo, por lo que en función de las necesidades de nuestra organización, podemos encontrarnos un PCTIC que contemple también la continuidad del personal, un PCTIC que se centre en la fase de análisis por haber sido ya definidas las estrategias de recuperación o un PRD con la documentación técnica en un estado muy avanzado de elaboración.

En el próximo post veremos las diferentes fases que se abordan en el desarrollo e implementación de un PCTIC y qué elementos contiene cada fase.

[Para más información, pueden contactar con mbenet [en] s2grupo.es. Sobre el autor]

Bien. Después de varias semanas o meses y un esfuerzo significativo, ya tenemos listo nuestro Plan de Continuidad de Negocio. Con su trabajo de campo, su Análisis de Riesgos y Análisis de Impacto sobre el Negocio, sus decisiones ejecutivas, estrategias de recuperación, Plan de Crisis y tal. Muchas horas de trabajo con sus respectivos cafés, colaboración más o menos voluntaria por parte de todos para obtener una serie de documentos y controles que reflejan la realidad de nuestra organización y la preparan para una contingencia que, afortunadamente, esperemos que no aparezca.

Y por suerte, el desastre no aparece. Pasan los meses y las cosas empiezan a cambiar: dos semanas después el responsable de mantenimiento cambia de teléfono móvil y a los seis meses se cambia el robot de copias y el software. Nueve meses más tarde, entra con impulso un nuevo técnico de comunicaciones y mejora significativamente la segmentación de la red. Un año después, se actualiza la aplicación que utiliza Recursos Humanos a la última versión y después de muchos dolores de cabeza conseguimos que todo funcione bien.

Hagamos algunas hipótesis.

Primero, seamos positivos. Además de todo lo descrito, nuestro Plan de Continuidad incluye un Plan de Mantenimiento que, adecuadamente, describe las circunstancias y condiciones en las que cada uno de los documentos, especialmente los ejecutivos, tienen que ser actualizados: cambio de infraestructura, actualizaciones, cambio de personal, etc. Y de acuerdo a éste, el Plan de Continuidad ha ido evolucionando de manera adecuada, reflejando todos y cada uno de los cambios.

Seamos un poco más negativos. Incluya nuestro Plan de Continuidad o no un Plan de Mantenimiento, lo cierto es que en escasas ocasiones alguien se ha acordado de actualizarlo. En general, sigue contemplando la realidad de la organización, aunque cada vez un poco menos. La aplicación de Recursos Humanos ya no es la versión que pone en la documentación, el software de copias tampoco y las competencias en materia de comunicaciones han cambiado, entre otras cosas.

Así que un buen día, sin avisar ni concertar cita previa, el desastre se presenta. Una tubería que pasa por encima de una sala que antes no era un CPD pero ahora sí lo es se rompe y provoca un cortocircuito que echa a perder un puñado de servidores, alguna placa base y el cuadro eléctrico del CPD. ¿Tiempo de resolución estimado? No tengo ni idea, pero menos de tres días no va a ser, contesta el de industrial. Parece que además del cuadro eléctrico, el SAI también está tocado y el proveedor dice que tiene que traer un rectificador del otro lado del mundo porque esa pieza no la tiene en España. Dado que 72 horas es mucho más de lo que cualquier proceso crítico es capaz de tolerar, es hora de poner en marcha nuestro Plan de Continuidad de Negocio.

Volvamos a nuestras hipótesis.

Primero, seamos positivos. Durante estos meses hemos realizado las respectivas pruebas de continuidad y aunque algo puede haber cambiado, lo cierto es que conocemos los problemas que surgen al utilizar un direccionamiento diferente en la aplicación de Recursos Humanos, el proveedor no nos mira con cara rara cuando le hablamos de desastre, y los usuarios tienen una idea aproximada de qué es lo que tienen que hacer. Bien por nosotros.

Segundo, un caso un poco más negativo. Aunque hemos actualizado el Plan de Continuidad de manera regular, lo cierto es que no se ha hecho ninguna prueba, ya sea por falta de tiempo, recursos o por confiar equivocadamente en que si está actualizado, no es necesario probarlo. Así que cuando llega el momento, todo está en su sitio, pero la base de datos de copias del nuevo sistema no podemos restaurarla hasta que no se ha instalado la aplicación, pero ésta no encuentra la base de datos y no se deja instalar y en eso perdemos tres horas. Y después, la recuperación no va a la velocidad que se esperaba, y perdemos otras dos. Al final, sí, todo recuperado, pero en un tiempo mayor del esperado.

Tercero, la joya de la corona. Imagínense. El Plan de Continuidad lleva guardado año y pico acumulando polvo. Ni se ha actualizado, ni se ha probado, ni siquiera se ha utilizado como papel reciclado. El caso es que al tipo de mantenimiento no lo localiza ni CSI, la aplicación de recursos humanos se reinstala desde cero… con la versión antigua, que como Murphy podría adelantar no es compatible con la actual y la base de datos no se puede restaurar (ni por tanto localizar el teléfono del de mantenimiento). El switch de backup que se suponía que debía servir para una posible contingencia (o eso pensábamos) se utilizó para poner en marcha la nueva segmentación, y en su lugar alguien decidió dejar un hub que sólo da pena. Cuando llamas al proveedor del sistema eléctrico, a la palabra “desastre” le sigue un silencio eterno por su parte y los usuarios se miran unos a otros como si el tema ni fuese con ellos y preguntan cuándo se va a arreglar. Y alguien se empieza a poner nervioso.

Tras estos escenarios, hagan un repaso mental y piensen cuál es su situación. En próximas entradas veremos las ventajas de llevar a cabo las pruebas de continuidad (aunque a la vista de lo anterior debería ser obvio) y entraremos a comentar los diferentes tipos de pruebas que se pueden realizar para que nadie se ponga más nervioso de lo necesario en una contingencia.

[Sobre el autor]

Seguimos con continuidad de negocio. Hace unos días estuvimos viendo, con cierto nivel de detalle (quizá demasiado para aquellos más interesados en una guía rápida más orientada al how-to), algunos aspectos sobre los elementos que forman los tiempos de recuperación y la importancia que tiene el tipo de actividad que estemos analizando. Pasando a otros temas más prácticos, hoy me gustaría repasar algunos puntos a tener en cuenta durante la realización de un Plan de Continuidad de Negocio, que considero vitales para llegar a buen puerto: alcance, contar con el apoyo de Dirección, tener en cuenta la posible necesidad de inversión, y cómo determinar los tiempos de recuperación objetivo.

Alcance

El primer aspecto que debemos tener en cuenta es el alcance de nuestro Plan de Continuidad de Negocio (PCN), en dos aspectos diferentes. Por un lado, en un sentido de horizontalidad; es necesario definir claramente qué servicios, actividades o procesos van a estar incluidos en el PCN, si además tenemos la intención de certificar el sistema según la ISO 22301; aunque desde un punto de vista de utilidad de un PCN lo más lógico es intentar que el alcance cubra toda la organización, especialmente en empresas de reducido tamaño donde la infraestructura se comparte, también cabe la posibilidad de escoger un alcance reducido que cubra elementos relativamente independientes (una división geográfica o la matriz organizativa de la empresa, por ejemplo) o simplemente aquellos procesos que de antemano ya se sabe que son los más críticos para la continuidad de la organización, como podría ser la producción o logística en una empresa de carácter más industrial, o el portal web en una empresa puramente de comercio electrónico.

[Read more…]

El pasado miércoles vimos algunas reflexiones, más teóricas que prácticas, todo sea dicho, sobre la importancia no sólo de conocer los tiempos límite de recuperación de cada actividad, sino de saber, en la medida de lo posible, cómo éstas se comportan tras el momento crítico, lo que puede determinar el margen de error tolerable al determinar los tiempos (que no olvidemos que están determinados por el impacto máximo tolerable) y la irreversibilidad del incidente una vez superado el tiempo límite de recuperación (sin que ésta se produzca).

Para complicar un poco más el asunto, hoy veremos que el tiempo límite de recuperación puede estar formado por más de un elemento, e introduciremos las variables habituales al definir un BIA. En entradas siguientes pondremos algunos ejemplos y veremos otros aspectos interesantes en la definición del BIA.

Para empezar, debemos descartar la idea de que para determinar el tiempo requerido de recuperación de una actividad, que (repetimos) viene a ser el tiempo máximo que puede estar interrumpida una actividad, la actividad tenga que estar totalmente recuperada. Aunque por simplicidad y rapidez es habitual considerar tasas de actividad del 100% para determinar los tiempos, lo cierto es que no necesariamente es así: estos tiempos estarán ligados a los niveles de funcionamiento mínimos que previamente haya definido la organización, y éstos a su vez con el impacto que el no-funcionamiento parcial (o total, si la recuperación estimada es total) de dicha actividad tiene sobre la organización.

Por ejemplo, una organización puede establecer que en las horas posteriores a una crisis no es necesario poner en marcha el 100% de la producción, sino que con llegar a una tasa de actividad del 40% en menos de 8 horas puede ser suficiente para garantizar la viabilidad de la empresa durante unos días más mientras otros procesos se recuperan; por tanto, el impacto no asumible del proceso de producción está ligado a dos variables: una tasa de actividad del 40% y un tiempo de recuperación de 8 horas.

Por tanto, el tiempo de recuperación no tiene porqué necesariamente ser el tiempo que transcurre desde la interrupción de la actividad hasta la recuperación total, sino que debe tomarse como el tiempo que transcurre desde la interrupción hasta que la actividad se recupera en los niveles establecidos por la organización, que en ocasiones será menos exigente para la organización y los recursos en los que descansa la actividad. Claro que ojalá fuese tan sencillo, porque a menudo seremos incapaces de determinar umbrales parciales de funcionamiento, y acabará siendo un todo o nada; no obstante, ya veremos eso más adelante. Para aquellos aficionados a las siglas, este nivel mínimo de funcionamiento puede encontrarse en la bibliografía bajo diversas siglas, tales como LBC, Level of Business Continuity, ROL, Revised Objective Level; en la ISO 22301 aparece como MBCO, Minimum Business Continuity Objective, aunque no tengo del todo claro si la ISO lo entiende como un parámetro específico de cada actividad o es un valor global de la organización que determina la continuidad de ésta en base al estado de sus procesos de negocio claves (aunque esto último no tiene demasiado sentido si asumimos que la continuidad de la organización está determinada por la continuidad de todos sus procesos clave y no por la continuidad de un porcentaje dado de éstos).

Resumiendo, el tiempo requerido de recuperación de una actividad será el tiempo máximo que puede transcurrir para que el impacto del funcionamiento de la actividad por debajo de los umbrales “tolerables” no ponga en riesgo la continuidad de la organización.

Tampoco hay que perder de vista que la puesta en marcha de una actividad estará en general compuesta por una “fase TIC” (puesta en marcha de entornos, entrada de elementos de respaldo, recuperación de copias de backup, sustitución de equipos, etc.) y una “fase de negocio” (consolidación de datos, verificación de integridad, introducción de información recogida manualmente durante la interrupción, etc.). Es decir, que el tiempo máximo de parada de la actividad (MTPD o maximum tolerable period of disruption, encontrado en la bibliografía habitualmente también como MTD) estará compuesto por un tiempo de recuperación objetivo (RTO o recovery time objective), parámetro habitualmente de carácter técnico, más un periodo de normalización de las actividades en el que el personal responsable de la actividad comienza a funcionar. Si al determinar los tiempos únicamente tenemos en cuenta los requisitos de recuperación técnicos, es muy probable que excedamos los tiempos máximos marcados, y en algunos casos la desviación pueden ser muy significativa.

En este sentido la ISO 22301 parece menos exigente que la BS 25999-2 en los aspectos que debe contener el BIA. Entre otros, la BS requiere identificar no sólo el tiempo hasta alcanzar los niveles mínimos de servicio, sino también el tiempo máximo que puede transcurrir hasta que los niveles normales de funcionamiento se recuperan, además de requerir que se explicite ese umbral mínimo de funcionamiento de la actividad. La ISO 22301 parece conformarse con los niveles que garantizan la continuidad, dejando fuera de consideración el tiempo hasta los niveles normales de funcionamiento. Por desgracia, esto no simplifica tanto las cosas; volviendo al ejemplo anterior, podemos salvar el primer hito y ser capaces de llegar a una tasa de producción del 40% en menos de 8 horas, pero es posible que la organización no pueda tolerar una tasa de producción inferior 50% durante más de dos semanas. Además, podrían existir otros hitos posteriores que no podamos cumplir: por ejemplo un nivel de funcionamiento de la actividad al 80% durante más de un mes puede seguir teniendo un impacto grave sobre la continuidad de la organización.

Para cada actividad, por tanto, podremos tener no una única tupla <tiempo de recuperación, nivel de funcionamiento de la actividad> cuyo incumplimiento tenga un impacto grave sobre la continuidad de la organización, sino también un conjunto de tuplas que recorrerán el nivel de funcionamiento de la actividad desde la tasa de actividad mínima imprescindible (40% en nuestro caso) hasta el 100%, estableciendo para cada uno de ellos en cuánto tiempo como máximo debemos alcanzar dicho nivel de funcionamiento de la actividad. Esto puede conducir a una gráfica como la indicada a continuación, donde existen cuatro hitos de funcionamiento que deben cumplirse, establecidos en el 40%, 50%, 60%, 80% y 100%, en unos tiempos máximos de 8 horas, 1 semana, 2 semanas, 1 mes y 1 mes y medio, respectivamente (naturalmente, la evolución entre hitos no tiene porque seguir una línea recta, sino que puede tomar otras formas). Nótese que la variable impacto no aparece en la gráfico al mantenerse constante.

Afortunadamente, este no es el caso común, ya que incorpora un nivel de complejidad no desdeñable y si resulta de por sí complicado establecer un porcentaje mínimo para el caso inicial (post-crisis), determinar porcentajes ulteriores es algo sólo para organizaciones con sistemas de gestión de la continuidad muy maduros y con criterios de actividad que permitan fácilmente establecer dichos porcentajes.

Veamos un ejemplo adicional que resume los parámetros vistos hasta ahora. En la imagen inferior, la organización ha determinado que el nivel mínimo de servicio para la actividad “A” es del 50%. Es decir, mientras la actividad se mantenga por debajo de este valor, existe riesgo para la continuidad de la organización.

La imagen muestra que a las 4h comienza la degradación de la actividad “A” (véase 1), alcanzando su parada total a las 5h. A las 10h la actividad se ha recuperado un 10%, un 30% a las 12h y un 50% a las 14h, momento en el que se alcanza el nivel mínimo tolerable de funcionamiento de la actividad (véase 3). Como en este caso, si todo ha ido bien (y de no ser así la gráfica sería diferente), el tiempo transcurrido hasta entonces (véase 2) será menor que el MTPD; de lo contrario, si el análisis realizado es correcto, la organización se enfrenta a problemas de extrema gravedad que pueden poner en riesgo su continuidad. Los puntos 4 y 5 de la gráfica muestran el tiempo transcurrido hasta la vuelta a la situación normal y el momento en el que éste se produce (22h).

Nótese que, en el ejemplo mostrado, si el tiempo transcurrido hasta alcanzar el umbral mínimo de funcionamiento de la actividad (establecido en 50%) es mayor que el MTPD pero aun así “no pasa nada“, pueden haberse establecido tiempos demasiado restrictivos, lo que puede generar varios efectos indeseados. Por un lado, estamos trasladando una presión innecesaria a la organización y a los equipos de recuperación, que en aras de cumplir con los tiempos establecidos pueden reducir la calidad del servicio de otras actividades, o incluso detener actividades que no se consideren críticas, todo ello sin necesidad.

Por otro lado, pueden tomarse decisiones desencadenadas por una situación de crisis “menos grave de lo real”, que afecten a otras áreas o impliquen una pérdida de servicio o de datos adicional (conmutar con un centro de respaldo, recuperar de cinta, etc.). Por último, puede generarse un efecto “Pedro y el lobo”: si tras varios incidentes en los que sistemáticamente se superan los tiempos máximos no hay ninguna consecuencia, puede ocurrir que los equipos de recuperación se relajen y/o el plan de continuidad de negocio pierda su “autoridad”, lo que hará que no haya un referente temporal claro para la recuperación y que tarde o temprano la recuperación no cumpla los objetivos y entonces “sí pase algo”.

Por tanto, es de vital importancia que los tiempos y umbrales de actividad que contiene el BIA reflejen en la medida de lo posible la realidad, sin entrar en umbrales irracionales pero tampoco relajando demasiado la recuperación. Hay que tener en cuenta que determinar cuándo la parada de una actividad puede poner en riesgo grave la continuidad del negocio no es para nada una tarea fácil; no sería la primera vez que un responsable establece que la actividad X no puede estar detenida más de N horas y tras algunas averiguaciones sale a la luz que el mes pasado estuvo detenida N*2 horas por una caída del suministro eléctrico sin que hubiese ningún efecto.

Hasta aquí la teoría, que dentro de lo razonable resulta no excesivamente complicada. Ahora bien, entrados en faena, la cosa se complica y surgen diversas preguntas: ¿quién y cómo debe determinar los tiempos de recuperación? ¿Cómo (narices) se determina el umbral mínimo de recuperación de una actividad? ¿Cómo establecemos tiempos de recuperación razonables y realistas al mismo tiempo? ¿Qué relación deben tener los tiempos de recuperación con el Análisis de Riesgos?

En otro orden de cosas, ¿qué nivel de detalle debe contener cada actividad? ¿Cómo medimos los impactos de interrupción a través del tiempo y cómo se relacionan estos con el Análisis de Riesgos? ¿Qué debe considerarse como una dependencia?

Todo esto y algo más, en la siguiente entrada. Siéntanse libres de comentar, preguntar y rectificar.

[Sobre el autor]

Como seguramente sepan, desde hace poco más de un mes tenemos la suerte de contar con una nueva norma ISO relacionada con la Continuidad de Negocio, concretamente la norma ISO 22301:2012, Societal Security – Business continuity management systems – Requirements. Como ya pasó con la norma BS 7799 y la norma ISO 27001, y es que estos británicos en temas normativos nos sacan un cuerpo y dos cabezas a todos, esta nueva norma toma como referencia a la BS 25999:2, Specification, aunque introduce algunas diferencias que pueden ver en esta infografía del blog de Dejan Kosutic.

Tras esta norma, es de esperar que en algunos meses sea publicada la guía de implantación, la norma ISO/DIS 22313, Societal security – Business continuity management systems – Guidance, correspondiente a la norma BS 25999-1, Code of practice. Actualmente está en estado Under development, fase “Enquiry stage / Close of voting“. Teniendo en cuenta que a la ISO 22301 se le esperaba hace ya algunos meses, no sería raro que esta nueva norma se publique ya bien entrado el 2013; hasta entonces, siempre nos quedarán los británicos y su excelente BS 25999-1.

Tras esta no tan breve introducción, que sirve para poner en contexto, la intención de esta serie de entradas es arrojar algo de luz sobre la continuidad de negocio, para lo que vamos a comenzar en esta entrada saltándonos los preliminares (algo que suele ser una mala costumbre) y pasando directamente al Análisis de Impacto sobre el Negocio (Business Impact Analysis) o BIA, por sus siglas en inglés. Para ello me basaré en la ISO 22301 recientemente publicada y en la norma británica. Más adelante veremos otros aspectos de la continuidad de negocio, desde un resumen de todos los elementos de la norma a los aspectos destacables de cada uno de ellos, así como a la relación entre el BIA y el Análisis de Riesgos, que siempre he encontrado poco desarrollada. Vamos pues con el Análisis de Impacto sobre el Negocio.

Si leemos el punto 8.2.2 Business Impact Analysis de la ISO 22301, este indica (traducción libre y resumida) que la organización deberá establecer, implementar y mantener un proceso de evaluación formal y documentado para establecer las prioridades y objetivos (en el sentido de hitos y también de targets) de continuidad y recuperación, así como evaluar los impactos de aquellas actividades que pueden interferir sobre la continuidad de los procesos (disrupting activities según la norma). Para cada actividad, el BIA deberá contener (al menos):

En definitiva, el principal resultado que debemos obtener tras la elaboración del BIA es un listado de procesos de negocio priorizados según sus tiempos requeridos de recuperación, los impactos de su interrupción y con las dependencias relevantes de otros elementos internos o externos a la organización. Vamos hoy con los tiempos, punto c) de la lista anterior.

Entenderemos el tiempo requerido de recuperación como aquel a partir del cual la interrupción de la actividad tiene un impacto grave para la continuidad del negocio. Como veremos a continuación, la relación entre el impacto y el tiempo sigue en general un modelo donde existe una fase inicial lineal con un punto en el que el impacto se incrementa de manera brusca. Aunque uno puede tender a pensar que este punto debe corresponderse con el impacto máximo tolerable, en realidad no es así y el punto crítico puede situarse en la fase de correspondencia lineal. Veamos un par de ejemplos.

En primer lugar tenemos el ejemplo de un proceso de inyección de plásticos; en caso de parada de una línea de inyección (por un problema de suministro eléctrico, incidencia mecánica, etc.) se dispone de un tiempo limitado para volver al funcionamiento normal antes de que el plástico se endurezca; si la incidencia se resuelve antes de que las toberas se obstruyan, el impacto es lineal: una pérdida de producción dependiente del tiempo. Pero si el tiempo de la parada es suficiente para que el plástico se endurezca, esto obligaría a una parada total para proceder a la limpieza de las toberas antes de retomar la actividad con normalidad, que forzaría una parada mayor incluso después de haberse restablecido las condiciones normales de operación.

En el otro caso tendríamos un almacén de expedición; si en una hora salen 10 unidades, podemos asumir que el impacto tras X horas de parada es 10*X, y esa relación puede mantenerse lineal durante mucho tiempo (no obstante, llegará un momento en el que la parada del proceso comienza a afectar a otras áreas de la organización y la relación tiempo/impacto comenzará a variar).

Veamos ahora un par de gráficas. En la primera, el impacto límite es de 50.000 €. Como podemos ver, la actividad 3, con un ratio de empeoramiento muy superior al de las otras actividades, alcanza dicho punto aproximadamente a las 15 horas del incidente, mientras que las actividades 1 y 2 lo hacen a las 55 horas y 35 horas respectivamente.

Aparentemente, a la vista de la curva la actividad 3 se consideraría más crítica que las actividades 1 y 2, dado que alcanza el punto crítico mucho antes. No obstante, si asumimos ahora un impacto grave mucho menor, en torno a 7.000 €, la situación cambia como podemos observar en la siguiente gráfica. A pesar de que la curva de la actividad 3 tiene un ratio de empeoramiento superior al de la actividad 2, ésta, siguiendo un modelo mucho más lineal, alcanza el punto crítico una hora antes y de hecho durante las 8 primeras horas el impacto de la interrupción de la actividad 2 es superior al de la actividad 3.

Por tanto, la evolución de una actividad interrumpida vendrá determinada por dos características: una fase inicial en la que la relación se mantiene cercana a un modelo lineal, seguida de un modelo más similar a una curva exponencial que representa la aceleración del impacto, seguida por una fase final de estabilización. Este modelo corresponde a la curva logística y podemos reinterpretar las gráficas anteriores, es decir, cada tipo de evolución frente a contigencias, como resultado de una mera cuestión de escala.

A partir de esto, la criticidad de una actividad vendrá determinada por lo rápido que ésta alcance el impacto crítico con independencia del modelo que siga. No obstante, el modelo tiene gran importancia ya que determina tanto la respuesta que se debe prever ante una contingencia como el margen de error tolerable al establecer los tiempos de recuperación objetivo. Por ejemplo, tomemos la segunda gráfica vista anteriormente. Aunque el impacto crítico (7.000 €) se alcanza antes cuando la actividad 2 se detiene que cuando lo hace la actividad 3 y por tanto la actividad 2 debe considerarse más crítica que la actividad 3, un error o retraso en la aplicación de las medidas de resolución de la contingencia puede tener efectos muy diferentes en uno y otro caso. En el caso de la actividad 2, teóricamente más crítica, un retraso de 5 horas en la recuperación de la actividad tendría un impacto adicional de 6.000 €, mientras que si esto sucede en la actividad 3, el impacto sería de 25.000 €.

De la misma manera, si el impacto crítico ha sido sobreestimado y es en realidad de 11.000 €, la actividad 3, teóricamente menos crítica, alcanzará ese impacto sólo 1 hora después que en el caso inicial cuando el impacto era de 7.000 €, mientras que la actividad 2, en principio más crítica, lo alcanzará 3 horas después.

Es por tanto de vital importancia conocer no sólo el punto crítico, sino en qué medida evoluciona un proceso o actividad tras una contingencia.

Espero que les haya parecido interesante; siéntanse libres de preguntar, rectificar o comentar. En la siguiente entrada continuaremos hablando de los otros aspectos temporales a tener en cuenta en la elaboración del BIA.

(Gracias a Óscar Navarro por su ayuda con los ejemplos de entornos industriales y su colaboración en otros puntos de la entrada)

[Sobre el autor]

Como seguramente recuerden, el pasado 12 de mayo tuvo lugar una jornada en la que participamos junto con AENOR y Tecnofor, titulada El papel de los Sistemas de Gestión en las TIC. Durante las próximas semanas iremos incluyendo en el blog las presentaciones que tuvieron lugar. Por una simple cuestión de orgullo, comenzaremos con la mía, que versaba sobre la Continuidad de Negocio, desde el punto de vista de la UNE 71599 / BS 25999. Aunque se pierden los chistes y mi vis cómica, espero que les guste la presentación.

Pueden descargar esta y el resto de presentaciones desde la página de descargas de la jornada.