Cómo hacer un análisis de impacto en el negocio (BIA) según la ISO 22301

El análisis de impacto en el negocio —BIA, por Business Impact Analysis— es el ejercicio que determina qué pasaría en tu organización si un proceso se detuviera: cuánto dinero se pierde por hora o por día, qué obligaciones legales se incumplen, qué clientes se van y a partir de qué momento el daño deja de ser asumible. Su resultado es una lista priorizada de actividades con sus tiempos máximos de parada tolerables y los recursos mínimos para reanudarlas. Es la pieza central de un sistema de gestión de continuidad de negocio: sin BIA no se puede justificar ninguna decisión posterior, porque nadie sabe qué hay que recuperar primero ni cuánto se puede esperar.

Dentro de la ISO 22301, la norma certificable de continuidad de negocio, el BIA no es un anexo opcional: es un requisito. La norma exige que la organización disponga de un proceso documentado para analizar el impacto de las interrupciones y que las estrategias y planes de continuidad se construyan sobre sus resultados. En esta guía verás cómo hacerlo paso a paso, qué parámetros deben salir de él (MTPD, RTO, RPO y nivel mínimo de servicio) y los errores que más se repiten cuando una pyme lo aborda por primera vez.

Qué es exactamente un BIA (y qué no es)

Un BIA responde a tres preguntas, en este orden:

1. ¿Qué hace la organización? Qué productos y servicios entrega, y qué procesos internos los sostienen.
2. ¿Qué pasa si cada proceso se para? Cómo crece el daño con el tiempo: no es lo mismo una hora sin facturar que una semana sin servir pedidos.
3. ¿Qué necesita cada proceso para reanudarse? Personas, aplicaciones, datos, proveedores, instalaciones y equipos, y en qué cantidad mínima.

Conviene distinguirlo de dos ejercicios con los que se confunde constantemente:

• No es una evaluación de riesgos. El análisis de riesgos estudia las causas (qué amenazas existen, con qué probabilidad); el BIA estudia las consecuencias de la interrupción, sea cual sea su causa: un ransomware, un incendio o la caída de un proveedor producen el mismo efecto sobre el proceso —está parado— y el BIA ya ha medido qué supone eso. La ISO 22301 pide las dos cosas; si gestionas riesgos con el enfoque de la ISO 31000, el BIA encaja como la mitad «de consecuencias» de ese trabajo.
• No es el plan de continuidad. El BIA es diagnóstico; el plan es tratamiento. Del BIA salen las prioridades y los objetivos de recuperación; el plan de continuidad de negocio define quién hace qué, cómo y con qué medios para cumplirlos.

Un matiz honesto: como toda norma ISO, el texto de la 22301 no es público —se adquiere en ISO o, en versión española, en AENOR—, así que lo que sigue es una explicación funcional de lo que exige y de cómo se aplica en la práctica, no una reproducción de su articulado. Existe además una especificación técnica dedicada en exclusiva al BIA, la ISO/TS 22317, que no es certificable pero sirve de manual de método para quien quiera profundizar.

El papel del BIA dentro de la ISO 22301

En el conjunto de normas ISO certificables, la 22301 sigue la estructura común de los sistemas de gestión: contexto, liderazgo, planificación, soporte, operación, evaluación y mejora. El BIA vive en el bloque operativo, y es la bisagra entre la parte «de despacho» del sistema y la parte que de verdad protege el negocio:

• Aguas arriba, el BIA hereda del análisis de contexto: qué productos y servicios son relevantes, qué esperan clientes, reguladores y otras partes interesadas, y qué alcance tiene el sistema.
• Aguas abajo, todo depende de él: la selección de estrategias de continuidad (¿centro alternativo? ¿trabajo en remoto? ¿proveedor de respaldo?), los planes de respuesta, los recursos que se contratan y hasta el programa de pruebas. Cuando el auditor de certificación revisa un sistema 22301, una de las primeras comprobaciones de fondo es la trazabilidad: que cada estrategia y cada plan se justifiquen en un resultado concreto del BIA, y no al revés.

