SGSI ISO 27001: gestionar controles, riesgos y evidencias

Un sistema de gestión de seguridad de la información no se sostiene con buenas intenciones ni con un manual guardado en una carpeta compartida. Se sostiene con orden: un catálogo de controles con su estado de aplicabilidad, un análisis de riesgos vivo, un plan de tratamiento, unos objetivos medibles, auditorías internas que dejan rastro, no conformidades con su plan de acción y, sobre todo, evidencias que demuestran que cada control funciona de verdad. Cuando ese orden falta, la auditoría lo detecta enseguida, porque el auditor no valora lo que dices que haces, sino lo que puedes probar que haces.

Este artículo es una guía para organizar ese trabajo con la norma ISO/IEC 27001 en la mano. Repasamos la estructura del sistema de gestión (las cláusulas 4 a 10), el Anexo A de la edición 2022 con sus 93 controles repartidos en cuatro grupos, la Declaración de Aplicabilidad como pieza central de la auditoría, el análisis y tratamiento de riesgos, los objetivos, las auditorías internas, las no conformidades y la revisión por dirección. Y lo conectamos con el Esquema Nacional de Seguridad, que en España sí es de obligado cumplimiento para el sector público, y con la razón por la que tantos pliegos piden acreditar controles de seguridad. Al final se ve por qué mantener el SGSI en el mismo entorno donde vive el conocimiento de la empresa permite reutilizar la evidencia cuando una licitación la reclama.

Lo esencial en 30 segundos

• ✓ISO/IEC 27001:2022 es una norma internacional voluntaria; el sistema de gestión lo definen sus cláusulas 4 a 10 (contexto, liderazgo, planificación, soporte, operación, evaluación y mejora).
• ✓El Anexo A de la edición 2022 reúne 93 controles en cuatro grupos: organizativos (37), de personas (8), físicos (14) y tecnológicos (34). La versión de 2013 tenía 114.
• ✓No se implantan todos los controles por defecto: se seleccionan según el riesgo y se justifican en la Declaración de Aplicabilidad (SoA), la pieza que más mira el auditor.
• ✓El motor del SGSI es el ciclo de mejora continua: apreciar riesgos, tratarlos, medir objetivos, auditar por dentro, corregir no conformidades y revisar por dirección.
• ✓El Esquema Nacional de Seguridad (Real Decreto 311/2022) sí es de obligado cumplimiento para el sector público y para quien le presta servicios por contrato.
• ✓Muchas licitaciones exigen acreditar controles de seguridad; la evidencia del SGSI puede reutilizarse para ese encaje si está ordenada y trazable.
• ✓Genlicit organiza y da trazabilidad al SGSI, pero no certifica ni garantiza el resultado de la auditoría, ni sustituye al responsable de seguridad.

Qué es un SGSI y qué pide ISO/IEC 27001:2022

Un SGSI, o sistema de gestión de seguridad de la información, es el conjunto de políticas, procesos, roles y controles con los que una organización gestiona de forma sistemática la confidencialidad, la integridad y la disponibilidad de su información. La clave está en la palabra sistema: no se trata de instalar antivirus y cifrar los portátiles, sino de gestionar la seguridad como un proceso continuo, con responsables, objetivos y revisiones periódicas. ISO/IEC 27001 es la norma internacional que fija los requisitos para establecer, implantar, mantener y mejorar ese sistema, y es la única de la familia ISO 27000 sobre la que una organización puede certificarse.

La edición vigente se publicó el 25 de octubre de 2022 y sustituyó a la de 2013. Conviene distinguir dos partes muy diferentes dentro de la norma. Por un lado, el cuerpo del texto, las cláusulas 4 a 10, que describe el sistema de gestión y es de cumplimiento obligatorio para certificarse. Por otro, el Anexo A, un catálogo de controles de seguridad que la organización selecciona en función de sus riesgos. Es un error frecuente empezar por el Anexo A eligiendo controles antes de haber montado el sistema de gestión que les da sentido. El orden correcto es el inverso: primero el sistema, después los controles que ese sistema decide aplicar.

Las cláusulas 4 a 10, el corazón del sistema

