ISO/IEC 27001:2022: arquitectura y bloques del SGSI moderno

La pregunta que cualquier responsable de seguridad de la información debería hacerse al aproximarse a ISO/IEC 27001:2022 no es «¿cuántos controles nuevos tiene?», sino «¿qué arquitectura de gestión exige y cómo se articula con lo que ya existe en mi organización?». La guía de implementación publicada por el ISACA Germany Chapter responde precisamente a esa pregunta con una orientación pragmática que va más allá de la mera exégesis normativa. Su lectura permite identificar tanto el andamiaje conceptual del estándar como las fricciones que la práctica genera al confrontarlo con estructuras organizativas reales.

El estándar como sistema de gobierno, no como catálogo de controles

Un error interpretativo frecuente consiste en reducir ISO/IEC 27001:2022 a su Anexo A —ahora compuesto por 93 controles frente a los 114 de la versión 2013— sin advertir que la norma es, ante todo, un sistema de gestión. La guía subraya esta distinción al articular el Sistema de Gestión de Seguridad de la Información (SGSI) desde tres perspectivas complementarias que no son categorías meramente descriptivas sino criterios de diseño: la perspectiva de gobernanza (Governance view), orientada a alinear los objetivos de seguridad con los objetivos de negocio; la perspectiva de riesgos (Risk view), que fundamenta la toma de decisiones en la evaluación sistemática de amenazas sobre la confidencialidad, integridad y disponibilidad de activos de información; y la perspectiva de cumplimiento (Compliance view), que integra requisitos legales, reglamentarios y contractuales como vectores de diseño del SGSI.

Conviene recordar que esta triple perspectiva no opera de manera independiente. La guía la representa gráficamente como un sistema en el que la gestión corporativa —con sus objetivos y apetito de riesgo— filtra hacia abajo hasta las medidas operativas de seguridad, mientras que los informes de cumplimiento y los resultados de auditoría retroalimentan hacia arriba las decisiones de dirección. Este modelo integrado, atribuido a Carmao GmbH, hace explícita una premisa que el texto normativo solo sugiere: la seguridad de la información no es una función técnica periférica sino un componente del sistema de gobierno corporativo.

Los catorce bloques funcionales: racionalidad de la estructura

La contribución metodológica más original de la guía consiste en reorganizar los contenidos de ISO/IEC 27001:2022 —que sigue la estructura armonizada del Anexo SL— en catorce bloques funcionales que reflejan la lógica operativa de un SGSI antes que la numeración del estándar. Esta decisión editorial no es trivial: reconoce que la estructura de la norma responde a criterios de estandarización transversal entre sistemas de gestión ISO, no necesariamente a la secuencia lógica en que una organización debe abordar la implementación.

Los catorce bloques son: Contexto de la Organización; Liderazgo y Compromiso; Objetivos de Seguridad de la Información; Política de Seguridad; Roles, Responsabilidades y Competencias; Gestión de Riesgos; Monitorización de Rendimiento, Riesgos y Cumplimiento; Documentación; Comunicación; Concienciación (Awareness); Relaciones con Proveedores; Auditoría Interna; Gestión de Incidentes; y Mejora Continua. La lectura sistemática de la guía permite verificar que estos bloques no son compartimentos estancos sino nodos de un grafo en el que cada uno condiciona el diseño de los demás.

Contexto organizacional y alcance: el primer error que lo contamina todo

La guía dedica atención privilegiada al bloque de Contexto de la Organización porque advierte —con fundamento en la experiencia de auditoría— que los errores cometidos en la definición del alcance del SGSI son los más costosos de corregir. Un alcance mal delimitado produce una Declaración de Aplicabilidad (Statement of Applicability, SoA) que no refleja los activos reales en riesgo, certificaciones que no cubren los procesos relevantes para terceros interesados, y análisis de riesgos construidos sobre una base deficiente.

