Análisis de impacto en el negocio para ISO 27001, NIS2 y DORA

La pregunta de auditoría que revela la verdadera brecha de continuidad

Es lunes por la mañana y María, CISO de una FinTech en rápido crecimiento, prepara una reunión del comité de riesgos del Consejo de Administración. El asunto es breve: “Preparación para DORA y NIS2: revisión del BIA”.

Su equipo ha construido lo que la mayoría de la alta dirección espera ver. Existe un SGSI certificado conforme a ISO/IEC 27001:2022, playbooks de respuesta a incidentes, capturas de pantalla de copias de seguridad, informes de vulnerabilidades, cuestionarios de proveedores, diagramas de arquitectura en la nube y un registro de riesgos actualizado. Los clientes empresariales están enviando cuestionarios NIS2. Los clientes del sector financiero están incorporando cláusulas DORA en los contratos. La auditoría de seguimiento de ISO/IEC 27001:2022 está a solo un mes.

Entonces, el auditor externo formula la pregunta que cambia la sala:

“Si su plataforma de incorporación de clientes no está disponible durante 18 horas, ¿qué servicios regulados se ven afectados, qué proveedores intervienen, cuál es la prioridad de recuperación aprobada y dónde está la evidencia de que la organización aceptó el RTO y el RPO?”

La sala queda en silencio.

El calendario de copias de seguridad dice una cosa. El plan de recuperación ante desastres dice otra. El contrato del proveedor incluye un acuerdo de nivel de servicio de disponibilidad, pero no evidencias de pruebas de recuperación. El registro de riesgos menciona la disponibilidad, pero no explica por qué un servicio debe recuperarse antes que otro. La dirección aprobó la política de seguridad, pero no el impacto en el negocio de la indisponibilidad.

Ese es el problema del análisis de impacto en el negocio en 2026.

Un análisis de impacto en el negocio, o BIA, ya no es una hoja de cálculo adjunta a un plan de continuidad. Es el puente de evidencias entre servicios de negocio, activos de TIC, proveedores, prioridades de recuperación, RTO/RPO, umbrales de incidente, pruebas de resiliencia y responsabilidad proactiva del Consejo de Administración. Para las organizaciones que alinean ISO/IEC 27001:2022 con la continuidad exigida por NIS2 y la resiliencia de las TIC de DORA, el BIA es el punto en el que el cumplimiento se vuelve operativo.

Las organizaciones más sólidas ya disponen de muchos de los controles adecuados. Su debilidad es la trazabilidad. El BIA convierte evidencias dispersas en una historia preparada para auditoría: qué importa, por qué importa, con qué rapidez debe recuperarse, qué dependencias lo soportan, qué se ha probado, qué falló, qué se mejoró y quién aprobó el riesgo residual.

Por qué las antiguas hojas de cálculo de BIA son ahora un pasivo

NIS2 y DORA cambiaron el tono del cumplimiento en materia de continuidad. No tratan la continuidad del negocio, la recuperación ante desastres, la respuesta a incidentes, la resiliencia de proveedores y el gobierno corporativo como documentos separados. Esperan que funcionen como un único sistema.

Para las entidades NIS2, Article 21 exige medidas técnicas, operativas y organizativas para gestionar los riesgos que afectan a las redes y sistemas de información, y para prevenir o minimizar el impacto de los incidentes sobre los destinatarios del servicio y otros servicios. Sus medidas mínimas incluyen análisis de riesgos, gestión de incidentes, continuidad del negocio incluida la gestión de copias de seguridad, recuperación ante desastres y gestión de crisis, seguridad de la cadena de suministro, gestión de vulnerabilidades, evaluación de la eficacia de los controles, formación, criptografía, seguridad de los recursos humanos, control de acceso, gestión de activos, autenticación multifactor y comunicaciones seguras.

NIS2 Article 20 traslada la cuestión al Consejo de Administración. Los órganos de dirección deben aprobar las medidas de gestión de riesgos de ciberseguridad, supervisar su implantación y pueden ser considerados responsables de las infracciones. Esto significa que un RTO de cuatro horas sin respaldo no es solo una inconsistencia técnica. Es una debilidad de gobernanza.