Las cláusulas numeradas del 4 al 10 son los requisitos que el auditor comprueba uno a uno. La cláusula 4, contexto de la organización, obliga a entender qué asuntos internos y externos afectan a la seguridad de la información, quiénes son las partes interesadas y qué esperan, y a fijar con precisión el alcance del SGSI, es decir, qué sedes, procesos y activos quedan dentro. Delimitar bien el alcance es una decisión estratégica: un alcance demasiado amplio dispara el esfuerzo, uno demasiado estrecho puede dejar fuera lo que el cliente esperaba ver certificado.

La cláusula 5, liderazgo, exige compromiso real de la dirección, una política de seguridad aprobada y un reparto claro de roles y responsabilidades. La cláusula 6, planificación, es donde entran el análisis de riesgos y los objetivos de seguridad, con sus indicadores. La cláusula 7, soporte, cubre los recursos, la competencia de las personas, la concienciación, la comunicación y el control de la documentación. La cláusula 8, operación, es la ejecución del plan de tratamiento de riesgos en el día a día. La cláusula 9, evaluación del desempeño, agrupa el seguimiento, la medición, las auditorías internas y la revisión por dirección. Y la cláusula 10, mejora, obliga a tratar las no conformidades con acciones correctivas y a mejorar el sistema de forma continua.

El ciclo de mejora continua

El SGSI no es un proyecto con fecha de fin, sino un ciclo que se repite. La lógica es la del conocido esquema planificar, hacer, verificar y actuar: se planifica el tratamiento de los riesgos y se fijan objetivos, se implantan los controles y se opera, se verifica mediante indicadores, auditorías internas y la revisión por dirección, y se actúa corrigiendo lo que no funciona. Cada vuelta de ese ciclo deja evidencia. Esa evidencia acumulada es la que sostiene la certificación y la que, año tras año, demuestra que el sistema está vivo y no congelado en el momento de la primera auditoría.

La enmienda de 2024 sobre cambio climático

En febrero de 2024 se publicó la Enmienda 1 a ISO/IEC 27001:2022, que introduce una modificación menor pero de obligada incorporación. Añade a la cláusula 4.1 la exigencia de determinar si el cambio climático es un asunto relevante para la organización, y a la cláusula 4.2 una nota que recuerda que las partes interesadas pueden tener requisitos relacionados con el clima. No obliga a implantar controles nuevos: obliga a considerar la cuestión de forma explícita y a documentar la conclusión. Las organizaciones ya certificadas la incorporan en su siguiente auditoría de seguimiento o de recertificación.

El Anexo A de la edición 2022: 93 controles en cuatro grupos

El cambio más visible de la edición 2022 está en el Anexo A. La versión de 2013 organizaba 114 controles en 14 dominios. La de 2022 los reordena en 93 controles agrupados en cuatro categorías. La reducción no significa menos seguridad: se fusionaron controles que se solapaban y se reagruparon en una estructura más clara. Además se incorporaron 11 controles nuevos que la versión anterior no contemplaba, entre ellos la inteligencia de amenazas, la seguridad de la información para el uso de servicios en la nube, la preparación de las TIC para la continuidad de negocio, la supervisión de la seguridad física, la gestión de la configuración, el borrado de información, el enmascaramiento de datos, la prevención de fuga de datos, la supervisión de actividades, el filtrado web y la codificación segura.

Cada control tiene un enunciado breve en el Anexo A y una guía de implementación mucho más detallada en la norma acompañante ISO/IEC 27002:2022. Esa distinción importa a efectos prácticos: el Anexo A dice qué se espera, ISO 27002 explica cómo puede lograrse y qué atributos tiene cada control. La edición 2022 introdujo además un sistema de atributos (por tipo de control, propiedad de la seguridad, concepto de ciberseguridad, capacidad operativa y dominio de seguridad) que permite filtrar y ordenar los controles según distintos criterios. No es obligatorio usarlos, pero facilita mucho relacionar los controles con marcos de referencia externos.

No se implantan todos: se seleccionan por riesgo

