Análisis de riesgos ISO 27001: metodología paso a paso

Todo Sistema de Gestión de Seguridad de la Información se sostiene sobre una única pieza: el análisis de riesgos. Es el requisito central de la cláusula 6 de la ISO 27001 y, sobre todo, es lo que convierte la seguridad en decisiones de negocio: qué proteger primero, cuánto invertir y qué riesgo aceptar conscientemente. Un análisis bien hecho ordena todo el proyecto de certificación; uno decorativo condena al SGSI a ser papel mojado.

Este artículo es el segundo capítulo de nuestra guía completa de certificación ISO 27001, y baja al detalle práctico: metodología paso a paso, escalas de valoración, matrices de riesgo, plan de tratamiento y los errores que vemos repetirse una y otra vez. Está escrito para que puedas ejecutarlo con tu equipo, sin humo y con ejemplos del sector tecnológico.

1. Qué exige exactamente la ISO 27001

La norma es menos rígida de lo que se cree. No impone ninguna metodología concreta; exige que tu proceso de apreciación de riesgos cumpla tres condiciones: que sea consistente (mismos criterios siempre), repetible (dos personas distintas llegarían a resultados comparables) y que produzca resultados comparables entre iteraciones. Además, debe definir criterios de aceptación del riesgo y quién es el propietario de cada riesgo.

En la práctica esto significa que puedes trabajar con una hoja de cálculo bien estructurada o con una herramienta GRC dedicada; lo que el auditor evaluará es la coherencia del método y que los resultados conecten con tus controles a través del plan de tratamiento y la Declaración de Aplicabilidad (SoA).

Un matiz importante de la versión 2022: el análisis no es un evento anual, sino un proceso vivo. Cambios relevantes —un proveedor nuevo, una migración a cloud, un incidente— deben disparar una revisión. Si tu empresa todavía está construyendo sus fundamentos de seguridad, te recomendamos empezar por nuestra guía de por dónde empezar con la ciberseguridad antes de formalizar el análisis.

2. Paso 1 — Inventario y valoración de activos

No puedes proteger lo que no sabes que tienes. El inventario de activos de información es el cimiento del análisis, y conviene abordarlo por capas:

• Información: datos de clientes, código fuente, credenciales, contratos, datos personales (RGPD), propiedad intelectual.
• Aplicaciones y servicios: tu plataforma SaaS, la web corporativa, el ERP/CRM, los repositorios de código, el correo.
• Infraestructura: servidores, cloud (VPC, buckets, bases de datos), redes, equipos de usuario.
• Personas y proveedores: roles clave, hosting, pasarelas de pago, APIs de terceros, freelancers con acceso.

Para cada activo se identifica un propietario (quien decide sobre él, no quien lo administra) y se valora en las tres dimensiones clásicas: confidencialidad, integridad y disponibilidad. Una escala de 1 a 5 por dimensión es suficiente; lo importante es definir qué significa cada nivel en términos de negocio («una fuga de este dato supone sanción RGPD + pérdida de clientes» = confidencialidad 5).

Consejo práctico: no inventaríes hasta el último ratón. Agrupa por tipos («puestos de trabajo de desarrollo», «buckets S3 de producción») y quédate con los activos cuya pérdida dolería de verdad. Un inventario de 40-80 activos agrupados es mucho más útil que uno de 500 filas que nadie mantendrá.

3. Paso 2 — Identificar amenazas y vulnerabilidades

Con los activos sobre la mesa, toca preguntarse qué puede salir mal. Una amenaza es el evento potencial (ransomware, phishing, error humano, caída del proveedor cloud, fuga por empleado descontento); una vulnerabilidad es la debilidad que lo hace posible (falta de MFA, backups sin probar, dependencias sin parchear, contratos sin cláusulas de seguridad).

