El BIA es solo el punto de partida.
Aquí está todo lo que un auditor serio va a pedir.
| BIA | Análisis de Impacto en el Negocio. Procesos críticos identificados, dependencias documentadas, RTO y RPO definidos por proceso con justificación de negocio. Actualizado y aprobado por dirección. |
| Análisis de riesgos | Escenarios de interrupción evaluados — fallo tecnológico, desastre natural, incidente de seguridad, pérdida de personal clave, fallo de proveedor crítico. Con probabilidad, impacto y medidas de tratamiento. |
| BCP | Plan de Continuidad de Negocio. Procedimientos de activación, árbol de decisión, roles y responsabilidades, comunicación interna y externa, alternativas operativas para cada proceso crítico. |
| DRP | Plan de Recuperación ante Desastres. Técnico y específico: cómo se recuperan los sistemas críticos, en qué orden, con qué recursos y en qué tiempos. Coherente con los RTO del BIA. |
| Política de continuidad | Documento de alto nivel firmado por la dirección que establece el compromiso de la organización con la continuidad de negocio, el alcance del sistema y los objetivos. |
«Pensaba que con el BIA era suficiente». Delimita el problema antes de elegir una respuesta.
Lo que debe existir antes de la auditoría. Busca una práctica observable, no solo una declaración.
Coherencia entre documentos y realidad. La decisión y su revisión deben dejar trazabilidad.
| Proveedores críticos | Contratos con SLAs que soporten los RTO declarados. Si tu RTO es 4 horas pero tu proveedor de hosting garantiza recuperación en 24 — hay una contradicción que el auditor va a señalar. |
| Comunicación de crisis | Plan de comunicación: quién informa, a quién, en qué momento y con qué mensaje. Clientes, proveedores, empleados, medios, reguladores. Con plantillas de comunicación preparadas. |
| Instalaciones alternativas | Si las instalaciones principales no están disponibles, ¿dónde trabaja el equipo? ¿Está contratado un espacio alternativo? ¿Funciona el trabajo remoto para todos los procesos críticos? |
| Inventario de recursos | Personal clave con sustitutos identificados. Sistemas críticos con alternativas documentadas. Equipamiento necesario para la recuperación localizado y accesible. |
| Declaración de alcance | Qué procesos, sistemas y ubicaciones están dentro del SGCN y cuáles están fuera, con justificación. El auditor verificará que el alcance es coherente con la criticidad real del negocio. |
| Ref. | Capa de evidencia | Qué debería permitir comprobar |
|---|---|---|
| EV-01 | BIA y dependencias | Quién es responsable, qué alcance se ha definido y qué decisión se ha tomado. |
| EV-02 | Estrategias y procedimientos | Que el control o proceso se aplica sobre casos reales y no existe únicamente en la documentación. |
| EV-03 | Resultados de ejercicios y acciones | Que las desviaciones se detectan, se corrigen y vuelven a revisarse con una frecuencia razonable. |
El error habitual al abordar este tema es convertirlo demasiado pronto en un documento o en una lista de tareas. En Continuidad de negocio, yo lo llevaría primero a un modelo operativo verificable: qué queda dentro del alcance, quién puede decidir, qué condiciones activan una revisión y qué rastro queda después de cada actuación.
Para este caso partiría de alcance y criterios. No porque sea el único punto importante, sino porque permite fijar el contexto antes de discutir controles. A partir de ahí conectaría muestreo y trazabilidad con la realidad del SGCN y cerraría el ciclo con hallazgos, causa y cierre efectivo.
La pregunta que utilizaría para probar la madurez sería sencilla: ¿puede una persona que no participó en el proyecto reconstruir la decisión, entender el riesgo y localizar la evidencia sin depender de una explicación oral? Si la respuesta es no, existe conocimiento, pero el gobierno todavía depende de personas concretas.
No intentaría implantar todo de una vez. Seleccionaría un caso representativo, documentaría la cadena BIA, estrategia, plan, ejercicio y mejora y comprobaría dónde se pierde la trazabilidad.
El primer objetivo no sería «tener más documentación», sino conseguir que el propietario del proceso crítico pueda demostrar qué decidió, por qué lo decidió y cómo sabe que el control sigue funcionando.
| Plano de revisión | Qué comprobaría | Señal de debilidad | Evidencia útil |
|---|---|---|---|
| Contexto | Alcance y criterios; límites, dependencias y supuestos. | El alcance cambia según quién lo explique. | Ficha de alcance, inventario o mapa de dependencias vigente. |
| Gobierno | Propietario, capacidad de decisión, escalado y excepciones. | IT ejecuta, pero nadie de negocio acepta el riesgo. | RACI, acta, ticket de decisión o registro de aceptación. |
| Control | Muestreo y trazabilidad; diseño, cobertura y operación real. | Se describe el control, pero no su población ni frecuencia. | Configuración, procedimiento, muestra de ejecución y resultado. |
| Supervisión | Hallazgos, causa y cierre efectivo; umbrales, desviaciones y revisión. | Solo se revisa cuando llega una auditoría o un incidente. | KPI/KRI, revisión periódica, hallazgo y acción de mejora. |
Utilizar ««Pensaba que con el BIA era suficiente»» como punto de entrada para describir la realidad actual, incluidas excepciones y dependencias que no aparecen en el procedimiento.
Tomar «Lo que debe existir antes de la auditoría» y comprobarlo con una muestra real. La documentación debe coincidir con usuarios, activos, configuraciones, decisiones o registros.
Relacionar «Documentos que el sistema está funcionando» con un responsable, una fecha y una evidencia de revisión. Una desviación sin seguimiento es información, no gobierno.
Estas preguntas no sustituyen una auditoría ni una evaluación formal. Sirven como prueba rápida de coherencia: si varias respuestas dependen de «creo», «normalmente» o «lo lleva otra persona», ya existe una línea de trabajo.
Si mañana la persona que domina este tema deja la organización, ¿el sistema seguiría funcionando y podríamos demostrar por qué se tomaron las decisiones? Esa respuesta suele revelar el nivel real de institucionalización.
La cantidad de documentación no es una medida de madurez. Para «Qué revisa un auditor de continuidad de negocio» prefiero una cadena corta de evidencias conectadas a la operación. Cada pieza debe responder a una pregunta distinta: qué decidimos, qué hicimos, qué ocurrió y qué revisamos después.
La siguiente matriz es el paquete mínimo que intentaría localizar en una revisión. El formato puede ser un acta, un ticket, una exportación, una configuración o un registro de una herramienta; lo importante es la trazabilidad y la coherencia entre las piezas.
| Ref. | Evidencia | Qué debería demostrar | Qué revisaría |
|---|---|---|---|
| EV-01 | Alcance y propietario | Qué cubre el control y quién responde por él. | Vigencia, exclusiones, dependencias y aceptación del propietario. |
| EV-02 | Criterio de riesgo | Por qué se ha priorizado o diseñado de una forma concreta. | Alcance y criterios, escenario, impacto y supuestos utilizados. |
| EV-03 | Diseño del control | Qué debe ocurrir, sobre qué población y con qué frecuencia. | Muestreo y trazabilidad, responsables, entradas, salidas y excepciones. |
| EV-04 | Muestra de ejecución | Que el control opera fuera del documento. | Fecha, población, resultado, anomalías y trazabilidad técnica u operativa. |
| EV-05 | Desviación y tratamiento | Cómo responde la organización cuando el control falla. | Causa, riesgo residual, responsable, plazo y medida compensatoria. |
| EV-06 | Revisión y mejora | Que hallazgos, causa y cierre efectivo se evalúa y puede cambiar. | Indicadores, tendencia, decisiones, cambios aprobados y seguimiento. |
Yo intentaría seguir una sola muestra de extremo a extremo. Si EV-01 dice una cosa, EV-03 otra y EV-04 no permite identificar la población afectada, el problema no es «falta de un PDF»: es una ruptura de trazabilidad.
La forma más útil de trabajar este tema es convertirlo en una cadena verificable de decisiones, responsables y evidencias. No basta con afirmar que existe un control: hay que poder reconstruir qué se decidió, con qué información, quién lo ejecutó y cómo se comprobó después.
En Qué revisa un auditor de continuidad de negocio, el análisis debería cubrir al menos población, periodo, muestra, criterio, corroboración y conclusión. Esto exige coordinar a Dirección, Continuidad, Tecnología, Operaciones, Seguridad, Comunicación y propietarios de proceso y trabajar sobre procesos, servicios, recursos, dependencias, RTO, RPO, planes, contactos y pruebas. Cuando cada área conserva una parte distinta de la información, se retrasan decisiones, se duplican controles y se aceptan excepciones sin una visión completa.
Una forma práctica de evitarlo es utilizar un expediente único por servicio, sistema, proceso o decisión relevante. Puede ser una herramienta GRC, un repositorio documental controlado o un registro estructurado. Lo importante es conectar alcance, propietario, riesgo, control, evidencia, excepción y acción, con fecha, fuente y estado.
Ese expediente debe mantenerse durante la operación ordinaria. Si solo se completa antes de una auditoría, la organización obtiene una fotografía preparada, pero no una visión fiable del control. La actualización debería activarse ante cambios de arquitectura, proveedor, alcance, responsables, requisitos, incidentes o resultados de pruebas. También conviene definir una revisión periódica para detectar documentación formalmente vigente pero materialmente obsoleta.
La revisión debe separar cuatro preguntas: si el control está bien diseñado, si se ha implantado en todo el alcance, si funciona de forma sostenida y si reduce realmente el riesgo o cumple el objetivo. Mezclar estas preguntas lleva a conclusiones débiles: una política aprobada puede no haberse desplegado, una herramienta instalada puede no cubrir toda la población y una actividad ejecutada puede no producir el efecto esperado.
| Dimensión | Qué debe quedar definido | Evidencia esperada |
|---|---|---|
| Alcance | Procesos, servicios, sistemas y terceros incluidos en «Qué revisa un auditor de continuidad de negocio». | Alcance aprobado, inventario y exclusiones justificadas. |
| Responsabilidad | Quién decide, ejecuta, valida y acepta desviaciones. | RACI, actas, aprobaciones y propietarios nominativos. |
| Operación | Actividades repetibles, entradas, salidas, plazos y escalados. | Procedimiento, tickets, registros, alertas y métricas. |
| Eficacia | Cómo se comprueba que el control cambia el riesgo o el resultado. | Pruebas, tendencias, incidencias, muestreo y acciones. |
Una captura demuestra un estado puntual. Un expediente completo demuestra el proceso, el criterio, la trazabilidad y la capacidad de corregir.
El objetivo no es generar más documentación, sino conservar la documentación que permite gobernar, operar y demostrar. La madurez aparece cuando las evidencias nacen del proceso ordinario y no de una campaña previa a la auditoría.