El punto que más cuesta interiorizar a quien empieza es que el Anexo A no es una lista de tareas a completar. Es un catálogo del que se escoge. La organización analiza sus riesgos y decide, para cada control, si lo aplica y cómo, o si lo excluye porque el riesgo que trataría no existe en su caso. Un proveedor de software que no gestiona centros de datos propios puede justificar la exclusión de determinados controles físicos; una empresa que sí los opera no podrá hacerlo. Esa decisión, control a control, es la que se plasma en el documento que vertebra toda la auditoría.

La Declaración de Aplicabilidad, la pieza que mira el auditor

La Declaración de Aplicabilidad, conocida por sus siglas inglesas SoA (Statement of Applicability), es el documento que conecta el análisis de riesgos con los controles del Anexo A. Enumera los 93 controles y, para cada uno, declara cuatro cosas: si aplica o no, si está implantado y en qué grado, la justificación de su inclusión o exclusión, y la referencia al riesgo o al requisito que motiva la decisión. Es, en la práctica, el índice del sistema de control. Por eso el auditor la usa como hoja de ruta: recorre la SoA y, control por control, pide ver la evidencia que respalda lo declarado.

Ahí está el punto crítico. Una SoA bien redactada pero sin evidencia detrás no aguanta la auditoría. Si la declaración afirma que el control de gestión de accesos está implantado, el auditor querrá ver la política de accesos, los registros de altas y bajas, las revisiones periódicas de permisos y la evidencia de que se aplica el mínimo privilegio. Si la afirmación no puede demostrarse, aparece una no conformidad. Mantener la SoA sincronizada con la evidencia real, y no dejar que se convierta en un documento que se actualiza la semana antes de la auditoría, es una de las claves de un SGSI que se sostiene en el tiempo.

El auditor no certifica lo que la Declaración de Aplicabilidad afirma. Certifica lo que la evidencia detrás de cada control demuestra.

Un ejemplo de cómo se lee una SoA

Imaginemos una pyme tecnológica de veinte personas que desarrolla software y lo despliega en la nube. En su SoA, el control de inteligencia de amenazas (uno de los nuevos de 2022) aparece como aplicable e implantado, con la justificación de que el riesgo de ataques dirigidos es real para su negocio, y con evidencia consistente en la suscripción a un servicio de alertas y las actas de las reuniones donde se revisan. El control de seguridad física de áreas seguras figura como aplicable pero delegado en el proveedor de nube, con la evidencia del certificado del proveedor. Y algún control muy ligado a instalaciones industriales propias aparece como no aplicable, con la justificación de que la empresa no dispone de ese tipo de infraestructura. Esa combinación de aplica, delega y excluye, siempre justificada, es exactamente lo que el auditor espera encontrar.

Análisis y tratamiento de riesgos

El análisis de riesgos es el motor que decide qué controles se aplican. La cláusula 6 exige un proceso de apreciación del riesgo repetible, que identifique los riesgos de seguridad de la información, los analice y los evalúe frente a unos criterios de aceptación definidos por la propia organización. No hay una metodología única impuesta por la norma: puede usarse un enfoque basado en activos, en escenarios de amenaza o en procesos, siempre que sea consistente y produzca resultados comparables en el tiempo.

Apreciación del riesgo

La apreciación combina, para cada riesgo identificado, la probabilidad de que se materialice y el impacto que tendría sobre la confidencialidad, la integridad o la disponibilidad de la información. El resultado es un nivel de riesgo que permite priorizar. No todos los riesgos merecen la misma atención: el objetivo es concentrar el esfuerzo donde más duele. Un riesgo de alta probabilidad e impacto grave exige tratamiento inmediato; uno de baja probabilidad e impacto menor puede aceptarse tal cual, siempre que la decisión quede documentada.

Tratamiento y aceptación de riesgos residuales

Una vez apreciados los riesgos, hay que decidir qué hacer con cada uno. Las opciones clásicas son cuatro: mitigar el riesgo aplicando controles del Anexo A, transferirlo (por ejemplo, mediante un seguro o un contrato con un proveedor), evitarlo eliminando la actividad que lo genera, o aceptarlo de forma consciente. La mayoría de riesgos se mitigan con controles, y el plan de tratamiento documenta qué controles se aplican a cada riesgo. Pero ningún control reduce el riesgo a cero. Lo que queda después de aplicar los controles es el riesgo residual, y ese riesgo residual debe ser aceptado formalmente por quien tiene autoridad para hacerlo, normalmente la dirección. Esa aceptación no es un trámite: es asumir de manera explícita que la organización convive con un nivel de riesgo determinado.