No partas de cero: los catálogos de amenazas de MAGERIT o los anexos de la ISO 27005 listan decenas de escenarios típicos que puedes filtrar por relevancia. Y complementa el catálogo con la realidad: los incidentes que tu empresa ya ha sufrido, los avisos del INCIBE-CERT y el panorama de amenazas de tu sector. El ransomware y el compromiso de credenciales encabezan hoy cualquier lista realista para pymes tecnológicas.

Para plataformas web, cruza siempre el análisis con el OWASP Top 10: inyección, fallos de control de acceso y configuraciones inseguras son vulnerabilidades técnicas con nombre propio que deben aparecer en tu registro de riesgos, no quedarse solo en el backlog del equipo de desarrollo.

3.1 Un catálogo de partida para empresas tecnológicas

Si no sabes por dónde empezar, este catálogo corto cubre los escenarios que casi siempre acaban en el top-10 de una empresa de software o una plataforma digital:

• Compromiso de credenciales (phishing, contraseñas reutilizadas, tokens filtrados en repositorios).
• Ransomware y malware en equipos corporativos o servidores.
• Explotación de vulnerabilidades web en aplicaciones propias o CMS (plugins desactualizados, inyecciones, fallos de control de acceso).
• Error humano: borrado accidental, despliegue defectuoso, envío de datos al destinatario equivocado, bucket mal configurado.
• Fallo o compromiso de proveedor: caída del cloud, incidente en la pasarela de pago, breach de una herramienta SaaS con tus datos.
• Abuso de privilegios internos: empleado o exempleado con accesos no revocados.
• Pérdida de disponibilidad: DDoS, picos de carga, fallo hardware sin redundancia.
• Incumplimiento normativo: tratamiento de datos personales sin base legal, brecha no notificada a tiempo (RGPD).
• Pérdida de conocimiento clave: salida de la única persona que entiende un sistema crítico.

Cada uno se cruza con los activos a los que aplica y con las debilidades reales de tu entorno. Esa honestidad es la que diferencia un análisis útil: si los backups nunca se han restaurado de prueba, la vulnerabilidad existe aunque incomode escribirla.

4. Paso 3 — Valorar los riesgos: impacto × probabilidad

Cada combinación relevante de activo + amenaza + vulnerabilidad genera un riesgo que hay que valorar. El modelo estándar cruza dos variables:

• Impacto (1-5): consecuencias si el escenario ocurre — económicas, legales, reputacionales y operativas. Define umbrales concretos: nivel 3 = «parada de servicio de 4-24 h o coste de 10.000-50.000 €».
• Probabilidad (1-5): frecuencia esperada, informada por historial propio, exposición y datos del sector. Nivel 4 = «esperable una o más veces al año».

El producto (o la posición en la matriz) da el nivel de riesgo inherente. La matriz 5×5 resultante es la foto que la dirección entiende de un vistazo: la esquina roja son los riesgos inaceptables, la zona verde lo que se asume. Contra esa foto se define el criterio de aceptación: por ejemplo, «tratamos todo riesgo ≥ 12; los de 8-11 se revisan trimestralmente; el resto se acepta».

Dos consejos de campo. Primero, valora en talleres cortos con quien conoce cada sistema —el CTO, el lead de plataforma, el responsable de soporte—, no en solitario desde un despacho: la calidad del análisis depende de ese conocimiento. Segundo, documenta la justificación de cada valoración en una frase; en la auditoría (y en la revisión del año siguiente) valen oro.

4.1 Ejemplo de escalas bien definidas

Para que «consistente y repetible» no se quede en teoría, así se ve una escala de impacto con umbrales de negocio (adáptala a tu tamaño):

• 1 — Insignificante: sin coste apreciable ni afectación a clientes; se resuelve en el día.
• 2 — Menor: coste < 5.000 €, molestias internas, sin visibilidad externa.
• 3 — Moderado: 5.000-50.000 €, degradación de servicio de horas, quejas de clientes.
• 4 — Mayor: 50.000-250.000 €, parada de servicio de más de un día, pérdida de algún cliente, posible sanción.
• 5 — Crítico: > 250.000 €, fuga masiva de datos, sanción grave, daño reputacional duradero, riesgo para la continuidad de la empresa.

