Cuando pensamos en ISO 27001, es fácil asociarla con políticas de seguridad, copias de seguridad, gestión de accesos, vulnerabilidades, proveedores, formación… En definitiva, mucha documentación y una inversión considerable de tiempo y recursos.
En una pequeña o mediana empresa, donde los recursos son los que son, todo esto puede hacer que la implantación de un marco como ISO 27001 se vea como un proceso demasiado complejo o difícil de asumir.
Sin embargo, las ventajas de implantar un Sistema de Gestión de Seguridad de la Información (SGSI) van mucho más allá que el obtener una certificación. Un SGSI permite establecer las bases para gobernar y gestionar la seguridad de la información de forma ordenada, definir responsabilidades, conocer los riesgos de la organización y tomar decisiones de seguridad con un criterio común. En definitiva, ayuda a mejorar la postura de seguridad de la organización y, sobre todo, a dejar de gestionar la seguridad como un conjunto de medidas aisladas.
Estas ventajas no quitan que la implantación de un SGSI sea compleja y, en muchos casos, tediosa. Y precisamente de este problema nació este proyecto: desarrollar una herramienta que facilite a pequeñas y medianas empresas la implantación y gestión de un SGSI de una forma más sencilla, ordenada y centralizada.
A lo largo del artículo veremos qué implica realmente ISO 27001, desglosando su implantación en un conjunto de actividades atómicas y viendo cómo cada una de ellas se mapea dentro de la aplicación.
También veremos cómo gran parte del esfuerzo realizado durante la implantación de ISO 27001 puede aprovecharse para abordar otros marcos y requisitos de seguridad, como NIS2 o el ENS, que al final, están construidos sobre la 27001.
ISO 27001…¿Qué es?
La ISO 27001 define los requisitos para establecer, implantar, mantener y mejorar de forma continua un sistema de gestión de seguridad de la información (SGSI). El SGSI incluye tecnología, pero también procesos, responsabilidades, políticas, gestión de riesgos, formación, gestión de proveedores, revisión, evidencias y mejora continua, así que no es solamente implementar un conjunto de controles técnicos.
En la práctica, el objetivo es que la seguridad deje de depender de medidas aisladas y pase a gestionarse de una forma estructura y alineada dentro de la organización.
La norma ISO 27001 anexo A de la versión del 22 está formada por 93 controles, agrupados en cuatro grandes bloques
| Categoría | Número de controles |
| Organizacionales | 37 |
| Personas | 8 |
| Físicos | 14 |
| Tecnológicos | 34 |
Una confusión habitual, es creer que para tener la certificación de la 27001, se tienen que implementar los 93 controles, pero NO es así. Cada organización tienen que analizar su contexto y sus riesgos, definir un alcance y en base a este alcance determinar que controles necesita y justificar cuáles son aplicables y cuales no, esto es lo que se conoce como Declaración de Aplicabilidad (SoA).
Por tanto, antes de empezar a implementar controles, necesitamos responder a dos preguntas muy básicas
¿Cuáles son nuestros activos y qué riesgos tiene realmente nuestra organización?
Análisis de riesgos… el punto de partida
Para conocer los riesgos a los que la organización está expuesta, el primer paso es saber qué queremos proteger. Parece algo evidente, pero muchas veces no existe un inventario único y actualizado de los activos que forman parte de los sistemas de información de la organización… y si no sabemos que tenemos que proteger, no lo podemos proteger.
Otra confusión habitual, es asociar activos a únicamente servidores o equipos, pero aplicaciones, servicios, información, infraestructura, proveedores también son activos de la organización, y tenemos que tenerlos en cuenta.
Por tanto, antes de analizar amenazas o pensar en controles, necesitamos identificar estos activos y entender qué importancia tienen para el negocio.
En la aplicación, cada activo dispone de una ficha propia donde podemos registrar información como su tipo, ubicación, responsable, entorno, proveedor o si trata datos personales, entre otros campos,
Además, para cada activo se realiza una valoración de tres propiedades fundamentales de la seguridad de la información: confidencialidad, integridad y disponibilidad.
La idea es sencilla, no todos los activos tienen la mima importancia ni necesitan el mismo nivel de protección. Por ejemplo un servidor que almacena y gestiona las historias clínicas de los pacientes, tendrá mas prioridad que una impresora. Por eso, la aplicación permite valorar individualmente cada una de estas dimensiones y obtener así una primera visión de criticidad del activo.
Una vez tenemos identificados los activos, y les hemos asignado una criticidad, la siguiente pregunta que nos tenemos que hacer es:
¿A Qué amenazas están expuestos mis activos?
Identificación de amenazas.
Con los activos ya identificados y priorizados, el siguiente paso es entender que puede ocurrirles. Se pueden seguir muchos frameworks, pero en este caso la aplicación incorpora un catálogo de amenazas basado en MAGERIT, una metodología utilizada para el análisis y gestión de riesgos.
Las amenazas se agrupan en categorías, como eventos Naturales, fallos de origen industrial, errores no intencionados o ataques deliberados. De esta forma, podemos partir de un catálogo común y evitar que el análisis dependa únicamente de aquello que se nos ocurra en ese momento.
La aplicación incorpora todo el catálogo de amenazas de Magerit, pero para adaptarse al contexto de cada organización, se permite añadir amenazas propias de manera que cada organización, puede enriquecer el catálogo de amenazas incorporando aquellas amenazas propias de su entorno.
El riesgo no depende únicamente de la amenaza, sino también del activo sobre el que se materializa. Un ataque de ransomware sobre un equipo de testing, no tiene las mismas consecuencias que sobre el servidor de producción que gestiona datos críticos de clientes.
Por tanto, el escenario que nos interesa analizar nace de combinar la criticidad del activo con la amenaza que hemos identificado. A partir de aquí. ya podemos pasar de identificar que puede ocurrir a intentar responder la siguiente pregunta
¿Qué riesgo representa esta amenaza en la organización?
y para responderla necesitamos valorar dos factores: la probabilidad de que ocurra y el impacto que tendría si llega a materializarse.
Evaluación del riesgo.
Definido el escenario de riesgo, necesitamos determinar hasta qué punto debería preocuparnos.
ISO 27001 no obliga a utilizar una fórmula ni una metodología en concreto para calcular el riesgo, pero si exige que la organización defina unos criterios coherentes para evaluarlo. Siguiendo la metodología Magerit, esta aplicación sigue el modelo de Riesgo = Probabilidad x Impacto.
Ambos valores se evalúan de una escala de 1 a 5, por lo que el resultado final se sitúa entre 1 y 25.
La probabilidad responde a la pregunta: ¿con qué facilidad o frecuencia podría materializarse esta amenaza sobre este activo? Mientras que el impacto nos permite valorar las consecuencias que tendría esa materialización sobre la organización.
Tanto la probabilidad como el impacto requieren cierto grado de juicio durante su valoración y están íntimamente ligados al activo y al escenario concreto que estamos evaluando. No tendrá las mismas consecuencias un ataque de ransomware sobre un equipo de pruebas que sobre un servidor que almacena las historias clínicas de los pacientes.
Del mismo modo, la probabilidad también dependerá de las salvaguardas y medidas de seguridad que ya estén implantadas. La existencia de mecanismos de protección, segmentación, copias de seguridad, MFA, EDR o controles de acceso puede modificar la probabilidad de que una amenaza llegue a materializarse o reducir las consecuencias en caso de que ocurra.
El impacto, además, puede evaluarse desde diferentes dimensiones: económica, reputacional, legal, operacional o sobre los propios clientes, además de su afectación a la confidencialidad, integridad y disponibilidad de la información.
En la metodología propuesta para esta aplicación se ha optado por elegir que el impacto final corresponde al valor más alto obtenido entre las distintas dimensiones evaluadas.
Por ejemplo, tomando los datos de la captura anterior, para el escenario Servidor HIS + Ataque de ransomware podríamos obtener una probabilidad de 4 y un impacto máximo de 5. Por tanto:
Riesgo = 4 × 5 = 20 → Riesgo Alto
Pero el valor numérico, por sí solo, no es suficiente. Si dentro de unos meses otra persona revisa el análisis, debería poder entender por qué se asignó una probabilidad de 4 y no de 2, o por qué determinada dimensión de impacto recibió la valoración máxima.
Por este motivo, cada riesgo dispone también de un apartado de notas donde documentar y justificar el razonamiento seguido durante la valoración.
Una vez hemos analizado los riesgos, y los tenemos organizados en la matriz de riesgo que hemos visto en las anteriores capturas, la siguiente pregunta que tenemos que responder es:
¿Qué hacemos con el riesgo que tenemos?
Y aquí es donde entra el tratamiento de riesgo.
Tratamiento del riesgo
Una vez identificados y valorados los riesgos, el siguiente paso es decidir qué vamos a hacer con ellos.
No todos los riesgos requieren la misma respuesta. Dependiendo de su nivel, del contexto de la organización y de los recursos disponibles, podemos optar por diferentes estrategias de tratamiento:
- Mitigar el riesgo, aplicando medidas que reduzcan su probabilidad o su impacto.
- Aceptar el riesgo, cuando se considera asumible para la organización.
- Transferirlo, por ejemplo mediante un proveedor o una póliza de seguro.
- Eliminarlo, suprimiendo la actividad, servicio o elemento que genera ese riesgo.
En la aplicación, cada riesgo puede asociarse a una o varias acciones dentro del plan de tratamiento, indicando qué se va a hacer, quién es el responsable, cuál es la fecha objetivo y en qué estado se encuentra la acción.
Por ejemplo, imaginemos que hemos identificado un riesgo elevado de phishing sobre las cuentas corporativas de Microsoft 365.
Una de las acciones de tratamiento podría ser Forzar MFA en todas las cuentas de Microsoft 365.
Esta acción tiene como objetivo reducir la probabilidad de que unas credenciales comprometidas puedan utilizarse directamente para acceder a la cuenta. Además la acción puede vincularse con controles de ISO 27001 que ayudan a implementar esa medida. En este caso en concreto, con el control 8.5 – Autenticación segura.
Veis, como el análisis de riesgos empieza a conectar con la norma !!!
Los controles, no son una lista aislada de requisitos, sino que tienen un contexto y una razón de ser concreta: se aplican porque existe un riesgo que queremos tratar.
El objetivo no es aplicar controles porque lo dice el Anexo A, sino seleccionar y justificar aquellos que son necesarios para la organización, en función de los riesgos identificados.
Ahora lo que tenemos que ver, es:
¿Cómo sabemos que este control está siendo realmente implementado?
Gestión de controles y evidencias
Una vez definido qué controles necesitamos aplicar, el siguiente paso es poder gestionar su estado y demostrar su implantación.
La aplicación incorpora los 93 controles del Anexo A de ISO 27001:2022, organizados en sus cuatro categorías: organizacionales, personas, físicos y tecnológicos
Cada control puede encontrarse en distintos estados:
- Conforme
- Parcial
- No conforme
- No aplica
- Sin evaluar
Un control no debería considerarse implantado simplemente porque alguien haya seleccionado la opción “Conforme”. Para que esa valoración tenga sentido, tiene que existir una justificación y, sobre todo, evidencias que permitan demostrarlo. Por este motivo, cada control dispone de una ficha propia.
En ella podemos registrar información como:
- responsable;
- estado;
- notas;
- evidencias;
- documentación adjunta;
- justificación en caso de que el control no aplique;
- relación con otros marcos.
Por ejemplo, para el control 5.1 — Políticas para la seguridad de la información, podríamos adjuntar como evidencia la política aprobada por Dirección y la documentación que demuestre su revisión y comunicación dentro de la organización.
De esta forma, cuando revisemos el control no solo veremos que está marcado como conforme, sino también por qué lo consideramos conforme y qué documentación lo respalda.
Esto resulta especialmente útil durante auditorías o revisiones internas, pero también para el propio mantenimiento del SGSI. Si una evidencia caduca, cambia un procedimiento o se modifica el responsable de un control, toda esa información queda centralizada en un mismo punto.
Lo mismo ocurre con los controles marcados como No aplica.
ISO 27001 permite que determinados controles del Anexo A no sean aplicables al contexto de una organización, pero esa decisión debe estar justificada. Por tanto, no basta con marcar un control como N/A; necesitamos explicar por qué no es necesario.
Toda esta información servirá posteriormente para construir y mantener la Declaración de Aplicabilidad (SoA), donde se documentan los controles aplicables, su estado y las razones de inclusión o exclusión.
ISO27001 implementada… ¿puedo reutilizar el esfuerzo para NIS2?
Una de las ventajas de estructurar toda esta información alrededor de un SGSI es que el trabajo realizado no tiene por qué quedarse únicamente en ISO 27001.
Existen otros marcos y requisitos de seguridad que comparten muchos principios, procesos y medidas con la norma. Dos ejemplos especialmente relevantes en España son NIS2 y el Esquema Nacional de Seguridad (ENS).
Esto no significa que ISO 27001, NIS2 y ENS sean equivalentes, ni que implementar uno de ellos implique automáticamente cumplir los demás. Sin embargo, existe un solapamiento importante que permite reutilizar buena parte del trabajo realizado.
El artículo 21 de NIS2 establece una serie de medidas para la gestión de riesgos de ciberseguridad que resultan muy familiares cuando ya estamos trabajando con ISO 27001: análisis de riesgos, gestión de incidentes, continuidad de negocio, seguridad de proveedores, gestión de vulnerabilidades, formación, criptografía, control de acceso o autenticación multifactor, entre otras.
Por este motivo, la aplicación mantiene un mapeo entre los controles de ISO 27001 y las distintas medidas recogidas en el artículo 21.2 de NIS2.
De esta forma, a medida que avanzamos en la implementación de los controles ISO, podemos visualizar qué medidas de NIS2 están siendo abordadas mediante esos mismos controles.
Aquí es importante diferenciar entre cobertura y cumplimiento. Que los controles ISO asociados a una determinada medida de NIS2 estén implementados no significa automáticamente que la organización pueda considerarse conforme con la Directiva.
La finalidad de este mapeo es mostrar qué parte del trabajo realizado puede reutilizarse y detectar qué áreas requieren medidas adicionales.
Conclusión
Implementar un SGSI sigue siendo un proceso complejo, especialmente en organizaciones pequeñas y medianas donde los recursos son limitados. El objetivo de esta aplicación no es eliminar esa complejidad ni sustituir el criterio necesario para analizar riesgos o decidir qué controles aplicar, sino intentar que todo el proceso sea más ordenado, trazable y manejable.
Descomponer la implantación en actividades más atómicas —identificar activos, amenazas, evaluar riesgos, definir tratamientos, implementar controles y recopilar evidencias— permite entender mejor qué estamos haciendo y, sobre todo, por qué lo estamos haciendo.
Además, estructurar toda esta información alrededor de ISO 27001 permite reutilizar buena parte del esfuerzo realizado para abordar otros marcos como NIS2 o ENS, evitando mantener procesos y evidencias completamente separados.
Al final, esa es la idea principal detrás del proyecto: facilitar que una organización pueda pasar de tener medidas de seguridad aisladas a gestionar su seguridad de una forma estructurada y basada en riesgos.