DORA es aplicable desde el 17 de enero de 2025 y crea un marco uniforme de la UE para la gestión del riesgo de las TIC, la notificación de incidentes, las pruebas de resiliencia operativa digital, la gestión del riesgo de terceros de TIC, los requisitos contractuales y la supervisión de proveedores terceros críticos de servicios de TIC. Para las entidades financieras, y para los proveedores tecnológicos que les prestan soporte mediante contratos, DORA convierte la resiliencia operativa en un requisito estructurado de evidencias.

DORA Articles 5 y 6 exigen gobernanza y un marco documentado de gestión del riesgo de las TIC. Articles 7 a 14 cubren sistemas de TIC fiables y resilientes, identificación de activos y dependencias, protección, detección, continuidad del negocio de TIC, copias de seguridad, restauración, recuperación, aprendizaje posterior al incidente, concienciación, formación y comunicación de crisis. Articles 24 a 26 exigen pruebas de resiliencia operativa digital para entidades financieras que no sean microempresas. Articles 28 a 30 formalizan el riesgo de terceros de TIC, los registros de contratos de servicios de TIC, las estrategias de salida, los niveles de servicio, los derechos de auditoría y los requisitos de contingencia.

ISO/IEC 27001:2022 proporciona la base del sistema de gestión. Sus cláusulas exigen que la organización defina el contexto, las partes interesadas, las obligaciones legales y contractuales, el alcance, el liderazgo, la política, los roles, la evaluación de riesgos, el tratamiento de riesgos, la Declaración de Aplicabilidad, la planificación operacional, la evaluación del desempeño y la mejora continua.

El eslabón que falta suele ser el BIA. Sin él, los planes de continuidad no están claramente basados en riesgos, los objetivos de copia de seguridad no están aprobados por la organización, los proveedores no están mapeados con los servicios críticos y la dirección no puede demostrar de forma fiable que las decisiones de resiliencia se basaron en el impacto en el negocio.

El BIA como plano de control de las evidencias de resiliencia

Un BIA defendible responde a siete preguntas que auditores, reguladores, clientes y consejos de administración plantean cada vez con más frecuencia:

1. ¿Qué servicios de negocio son críticos?
2. ¿Qué activos de TIC, repositorios de datos, personas, proveedores y servicios auxiliares soportan cada servicio?
3. ¿Cuál es el impacto operativo, financiero, legal, contractual, para el cliente, de seguridad y reputacional de la interrupción a lo largo del tiempo?
4. ¿Cuál es el tiempo máximo tolerable de interrupción, o MTD?
5. ¿Cuáles son el objetivo de tiempo de recuperación aprobado, o RTO, y el objetivo de punto de recuperación, o RPO?
6. ¿Los acuerdos de copias de seguridad, redundancia, nube, proveedores, dotación de personal y comunicación hacen alcanzables esos objetivos?
7. ¿La organización ha probado la ruta de recuperación y revisado los resultados?

La Política de Continuidad del Negocio y Recuperación ante Desastres empresarial de Clarysec P32 Política de Continuidad del Negocio y Recuperación ante Desastres establece el requisito con claridad:

El análisis de impacto en el negocio (BIA) deberá realizarse al menos una vez al año para todas las unidades de negocio críticas y revisarse cuando se produzcan cambios significativos en sistemas, procesos o dependencias. Los resultados del BIA deberán definir: 5.2.1. Tiempo máximo tolerable de interrupción (MTD) 5.2.2. Objetivos de tiempo de recuperación (RTO) 5.2.3. Objetivos de punto de recuperación (RPO) 5.2.4. Dependencias críticas (sistemas, proveedores, personal)

Esa cláusula ofrece a los auditores un punto de partida práctico. También evita el fallo habitual por el que el plan de continuidad del negocio, el plan de recuperación ante desastres, el calendario de copias de seguridad, el registro de proveedores y el proceso de respuesta a incidentes utilizan cada uno una definición distinta de “crítico”.

La misma política exige un enfoque de gestión integrado:

La organización deberá mantener un sistema de gestión de la continuidad del negocio integrado, alineado con ISO 22301 e ISO/IEC 27001, que garantice la integración de: 5.1.1. Análisis de impacto en el negocio (BIA) 5.1.2. Evaluación de riesgos de seguridad para amenazas a la continuidad 5.1.3. Planes de continuidad del negocio 5.1.4. Planes de recuperación ante desastres de TIC 5.1.5. Programas de pruebas y ejercicios 5.1.6. Documentación y mejora continua

Esta es la diferencia entre cumplimiento de lista de verificación y resiliencia preparada para auditoría. El BIA no es un documento puntual. Pasa a formar parte de la cadena de evidencias del SGSI y del sistema de gestión de la continuidad del negocio.

Cómo ISO/IEC 27001:2022 convierte el BIA en evidencias auditables

ISO/IEC 27001:2022 no exige que todas las organizaciones utilicen la expresión “análisis de impacto en el negocio” en cada cláusula, pero sus requisitos hacen que las evidencias del BIA sean extremadamente valiosas.

Las cláusulas 4.1 a 4.4 exigen que la organización comprenda las cuestiones internas y externas, las partes interesadas, las obligaciones legales y regulatorias, los requisitos contractuales, las interfaces, las dependencias y el alcance del SGSI. Un BIA suele ser la evidencia más práctica de esas interfaces y dependencias. Muestra qué servicio en la nube, procesador de pagos, proveedor de identidad, proveedor de telecomunicaciones, servicio de seguridad gestionada, centro de datos o equipo de soporte externalizado habilita un servicio crítico.

Las cláusulas 5.1 a 5.3 exigen liderazgo de la alta dirección, dotación de recursos, comunicación, asignación de roles e informes. Un BIA proporciona al liderazgo una base de negocio para las inversiones en continuidad. Sin él, los objetivos RTO y RPO son aspiraciones técnicas, no requisitos de negocio aprobados.

Las cláusulas 6.1.1 a 6.1.3 exigen una evaluación de riesgos y un tratamiento de riesgos de seguridad de la información repetibles. La organización debe identificar riesgos para la confidencialidad, integridad y disponibilidad, analizar consecuencias y probabilidad, determinar niveles de riesgo, priorizar el tratamiento, seleccionar controles, comparar los controles seleccionados con el Anexo A, elaborar una Declaración de Aplicabilidad, crear un plan de tratamiento de riesgos y obtener la aprobación del propietario del riesgo. Un BIA refuerza la dimensión de “consecuencia” de la evaluación de riesgos. Explica por qué una indisponibilidad de dos horas de un sistema es tolerable, mientras que una indisponibilidad de dos horas de otro genera perjuicio al cliente, exposición regulatoria, incumplimiento contractual o un impacto severo en ingresos.

El Anexo A proporciona el catálogo de controles. Para BIA y continuidad, los controles más relevantes del Anexo A de ISO/IEC 27001:2022 incluyen:

En Zenith Controls: The Cross-Compliance Guide Zenith Controls, Clarysec perfila el control 5.30 de ISO/IEC 27002:2022, preparación de las TIC para la continuidad del negocio, como un control correctivo centrado en la disponibilidad, mapeado con el concepto de ciberseguridad Respond, la capacidad operativa de continuidad y el dominio de seguridad de resiliencia. El control 5.29, seguridad de la información durante una interrupción, se perfila como preventivo y correctivo, protegiendo la confidencialidad, integridad y disponibilidad. El control 8.13, copia de seguridad de la información, se perfila como correctivo, soportando la integridad y la disponibilidad mediante la recuperación.

Esa distinción importa. Un BIA no solo debe preguntar: “¿Podemos restaurar?”. También debe preguntar: “¿Podemos seguir siendo seguros durante la interrupción?”. Durante un evento de ransomware, una indisponibilidad de la nube, un fallo de proveedor o un incidente de centro de datos, la organización sigue necesitando control de acceso, registro de eventos, supervisión, preservación de evidencias, comunicaciones seguras y salvaguardas de privacidad.