Un ejemplo concreto lo aclara. Una empresa identifica el riesgo de fuga de información sensible por parte de un empleado con acceso legítimo. Lo mitiga con varios controles: acuerdos de confidencialidad, gestión de accesos con mínimo privilegio, prevención de fuga de datos y supervisión de actividades. Aun así, queda un riesgo residual, porque ningún conjunto de controles elimina por completo la posibilidad. La dirección revisa ese riesgo residual, lo considera tolerable a la vista de los controles implantados y lo acepta por escrito. Esa decisión documentada es la evidencia de que el riesgo se ha gestionado, no ignorado.

Objetivos, auditorías internas, no conformidades y revisión por dirección

Un SGSI que no se mide es un SGSI que no se puede mejorar. La norma exige fijar objetivos de seguridad coherentes con la política, medibles y con responsables y plazos. Reducir el tiempo medio de respuesta ante incidentes, elevar el porcentaje de personal formado en concienciación o disminuir las incidencias derivadas de accesos mal gestionados son ejemplos de objetivos que pueden seguirse con indicadores. Sin objetivos, la revisión anual se queda en una declaración de buenas intenciones.

Auditorías internas

Antes de que venga el auditor externo, la organización debe auditarse a sí misma. La auditoría interna comprueba que el SGSI cumple los requisitos de la norma y los propios de la organización, y que está implantado y mantenido de forma eficaz. La lleva a cabo personal con independencia respecto de lo que audita, o un tercero contratado, y su resultado alimenta la mejora. Las auditorías internas no son un ensayo general de la externa: son un mecanismo de control propio que, bien usado, detecta los problemas cuando todavía hay margen para corregirlos sin coste reputacional.

No conformidades y acciones correctivas

Cuando una auditoría, interna o externa, detecta que algo no cumple, se abre una no conformidad. La norma exige no solo corregir el hecho concreto, sino analizar la causa raíz y tomar acciones para evitar que se repita. Una no conformidad mayor puede impedir la certificación hasta que se resuelva; una menor suele admitir un plan de acción con plazo. Registrar las no conformidades, su análisis de causa, las acciones tomadas y la verificación de su eficacia es, otra vez, evidencia que el auditor revisará en la siguiente visita.

Revisión por dirección

El ciclo se cierra con la revisión por dirección, una reunión formal en la que la alta dirección examina el estado del SGSI: resultados de auditorías, cumplimiento de objetivos, incidentes, cambios en el contexto, evolución de los riesgos y oportunidades de mejora. De esa revisión salen decisiones documentadas sobre recursos, prioridades y cambios en el sistema. Es la evidencia de que la seguridad de la información no es un asunto delegado en el equipo técnico, sino una responsabilidad asumida en el nivel más alto de la organización. Un acta de revisión por dirección bien construida vale más ante el auditor que cualquier declaración de principios.

ISO 27001 y el ENS: dos marcos que conviven

Aquí conviene deshacer una confusión habitual. ISO/IEC 27001 es una norma internacional de adopción voluntaria: nadie está obligado por ley a certificarse, aunque muchos clientes lo exijan por contrato. El Esquema Nacional de Seguridad, en cambio, es una norma legal española de obligado cumplimiento. Lo regula el Real Decreto 311/2022, de 3 de mayo, publicado en el BOE, que derogó el anterior Real Decreto 3/2010 y actualizó el marco para adaptarlo al aumento de las amenazas. El ENS obliga a todo el sector público y, por extensión, a las empresas privadas cuando prestan servicios a entidades públicas en virtud de una relación contractual.

Categorías y dimensiones del ENS