Esto tiene una consecuencia práctica: un BIA flojo invalida todo lo que se construye encima. Si los tiempos de recuperación se fijaron «a ojo», la organización estará pagando de más por proteger procesos que podían esperar, o descubierta en procesos que no pueden.

Los cuatro parámetros que salen de un BIA

El producto final del BIA se resume en cuatro parámetros por cada proceso o actividad. Merece la pena fijarlos bien, porque son el vocabulario de todo lo que viene después:

Dos reglas de coherencia que los auditores miran siempre:

• El RTO debe ser menor que el MTPD. El RTO es el objetivo que te pones; el MTPD es el muro. Si tu proceso de facturación tiene un MTPD de 5 días, un RTO de 5 días no deja margen para que algo salga mal: lo razonable es fijarlo en 2 o 3.
• El RPO manda sobre las copias de seguridad. Si declaras que solo puedes perder 4 horas de datos de pedidos, tu sistema de copias tiene que ejecutarse al menos cada 4 horas. Un RPO de 4 horas con copia diaria es una contradicción documentada que cualquier auditoría detecta.

Cómo se hace un BIA, paso a paso

El método cabe en cinco pasos. Ninguno es opcional y el orden no es negociable: cada uno se alimenta del anterior, así que saltarse el inventario para empezar por las entrevistas es la forma más rápida de tener que repetirlas.

Paso 1 — Inventariar productos, servicios y procesos

El BIA empieza por un inventario, no por una encuesta de impactos. Antes de preguntar «¿qué pasa si esto se para?» hay que tener claro qué es «esto»:

1. Lista los productos y servicios que la organización entrega a terceros. En una pyme suelen ser entre 3 y 10.
2. Descompón cada uno en los procesos que lo hacen posible: captación y pedidos, producción o prestación, logística, facturación y cobro, atención posventa, y los procesos de soporte que lo sostienen todo (sistemas, nóminas, compras).
3. Asigna un responsable por proceso. Será tu interlocutor en los pasos siguientes; el impacto de parar un proceso lo conoce quien lo opera, no quien coordina el BIA.

El nivel de detalle correcto es el que permite tomar decisiones distintas: si dos actividades van a tener siempre el mismo tratamiento, agrúpalas; si dentro de un proceso conviven una parte que tolera días de parada y otra que no tolera horas, sepáralas. Una pyme de 30 personas suele manejarse bien con 10-20 procesos.

Paso 2 — Valorar el impacto de la interrupción en el tiempo

Aquí está el corazón del método, y la diferencia con cualquier ejercicio intuitivo: el impacto no se valora en abstracto, sino en función del tiempo. Para cada proceso se estima el daño en varios horizontes —por ejemplo: 4 horas, 24 horas, 3 días, 1 semana, 1 mes— y en varias dimensiones:

• Económica: ingresos no facturados, penalizaciones contractuales, costes extra de recuperación, horas improductivas.
• Legal y regulatoria: plazos que se incumplen (presentaciones a la Administración, obligaciones fiscales o laborales, requisitos sectoriales), con sus sanciones asociadas.
• De clientes y reputación: pedidos que se pierden, contratos que no se renuevan, daño de imagen difícil de cuantificar pero real.
• Operativa interna: trabajo acumulado que luego hay que reprocesar, equipos bloqueados, efecto dominó sobre otros procesos.

La mecánica habitual es una entrevista estructurada con el responsable de cada proceso, con una plantilla común: misma escala (por ejemplo, 1 a 5 por dimensión y horizonte, con umbrales en euros definidos de antemano), mismos horizontes temporales y espacio para observaciones. Dos consejos de campo:

• Ancla las escalas en cifras. «Impacto alto» no significa nada; «más de 20.000 € o incumplimiento con sanción» sí. Sin umbrales objetivos, cada responsable puntúa con su propia vara y los resultados no son comparables.
• Pregunta por la estacionalidad. Muchos procesos tienen impactos radicalmente distintos según el calendario (una gestoría parada en plena campaña de renta no es una gestoría parada en agosto): el BIA debe registrar el peor caso razonable y anotar cuándo ocurre.

Paso 3 — Fijar MTPD, RTO y RPO por proceso

Con las curvas de impacto sobre la mesa, los parámetros salen casi solos:

1. MTPD: localiza en cada proceso el horizonte temporal en el que el impacto pasa a inaceptable —la fila de la tabla donde el responsable diría «esto ya no lo remontamos» o donde aparece un incumplimiento legal serio—. Ese es el máximo tolerable.
2. RTO: fíjalo por debajo del MTPD con margen de seguridad. La distancia entre ambos es tu colchón para imprevistos durante la propia recuperación.
3. RPO: pregunta a cada responsable cuánto trabajo podría reconstruir si perdiera los datos recientes (¿se pueden volver a teclear los pedidos de la mañana? ¿existen los albaranes en papel?). Donde la reconstrucción es imposible o carísima, el RPO se acerca a cero y las copias tendrán que ser casi continuas.
4. MBCO: define el mínimo digno de cada servicio en modo degradado. ¿Atender solo pedidos urgentes? ¿Facturar a mano a los 10 clientes principales? Este dato dimensiona los recursos de contingencia, que casi nunca necesitan replicar el 100 % de la capacidad normal.

El resultado se valida en una sesión conjunta, porque los parámetros de procesos interdependientes deben ser coherentes entre sí: si la expedición de pedidos tiene un RTO de 8 horas pero depende del ERP, el ERP no puede tener un RTO de 3 días.

Paso 4 — Mapear dependencias y recursos mínimos

Un proceso no se recupera en abstracto: se recupera si vuelven a estar disponibles las cosas de las que depende. Para cada proceso priorizado, documenta:

• Personas: cuántas y con qué conocimientos; señala las dependencias de una sola persona, que son un hallazgo de continuidad en sí mismas.
• Tecnología y datos: aplicaciones, servidores o servicios en la nube, y los datos que consume y produce. Aquí el RPO conecta con la política de copias de seguridad real, no con la teórica.
• Proveedores y suministros: servicios externos sin los cuales el proceso no arranca (asesoría, logística, plataformas SaaS, suministro eléctrico y comunicaciones). Anota qué compromiso de recuperación ofrece cada proveedor crítico, si es que ofrece alguno.
• Instalaciones y equipos: puestos de trabajo, maquinaria, vehículos, y si existe alternativa (teletrabajo, segunda sede, alquiler exprés).

Este mapa de dependencias es lo que convierte el BIA en algo accionable: revela que dos procesos «independientes» caen juntos porque comparten una aplicación, o que el RTO de 8 horas prometido es imposible porque un proveedor clave solo se compromete a 48.

Paso 5 — Priorizar y validar con dirección

El cierre del BIA es un entregable corto para dirección: la lista de actividades ordenada por prioridad de recuperación, con sus MTPD, RTO, RPO y recursos mínimos, y las incoherencias detectadas (RPO imposibles con las copias actuales, dependencias de proveedor sin garantía, personas únicas). La dirección debe aprobarlo formalmente, por dos motivos:

• Los parámetros son decisiones de negocio, no técnicas. Aceptar un RTO de 3 días para la facturación es aceptar un riesgo; solo dirección puede aceptarlo.
• La ISO 22301 exige compromiso demostrable de la dirección con el sistema, y la aprobación del BIA es una de las evidencias más claras de ese compromiso.

Si todavía estás decidiendo si te conviene la ISO 22301, otra norma o un marco distinto como el ENS, el comprobador de normativa aplicable te orienta en un par de minutos antes de meterte en faena.