El modelo práctico de evidencias del BIA

Un BIA sólido conecta el lenguaje de negocio con la prueba técnica. Clarysec suele estructurar el modelo de evidencias en cinco capas.

Este modelo de evidencias funciona porque sigue la forma de pensar de los auditores. Primero preguntan qué es crítico. Después preguntan qué lo soporta. Después preguntan quién aprobó el objetivo de recuperación. Después preguntan si los acuerdos técnicos y con proveedores pueden cumplir el objetivo. Finalmente, preguntan si la organización ha probado y mejorado la capacidad.

NIST CSF 2.0 es útil como capa de comunicación. Su método de perfiles CSF anima a las organizaciones a definir el alcance, recopilar entradas como políticas, prioridades de riesgo de la organización, registros de BIA, requisitos de ciberseguridad, normas, procedimientos, medidas de seguridad y roles de trabajo, crear perfiles actuales y objetivo, analizar deficiencias, producir un plan de acción priorizado, implantar ese plan y actualizar el perfil. Eso es casi exactamente cómo un BIA debe alimentar una hoja de ruta de cumplimiento transversal.

Un ejercicio de BIA de una semana que crea evidencias reales

Supongamos que un proveedor SaaS da soporte a clientes de servicios financieros. Su plataforma soporta la incorporación de clientes, la verificación documental y las notificaciones a clientes. No es un banco, pero sus clientes le envían solicitudes contractuales impulsadas por DORA y cuestionarios de proveedores NIS2.

Un ejercicio focalizado de una semana puede crear evidencias útiles con rapidez.

Día 1: Identificar servicios críticos y ventanas de impacto

Empiece por los servicios, no por los servidores. Involucre a propietarios de negocio, TIC, seguridad, legal, soporte, privacidad y gestión de proveedores.

Este encuadre es importante. Reguladores y clientes reconocen servicios y funciones. Las aplicaciones importan porque soportan esos servicios.

Día 2: Mapear dependencias

Para cada servicio, mapee aplicaciones, bases de datos, infraestructura, servicios en la nube, proveedores de identidad, supervisión, herramientas de copia de seguridad, personas, proveedores y servicios auxiliares.

Aquí es donde el BIA empieza a generar valor. Revela la ruta de recuperación invisible, incluidas las dependencias que suelen faltar en un plan técnico de DR.

Día 3: Aprobar MTD, RTO y RPO

El propietario de negocio propone el MTD. TIC y seguridad validan si el RTO y el RPO propuestos son técnicamente alcanzables. La dirección aprueba los objetivos finales.

Para organizaciones más pequeñas, la Política de Continuidad del Negocio y Recuperación ante Desastres - SME de Clarysec P32S Política de Continuidad del Negocio y Recuperación ante Desastres - SME ofrece la misma disciplina con un lenguaje más sencillo. Exige planes BCP/DRP que establezcan el enfoque para restaurar funciones esenciales:

El Director General (DG) debe aprobar y mantener planes de continuidad del negocio y recuperación ante desastres (BCP/DRP) que establezcan claramente el enfoque de la organización para restaurar funciones esenciales.

También exige que el plan incluya:

servicios y sistemas priorizados (funciones críticas de la organización)

Y:

Objetivos de tiempo de recuperación (RTO) y objetivos de punto de recuperación (RPO) para cada sistema

La clave no es una documentación excesiva. La clave es trazabilidad, aprobación y evidencia de que los objetivos de recuperación se basan en un impacto real en el negocio.

Día 4: Conciliar las copias de seguridad con el impacto en el negocio

Muchas organizaciones fallan aquí. El BIA puede establecer un RPO de cuatro horas mientras las copias de seguridad se ejecutan cada 24 horas. O la herramienta de copia de seguridad protege bases de datos de producción, pero no configuración, secretos, repositorios de infraestructura como código, almacenamiento de objetos, registros DNS, ajustes de identidad o configuración de pasarelas API.

La Política de Copias de Seguridad y Restauración de Clarysec P15 Política de Copias de Seguridad y Restauración exige un calendario maestro de copias de seguridad vinculado a los resultados del BIA:

Deberá mantenerse y revisarse anualmente un calendario maestro de copias de seguridad. Debe especificar: 5.1.1 Frecuencia de copia de seguridad (por ejemplo, copias de seguridad incrementales diarias y copias de seguridad completas semanales) 5.1.2 Períodos de conservación por sistema o tipo de datos 5.1.3 Requisitos de cifrado y detalles de ubicación de almacenamiento 5.1.4 Objetivos RTO/RPO vinculados a los resultados de la evaluación de impacto en el negocio

Esta cláusula es oro para auditoría. Obliga a que el diseño de las copias de seguridad refleje el impacto en el negocio, no la comodidad del almacenamiento.

Día 5: Probar una ruta de recuperación y abrir acciones correctivas

No pruebe todo de una vez. Seleccione un servicio crítico y ejecute una prueba de recuperación focalizada. Restaure la base de datos. Reconstruya la configuración de la aplicación. Valide la autenticación. Confirme que los registros están disponibles. Compruebe la capacidad de notificación a clientes. Registre el tiempo empleado, la pérdida de datos, los defectos, las decisiones y las acciones correctivas.

En Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, la fase Controls in Action, Step 23, aborda los controles organizativos, incluida la preparación de las TIC para la continuidad del negocio. Plantea la pregunta que todo equipo auditor debería formular:

¿Pueden sus sistemas soportar sus objetivos de continuidad del negocio cuando las luces parpadean, cuando las redes caen, cuando ocurre un desastre?

El mismo paso ofrece una instrucción práctica:

Verifique que los objetivos de tiempo de recuperación (RTO) y los objetivos de punto de recuperación (RPO) de los sistemas críticos estén alineados con las expectativas de continuidad del negocio (5.30). Realice al menos una prueba técnica de recuperación o simulación de conmutación por error y documente los resultados.

Esa es la diferencia entre tener un BIA y disponer de evidencias de BIA defendibles. El objetivo no solo está documentado. Está probado.

Mapeo de evidencias de BIA con NIS2, DORA, GDPR, NIST y COBIT 2019

Un BIA bien construido se convierte en un activo de cumplimiento transversal. Un único conjunto de evidencias puede responder a muchas preguntas.

El GDPR suele pasarse por alto en las conversaciones sobre BIA. Sin embargo, GDPR Article 5 exige que los datos personales se traten con integridad y confidencialidad, incluida la protección contra la pérdida, destrucción o daño accidentales mediante medidas técnicas u organizativas adecuadas. La responsabilidad proactiva exige que el responsable del tratamiento pueda demostrar el cumplimiento. Si una plataforma de datos personales no puede restaurarse dentro de un plazo aprobado y probado, el riesgo de privacidad afecta a la disponibilidad, la integridad, la evaluación de brechas de seguridad y la confianza del cliente.

La notificación de incidentes de NIS2 añade otra dimensión. Article 23 exige que los incidentes significativos se notifiquen sin dilación indebida, incluida una alerta temprana en 24 horas, una notificación de incidente en 72 horas y un informe final en el plazo de un mes. Un BIA ayuda a clasificar la severidad porque define los servicios afectados, los destinatarios del servicio, la interrupción operativa y el posible impacto transfronterizo.

La clasificación de incidentes de DORA también considera clientes o transacciones afectados, duración, distribución geográfica, pérdidas de datos, criticidad de los servicios afectados e impacto económico. Estos son campos del BIA. Si el BIA es débil, la clasificación de incidentes se vuelve subjetiva en el peor momento posible.

La continuidad de proveedores es donde el BIA se encuentra con la realidad contractual

Para NIS2 y DORA, la continuidad de proveedores ya no es opcional. NIS2 Article 21 incluye seguridad de la cadena de suministro y exige prestar atención a las vulnerabilidades de proveedores, la calidad y resiliencia de productos, las prácticas de ciberseguridad de proveedores y los procedimientos de desarrollo seguro. DORA exige que el riesgo de terceros de TIC se gestione dentro del marco de riesgo de TIC, incluidos registros de contratos de servicios de TIC, diligencia debida, riesgo de concentración, estrategias de salida, derechos de auditoría y acceso, asistencia en incidentes, niveles de servicio y requisitos de contingencia.