El ENS clasifica los sistemas en tres categorías (básica, media y alta) según el impacto que tendría un incidente sobre cinco dimensiones de la seguridad: confidencialidad, integridad, disponibilidad, autenticidad y trazabilidad. Esas dos últimas dimensiones, autenticidad y trazabilidad, son un matiz frente al enfoque clásico de ISO 27001 y encajan bien con la lógica de la contratación pública, donde poder demostrar quién hizo qué y cuándo tiene valor probatorio. La categoría determina las medidas de seguridad exigibles y el modo de acreditar la conformidad.

La acreditación tiene dos vías. Los sistemas de categoría básica pueden acreditar su conformidad mediante una autoevaluación y la correspondiente declaración de conformidad. Los de categoría media o alta requieren una auditoría de certificación de la conformidad, realizada al menos cada dos años por entidades acreditadas por ENAC. El Centro Criptológico Nacional puede aprobar además perfiles de cumplimiento específicos, adaptados a un sector o tipo de entidad, que racionalizan las medidas exigibles sin merma de la protección.

Por qué muchas licitaciones exigen acreditar seguridad

La consecuencia práctica de todo lo anterior es que la seguridad de la información se ha convertido en un requisito recurrente de los pliegos. Cuando una Administración saca a licitación un servicio que va a tratar información sujeta al ENS, traslada esa exigencia a quien lo va a prestar. El pliego puede pedir la conformidad con el ENS en la categoría que corresponda, puede aceptar la certificación ISO 27001 como medio de acreditar solvencia técnica o como condición de ejecución, y puede exigir medidas concretas de seguridad durante la vida del contrato. La forma exacta en que se pide varía de un pliego a otro, y de ahí la importancia de leerlo con precisión, algo que tratamos en la guía sobre SaaS o self-hosted en licitaciones y en la de solvencia técnica y económica.

No acreditar lo que el pliego exige en materia de seguridad puede dejar una oferta fuera del procedimiento, igual que ocurre con cualquier otro requisito de aptitud. Conviene distinguir entre un requisito de solvencia, que actúa como filtro previo, y un requisito de ejecución, que se aplica durante el contrato. Confundirlos lleva a errores caros, un asunto que desarrollamos en la guía sobre causas de exclusión en una licitación. Tener la certificación o la conformidad ordenada y disponible evita descubrir a última hora que falta un documento que se podía haber preparado con meses de antelación.

Reutilizar la evidencia del SGSI en las licitaciones

Aquí es donde el trabajo del SGSI y el trabajo de licitar se cruzan. Si una empresa mantiene su SGSI ordenado (con su Declaración de Aplicabilidad al día, sus riesgos tratados, sus políticas aprobadas y sus evidencias asociadas a cada control), esa misma documentación es la que un pliego reclama cuando pide acreditar seguridad. La política de seguridad, el plan de continuidad, la evidencia de la gestión de accesos, los acuerdos de confidencialidad o el registro de incidentes no hay que fabricarlos para cada licitación: ya existen dentro del sistema de gestión. El problema, cuando lo hay, no es de contenido sino de localización: la evidencia está, pero repartida entre carpetas, correos y personas que recuerdan dónde se guardó.

Mantener el SGSI en el mismo entorno donde vive el conocimiento de la empresa resuelve ese problema de raíz. Cuando el pliego pide acreditar un control, la evidencia se localiza por su vínculo con el control del Anexo A al que pertenece, y desde ahí se lleva al expediente de la licitación. La relación entre el requisito del pliego y el control que lo respalda se mantiene, de modo que la misma evidencia sirve dos veces: para la auditoría del SGSI y para el encaje de la oferta. Es el mismo principio de trazabilidad que aplicamos al análisis de pliegos, donde cada dato vuelve a su fuente.

La evidencia que sostiene un control de seguridad y la que acredita ese control ante un pliego son la misma. El trabajo está en no tener que buscarla dos veces.

Un ejemplo de reutilización

Una consultora se presenta a un contrato de servicios para una entidad pública que trata datos de categoría media según el ENS. El pliego exige acreditar una política de seguridad aprobada, un procedimiento de gestión de incidentes y evidencia de formación en seguridad del personal adscrito al contrato. Los tres requisitos coinciden con controles que la consultora ya tiene implantados en su SGSI: la política de seguridad del grupo organizativo, la gestión de incidentes del mismo grupo y la concienciación y formación del grupo de personas. En lugar de reconstruir esa documentación, el equipo la localiza por su vínculo con cada control, comprueba que está vigente y la aporta al expediente. Lo que en otras empresas es una carrera contrarreloj se convierte en una consulta, porque la evidencia estaba ordenada desde el principio.