La norma exige que el alcance sea documentado y que identifique los activos —procesos, unidades de negocio, ubicaciones, aplicaciones— incluidos y excluidos. Pero la guía va más lejos al señalar que el nivel de detalle adecuado no deriva de un criterio formal sino de los requisitos internos y externos de seguridad de la información para el ámbito en cuestión. El análisis del entorno (environment analysis) y el análisis de requisitos (requirements analysis) son los instrumentos que alimentan esta determinación. El primero mapea interfaces organizativas y técnicas —otros sistemas de gestión, departamentos de riesgo, recursos humanos, protección de datos— así como el entorno externo, con proveedores y socios estratégicos. El segundo establece qué partes interesadas existen y qué requisitos imponen sobre la organización: desde el RGPD y las instrucciones de autoridades reguladoras hasta las obligaciones contractuales con clientes.

Lo que resulta llamativo en este análisis es la advertencia práctica sobre el uso de certificados como sustitutos del alcance detallado. La guía señala que, en la práctica, las organizaciones presentan certificados ISO/IEC 27001 a solicitudes de terceros que —en una lectura cuidadosa— no cubren los procesos o infraestructuras que el solicitante necesita verificar. Esta observación apunta a un problema sistémico: la certificación puede generar una señal de cumplimiento que oscurece la realidad del alcance efectivo.

Liderazgo, compromiso y el problema del «tono desde arriba»

La sección dedicada al Liderazgo y Compromiso aborda con franqueza una tensión que cualquier CISO conoce: la dependencia estructural del SGSI respecto de un mandato de dirección que, en la práctica, no siempre se traduce en conducta observable. ISO/IEC 27001:2022 exige que la alta dirección asuma de manera demostrable la responsabilidad global sobre la seguridad de la información. Esta exigencia tiene dos dimensiones. La primera, visible en el texto normativo, se refiere a la asignación de recursos, la comunicación de la importancia del SGSI y la conducción de revisiones de gestión. La segunda, subrayada por la guía, concierne a la función de modelo que la dirección ejerce —el llamado tone from the top— en la aceptación de no conformidades, el cumplimiento ejemplar de requisitos de seguridad y el respaldo visible a medidas impopulares.

La guía precisa el concepto de «alta dirección» a efectos del estándar: no se refiere necesariamente al máximo nivel del grupo corporativo, sino al nivel que controla el ámbito cubierto por el SGSI y decide sobre la asignación de recursos. Esta aclaración tiene relevancia directa para organizaciones matrices o con estructuras divisionales, donde el CISO puede operar bajo una dirección intermedia que, a efectos normativos, actúa como alta dirección. La implicación para los procesos de certificación es que la entidad certificadora puede requerir la participación del nivel jerárquico superior si el alcance del SGSI lo justifica.

Gestión de riesgos: proceso antes que herramienta

El tratamiento de la gestión de riesgos en la guía merece atención particular porque desplaza el foco desde las herramientas —matrices de evaluación, registros de riesgos— hacia el proceso subyacente. La norma exige un proceso de evaluación de riesgos que produzca resultados consistentes, válidos y comparables, sin prescribir una metodología concreta. Este margen de discreción es valorado por la guía como una fortaleza del estándar, pero también como fuente de errores de diseño frecuentes.

El proceso recomendado sigue la estructura de ISO 31000:2018 en cuatro pasos: identificación de riesgos, análisis, evaluación y tratamiento. Lo que la guía añade a esta secuencia conocida es una articulación de las fuentes de riesgo específicas para entornos de información —intercambio de datos interno y externo, sistemas heredados no actualizables, acceso remoto a redes corporativas, computación en la nube, ingeniería social, desastres naturales— que ancla la metodología en la realidad operativa antes que en categorías abstractas.

