BIA (Business Impact Analysis)
El Business Impact Analysis (BIA), o análisis de impacto en el negocio, responde a una sola pregunta con muchas consecuencias: cuánto duele, y a partir de qué hora, que cada proceso de la empresa deje de funcionar. De ahí salen el orden en que hay que recuperar las cosas y los plazos que ese orden tiene que cumplir.
Qué pregunta responde un BIA
Un análisis de impacto en el negocio no mide amenazas ni probabilidades. Eso es el análisis de riesgos, que es otro ejercicio y responde a otra pregunta. El BIA da por hecho que la interrupción ocurre y mide sus consecuencias: qué se para, a quién afecta, cuánto se puede aguantar así y cuánto cuesta cada hora que pasa.
La distinción es útil porque cambia con quién se hace. Un análisis de riesgos se puede sostener casi entero desde el departamento técnico. Un BIA no: quien sabe cuánto cuesta que la facturación esté doce horas parada es finanzas, y quien sabe qué clientes se van si el portal no responde es negocio. Un BIA hecho solo por sistemas acaba ordenando los servidores por lo caros que fueron.
Y su salida no es un informe para archivar: es una lista ordenada. Cuando todo está caído a la vez, alguien tiene que decidir qué se levanta primero, y esa decisión se toma mucho mejor en frío que a las tres de la madrugada.
Los cinco pasos del análisis
Identificar las actividades críticas. No los sistemas, las actividades: cobrar, atender a un cliente, fabricar, pagar nóminas. Los sistemas vienen después, cuando se pregunta de qué depende cada actividad. Empezar por el inventario técnico es el error más común, y produce una lista de máquinas sin prioridad.
Trazar las dependencias. Qué necesita cada actividad para funcionar: aplicaciones, datos, proveedores, personas concretas, una línea de comunicaciones. Aquí es donde aparecen las sorpresas, porque casi siempre hay una pieza compartida de la que cuelga media empresa y que nadie tenía en su lista. Un inventario de activos al día ahorra la mitad de este paso.
Estimar cuánto se aguanta. Cada actividad tiene un punto a partir del cual el daño deja de crecer poco a poco y pega un salto: se incumple un plazo legal, se pierde el cliente, se para la línea de producción. Ese punto es lo que hay que buscar, y no es el mismo para dos actividades de la misma empresa.
Cuantificar la pérdida. Ingresos que no entran, costes de recuperación, penalizaciones contractuales, sanciones y daño reputacional. Lo reputacional no se puede poner en un número honesto, así que se declara aparte en vez de inventarle una cifra.
Priorizar con eso delante. El resultado es el orden de recuperación y el presupuesto que justifica: qué merece una réplica caliente, qué merece una copia inmutable y qué puede esperar dos días sin que pase nada grave.
RTO y RPO: los dos números que salen de aquí
El RTO (Recovery Time Objective) es cuánto tiempo puede estar caída una actividad antes de que el daño sea inaceptable. El RPO (Recovery Point Objective) es cuántos datos se puede permitir perder, medido en tiempo: un RPO de una hora significa que se acepta volver al estado de hace una hora.
Los dos son decisiones de negocio, no capacidades técnicas. Es habitual descubrir en un BIA que el RTO que la dirección da por supuesto es de minutos y que la arquitectura contratada da horas. Esa distancia es el hallazgo, y encontrarla en una reunión es infinitamente más barato que encontrarla durante un incidente.
El RPO además decide cómo tienen que ser las copias de seguridad: su frecuencia, dónde viven y con qué se restauran. Una copia que se hace todas las noches no puede cumplir un RPO de una hora por mucho que se prometa en una diapositiva.
Por qué el BIA dejó de ser solo un asunto de continuidad
Se escribió pensando en incendios, inundaciones y caídas de suministro. Lo que lo ha puesto en el centro de la ciberseguridad es el ransomware, porque produce exactamente el escenario que el BIA modela: todo parado a la vez, sin fecha de vuelta y con la copia de seguridad como única salida.
Y añade una condición que un desastre natural no tiene: el atacante ha estado dentro antes, así que las copias pueden estar cifradas o borradas también. Por eso el BIA moderno no pregunta solo cuánto se tarda en restaurar, sino desde dónde se restaura si el atacante tenía las credenciales de administración.
Un ataque de denegación de servicio distribuida plantea la misma pregunta en pequeño: nada se ha roto, pero nada responde. Si el BIA no ha puesto número a esa hora de indisponibilidad, la conversación sobre cuánto invertir en protegerla no tiene con qué compararse.
La conexión con la respuesta ante incidentes es directa: el BIA decide qué se recupera primero y el playbook dice cómo. Sin el primero, el segundo se improvisa por orden de quien más grite.
Dónde lo pide la normativa
ISO 27001 lo trata dentro de la continuidad de negocio: hay que determinar los requisitos de continuidad de la seguridad de la información, y determinarlos sin haber medido el impacto no se sostiene ante un auditor.
DORA es más explícita para el sector financiero: exige análisis de impacto en el negocio sobre escenarios de interrupción grave y que las pruebas de continuidad se hagan contra ellos. NIS2 va en la misma dirección para las entidades que cubre, y el ENS lo pide en el marco operacional para los sistemas de categoría alta.
Conviene decir la parte incómoda: un BIA hecho para pasar una auditoría y no para usarlo se nota enseguida, porque todas las actividades salen críticas y con el mismo plazo. Si todo es prioritario, no hay prioridad, y el documento no sirve para lo único que servía.
Un ejemplo: la entidad que descubre en qué orden recuperar
Una entidad financiera hace un BIA para un escenario de indisponibilidad total. Identifica tres actividades críticas: el procesamiento de transacciones, los servicios en línea para clientes y los sistemas de gestión de riesgos.
La intuición del equipo era que la banca en línea iba primero, porque es lo que el cliente ve. El análisis dice otra cosa: el procesamiento de transacciones tiene un plazo de recuperación mucho más corto, porque su parada incumple compromisos con terceros que no dependen del horario de atención. La banca en línea aguanta más de lo que parecía y la gestión de riesgos, que nadie había puesto en la lista, resulta ser lo que bloquea volver a operar con normalidad.
El resultado no es un número: es que el orden de recuperación cambia. Y cambia también en qué se gasta, porque solo la primera actividad justifica el coste de mantener una capacidad de recuperación en caliente. Las cifras de este ejemplo son ilustrativas y no salen de ningún cliente.
Qué aporta un pentesting a un BIA
El BIA dice qué sistemas no se pueden parar. Un pentesting orientado a ISO 27001 responde a la pregunta de al lado, que el BIA no se hace: si esos sistemas se pueden alcanzar, desde dónde y con qué esfuerzo.
Las dos respuestas juntas son las que permiten decidir. Un sistema crítico e inalcanzable y uno secundario expuesto a Internet no piden la misma inversión, y sin las dos medidas esa comparación se hace a ojo.