La evaluación de riesgos es el punto en el que casi todos los proyectos de ISO 27001 se atascan, y también donde más se nota si el sistema de gestión se ha montado de verdad o solo sobre el papel. Muchas organizaciones invierten semanas en rellenar una hoja de cálculo enorme, con decenas de amenazas teóricas y puntuaciones puestas a ojo, y llegan a la auditoría con un documento que nadie usa y que no explica por qué se han elegido unos controles y descartado otros.
En este artículo repasamos qué es la evaluación de riesgos según la ISO 27001, por qué condiciona el resto del sistema, qué método conviene usar y cómo hacerla paso a paso.
¿Qué es la evaluación de riesgos en la ISO 27001?
La evaluación de riesgos es el proceso mediante el cual una organización identifica los riesgos que amenazan la seguridad de su información y determina su probabilidad y su impacto. En otras palabras, reconocer qué puede salir mal, con qué probabilidad ocurriría y qué consecuencias tendría para la confidencialidad, la integridad y la disponibilidad de la información.
La cláusula 6.1.2 de la ISO 27001 obliga a definir un proceso de evaluación de riesgos, aplicarlo de forma coherente y conservar la información documentada como evidencia. La norma no lo plantea como una tarea de una sola vez, sino que exige repetirlo a intervalos planificados y siempre que se produzcan cambios relevantes en la organización o en su entorno.
Conviene aclarar tres términos que a menudo se usan como sinónimos y no lo son. El análisis de riesgos es la fase en la que se estiman probabilidad e impacto de cada riesgo. La evaluación de riesgos es el proceso completo, que incluye ese análisis más la comparación de los resultados con los criterios de aceptación para decidir qué riesgos son prioritarios. Y el tratamiento de riesgos es el paso posterior, en el que se decide qué hacer con cada uno.
¿Por qué la evaluación de riesgos es el punto de partida del SGSI?
La ISO 27001 es una norma basada en el riesgo. Esto significa que los controles que implanta una empresa no salen de una lista estándar ni de imitar a la competencia, sino de su propia exposición. Dos organizaciones del mismo sector pueden acabar con sistemas de control muy distintos porque sus riesgos son distintos.
Esa lógica coloca la evaluación en la base del sistema de gestión de seguridad de la información (SGSI). De sus resultados depende qué controles del Anexo A vas a aplicar y cuáles vas a justificar por escrito que descartas. Sin una evaluación sólida, esa decisión se queda sin fundamento y el auditor lo detecta enseguida.
Hay además una dependencia previa que conviene tener presente, y es que no se pueden evaluar riesgos sobre activos que no se conocen.
Enfoque cualitativo vs cuantitativo: ¿cuál elegir?
La ISO 27001 no impone un método concreto. Exige que sea coherente, reproducible y que genere resultados comparables, pero deja a cada organización decidir cómo lo aplica. En la práctica existen dos grandes enfoques, y la mayoría combina elementos de ambos.
- Enfoque cualitativo: valora probabilidad e impacto sobre escalas descriptivas (por ejemplo, de 1 a 5, o baja/media/alta) y los cruza en una matriz de riesgo. Es rápido de aplicar, fácil de comunicar a dirección y suficiente para la mayoría de las pymes.
- Enfoque cuantitativo: asigna valores numéricos y monetarios a la probabilidad y al impacto, apoyándose en datos y fórmulas. Aporta más precisión y ayuda a justificar inversiones, pero exige información histórica fiable y más tiempo de trabajo.
¿Cómo hacer una evaluación de riesgos ISO 27001 paso a paso?
Aunque la norma da libertad metodológica, las evaluaciones que funcionan siguen casi siempre la misma secuencia. Estos seis pasos ordenan el trabajo y evitan que se quede a medias.
1. Inventaría los activos de información
Empieza por lo que hay que proteger. Recorre cada categoría (datos, hardware, software, servicios en la nube y personas con acceso) y catalógala dentro del alcance del SGSI. Este paso se apoya directamente en el inventario de activos, así que si ya lo tienes construido, buena parte del trabajo está hecho. Si partes de cero, delimita primero el alcance con claridad, porque es lo que te dice qué entra en el inventario y qué queda fuera.
Cada activo debería quedar registrado con un mínimo de información útil para el análisis posterior: qué es, quién es su propietario y qué nivel de sensibilidad tiene la información que maneja. Ese contexto es el que después te permite estimar el impacto de un riesgo con criterio y no a ojo.
El error más común aquí es limitarse al hardware y dejar fuera el SaaS contratado por cada equipo, que es justo por donde suele entrar el riesgo que nadie vigila. Ese shadow IT no aparece solo, así que conviene cruzar el inventario con las herramientas que realmente se están usando y con los gastos recurrentes antes de darlo por cerrado.
2. Identifica amenazas y vulnerabilidades
Para cada activo, pregúntate qué puede salir mal y qué debilidad lo haría posible. Una amenaza es el evento (robo, cifrado por ransomware, error humano, caída de un proveedor) y la vulnerabilidad es la puerta que deja pasar esa amenaza (un portátil sin cifrar, un software sin parchear, un acceso que no se revocó a tiempo). Casi siempre hacen falta las dos para que un riesgo se materialice, así que conviene enlazar cada amenaza con la vulnerabilidad concreta que la habilita.
No hace falta inventar catálogos infinitos. Céntrate en los escenarios realistas para tu tipo de organización y tu forma de trabajar, y apóyate en los incidentes que ya habéis vivido o que son habituales en vuestro sector.
3. Analiza la probabilidad y el impacto
Aquí llega el análisis de riesgos propiamente dicho. Puntúa, para cada riesgo, la probabilidad de que ocurra y el impacto que tendría si ocurriese, usando la escala que hayas definido en tu metodología. Recuerda que el impacto no es solo económico, porque también puede ser reputacional, legal o de continuidad del negocio.
La combinación de ambas puntuaciones da el nivel de riesgo. Aplica el mismo criterio a todos los riesgos para que los resultados sean comparables entre sí, que es precisamente lo que la norma espera de un método coherente.
4. Prioriza los riesgos con la matriz
Ningún equipo tiene recursos infinitos, así que hay que decidir a qué riesgos dedicas tiempo y dinero y cuáles puedes dejar en segundo plano. Cruza probabilidad e impacto en una matriz de riesgo y contrasta el resultado con tus criterios de aceptación. Así distingues los riesgos que exigen acción inmediata de los que caen dentro de un nivel asumible.
La matriz es, además, la forma más clara de explicar esas prioridades a dirección, porque traduce el análisis a un mapa visual en el que se ve de un vistazo dónde está lo crítico. Ese respaldo es el que después justifica la inversión en controles y ayuda a que las decisiones no dependan solo del criterio de IT.
5. Define el tratamiento de cada riesgo
Para cada riesgo por encima del umbral, decide qué vas a hacer con él (lo vemos con detalle en el apartado siguiente) y asisgna un propietario responsable de esa decisión.
Cuando apliques un control para reducirlo permanece un riesgo residual, que es el nivel que sigue existiendo una vez implantada la medida, y que también hay que valorar y aceptar formalmente. Todas estas decisiones se plasman después en la Declaración de Aplicabilidad, que conecta cada riesgo con los
6. Documenta y revisa a intervalos planificados
Todo lo anterior tiene que dejar rastro. El auditor querrá ver dos documentos: el informe de evaluación de riesgos, con los riesgos identificados y sus puntuaciones, y el plan de tratamiento de riesgos, con la opción elegida y el responsable de cada uno. Puedes partir de una plantilla para no empezar de cero, pero adáptala a tu realidad en lugar de heredar riesgos que no son tuyos.
Y no lo trates como un entregable de un solo uso. Fija una periodicidad de revisión y actualiza la evaluación cada vez que cambie algo relevante: un nuevo servicio, un incidente, una reorganización.
Las cuatro opciones de tratamiento del riesgo
Una vez priorizados los riesgos, la ISO 27001 contempla cuatro maneras de responder a cada uno. No son excluyentes, es decir, un mismo riesgo puede mitigarse en parte y aceptarse en lo que quede.
- Mitigar: aplicar controles de seguridad que reduzcan la probabilidad o el impacto. Es la opción más frecuente y la que conecta con el Anexo A.
- Aceptar: asumir el riesgo de forma consciente y documentada cuando su nivel está dentro del umbral o el coste de tratarlo supera al daño potencial.
- Transferir: trasladar el riesgo a un tercero, por ejemplo mediante un seguro o externalizando el servicio afectado.
- Evitar: eliminar la causa del riesgo dejando de realizar la actividad que lo genera.
Ejemplo práctico: un registro de riesgos ISO 27001
Así se vería un registro de riesgos simplificado para una empresa con un equipo de IT reducido y trabajo híbrido. Las puntuaciones van en una escala de 1 a 3 (1 = bajo, 3 = alto) y el nivel de riesgo resulta de combinar probabilidad e impacto.
| Riesgo | Probabilidad | Impacto | Nivel | Tratamiento |
|---|---|---|---|---|
| Un empleado cae en un phishing y le roban las credenciales | 3 | 3 | Alto | Mitigar — MFA y formación en concienciación |
| Software sin parchear explotado por malware | 2 | 3 | Alto | Mitigar — política de patching centralizado |
| Portátil perdido o robado con datos sin cifrar | 2 | 2 | Medio | Mitigar — cifrado de disco y MDM con borrado remoto |
| Baja de un empleado sin revocar sus accesos | 2 | 3 | Alto | Mitigar — offboarding vinculado a RRHH |
| Caída de un proveedor SaaS crítico | 1 | 3 | Medio | Transferir — SLA y copia de seguridad propia |
| Cuenta de redes sociales comprometida | 1 | 1 | Bajo | Aceptar — supervisar, sin controles adicionales |
En casi todas las evaluaciones, los riesgos que acaban arriba tienen que ver con las personas y con los dispositivos, y muchos se mitigan con controles técnicos concretos como el cifrado, el parcheo, la gestión de accesos o el borrado remoto de un equipo perdido. Tenerlos centralizados es lo que convierte el registro de riesgos en una herramienta que reduce la exposición y no solo la describe.
¿Cómo Factorial IT te ayuda a gestionar el riesgo de tu SGSI?
Una cosa es tener el riesgo identificado en un registro y otra reducirlo de verdad. Factorial IT actúa sobre esa segunda parte, la del tratamiento, porque reúne en una sola plataforma las palancas técnicas con las que se mitigan los riesgos que casi siempre acaban en la parte alta de la matriz.
Si repasas el ejemplo de la tabla anterior, la mayoría de esos riesgos se tratan desde aquí:
- Equipos perdidos o robados: el MDM aplica cifrado de forma centralizada y permite bloquear o borrar en remoto un dispositivo, de modo que un portátil extraviado deja de ser una fuga de datos.
- Software desactualizado: el control del parque permite saber qué versiones corren en cada equipo y mantener el patching al día, que es la vulnerabilidad detrás de buena parte de los incidentes por malware.
- Accesos que sobreviven a una baja: la gestión de accesos deja retirar permisos cuando una persona cambia de rol o se va, y cierra la puerta a los accesos huérfanos.
- Riesgos que decides aceptar o vigilar: al tener el estado real de cada activo a mano, revisar un riesgo asumido y justificar esa decisión ante el auditor deja de depender de una hoja de cálculo desactualizada.