Dicho esto, la aportación más sustantiva es la discusión sobre los criterios de aceptación de riesgos. La guía señala que la definición de estos criterios es la tarea central del proceso de gestión de riesgos porque permite diferenciar entre riesgos que requieren tratamiento prioritario y riesgos que pueden aceptarse o transferirse. Sin criterios bien definidos, el proceso tiende a producir listas extensas de riesgos nominalmente identificados pero sin priorización real. Ahora bien, la guía advierte contra la tentación de establecer criterios excesivamente permisivos o excesivamente restrictivos: los primeros generan un SGSI que acepta riesgos que el apetito real de la organización no toleraría; los segundos producen un sistema que requiere el tratamiento de todo riesgo identificado, consumiendo recursos desproporcionados.

La responsabilidad del tratamiento se asigna al risk owner, definido como la entidad que soporta el impacto económico cuando el riesgo se materializa. Esta definición tiene una implicación organizativa relevante: aunque los riesgos puedan originarse en sistemas de TI gestionados por el departamento de tecnología, la responsabilidad sobre el tratamiento corresponde a las unidades de negocio cuyos procesos dependen de esos sistemas. La disociación entre responsabilidad de ejecución (IT) y responsabilidad global (accountability, unidades de negocio) es una distinción que la guía considera crítica para que el SGSI funcione como instrumento de gobierno y no como función técnica subordinada.

Monitorización y métricas: el problema de la medibilidad

El bloque dedicado a la monitorización del rendimiento introduce el marco de indicadores clave —KPI (Key Performance Indicators), KRI (Key Risk Indicators) y KCI (Key Control Indicators)— como instrumentos para hacer observable la eficacia del SGSI. La distinción entre las tres categorías no es meramente formal: los KPI miden el éxito en el logro de objetivos de seguridad; los KRI señalan cambios en el perfil de riesgo que podrían superar los límites de tolerancia definidos; los KCI verifican que los controles establecidos operan con la efectividad prevista.

La guía es honesta sobre la dificultad práctica de este bloque. Formular indicadores que sean al mismo tiempo específicos, medibles, relevantes para la seguridad y viables en términos de coste de recogida de datos es uno de los desafíos más exigentes de la implementación del SGSI. La norma requiere que los objetivos de seguridad sean medibles «en la medida en que sea practicable», formulación que la guía interpreta como más flexible que «en la medida en que sea posible», aunque sin que ello justifique la renuncia a la medibilidad. La recomendación práctica es comenzar con un número reducido de indicadores significativos para la organización concreta y ampliar progresivamente el sistema conforme madura el SGSI.

Auditoría interna y mejora continua: el circuito de retroalimentación

La auditoría interna del SGSI —diferenciada tanto de la auditoría de certificación como del sistema de control interno (ICS)— opera como el mecanismo primario de retroalimentación del ciclo de mejora. La guía distingue entre el programa de auditoría —estructura organizativa que define frecuencia, criterios, competencias de auditores y gestión de hallazgos— y las actividades de auditoría concretas, y señala que en organizaciones de cierto tamaño conviene separar organizativamente la responsabilidad de ambas dimensiones.

El programa de auditoría debe garantizar que todos los procesos cubiertos por el SGSI sean auditados al menos una vez cada tres años respecto de los requisitos de seguridad aplicables en el momento de la auditoría. Esta periodicidad no es un criterio arbitrario sino el reflejo de un equilibrio entre la necesidad de cobertura completa y la limitación de recursos disponibles para auditoría interna.

El ciclo PDCA (Plan-Do-Check-Act) subyace al bloque de mejora continua como marco de referencia, aunque la guía lo articula en términos de acciones correctivas —orientadas a eliminar la causa raíz de no conformidades para prevenir su repetición— y correcciones —orientadas a remediar la situación no conforme inmediata sin necesariamente abordar la causa—. Esta distinción, que la norma establece en su sección 10.1, es relevante porque las organizaciones frecuentemente aplican correcciones sin implementar acciones correctivas, lo que genera la recurrencia de los mismos problemas en ciclos de auditoría sucesivos.

Los cambios respecto a la versión 2013: lo que el estándar actualiza

