Qué exige la ISO 27001 en el análisis de riesgos
El análisis de riesgos es el núcleo de un sistema de gestión de seguridad de la información (SGSI) conforme a la ISO 27001. Casi todas las demás decisiones del sistema dependen de él: qué controles del Anexo A aplican, qué entra en el plan de tratamiento, dónde se invierte el esfuerzo. Por eso los auditores le dedican tanto tiempo, y por eso un análisis flojo debilita todo lo que se construye encima.
La ISO 27001:2022 establece qué debe conseguir el proceso, no cómo hacerlo. Los requisitos están en tres cláusulas: la 6.1.2 para el análisis de riesgos, la 6.1.3 para el tratamiento y la 8.2 para su ejecución a lo largo del tiempo. Leídas juntas, describen un ciclo, no un documento.
Cláusula 6.1.2: el análisis de riesgos
En resumen, la cláusula 6.1.2 obliga a definir y aplicar un proceso que establezca criterios de riesgo, tanto de aceptación como para realizar las evaluaciones; que produzca resultados coherentes, válidos y comparables cuando se repite; que identifique los riesgos para la confidencialidad, integridad y disponibilidad de la información dentro del alcance; que asigne un propietario a cada uno; que analice las consecuencias potenciales y la probabilidad realista de cada riesgo; que determine niveles de riesgo; y que los evalúe frente a los criterios para priorizar su tratamiento.
La organización también debe conservar información documentada sobre el proceso. En la práctica, eso significa una metodología escrita que otra persona pueda aplicar de la misma forma, no solo el resultado. Un auditor que encuentra un registro de riesgos sin ninguna descripción de cómo se calcularon las puntuaciones lo va a señalar.
Cláusula 6.1.3: el tratamiento
En resumen, la cláusula 6.1.3 parte de los riesgos evaluados y exige elegir opciones de tratamiento, determinar los controles necesarios y compararlos con el Anexo A para comprobar que no se ha omitido ninguno necesario. La propia norma aclara que el Anexo A no es exhaustivo, así que se pueden añadir controles que no estén en él si los riesgos lo requieren.
La misma cláusula exige la Declaración de Aplicabilidad, un plan de tratamiento y la aprobación de los propietarios del riesgo, tanto del plan como de los riesgos residuales que quedan después. Este último requisito se olvida con frecuencia: el riesgo residual tiene que aceptarlo expresamente quien responde de él, y esa aceptación debe quedar registrada.
Cláusula 8.2: realizarlo de forma planificada
La cláusula 8.2 lleva el proceso de la planificación a la operación. En resumen, exige realizar el análisis a intervalos planificados y también cuando se propongan o se produzcan cambios significativos, aplicando los criterios definidos en la 6.1.2. Los resultados deben conservarse como información documentada.
La cláusula 8.3 exige después implantar el plan de tratamiento y conservar sus resultados. Con estas dos cláusulas el auditor comprueba si el análisis está vivo. Un primer análisis preparado para la fase 1 de la auditoría de certificación y que nadie vuelve a tocar cumple la 6.1.2 sobre el papel y falla la 8.2 en la primera auditoría de seguimiento.
Cómo fijar los criterios antes de empezar
La mayoría de los análisis se tuercen antes de escribir el primer riesgo, porque nunca se acordaron los criterios. Sin ellos, dos personas valoran el mismo riesgo de forma distinta, las puntuaciones cambian de un año a otro y nadie puede decir qué riesgos son aceptables. Por eso la cláusula 6.1.2 pide los criterios primero.
Criterios de aceptación
Los criterios de aceptación definen el nivel de riesgo que la organización está dispuesta a asumir sin más tratamiento. Una forma habitual es un umbral en la matriz de riesgos: lo que queda por debajo de cierto nivel puede aceptarlo el propietario; lo que lo supera se trata o se eleva a dirección para que decida.
Los criterios deben reflejar el negocio, no una plantilla. Una empresa cuyo producto es una plataforma que usan sus clientes a diario puede tolerar muy poco riesgo de disponibilidad; otra que trata datos de salud o financieros puede ser más estricta con la confidencialidad. Sea cual sea la decisión, debe aprobarla la dirección y quedar por escrito, porque todas las decisiones de aceptación posteriores se remiten a ella.
Criterios para que el análisis sea coherente
El segundo bloque de criterios define cómo se hace el análisis: la escala de probabilidad, la de impacto, cómo se combinan en un nivel de riesgo, quién participa y con qué frecuencia. Una escala de cinco niveles para cada una, combinadas en una matriz, es una elección frecuente. Lo importante es que cada nivel esté definido en términos aplicables, como "puede ocurrir en el próximo año" o "pérdida de un contrato con un cliente clave", y no solo "medio".
Estas definiciones son las que permiten cumplir el apartado b) de la cláusula 6.1.2: que los análisis repetidos den resultados coherentes y comparables. Si el "alto" del año pasado y el de este año significan cosas distintas, la organización no puede demostrar si su situación de riesgo ha mejorado, y el auditor lo nota.
Cómo identificar los riesgos y asignar propietarios
En la identificación el alcance se vuelve concreto. La pregunta es qué hechos podrían comprometer la confidencialidad, integridad o disponibilidad de la información dentro del alcance del SGSI, y la respuesta tiene que cubrir tecnología, personas, proveedores e instalaciones, no solo los sistemas.
Enfoque basado en eventos y enfoque basado en activos
La ISO 27001 no impone cómo identificar riesgos. La ISO 27005:2022, la norma de orientación para la gestión de riesgos de seguridad de la información, describe dos enfoques complementarios. El basado en eventos parte de fuentes de riesgo y escenarios: qué puede pasar, quién o qué lo provocaría y qué consecuencias tendría. El basado en activos parte de los activos de información y de las amenazas y vulnerabilidades que afectan a cada uno.
En España, muchas organizaciones que también trabajan con el ENS usan MAGERIT, la metodología de análisis y gestión de riesgos elaborada por el Consejo Superior de Administración Electrónica, apoyada por la herramienta PILAR del Centro Criptológico Nacional. Es un enfoque basado en activos y es perfectamente válido para la ISO 27001, siempre que se cumplan los requisitos de la cláusula 6.1.2. Lo que importa no es la metodología elegida, sino que se aplique con criterios definidos y de forma coherente. Usar un único enfoque tiene un riesgo: dejar fuera lo que el otro habría detectado, como un escenario de negocio que no aparece mirando activo por activo, o una cuenta de un antiguo empleado que sigue activa en una herramienta SaaS.
Por qué cada riesgo necesita un propietario
La cláusula 6.1.2 exige un propietario para cada riesgo identificado. El vocabulario de la ISO lo define como la persona o entidad que tiene la responsabilidad y la autoridad para gestionar el riesgo. Es un rol de negocio, no automáticamente el responsable de sistemas: el propietario de un riesgo sobre los datos de clientes en el CRM suele ser la dirección comercial o de operaciones, porque decide cómo se usa ese sistema.
La propiedad es lo que convierte el registro en decisiones. El propietario aprueba el tratamiento, acepta el riesgo residual y responde cuando el auditor pregunta por qué se eligió un control. Un registro en el que todos los riesgos son de "IT", o de nadie, es para un auditor una de las señales más claras de que el análisis se redactó pero no se gestiona.
Cómo analizar y evaluar cada riesgo
El análisis asigna un nivel a cada riesgo y la evaluación lo compara con los criterios de aceptación. Ambos pasos dependen de los criterios fijados al principio; si se saltó ese trabajo, aquí aparece en forma de puntuaciones incoherentes.
Escalas de probabilidad e impacto
Para cada riesgo se estima la probabilidad realista de que ocurra y el impacto si ocurriera, teniendo en cuenta los controles que ya existen. La norma habla de probabilidad realista, así que la estimación debe apoyarse en lo que se sabe: historial de incidentes, amenazas propias del sector, la exposición real de la organización y la eficacia de los controles en funcionamiento.
El impacto conviene expresarlo en términos de negocio: interrupción de la actividad, exposición contractual o regulatoria, pérdida de clientes, daño a personas. Así las puntuaciones se pueden defender ante la dirección y el análisis se conecta con lo que de verdad le importa a la organización, no con una severidad técnica abstracta.
Priorizar frente a los criterios de aceptación
Con un nivel asignado a cada riesgo, la evaluación los ordena. Los que están dentro de los criterios pueden aceptarlos sus propietarios; los que superan el umbral pasan a tratamiento, por orden de nivel. Ese orden es el que sigue el plan de tratamiento y debería notarse en cómo se reparten los recursos.
La evaluación es también el momento de revisar el conjunto. Si casi todo sale alto, probablemente las escalas están mal calibradas. Si casi todo es aceptable, puede que el análisis subestime la exposición o que se atribuya a los controles existentes más eficacia de la que tienen. Conviene corregir ambos patrones antes de construir el plan de tratamiento sobre ellos.
Cómo alimenta el análisis el plan de tratamiento y la Declaración de Aplicabilidad
En la cláusula 6.1.3 el análisis produce sus dos resultados más visibles: el plan de tratamiento y la Declaración de Aplicabilidad. Ambos deben poder trazarse hasta riesgos concretos. Si no se puede, el auditor concluirá que primero se eligieron los controles y después se escribieron riesgos para justificarlos.
Las cuatro opciones de tratamiento
La ISO 27005 y la ISO 31000 describen las opciones entre las que se suele elegir. Un riesgo se puede modificar, añadiendo o mejorando controles para reducir probabilidad o impacto; retener, aceptándolo tal como está dentro de los criterios; evitar, dejando de hacer la actividad que lo genera; o compartir, transfiriendo parte de él, por ejemplo con un seguro o un contrato con un proveedor.
Cada opción es una decisión de negocio y necesita un registro de quién la tomó y por qué. Compartir un riesgo con un proveedor no elimina la obligación de supervisarlo, y retener un riesgo por encima del umbral de aceptación requiere la aprobación expresa de la dirección. El plan de tratamiento recoge qué opción aplica a cada riesgo, las acciones, el responsable y los plazos.
Cómo enlazar el tratamiento con los controles del Anexo A
Los controles elegidos para modificar los riesgos se comparan después con los 93 controles del Anexo A de la ISO 27001:2022, agrupados en cuatro temas: organizativos, de personas, físicos y tecnológicos. La Declaración de Aplicabilidad recoge, para cada control del Anexo A, si se incluye, si está implantado y la justificación de su inclusión o exclusión.
En esa justificación se ve el vínculo con el análisis. Un control incluido porque trata riesgos concretos, y otro excluido porque ningún riesgo identificado lo requiere, dejan al auditor un rastro limpio. Una Declaración de Aplicabilidad en la que todos los controles figuran como aplicables, sin referencia a ningún riesgo, sugiere que el análisis no influyó en la selección de controles.
Cuándo hay que repetir el análisis
La cláusula 8.2 exige repetir el análisis a intervalos planificados y cuando se propongan o se produzcan cambios significativos. La norma no fija el intervalo; un ciclo anual alineado con la revisión por la dirección de la cláusula 9.3 es la práctica habitual. La revisión por la dirección debe tener en cuenta los resultados del análisis de riesgos y el estado del plan de tratamiento, así que alinear ambos mantiene los dos con sentido.
Los cambios significativos obligan a un análisis fuera de ciclo. Los más habituales son un nuevo producto o servicio, el cambio de proveedor cloud, una adquisición, nuevas obligaciones normativas, el cambio de un proveedor crítico o un incidente grave. La palabra clave de la cláusula 8.2 es "propongan": el análisis debe hacerse antes de que el cambio entre en producción, cuando todavía puede influir en el diseño, no meses después.
Qué suelen encontrar mal los auditores
Las observaciones de los auditores sobre el análisis de riesgos se repiten mucho. Criterios que nunca se documentaron ni aprobaron, de modo que las puntuaciones no se pueden reproducir. Registros de riesgos sin propietarios, o con todos los riesgos asignados a la misma persona. Planes de tratamiento con acciones pero sin fechas ni responsables. Riesgos residuales que nadie aceptó formalmente.
Otras observaciones surgen cuando el análisis se aleja de la realidad. Riesgos que solo cubren tecnología y olvidan personas, proveedores y seguridad física. Una Declaración de Aplicabilidad con exclusiones que el análisis no justifica. Y, sobre todo en auditorías de seguimiento, un análisis que no se actualizó tras un cambio significativo que el auditor ve en otras evidencias, como una migración o una nueva línea de producto. El artículo sobre cómo reactivar un proyecto ISO 27001 parado explica cómo se acumulan estas carencias cuando nadie se ocupa del sistema entre auditorías, y SGSI vs políticas de seguridad explica por qué es el proceso de riesgos, y no el conjunto de documentos, lo que convierte el SGSI en un sistema de gestión.
La plataforma de Qalea reúne en un mismo lugar la gestión de riesgos, los controles y las evidencias, de modo que el registro, el plan de tratamiento y las pruebas de cada control se mantienen juntos. El equipo de Qalea acompaña el trabajo alrededor: fijar criterios que la organización pueda aplicar de forma coherente, hacer los análisis con los propietarios adecuados y avisar cuando un cambio en el negocio debería dar lugar a uno nuevo. La página de ISO 27001 reúne el resto de la serie.