La Política de Continuidad del Negocio y Recuperación ante Desastres empresarial exige:

Dependencias de terceros y de la cadena de suministro 6.5.1. Los contratos con proveedores críticos deberán incluir obligaciones de continuidad y compromisos de tiempo de recuperación. 6.5.2. Los proveedores de servicios clave deberán, previa solicitud, demostrar pruebas periódicas de continuidad y participación en simulacros de incidentes.

La versión SME también exige:

puntos de contacto de continuidad de proveedores

Ese pequeño campo puede ser decisivo en un incidente real. Si su plan de recuperación dice “contactar con el soporte del proveedor de servicios en la nube”, pero nadie conoce la vía de escalado, la referencia contractual, el proceso de severidad o el contacto fuera de horario, el RTO es ficticio.

Esta tabla no sustituye a la gestión de riesgos de proveedores. Hace que el riesgo de proveedores sea operativo.

Cómo probarán los auditores su BIA

Un auditor de ISO/IEC 27001:2022 normalmente empezará por el alcance, el contexto, la evaluación de riesgos, el tratamiento de riesgos, la Declaración de Aplicabilidad, los controles del Anexo A, la información documentada, la planificación operacional, la evaluación del desempeño y la mejora. Comparará el BIA con la evaluación de riesgos y la SoA. Si A.5.30, A.5.29 o A.8.13 están incluidos, solicitará evidencias de implantación y pruebas.

Un revisor de DORA se centrará en funciones críticas o importantes, activos de TIC, dependencias de terceros de TIC, pruebas de resiliencia, clasificación de incidentes, requisitos contractuales, estrategias de salida y supervisión del órgano de dirección. Esperará que el BIA esté alineado con el marco de gestión del riesgo de las TIC, la estrategia de resiliencia operativa digital, los planes de continuidad del negocio de TIC, los planes de respuesta y recuperación y el programa de pruebas.

Un supervisor NIS2 solicitará medidas de continuidad del negocio, gestión de copias de seguridad, recuperación ante desastres, gestión de crisis, seguridad de la cadena de suministro, aprobación de gobernanza y capacidad de notificación de incidentes significativos. El BIA debe demostrar que estas medidas se basan en el impacto en el servicio y en prioridades aprobadas.

Un evaluador de NIST CSF 2.0 preguntará cómo el BIA informa el perfil actual, el perfil objetivo, el análisis de deficiencias y el plan de acción. Revisará los resultados de Govern relativos a decisiones legales, regulatorias, contractuales, de riesgo, roles, políticas, supervisión y riesgo de proveedores. También examinará los resultados de Identify, Protect, Detect, Respond y Recover.

Un auditor COBIT 2019 o de estilo ISACA normalmente se centrará en la gobernanza. ¿Quién es propietario del servicio? ¿Quién aceptó el riesgo? ¿Los objetivos están alineados con las metas de la organización? ¿Se supervisa a los proveedores? ¿Están equilibrados los beneficios, el riesgo y los recursos? ¿Las acciones correctivas se llevan hasta su cierre?

La Política de Auditoría y Supervisión del Cumplimiento de Clarysec Política de Auditoría y Supervisión del Cumplimiento incorpora el BIA al ciclo de planificación de auditoría:

Deberá elaborarse y aprobarse anualmente un plan de auditoría basado en riesgos, teniendo en cuenta: 5.2.1 Los resultados de las evaluaciones de riesgos y del análisis de impacto en el negocio (BIA) más recientes 5.2.2 Los hallazgos de auditoría anteriores y el estado de las acciones correctivas 5.2.3 Cambios en procesos, infraestructura de TIC, sistemas o proveedores 5.2.4 Obligaciones externas como DORA Article 25 o contratos de clientes

Este es un paso de madurez que muchas organizaciones omiten. El BIA no debe quedar fuera del aseguramiento. Debe impulsar el plan de auditoría.

