Quien implementa la ISO 27001 suele atascarse en el mismo punto: las cláusulas 6.1.2 y 6.1.3 exigen un proceso de apreciación y de tratamiento de riesgos, con criterios definidos y resultados repetibles — y no explican cómo construir ese proceso. Quien lo explica es la ISO/IEC 27005.
Esa división es intencional. La 27001 es norma de requisitos: dice qué debe existir para que haya certificación. La 27005 es norma de orientación: describe un camino posible para cumplir el requisito. No te certificas en la 27005, y ningún auditor va a exigir que tu metodología sea exactamente la suya. Pero sí va a exigir que exista una metodología, documentada, aplicada y capaz de producir el mismo resultado al repetirse.
Qué pide realmente la 27001
Antes de mirar la 27005, conviene separar lo obligatorio de lo que es elección tuya:
- Criterios definidos antes. El criterio de aceptación del riesgo y el criterio para ejecutar las apreciaciones deben estar escritos antes de evaluar el primer riesgo. Definir el criterio después de ver el resultado es elegir el blanco después del disparo.
- Resultados consistentes y comparables. Dos personas aplicando el mismo método a los mismos hechos deben llegar cerca. Si el resultado cambia según quién completa la hoja, eso no es método: es opinión con formato.
- Cada riesgo con dueño. Cada riesgo identificado necesita un responsable — y ese responsable debe tener autoridad para aceptarlo. Un analista no acepta riesgo de negocio.
- Trazabilidad hasta el Anexo A. El tratamiento elegido se vuelve control, y el control aparece en la Declaración de Aplicabilidad. Ahí es donde el análisis de riesgo se encuentra con el checklist del Anexo A.
Fíjate en lo que no está en la lista: matriz 5×5, escala de 1 a 5, mapa de calor. Nada de eso lo exige la norma. Son convenciones de mercado que mucha gente confunde con requisitos.
Qué cambió en la edición de 2022
La revisión de 2022 no fue cosmética. El título pasó a ser Information security, cybersecurity and privacy protection — Guidance on managing information security risks, reflejando un alcance más amplio que la seguridad de la información en sentido estricto.
- Alineación con la ISO 31000. El vocabulario se armonizó con la norma madre de gestión de riesgos. El término impacto dio lugar a consecuencia — no es un cambio de sinónimo, es alineación con el lenguaje que el resto de la organización ya usa para riesgo financiero y operativo.
- Escenario de riesgo. Entró el concepto de escenario como secuencia o combinación de eventos que lleva de la causa inicial a la consecuencia no deseada, en lugar del antiguo escenario de incidente.
- La aceptación dejó de ser una fase. Aceptar un riesgo pasó a ser una decisión tomada después del tratamiento, y no una etapa separada del proceso.
Revisa el año de tu copia. Buena parte del material de resumen disponible todavía describe la edición anterior, y los dos textos difieren en terminología y en estructura de proceso. Si tu metodología se escribió a partir de un resumen antiguo, probablemente usa palabras que el auditor va a esperar de otra forma.
Los dos enfoques de identificación
Aquí es donde la 27005 resulta más útil, y es la parte que casi nadie lee antes de armar la hoja de cálculo. La norma describe dos maneras de identificar riesgo, y exigen insumos muy distintos.
| Basado en eventos | Basado en activos | |
|---|---|---|
| Punto de partida | Qué puede salir mal para el negocio | Qué tenemos y cómo puede ser atacado |
| Profundidad | Apreciación de alto nivel | Apreciación en profundidad |
| Exige | Entender el negocio y sus partes interesadas | Un inventario fiable de activos, amenazas y vulnerabilidades |
| Bueno para | Empezar, priorizar, hablar con la dirección | Detallar lo que ya fue priorizado |
| Falla cuando | Se vuelve una lista de miedos genéricos sin dueño | El inventario está incompleto o desactualizado |
El enfoque basado en eventos parte de la consecuencia: facturación interrumpida, base de clientes expuesta, un servicio regulado indisponible. Produce pocos riesgos, todos ligados a algo que el negocio reconoce. El basado en activos parte del inventario y baja hasta amenaza y vulnerabilidad por activo. Produce muchas más líneas y mucho más detalle.
Cuál elegir
No son competidores, son una secuencia. El error más común en una primera implementación es empezar por el enfoque basado en activos porque parece más técnico y más completo — y atascarse tres meses después, con una hoja de ochocientas líneas que nadie revisa y que ya estaba desactualizada el día en que se terminó.
El camino que funciona es el inverso: empieza por eventos, llega a una lista corta de escenarios que la dirección reconoce como relevantes, y solo entonces baja al nivel de activo en los escenarios que sobrevivieron a la priorización. El detalle cuesta caro; gástalo donde cambia una decisión.
Hay un prerrequisito escondido en esto. El enfoque basado en activos solo funciona sobre un inventario fiable. Si la organización no sabe qué sistemas existen, quién es el dueño de cada uno y qué información trata cada uno, la apreciación en profundidad va a medir con precisión un universo que no corresponde a la realidad — y precisión sobre dato equivocado es lo peor de los dos mundos, porque parece rigor.
Qué va a pedir el auditor
Al final, el análisis de riesgo tiene que dejar cuatro evidencias. Ninguna de ellas es la hoja de cálculo en sí:
- El documento de metodología, con criterios de apreciación y de aceptación definidos antes de la primera ronda.
- El resultado de la apreciación, con riesgos identificados, analizados y priorizados según esos criterios.
- El plan de tratamiento, con control elegido, responsable y plazo para cada riesgo tratado.
- La aceptación formal de los riesgos residuales, firmada por quien tiene autoridad para aceptarlos.
Quien tiene esos cuatro documentos coherentes entre sí pasa la auditoría incluso con una metodología simple. Quien tiene una hoja sofisticada y ninguna aceptación formal no pasa.
Fuente consultada: ISO/IEC 27005:2022, Information security, cybersecurity and privacy protection — Guidance on managing information security risks. Este artículo tiene finalidad informativa; consulta el texto oficial de la norma antes de definir tu metodología.