Hablemos del BIA que vive en vuestra unidad compartida.
Ese en el que IT rellenó las valoraciones de impacto un martes por la tarde, lo envió al responsable de BC para «revisión» y nadie lo volvió a tocar hasta que el auditor preguntó.
Ese ya lo conocéis.
Las columnas están todas en «Alto». O todas en «Medio». Nadie recuerda qué significan los umbrales. No hay RTO. No hay MTPoD. No hay dependencias de sistemas. No hay columna de contingencia, porque nadie pensó en qué ocurre después de que la hoja de cálculo se apruebe.
¿Y cuando llega la interrupción real? Nadie abre el BIA. Porque el BIA no les dice nada útil.
Ese es el BIA que vamos a reemplazar.
Por qué fracasan la mayoría de los BIA
Un BIA no es un formulario. Es una conversación. Y la mayoría de las organizaciones se saltan la conversación y van directamente al formulario.
Esto es lo que sale mal:
- IT lo hace solo. Un BIA es un ejercicio de negocio. Si el CFO, el Director de Operaciones y el Director de Ventas no han estado en la sala, vuestro BIA es una suposición en una hoja de cálculo.
- Los niveles de impacto no tienen definición. «Alto» no significa nada si no habéis definido qué aspecto tiene «Alto» en euros, en clientes perdidos o en exposición regulatoria.
- Cubre sistemas pero olvida a las personas. Que vuestro ERP esté caído es un problema. Que todo vuestro equipo de finanzas no pueda trabajar es un problema diferente.
- Cubre sistemas pero olvida las ubicaciones. Si vuestra sede central es inaccesible, ¿funciona realmente vuestra contingencia?
- No hay dimensión temporal. Perder el correo durante 4 horas es molesto. Perderlo durante 10 días es catastrófico. Un BIA sin una matriz de impacto a lo largo del tiempo es una instantánea, no un análisis.
- Faltan el RTO y el MTPoD. Si no definís con qué rapidez debe restaurarse un sistema y cuánto tiempo puede tolerar la organización la interrupción, vuestro equipo de DR está adivinando.
Lo que hemos construido
Hemos construido la plantilla de BIA que utilizamos en nuestros compromisos de consultoría ISO 22301. Y la hemos puesto a disposición de forma gratuita.
Tres secciones de evaluación. Un marco de definición de impacto. Cero ambigüedad.
Sección 1: Personas
ColumnaQué capturaDepartamento / FunciónCada unidad de negocio, no solo ITPrioridadAlto / Medio / Bajo: clasificación de criticidad del departamentoResponsable del departamentoPropietario nominado, no «la persona responsable»Número de empleadosA tiempo completo, a tiempo parcial, contratistas; el número de personas afecta a la recuperaciónLugar de trabajoDesde dónde operan; orienta la planificación de ubicaciones alternativasImpacto a lo largo del tiempoMatriz de 4 niveles: 0-1 días, 2-4 días, 5-10 días, >10 díasDependencias de sistemasQué sistemas no puede permitirse perder este equipo
Esto no es solo una lista de departamentos. Es un mapa de cómo se desmorona vuestro negocio cuando las personas no pueden trabajar.
Sección 2: Sistemas
ColumnaQué capturaPara qué sirveLenguaje sencillo, no el nombre del producto del proveedorCómo se llamaEl nombre real del sistemaQuién lo usaQué equipos dependen de este sistemaRTORecovery Time Objective: con qué rapidez debe restaurarseMTPoDMaximum Tolerable Period of DisruptionImpacto a lo largo del tiempoMisma matriz de 4 niveles: escalada de Bajo a CatastróficoDependenciasPersonas, funciones y departamentos que dependen de élContingenciaQué despliegáis cuando este sistema cae
Precargada con sistemas habituales: aplicación principal, contabilidad, RRHH, correo electrónico, almacenamiento de ficheros, sitio web, alojamiento web, gestión de código fuente, CRM; más filas en blanco para los vuestros.
Sección 3: Ubicaciones
ColumnaQué capturaNombre de la ubicaciónSede central, oficinas regionales, centros de datosDónde estáDirección físicaQuién la usaQué equipos tienen su base allíRTOCon qué rapidez necesita estar operativa de nuevo la ubicaciónMTPoDPeríodo máximo tolerable sin esta ubicaciónImpacto a lo largo del tiempoMisma matriz de escalada de 4 nivelesDependenciasEquipos y funciones afectadosContingencia«Trabajo remoto» no siempre es la respuesta. ¿Cuál es la vuestra?
«La mayoría de los BIA omiten las ubicaciones por completo. Entonces llega la inundación y nadie sabe qué equipos se ven afectados, qué sistemas estaban alojados allí ni adónde deben ir las personas.»
Definiciones de niveles de impacto
La plantilla incluye una hoja específica que define cuatro niveles de impacto:
NivelUmbral financieroQué significaCatastrófico>£100.000Riesgo para la vida. La organización no puede cumplir sus obligaciones legales. Puede cesar su actividad.Alto£30.000–£50.000Daño excepcional. Posible pérdida de clientes y contratos.Medio£10.000–£30.000Daño interno apreciable. Bajo riesgo para la actividad. Impacto reducido en clientes.Bajo<£10.000Impacto escaso o nulo.
“Customise the thresholds to your organisation, but keep the structure. The point is that when someone selects “High,” everyone in the room knows exactly what that means.”
Para quién es esto
- Responsables de BC que realizan su primer BIA o que rehacen uno deficiente
- CISOs y gestores de riesgos que necesitan conectar la recuperación ante desastres de IT con el impacto en el negocio
- Implementadores de ISO 22301 que necesitan evidencia documentada del BIA para la certificación
- Organizaciones afectadas por NIS2 el Artículo 21 exige medidas de continuidad de negocio, y un BIA es el punto de partida
- Entidades reguladas por DORA los Artículos 11-12 exigen pruebas de continuidad de las TIC basadas en el análisis de impacto
- Consultores hartos de construir plantillas de BIA desde cero para cada cliente
Cómo utilizarla
- Empezad por las Personas. Reunid a los responsables de departamento en la sala. No solo IT. Rellenad juntos las prioridades, el número de personas, las ubicaciones y el impacto a lo largo del tiempo.
- Pasad a los Sistemas. Para cada sistema, definid el RTO y el MTPoD. Rellenad la matriz de impacto. Documentad la contingencia: «ya lo resolveremos» no es una contingencia.
- Cubrid las Ubicaciones. Cada emplazamiento físico. ¿Qué ocurre si no está disponible durante un día? ¿Una semana? ¿Dos semanas?
- Calibrad con la hoja de Niveles de Impacto. Aseguraos de que todos estén de acuerdo sobre qué significa «Catastrófico» antes de que nadie empiece a puntuar nada.
- Revisad trimestralmente. Un BIA con 12 meses de antigüedad es ficción. Los sistemas cambian, las personas se mueven, las prioridades evolucionan.
Descargadla
Ajustad los umbrales financieros, añadid vuestros departamentos y sistemas, y tendréis un BIA operativo en una tarde. No uno perfecto, sino uno real. La perfección viene después.
👉 Descargar la plantilla de Business Impact Assessment, gratis
¿Queréis ir más lejos?
Un BIA es el primer paso. La metodología, los talleres, los casos prácticos: eso es lo que convierte una hoja de cálculo en un programa.
- ISO 22301 Lead Implementer, metodología BIA, estrategias de BC, diseño de ejercicios
- ISO 27001 Lead Implementer, porque la seguridad de la información y la continuidad de negocio son inseparables
- DORA Lead Manager, continuidad de las TIC para entidades financieras
- NIS2 Lead Implementer, para entidades esenciales e importantes bajo NIS2
Todas las formaciones: Certificado o Reembolsado.
Cyber Academy, cyberacademy.net
No enseñamos teoría. Enseñamos a sobrevivir.