Y la de probabilidad: 1 = excepcional (menos de una vez cada 5 años), 2 = improbable (una vez cada 2-5 años), 3 = posible (una vez cada 1-2 años), 4 = probable (una o más veces al año), 5 = frecuente (varias veces al año o intentos constantes observados). Con estas definiciones, dos personas distintas valoran parecido, que es exactamente lo que la norma pide.

5. Paso 4 — El plan de tratamiento

Para cada riesgo por encima del umbral de aceptación hay exactamente cuatro opciones:

• Mitigar: aplicar controles que reduzcan impacto o probabilidad. Es la vía habitual, y los controles elegidos salen del Anexo A: MFA, cifrado, backups inmutables, revisión de código, segregación de accesos…
• Transferir: trasladar parte del riesgo a un tercero — ciberseguro, cláusulas contractuales con proveedores, externalización de un servicio crítico.
• Evitar: eliminar la actividad que genera el riesgo — dejar de almacenar un dato que no necesitas, retirar un servicio legacy expuesto.
• Aceptar: asumirlo formalmente, con firma del propietario del riesgo. Aceptar no es ignorar: es una decisión documentada y revisable.

El plan de tratamiento aterriza cada decisión con control, responsable, plazo y estado; y de ahí nace la SoA: la tabla que recorre los 93 controles del Anexo A justificando cuáles aplican (y contra qué riesgo) y cuáles no. La trazabilidad riesgo → control → evidencia es exactamente lo que el auditor va a recorrer en la auditoría de certificación, así que constrúyela desde el principio.

Tras aplicar los controles se re-estima el riesgo residual, que debe quedar dentro de tu criterio de aceptación. Ese ciclo —inherente, tratamiento, residual— se repite en cada revisión y es la métrica de progreso más honesta del SGSI.

6. Metodologías y herramientas

Sobre el método, tres referencias cubren el 95% de los casos en España:

• MAGERIT: la metodología de la administración pública española. Exhaustiva, con catálogos de amenazas muy completos, y la opción natural si tu empresa también apunta al Esquema Nacional de Seguridad. Su herramienta asociada (PILAR) es potente aunque árida.
• ISO 27005: la guía «oficial» de gestión de riesgos de la familia 27000. Marco flexible más que receta; ideal como base para un método propio ligero.
• Método propio simplificado: perfectamente válido para pymes — activos agrupados, catálogo corto de amenazas, matriz 5×5 y los criterios documentados. Es lo que recomendamos para una primera certificación.

Sobre herramientas: una hoja de cálculo bien diseñada es suficiente y auditable para organizaciones de hasta 100-150 empleados (pestañas: activos, riesgos, tratamiento, SoA, con versionado). Si prefieres software, las opciones GRC open source como eramba o SimpleRisk añaden flujos de revisión y recordatorios; y las plataformas de compliance automatizado tipo Vanta o Drata aceleran la recogida de evidencias, aunque no sustituyen el pensamiento: la valoración sigue siendo tuya.

7. Ejemplo práctico: SaaS B2B de 30 empleados

Aterricemos con un caso tipo, muy parecido a los que acompañamos desde Keliam. Empresa SaaS B2B, 30 empleados, plataforma en cloud, datos de clientes corporativos.

Activos críticos identificados (agrupados): base de datos de producción (C5/I5/D4), código fuente y pipeline CI/CD (C4/I5/D3), panel de administración interno (C5/I4/D3), correo y Workspace corporativo (C4/I3/D3), proveedor cloud e integraciones de pago (C4/I4/D5).

Tres riesgos de su top-10, con tratamiento:

• Compromiso de credenciales de un desarrollador con acceso a producción — impacto 5, probabilidad 4 → riesgo 20. Mitigar: MFA obligatorio resistente a phishing, acceso a producción por roles temporales, alertas de inicio de sesión anómalo. Residual: 8.
• Ransomware en equipos corporativos que salta a sistemas compartidos — impacto 4, probabilidad 3 → 12. Mitigar: EDR en endpoints, backups inmutables probados trimestralmente, segmentación. Transferir: ciberseguro. Residual: 6.
• Caída prolongada del proveedor cloud principal — impacto 4, probabilidad 2 → 8. Dentro del umbral de revisión: se acepta con plan de continuidad documentado y RTO acordado con clientes. Residual: 8 (aceptado y firmado).

El taller completo les llevó tres sesiones de dos horas más una semana de documentación. Ese registro de riesgos —no las políticas— fue lo que más valoró el auditor en su fase 1, y la matriz se convirtió en la diapositiva fija del reporting trimestral a dirección.

8. Mantener vivo el análisis: revisiones y disparadores

El registro de riesgos es un documento operativo, no un entregable de certificación. Para que siga siendo real durante los tres años del ciclo, establece dos mecanismos:

Revisión periódica. Una revisión anual completa como mínimo (idealmente coincidiendo con la preparación de la auditoría interna) y un repaso ligero trimestral del top-10 en el comité o reunión de dirección: ¿ha cambiado la probabilidad de algo? ¿los controles comprometidos se han implantado? ¿el residual sigue dentro del criterio de aceptación? Veinte minutos bien empleados que además generan la evidencia de seguimiento que la cláusula 9 exige.

Disparadores por cambio. Define una lista corta de eventos que obligan a re-evaluar riesgos sin esperar al ciclo: incorporación de un proveedor crítico, lanzamiento de un producto o servicio nuevo, migración de infraestructura, incidente de seguridad relevante (propio o de un proveedor), cambio normativo o crecimiento significativo de plantilla. Intégralo donde ya trabaja el equipo: una etiqueta en el gestor de proyectos o un checklist en el proceso de compras es suficiente para que ningún cambio grande pase sin su re-evaluación.

Este mantenimiento es, además, el puente natural hacia la mejora continua del SGSI: los riesgos re-valorados alimentan objetivos, los objetivos generan controles y las métricas verifican el avance. Ese ciclo completo lo desarrollaremos en los próximos capítulos de la serie dedicados al ENS y a la mejora continua.

9. Errores que arruinan un análisis de riesgos

• Hacerlo en solitario. El consultor (interno o externo) que rellena la matriz sin talleres produce un documento que el equipo no reconoce y el auditor desmonta con dos preguntas.
• Granularidad absurda. 400 riesgos indistinguibles paralizan; 25-60 riesgos bien formulados se gestionan.
• Escalas sin definición. Si «impacto 3» no tiene umbral concreto, cada persona valora un análisis distinto y los resultados no son comparables (incumples la norma).
• Ignorar a los proveedores. Hosting, pasarelas, APIs de terceros y freelancers concentran hoy buena parte del riesgo real; un análisis que solo mira dentro está incompleto. Si gestionas plataformas ecommerce, nuestro artículo sobre pentesting para tiendas online muestra cuántos vectores llegan por integraciones.
• No revisarlo nunca. Un análisis de hace 18 meses sin cambios registrados le dice al auditor que el SGSI está muerto. Revisión anual mínima + disparadores por cambios.
• Confundir análisis con auditoría técnica. El pentest encuentra vulnerabilidades concretas; el análisis de riesgos las pone en contexto de negocio. Se alimentan mutuamente, pero no se sustituyen.

Conclusión: la brújula del SGSI

El análisis de riesgos no es el trámite previo a «lo importante»: es lo importante. De él salen las prioridades de inversión, la justificación de cada control de la SoA y el lenguaje común entre el equipo técnico y la dirección. Hazlo con método, con la gente adecuada en la sala y con escalas definidas, y el resto de la certificación se convierte en ejecución ordenada.

En el siguiente capítulo de la serie entramos en los controles organizativos del Anexo A —políticas, roles y gobernanza—, y si aún no has leído la visión completa del proceso, empieza por la guía completa de certificación ISO 27001.