Del BIA a la estrategia de continuidad

El BIA no decide soluciones, pero las condiciona todas. Con los parámetros aprobados, la selección de estrategias se vuelve un ejercicio casi mecánico de casar objetivos con opciones y costes:

• Un RTO de horas en un sistema exige redundancia preparada de antemano (alta disponibilidad, entorno de respaldo listo para arrancar); un RTO de una semana admite soluciones baratas como restaurar en hardware alquilado.
• Un RPO cercano a cero exige replicación continua de datos; un RPO de un día se cubre con la copia nocturna de toda la vida —verificada y con prueba de restauración, que es donde suelen fallar.
• Un MBCO bajo abarata la contingencia: mantener el 20 % de la capacidad cuesta mucho menos que replicar el 100 %.

Ese trabajo de estrategias y planes tiene guía propia en este sitio —el plan de continuidad de negocio, con su encaje en el ENS—, así que aquí no lo repetiré. Lo que importa retener es la dirección de la flecha: primero impacto, luego estrategia, luego plan. Al revés (comprar la solución y redactar después un BIA que la justifique), el sistema entero pierde credibilidad.

Errores frecuentes al hacer un BIA

Los que más se repiten en pymes, por orden de daño:

1. Confundir BIA con análisis de riesgos y entregar un catálogo de amenazas sin un solo dato de impacto en el tiempo. Son ejercicios complementarios, no intercambiables.
2. Fijar los RTO por intuición del informático en lugar de derivarlos del impacto de negocio. El resultado típico: todo «crítico» y todo con RTO de 4 horas, lo que convierte la priorización en papel mojado y la contingencia en algo impagable.
3. Escalas sin anclar en euros ni en obligaciones concretas, que hacen que cada departamento se declare el más crítico de la casa.
4. Ignorar dependencias externas. El BIA interno perfecto se derrumba si nadie preguntó qué garantiza el proveedor del ERP en la nube o la asesoría que presenta los impuestos.
5. RPO declarados que las copias reales no cumplen. Es la incoherencia más fácil de detectar en auditoría: basta comparar el BIA con la programación de copias.
6. Tratarlo como un documento de una vez. Un BIA de hace tres años describe una empresa que ya no existe.
7. Perfeccionismo paralizante. Mejor una primera versión razonable en dos o tres semanas, validada por dirección, que seis meses de entrevistas para un documento que nace caducado.

Cada cuánto se revisa el BIA

La ISO 22301 exige mantener el BIA al día, y la práctica asentada es revisarlo al menos una vez al año y, además, ante cualquier cambio relevante: un producto o servicio nuevo, un cambio de sistema informático importante, una mudanza, un proveedor crítico nuevo o una reorganización. También conviene revisarlo tras cada incidente real o cada prueba del plan: si la realidad contradice al BIA, gana la realidad.

La revisión anual no es rehacerlo: con el inventario y las plantillas del primer ciclo, confirmar o ajustar parámetros con cada responsable es cuestión de días, no de meses. Es exactamente la evidencia periódica que el auditor esperará encontrar en cada ciclo de seguimiento.

Preguntas frecuentes

Fuentes

• ISO 22301:2019 — Security and resilience. Business continuity management systems. Requirements (catálogo oficial de ISO, iso.org). Texto no público; se adquiere bajo licencia.
• UNE-EN ISO 22301 — versión oficial española de la norma (tienda de normas UNE/AENOR, une.org).
• ISO/TS 22317:2021 — Security and resilience — Business continuity management systems — Guidelines for business impact analysis (catálogo oficial de ISO, iso.org). Especificación técnica de directrices, no certificable. Ojo al título: la edición vigente es la de 2021 y abre con «Security and resilience»; la de 2015 empezaba por «Societal security».
• INCIBE — recursos de continuidad de negocio para empresas dentro de «Protege tu empresa» (incibe.es).