La versión 2022 de ISO/IEC 27001 introduce modificaciones en el cuerpo principal de la norma —adaptadas a la nueva Estructura Armonizada del Anexo SL— y una renovación sustancial del Anexo A, que ahora refleja íntegramente los controles de ISO/IEC 27002:2022. Las modificaciones en el cuerpo principal incluyen: la exigencia de determinar cuáles de los requisitos de las partes interesadas se abordan en el marco del SGSI (sección 4.2); la incorporación explícita de la planificación de cambios al SGSI (sección 6.3); la adición del monitoreo de los objetivos de seguridad (sección 6.2); y la reorganización del capítulo 10 para anteponer la mejora continua a las no conformidades, señalando una orientación hacia la proactividad frente a la corrección reactiva.

En el Anexo A, la reducción de 114 a 93 controles no representa una disminución de requisitos sino una racionalización por agrupación y eliminación de redundancias: 57 controles de la versión anterior se consolidan en 24, un control se divide en dos y se añaden 11 controles nuevos que abordan áreas emergentes. Entre los nuevos controles destacan la inteligencia sobre amenazas (Threat intelligence, 5.7), la seguridad de la información en servicios en la nube (5.23), la preparación de las TIC para la continuidad del negocio (5.30), el enmascaramiento de datos (8.11), la prevención de fuga de datos (8.12), la gestión de configuración (8.9), la eliminación de información (8.10), las actividades de monitorización (8.16), el filtrado web (8.23) y la codificación segura (8.28). La restructuración en cuatro categorías —controles organizativos, de personas, físicos y tecnológicos— facilita la asignación de responsabilidades por dominio y la creación de vistas diferenciadas para distintos grupos de interés mediante los nuevos atributos de los controles.

Integración con otros sistemas de gestión: la economía del cumplimiento

La guía dedica un capítulo final a la integración del SGSI con otros sistemas de gestión —ISO 9001, ISO 22301, ISO 14001— y a la operacionalización mediante lo que denomina una «base de datos corporativa de controles». Esta arquitectura de control consolidada, que alinea controles de múltiples estándares sobre una capa de dominios temáticos comunes, responde a una realidad que las organizaciones con múltiples certificaciones conocen bien: la gestión paralela de controles equivalentes en distintos marcos normativos genera duplicidades, aumenta la carga de evidencias y produce confusión en los responsables operativos sobre qué requisito de qué estándar están atendiendo en cada momento.

La propuesta metodológica —organizar los controles por dominio temático y vincularlos mediante una metaestructura a los distintos estándares aplicables— no es nueva en el ámbito del GRC (Governance, Risk and Compliance), pero la guía la presenta con suficiente concreción como para orientar decisiones de diseño reales. La referencia al COBIT 2019 como marco de orientación para la estructura de dominios resulta coherente con el perfil de la audiencia de ISACA, aunque la guía reconoce que el marco de control secundario puede variar en función del sector: TISAX para automoción, la Cloud Control Matrix de CSA para proveedores de software como servicio, el Compendio de IT-Grundschutz del BSI en entornos regulados alemanes.

Conclusión: lo que la norma exige y lo que la guía aporta

Tres conclusiones articulan el valor doctrinal de esta guía de implementación. Primera, que ISO/IEC 27001:2022 exige fundamentalmente un sistema de gobierno de la seguridad de la información —con mandato de dirección, gestión de riesgos basada en el contexto organizacional, objetivos medibles y ciclo de mejora continua— y que los 93 controles del Anexo A son instrumentos de ese sistema, no su contenido esencial. Segunda, que los catorce bloques funcionales propuestos por ISACA permiten abordar la implementación con una lógica operativa más próxima a la realidad organizacional que la estructura armonizada del estándar, sin dejar de cumplir todos los requisitos normativos. Tercera, que los errores más costosos en la implementación del SGSI no son técnicos sino de diseño: un alcance deficientemente delimitado, criterios de aceptación de riesgos mal calibrados, y la ausencia de un propietario de riesgo claramente identificado para cada riesgo tratado son los factores que con mayor frecuencia comprometen la efectividad real del sistema frente a la mera apariencia de cumplimiento.