Errores frecuentes al gestionar un SGSI

Los sistemas de gestión no suelen fallar por falta de controles, sino por falta de mantenimiento y de evidencia. Estos son los tropiezos que más se repiten.

• ✓Elegir controles del Anexo A antes de haber analizado los riesgos, con lo que la Declaración de Aplicabilidad no responde a ningún riesgo real.
• ✓Redactar una SoA impecable pero sin evidencia detrás de los controles que declara implantados.
• ✓Definir un alcance demasiado amplio que dispara el esfuerzo, o demasiado estrecho que deja fuera lo que el cliente esperaba certificar.
• ✓Fijar objetivos de seguridad que no se miden, con lo que la revisión por dirección se queda sin datos sobre los que decidir.
• ✓Aceptar riesgos residuales de forma tácita, sin una aprobación documentada de quien tiene autoridad para asumirlos.
• ✓Tratar la auditoría interna como un trámite en lugar de como un mecanismo real de detección temprana de problemas.
• ✓Cerrar las no conformidades corrigiendo el hecho puntual sin analizar la causa raíz, con lo que el problema reaparece.
• ✓Actualizar toda la documentación la semana antes de la auditoría, en vez de mantener el sistema vivo durante todo el año.

Detrás de casi todos estos errores hay una causa común: la documentación del SGSI vive dispersa y desconectada del trabajo diario. Cuando las políticas están en una carpeta, los riesgos en una hoja de cálculo, las evidencias en el correo y las actas en el ordenador de una persona, mantener la coherencia entre todo ello se vuelve un esfuerzo que nadie sostiene mucho tiempo. La solución no es más disciplina individual, sino un entorno donde controles, riesgos, aplicabilidad y evidencias estén relacionados entre sí y se mantengan juntos.

Cómo Genlicit ayuda a gestionar el SGSI

Genlicit incorpora un módulo de SGSI pensado para organizar exactamente el trabajo que hemos descrito. Permite mantener el catálogo de controles y su estado de aplicabilidad, gestionar el análisis y el tratamiento de riesgos, registrar la aceptación de los riesgos residuales, fijar objetivos, documentar auditorías internas, no conformidades y revisión por dirección, y asociar documentos, aprobaciones y evidencias a cada control. La Declaración de Aplicabilidad deja de ser un documento suelto que se actualiza a mano y pasa a reflejar el estado real de los controles, con su evidencia a un clic.

La ventaja de hacerlo en el mismo entorno donde vive el conocimiento de la empresa es la trazabilidad y la reutilización. Cada control conserva su vínculo con la evidencia que lo respalda, y esa evidencia puede aportarse tanto a la auditoría del SGSI como al encaje de una licitación que la reclame, sin reconstruirla. El sistema se despliega en modo SaaS o self-hosted, con la posibilidad de usar claves propias del cliente (BYOK), de modo que la propia documentación del SGSI se gestiona con las garantías de seguridad y despliegue que la organización decida durante la implantación.

Conviene ser claro sobre lo que Genlicit no hace. Genlicit no certifica ningún SGSI: la certificación en ISO 27001 la emite exclusivamente una entidad de certificación acreditada tras auditar el sistema, y el software no está certificado por sí mismo por el mero hecho de organizar la documentación. Tampoco garantiza el resultado de la auditoría, que depende del estado real del sistema y del criterio del auditor, ni sustituye al responsable de seguridad, que es quien mantiene el criterio y asume la responsabilidad del SGSI. Lo que Genlicit aporta es orden, relación entre las piezas y trazabilidad de la evidencia, que es justo donde la mayoría de los sistemas de gestión se resienten.

El software organiza los controles, los riesgos y las evidencias, y mantiene la trazabilidad entre ellos. La certificación la emite una entidad acreditada tras la auditoría, y el criterio lo pone el responsable de seguridad.