Fallos habituales de BIA encontrados en evaluaciones reales

Las mismas debilidades aparecen una y otra vez.

En primer lugar, el BIA enumera aplicaciones, no servicios. A clientes y reguladores les preocupa la interrupción del servicio. Las aplicaciones importan porque soportan esos servicios.

En segundo lugar, los objetivos RTO y RPO se copian de plantillas. Un RTO de cuatro horas puede parecer razonable hasta que una prueba de restauración demuestra que se tardan nueve horas en reconstruir la integración de identidad, recuperar la configuración, restaurar datos, validar la integridad y reactivar la supervisión.

En tercer lugar, las copias de seguridad no están vinculadas al impacto en el negocio. La frecuencia, la conservación, el cifrado, la ubicación de almacenamiento, la prioridad de restauración y las pruebas deben reflejar los objetivos de recuperación aprobados.

En cuarto lugar, los proveedores se tratan como elementos de cuestionario, no como dependencias de recuperación. Los compromisos de continuidad de proveedores, los contactos de escalado, las evidencias de recuperación y la participación en simulacros de incidentes deben vincularse a servicios críticos.

En quinto lugar, falta la aprobación de la dirección. En NIS2 y DORA, la responsabilidad de la dirección es explícita. En ISO/IEC 27001:2022, el liderazgo, los roles, la aprobación del propietario del riesgo y los informes de desempeño son requisitos esenciales.

En sexto lugar, las pruebas son demasiado limitadas. Restaurar un archivo es útil, pero no demuestra la recuperación del servicio. Una ruta de recuperación de un servicio crítico puede incluir DNS, identidad, secretos, infraestructura como código, pasarelas API, supervisión, registro de eventos, escalado de proveedores, comunicación con clientes y revisión de privacidad.

El Zenith Blueprint, en la fase Controls in Action, Step 19, recoge la expectativa de auditoría sobre las copias de seguridad:

¿Prueba sus copias de seguridad?

La respuesta debe ser “sí, con evidencias”, y esas evidencias deben conectarse de nuevo con el BIA.

El paquete de evidencias de BIA preparado para auditoría

Un programa práctico de BIA debe producir un paquete conciso de evidencias que pueda utilizarse para auditorías, diligencia debida de clientes, informes al Consejo de Administración y mejora de la resiliencia.

Este paquete cuenta una historia coherente. También hace que la resiliencia sea medible.

Siguiente paso: convierta su BIA en evidencias de cumplimiento

María no necesita una hoja de cálculo más grande. Necesita una cadena de evidencias viva.

Empiece con un servicio crítico. Mapee sus activos de TIC, datos, personas, proveedores y servicios auxiliares. Apruebe MTD, RTO y RPO. Concilie el calendario de copias de seguridad. Compruebe los compromisos de recuperación de proveedores. Ejecute una prueba de recuperación. Registre las deficiencias. Actualice el plan de tratamiento de riesgos. Presente el resultado a la dirección.

Después, repita.

Clarysec puede ayudar a acelerar ese proceso mediante la Política de Continuidad del Negocio y Recuperación ante Desastres, la Política de Continuidad del Negocio y Recuperación ante Desastres - SME, la Política de Copias de Seguridad y Restauración, la Política de Auditoría y Supervisión del Cumplimiento, Zenith Blueprint y Zenith Controls.

Su BIA no debe ser documentación de estantería creada para una auditoría. Debe ser la prueba operativa de que sus servicios más importantes pueden sobrevivir a una interrupción, cumplir las expectativas de clientes y reguladores y recuperarse dentro de los límites que su liderazgo ha aprobado realmente.

Si su organización se está preparando para una auditoría de seguimiento de ISO/IEC 27001:2022, aseguramiento de clientes NIS2, revisiones de terceros de TIC bajo DORA o informes de resiliencia a nivel de consejo, empiece por hacer defendible el BIA. Descargue las políticas de continuidad y auditoría de Clarysec, revise la hoja de ruta de implantación de Zenith o solicite una evaluación de evidencias de resiliencia para convertir controles dispersos en una única historia preparada para auditoría.