Cómo se hace el análisis de riesgos en ISO 27001

Todo el sistema de gestión de seguridad de la información de la ISO 27001 se sostiene sobre una cosa: el análisis de riesgos. De él salen los controles que la organización decide aplicar y la declaración de aplicabilidad que el auditor revisa cláusula por cláusula. Cuando el análisis está bien hecho, el resto del sistema fluye; cuando se hace al revés —eligiendo controles primero y justificándolos después— el sistema completo queda sobre una base que no se sostiene en la auditoría.

Qué pide exactamente la norma

Las cláusulas 6.1.2 y 6.1.3 de la ISO 27001 exigen definir un proceso de apreciación de riesgos de seguridad de la información y un proceso de tratamiento. La apreciación debe identificar los riesgos asociados a la pérdida de confidencialidad, integridad y disponibilidad de la información dentro del alcance del sistema, analizarlos y evaluarlos con criterios definidos. El tratamiento debe seleccionar opciones para abordar esos riesgos y determinar los controles necesarios, comparándolos con los del Anexo A para no dejar ninguno fuera sin justificación.

La secuencia correcta: activo, amenaza, vulnerabilidad, riesgo

• —Identifica los activos de información: bases de datos, sistemas, documentos, know-how, infraestructura — todo lo que tiene valor y hay que proteger.
• —Determina las amenazas sobre cada activo: qué podría pasarle (robo de datos, ransomware, error humano, fallo de hardware, acceso no autorizado).
• —Identifica las vulnerabilidades: qué debilidad permitiría que la amenaza se materialice (falta de cifrado, contraseñas débiles, ausencia de respaldos, permisos sin control).
• —Evalúa probabilidad e impacto: cruza ambas para obtener el nivel de riesgo, con la misma escala para todos.
• —Define el tratamiento: mitigar (aplicar controles), aceptar, transferir o evitar. Los riesgos que decides mitigar generan los controles del sistema.

La declaración de aplicabilidad depende de este análisis

La declaración de aplicabilidad (SoA) —el documento estrella de la ISO 27001— lista cada control del Anexo A, indica si aplica o no y por qué, y solo tiene sentido si sale del análisis de riesgos. Si los controles se eligieron sin ese sustento, la SoA queda inconsistente y el auditor lo detecta al pedir la trazabilidad entre un riesgo y su control. Mantener ese vínculo vivo —cada riesgo con su tratamiento, su control y su responsable, recalculado cuando cambia el contexto— es justo lo que hace un Software de gestión de riesgos y oportunidades: conserva la apreciación de riesgos conectada con las acciones de tratamiento y evita que la matriz se congele en la foto que se armó para la certificación.