Introducción
El análisis de riesgos es uno de los pilares de un Sistema de Gestión de Seguridad de la Información. Sin esta actividad, la organización termina aplicando controles por intuición o presión comercial, en lugar de responder a amenazas reales con criterios de negocio.
ISO 27001 no exige una plantilla única, pero sí un método consistente, repetible y alineado con el contexto de la organización. No basta con llenar una matriz: hay que demostrar que las decisiones de seguridad tienen fundamento.
¿Qué busca ISO 27001 en el análisis de riesgos?
La norma espera que la organización defina criterios claros para evaluar riesgos, identifique activos, amenazas y vulnerabilidades, estime impacto y probabilidad, y determine qué riesgos requieren tratamiento.
- Definir criterios de evaluación
- Identificar riesgos de forma estructurada
- Seleccionar controles apropiados
- Conservar evidencia y revisión periódica
Paso 1: Definir el contexto
Antes de valorar riesgos, conviene delimitar qué procesos, servicios, sedes, sistemas y requisitos legales forman parte del alcance del SGSI. Sin este contexto, la evaluación se vuelve genérica y poco defendible ante auditoría.
- Procesos cubiertos por el SGSI
- Requisitos contractuales y regulatorios
- Dependencias tecnológicas críticas
- Impacto esperado sobre operación, reputación y cumplimiento
Paso 2: Identificar activos de información
Un activo no es solo hardware. También pueden ser bases de datos, credenciales, repositorios, servicios SaaS, documentación clave o personal con conocimiento crítico.
| Tipo de activo | Ejemplos |
|---|---|
| Información | Bases de datos, contratos, historiales, reportes |
| Tecnología | Servidores, firewalls, hipervisores, repositorios Git |
| Servicios | Correo, ERP, VPN, plataformas cloud |
| Personas | Administradores, responsables de procesos, terceros críticos |
Paso 3: Identificar amenazas y vulnerabilidades
Una amenaza es el evento o actor que puede causar daño. Una vulnerabilidad es la debilidad que permite que ese daño se materialice.
| Activo | Amenaza | Vulnerabilidad |
|---|---|---|
| Servidor web | Ransomware | Parches pendientes |
| Correo corporativo | Phishing | MFA no habilitado |
| Base de datos | Acceso no autorizado | Roles excesivos |
| Pipeline CI/CD | Manipulación del despliegue | Secretos expuestos |
Paso 4: Estimar impacto y probabilidad
Muchas organizaciones usan escalas simples de 1 a 5. Lo importante es que el criterio esté documentado y sea consistente entre áreas.
Impacto
- Interrupción operativa
- Pérdida financiera
- Afectación reputacional
- Incumplimiento legal o contractual
Probabilidad
- Exposición del activo
- Frecuencia del evento
- Controles ya implementados
- Facilidad de explotación
Paso 5: Calcular el nivel de riesgo
Un método común es multiplicar impacto por probabilidad. No es la única opción, pero funciona bien cuando la organización necesita una metodología simple y repetible.
Riesgo = Impacto x Probabilidad| Resultado | Nivel |
|---|---|
| 1 - 4 | Bajo |
| 5 - 9 | Medio |
| 10 - 15 | Alto |
| 16 - 25 | Crítico |
Paso 6: Determinar el tratamiento
Cada riesgo debe terminar en una decisión explícita y trazable.
- Mitigar: implementar controles
- Aceptar: asumir el riesgo dentro del umbral definido
- Transferir: mover parte del riesgo a terceros o seguros
- Evitar: cambiar o eliminar la actividad que genera el riesgo
Paso 7: Relacionar riesgos con controles del Anexo A
Aquí el análisis se conecta con la Declaración de Aplicabilidad. Los controles no se seleccionan por moda, sino porque responden a riesgos concretos.
- MFA y gestión de identidades para accesos críticos
- Hardening y gestión de vulnerabilidades para servidores
- Backups y pruebas de restauración para continuidad
- Monitoreo y alertamiento para detección temprana
- Segregación de funciones en procesos sensibles
Ejemplo práctico de matriz de riesgos
| Activo | Riesgo | Impacto | Probabilidad | Nivel | Tratamiento |
|---|---|---|---|---|---|
| Correo corporativo | Robo de cuentas por phishing | 5 | 4 | 20 | MFA, capacitación y revisión de políticas |
| Servidor ERP | Caída por ransomware | 5 | 3 | 15 | EDR, backups y segmentación |
| Repositorio Git | Fuga de secretos | 4 | 4 | 16 | Secret scanning, vault y permisos mínimos |
Errores frecuentes
1. Hacer una matriz demasiado teórica
Si el negocio no participa, el documento puede verse bien pero no reflejar la realidad operativa.
2. Marcar todo como crítico
Eso destruye la priorización. La utilidad del análisis depende de distinguir qué debe atenderse primero.
3. No revisar cambios del entorno
Migraciones a nube, nuevas integraciones, automatizaciones o uso de IA modifican el perfil de riesgo.
4. Separar cumplimiento y operación
El SGSI debe conversar con TI, DevOps, RR. HH., dirección y las áreas responsables del negocio.
Recomendaciones finales
Para que el análisis de riesgos aporte valor real, conviene mantener una metodología simple, respaldada por evidencia y revisada de manera periódica.
- Usa talleres breves por proceso
- Integra incidentes, hallazgos y vulnerabilidades reales
- Documenta responsables y fechas de revisión
- Incluye riesgos en cloud, CI/CD, terceros e IA
Conclusión
Un buen análisis de riesgos en ISO 27001 no es burocracia: es una herramienta de decisión. Permite justificar inversiones, priorizar controles y demostrar que la seguridad está alineada con la realidad técnica y de negocio.
Cuando el método es claro y repetible, el SGSI gana credibilidad, utilidad operativa y mejores resultados ante auditoría.