ISO 27001 no propone gestionar la seguridad de la información mediante una lista fija de controles aplicados de la misma forma a todas las organizaciones. Si consultas nuestra guía completa de ISO 27001, verás que la norma basa su eficacia en la adaptabilidad al riesgo real.
El enfoque parte de otra pregunta clave:
¿Qué podría impedir que el SGSI y la organización alcancen sus objetivos, y qué decisiones debemos tomar frente a esa incertidumbre?
Esa pregunta conecta el contexto de la organización y alcance del SGSI con los riesgos, las oportunidades, los controles y las decisiones de tratamiento.
Pero existe una dificultad frecuente: bajo la expresión “gestión de riesgos ISO 27001” suelen mezclarse conceptos distintos. Una empresa puede terminar con un Excel lleno de colores, una lista inconexa de vulnerabilidades y 93 controles marcados mecánicamente como sí/no sin poseer una metodología de riesgo verdaderamente útil. Para evitarlo, necesitamos separar cada pieza.
Riesgos y oportunidades en ISO 27001: dos capas que conviene distinguir
Cuando ISO 27001 habla de planificación en la Cláusula 6, no todo se reduce a riesgos técnicos de infraestructura. Como ya sentamos al explorar qué es un SGSI y cómo definir su alcance, podemos distinguir dos capas claramente relacionadas:
1. Riesgos y oportunidades del SGSI
Son cuestiones que pueden afectar la capacidad del sistema de gestión para lograr sus resultados previstos y mejorar de manera sostenida.
Ejemplos habituales:
- Falta de recursos especializados o rotación en el equipo de seguridad.
- Dependencia excesiva de una sola persona clave para operar los controles.
- Cambio regulatorio brusco que altera las obligaciones de cumplimiento.
- Adquisición o fusión con otra empresa que modifica los límites operativos.
- Migración acelerada a entornos multi-cloud sin gobierno unificado.
- Oportunidad de automatizar la recolección de evidencias de auditoría.
- Oportunidad de integrar el SGSI con continuidad de negocio o privacidad de datos.
No todos estos elementos son “riesgos de ciberseguridad” en sentido puramente operativo, pero afectan directamente al funcionamiento del propio SGSI.
2. Riesgos de seguridad de la información
Son riesgos relacionados con la preservación de las propiedades de la información frente a eventos adversos:
- Confidencialidad: acceso no autorizado a información reservada o sensible.
- Integridad: modificación, corrupción o destrucción no autorizada de datos.
- Disponibilidad: interrupción de accesos a sistemas o información en el momento necesario.
Ejemplo práctico: Una empresa SaaS depende de un proveedor cloud para su infraestructura de producción. El hecho de depender de ese proveedor forma parte del contexto. Un escenario de riesgo bien redactado sería: “Una interrupción prolongada del proveedor cloud impide prestar el servicio contratado, provocando el incumplimiento de los SLA y pérdidas financieras directas.”
Oportunidad no significa automáticamente “riesgo positivo”
En gestión de riesgos existen marcos teóricos en los que el concepto de riesgo abarca tanto los efectos negativos como positivos de la incertidumbre sobre los objetivos. Sin embargo, al diseñar el SGSI conviene no simplificar afirmando que oportunidad = riesgo positivo.
La oportunidad en ISO 27001 representa una condición o posibilidad que permite mejorar activamente los resultados del sistema. Si una organización detecta que recopila evidencias manualmente desde ocho herramientas aisladas, esa ineficiencia genera un riesgo de error humano y pérdida de tiempo. Pero también abre una oportunidad: automatizar la recolección de evidencias e integrar APIs para mejorar la trazabilidad y reducir drásticamente el tiempo de auditoría.
No hace falta inventar una “matriz ISO de oportunidades” compleja. Lo verdaderamente importante es identificar qué acciones concretas pueden aumentar la eficacia del SGSI.
El riesgo empieza por los objetivos, no por la matriz
Uno de los errores más extendidos es iniciar la gestión de riesgos abriendo una hoja de cálculo con columnas preseteadas de activo, amenaza y probabilidad, sin haber determinado primero qué objetivos se pretenden proteger.
Como vimos al repasar los conceptos de riesgo, evaluación y tratamiento, el riesgo siempre está ligado a la incertidumbre sobre la consecución de objetivos. Ejemplos de objetivos protegidos por el SGSI:
- Mantener disponible en un 99,9 % la plataforma de facturación electrónica.
- Proteger la confidencialidad de la información médica o datos sensibles de clientes.
- Garantizar la integridad de las bases de datos de órdenes de pago bancarias.
- Cumplir rigurosamente las obligaciones contractuales y regulatorias aplicables.
Sin objetivos claramente trazados, cualquier puntuación de riesgo corre el riesgo de convertirse en un número abstracto carente de contexto de negocio.
Riesgo no es amenaza, vulnerabilidad ni activo
Para formular escenarios de riesgo útiles para la toma de decisiones, es imprescindible dominar las diferencias conceptuales básicas:
| Concepto | Definición en el SGSI | Ejemplo | Por qué NO es el riesgo completo |
|---|---|---|---|
| Amenaza | Causa potencial de un incidente no deseado que puede dañar un sistema o sistema de información. | Ransomware, atacante externo, fallo de suministro eléctrico. | La amenaza por sí sola no indica el nivel de exposición ni los controles existentes. |
| Vulnerabilidad | Debilidad o condición que puede ser explotada por una amenaza. | Servidor web sin parches de seguridad aplicados. | Describe un defecto o condición, no el impacto final ni el escenario completo. |
| Activo | Elemento con valor para la organización dentro del alcance del SGSI. | Base de datos de clientes, servidor ERP, repositorio de código. | El activo es la entidad afectada, pero puede verse involucrado en múltiples escenarios distintos. |
| Escenario de Riesgo | Relación estructurada entre objetivo, activo, amenaza, vulnerabilidad y consecuencia. | Explotación de software desactualizado por ransomware que cifra la base de datos de facturación provocando indisponibilidad. | Representa la unidad completa de análisis para evaluar y tratar el riesgo. |
Decir “Ransomware = riesgo alto” o “ERP = riesgo 20” aporta muy poco a la dirección. Es necesario estructurar el escenario completo para determinar la gravedad real y las respuestas necesarias.
Riesgo no es simplemente “probabilidad × impacto”
Muchas organizaciones utilizan metodologías en las que el riesgo se calcula multiplicando numéricamente probabilidad (o likelihood) por impacto. Esta aproximación es totalmente válida como herramienta metodológica interna, pero ISO 27001 no exige ni impone la fórmula Riesgo = Probabilidad × Impacto como requisito universal obligatorio.
La norma permite la adopción de metodologías cualitativas, semicuantitativas o cuantitativas (como FAIR u OCTAVE), siempre que el proceso sea:
- Definido y documentado: con reglas claras explicadas de forma consistente.
- Coherente y repetible: que dos analistas independientes lleguen a conclusiones similares ante las mismas condiciones.
- Útil para la decisión: capaz de priorizar acciones y justificar asignaciones presupuestarias reales.
Cómo construir una metodología de evaluación útil
Una metodología interna madura debe proporcionar respuestas claras a diez preguntas fundamentales:
- ¿Cómo se identifican y redactan los escenarios de riesgo de forma homogénea?
- ¿Qué escalas se utilizan para valorar consecuencias e incertidumbre?
- ¿Cómo se toman en cuenta las opiniones de los propietarios de los procesos?
- ¿Qué criterios determinan qué nivel de riesgo requiere tratamiento obligatorio?
- ¿Quién posee la autoridad formal para aceptar los distintos niveles de riesgo residual?
- ¿Cómo se diferencian el análisis del riesgo y la evaluación frente a criterios?
- ¿De qué manera se contrasta el tratamiento con el conjunto de referencia del Anexo A?
- ¿Cómo se refleja la decisión en la Declaración de Aplicabilidad (SoA)?
- ¿Qué disparadores (cambios, incidentes) obligan a reevaluar los riesgos fuera del ciclo habitual?
- ¿Cómo se documenta todo el proceso para garantizar trazabilidad ante auditorías internas y externas?
Criterios, identificación, análisis y evaluación (risk assessment)
Siguiendo las directrices de la norma de orientación ISO/IEC 27005:2022 y el marco de referencia ISO 31000:2018, el proceso de apreciación del riesgo (risk assessment) comprende tres fases secuenciales:
Paso 1 — Definir criterios de riesgo y de aceptación
Los criterios son los parámetros de medición frente a los cuales se compara la magnitud de un riesgo. Deben contemplar aspectos operativos, financieros, legales, reputacionales y de continuidad.
Ejemplo de criterios de consecuencia de disponibilidad:
- Baja: Interrupción inferior a 30 minutos sin afectación a clientes ni incumplimiento de SLA.
- Media: Interrupción entre 30 minutos y 4 horas que degrada el servicio o genera reclamaciones menores.
- Alta: Caída superior a 4 horas de un servicio crítico con penalizaciones contractuales o infracción regulatoria.
Asimismo, los criterios de aceptación establecen las líneas rojas corporativas. Por ejemplo, los riesgos clasificados como Críticos no pueden aceptarse bajo ningún concepto sin la aprobación explícita del Comité de Dirección y un plan de mitigación inmediato.
Paso 2 — Identificación de riesgos
Consiste en descubrir, reconocer y describir los riesgos que pueden impedir el logro de los objetivos del SGSI. Requiere vincular activos, amenazas, vulnerabilidades y consecuencias asociadas.
Paso 3 — Análisis de riesgos
Es la fase dedicada a comprender la naturaleza del riesgo y determinar su nivel. En este punto es indispensable evaluar los controles existentes. Si la empresa ya dispone de autenticación de doble factor (MFA) y copias de seguridad inmutables, la estimación del escenario debe reflejar el efecto mitigador de dichos controles operativos.
Paso 4 — Evaluación de riesgos
Consiste en comparar los resultados del análisis de riesgo con los criterios de riesgo previamente establecidos para determinar si el riesgo es tolerable o si requiere tratamiento. Como vimos al analizar cómo se conectan los conceptos dentro del SGSI, evaluar es decidir prioridades.
Respuesta de tratamiento y selección de controles
Una vez evaluados los riesgos, la organización debe seleccionar las opciones de tratamiento más adecuadas. Las opciones fundamentales son:
- Mitigar / Reducir: Aplicar controles de seguridad (técnicos, organizativos, físicos o de personas) para disminuir la probabilidad o la consecuencia.
- Evitar: Decidir no iniciar o interrumpir la actividad que da origen al riesgo (por ejemplo, desestimar el uso de un servicio legacy inseguro).
- Compartir / Transferir: Transferir parte del impacto financiero o de servicio a un tercero mediante contratos, SLAs reforzados o pólizas de seguro de ciberriesgos.
- Aceptar: Retener conscientemente el riesgo residual si este se encuentra dentro de los criterios de aceptación aprobados.
Es vital recalcar que no todo tratamiento consiste en comprar una nueva herramienta de software. Con frecuencia, la revisión de un procedimiento operativo, la delimitación de roles o la formación del personal ofrecen una mitigación más eficaz y sostenible.
La Declaración de Aplicabilidad (SoA) y el Anexo A
Un error muy común entre organizaciones que buscan certificarse es abrir el Anexo A de ISO 27001 e ir marcando directamente los 93 controles de ISO/IEC 27002:2022 antes de analizar sus propios riesgos.
La secuencia metodológica correcta dictada por ISO 27001 es:
Contexto y Objetivos → Riesgos Evaluados → Opciones de Tratamiento → Controles Necesarios → Comparación con Anexo A → Justificación de Inclusiones/Exclusiones → Declaración de Aplicabilidad (SoA)
El Anexo A actúa como un catálogo de referencia de 93 controles (divididos en 37 organizacionales, 8 de personas, 14 físicos y 34 tecnológicos) para verificar que no se haya omitido ninguna salvaguarda necesaria. Si la empresa requiere controles adicionales no incluidos en el Anexo A (por ejemplo, exigencias reguladoras del sector bancario o médico), puede e incluso debe añadirlos a su esquema de tratamiento.
La Declaración de Aplicabilidad (SoA) no es un simple documento estático de respuestas sí/no. Es la pieza fundamental de evidencia que demuestra al auditor por qué cada control es necesario, si se encuentra implementado y cuáles son las justificaciones razonables para cualquier exclusión.
Riesgo residual, aceptación y autoridades de decisión
Tras la aplicación de los controles de seguridad seleccionados, el riesgo no desaparece por completo. El nivel que permanece se denomina riesgo residual.
El objetivo de la gestión de riesgos no es alcanzar el "riesgo cero" (un concepto irreal en entornos operativos), sino garantizar que el riesgo residual sea conocido, controlado y aceptado formalmente por la autoridad competente.
Importante: El CISO o el equipo de seguridad facilita el análisis y aconseja sobre las salvaguardas, pero la aceptación formal del riesgo residual debe recaer en el Propietario del Riesgo (Risk Owner), es decir, el responsable de negocio o dirección con capacidad para asumir el impacto operativo y financiero.
Asimismo, la decisión de aceptar un riesgo debe incluir fecha de caducidad y condiciones de seguimiento. Aceptar un riesgo no equivale a ignorarlo indefinidamente; requiere revisiones periódicas o tras cualquier cambio significativo en el entorno de operaciones.
Casos prácticos: ransomware, cloud, IA y cambio climático
Para aterrizar estos conceptos en la realidad corporativa actual, analicemos cuatro escenarios típicos:
Caso 1 — Ataque de Ransomware en infraestructura híbrida
- Riesgo: Interrupción prolongada de los servicios centrales por cifrado malicioso de servidores debido a credenciales administrativas robadas.
- Tratamiento: Despliegue obligatorio de MFA en todos los accesos remotos y administrativos, aislamiento de copias de seguridad inmutables y despliegue de soluciones EDR/XDR.
- Controles Anexo A: A.5.15 (Gestión de identidades), A.8.5 (Autenticación segura), A.8.13 (Copias de seguridad).
Caso 2 — Gobernanza de servicios Multi-Cloud
- Riesgo: Fuga involuntaria de repositorios de datos confidenciales por errónea configuración de permisos en buckets cloud.
- Tratamiento: Implementación de políticas de configuración como código (IaC), análisis automatizado de postura de seguridad cloud (CSPM) y cifrado en reposo con claves gestionadas por la empresa.
- Controles Anexo A: A.8.9 (Gestión de configuración), A.8.24 (Uso de criptografía).
Caso 3 — Uso de Inteligencia Artificial Generativa en la plantilla
- Riesgo: Exposición no autorizada de código fuente o propiedad intelectual de la empresa al introducir datos sensibles en modelos de IA públicos de terceros.
- Oportunidad: Utilizar herramientas de IA con acuerdos empresariales de privacidad para acelerar el desarrollo informático.
- Tratamiento: Publicación de directrices de uso aceptable de IA, despliegue de DLP (Data Loss Prevention) y contratación de planes empresariales con garantía de no reentrenamiento de modelos.
- Controles Anexo A: A.5.10 (Uso aceptable de la información y otros activos asociados), A.5.31 (Requisitos legales, estatutarios, reglamentarios y contractuales).
Caso 4 — Relevancia del cambio climático en el SGSI (Amd 1:2024)
- Contexto: Conforme al enmienda ISO/IEC 27001:2022/Amd 1:2024, las organizaciones deben determinar si el cambio climático es una cuestión relevante en su contexto.
- Escenario de riesgo: Aumento en la frecuencia de olas de calor extremas o inundaciones que afectan la refrigeración o el suministro eléctrico de los Data Centers locales.
- Tratamiento: Migración de cargas de trabajo críticas a Data Centers con redundancia ambiental de alta eficiencia o diversificación geográfica.
Evidencias de auditoría, errores frecuentes y plantillas
En el momento de afrontar una auditoría de certificación (Cláusula 9.2 y 9.3), el auditor no buscará únicamente la existencia de una tabla con colores. Verificará que existe un proceso vivo y coherente exigiendo las siguientes evidencias documentadas:
- Metodología de gestión de riesgos formalmente aprobada.
- Criterios de evaluación y de aceptación documentados.
- Registro o Inventario de Riesgos actualizado con sus respectivos Risk Owners identificados.
- Justificación documentada de las decisiones de tratamiento tomadas.
- Declaración de Aplicabilidad (SoA) aprobada por la Dirección.
- Actas de revisión de riesgos firmadas tras cambios importantes o incidentes de seguridad.
Ejemplo simplificado de estructura de Registro de Riesgos
| ID | Escenario de Riesgo | Riesgo Inicial | Tratamiento Seleccionado | Controles Anexo A | Riesgo Residual | Aceptado Por |
|---|---|---|---|---|---|---|
| R-01 | Robo de credenciales de soporte por falta de MFA originando acceso no autorizado a datos. | Alto | Mitigar: Despliegue de MFA obligatorio y formación en phishing. | A.5.17, A.8.5, A.7.4 | Bajo | Director de Tecnología (CTO) |
| R-02 | Indisponibilidad del servicio por caída de Data Center primario en zona de inundación. | Crítico | Mitigar / Evitar: Réplica activa-pasiva en región cloud secundaria. | A.8.14, A.5.29, A.5.30 | Medio (Aceptable) | Comité de Dirección / CEO |
Al estructurar tus políticas y directrices operativas, es recomendable revisar nuestros artículos sobre liderazgo y compromiso en ISO 27001 y la definición de una política de seguridad de la información alineada con la estrategia de la organización. Asimismo, puedes comprobar el estado de madurez inicial de tus procesos realizando un análisis GAP ISO 27001.
Preguntas frecuentes
¿ISO 27001 obliga a usar una matriz 5×5 o multiplicar probabilidad por impacto?
No. La matriz 5×5 y la fórmula cuantitativa simple son opciones metodológicas habituales pero no obligatorias. ISO 27001 exige una metodología definida, coherente y repetible, que bien puede ser cualitativa o basarse en otros marcos reconocidos.
¿Cuál es la diferencia entre ISO/IEC 27001 e ISO/IEC 27005?
ISO 27001 es la norma certificable que establece los requisitos del SGSI. ISO 27005 es una norma de orientación específica que proporciona directrices detalladas sobre cómo llevar a cabo la gestión de riesgos de seguridad de la información.
¿Puede el CISO aceptar todos los riesgos residuales de la empresa?
No es recomendable. La aceptación formal del riesgo residual debe recaer en los Risk Owners (propietarios del riesgo), que suelen ser los directores de línea o de negocio con autoridad presupuestaria para asumir las consecuencias operativas.
¿Qué diferencia hay entre la evaluación de riesgos y el plan de tratamiento de riesgos?
La evaluación comprende la identificación, análisis y valoración de los riesgos para tomar decisiones. El plan de tratamiento (desarrollado en detalle más adelante en nuestro clúster) es el plan operativo que asigna tareas, responsables, recursos y plazos para ejecutar dichas decisiones.
De la evaluación a la gobernanza práctica
Una gestión de riesgos efectiva transforma el SGSI de una obligación documental en una ventaja competitiva de gobierno corporativo. El siguiente paso en la serie consiste en convertir estas decisiones en objetivos de seguridad de la información claros y medibles.
Si quieres dominar el diseño e implementación de metodologías de riesgo, cuadros de mando, gobernanza de TI, controles y evaluación de terceros en escenarios reales, te recomendamos explorar el curso Analista GRC. Gobernanza de IT, Riesgo y Cumplimiento.
