Cuando un auditor, un cliente enterprise o una autoridad supervisora pide ver el marco de gestión de riesgos, no busca un PDF con la palabra «framework» en la portada. Busca evidencia de que la organización identifica riesgos con método, prioriza con criterio, trata lo que importa y revisa el resultado con periodicidad definida. Sin eso, la certificación ISO 27001 se estanca, el programa NIS2 no aguanta una inspección y el due diligence de clientes se convierte en un ejercicio de improvisación.
El problema habitual no es la falta de documentos: es la falta de un marco coherente que conecte política, evaluación, controles y supervisión en un solo ciclo. Y el primer obstáculo suele ser el vocabulario: «Risk Management Framework», «ISO 27005» y «NIST RMF» se usan como sinónimos cuando en realidad describen enfoques distintos con alcances y audiencias diferentes.
Tres marcos distintos bajo el mismo nombre
Antes de elegir pasos o herramientas, conviene aclarar qué marco se está implantando.
ISO/IEC 27005:2022 es la guía internacional de gestión de riesgos de seguridad de la información. No es certificable por sí sola: complementa ISO 27001 y describe un proceso cíclico para identificar, analizar, evaluar y tratar riesgos. Es el marco de referencia más usado en Europa para construir el registro de riesgos que exige la cláusula 6.1.2 de ISO 27001 y que muchos programas NIS2 asumen como base metodológica.
NIST Risk Management Framework (RMF) es un proceso de siete pasos (Prepare, Categorize, Select, Implement, Assess, Authorize, Monitor) definido en NIST SP 800-37 Rev. 2 para gestionar riesgos de seguridad y privacidad en sistemas de información. Es prescriptivo, orientado al ciclo de vida del sistema y muy influyente en entornos regulados de Estados Unidos. En la UE se consulta con frecuencia por empresas con clientes estadounidenses o por equipos que trabajan con el NIST Cybersecurity Framework 2.0, pero no es el marco que una autoridad española o europea espera ver como sustituto de ISO 27005 en un SGSI.
Marco de gestión de riesgos empresarial (ERM) es el nivel superior: integra riesgos operativos, financieros, legales y de ciberseguridad bajo gobernanza de dirección. ISO 31000 describe principios generales; no sustituye la profundidad de ISO 27005 en seguridad de la información, pero define apetito de riesgo, roles y reporting que el marco de ciberseguridad debe respetar.
Para la mayoría de organizaciones europeas medianas, la combinación práctica es: ISO 27005 como metodología de riesgos de seguridad, ISO 27001 como sistema de gestión que exige evidencias, y alineación con los requisitos de evaluación de riesgos de NIS2 (artículo 21) cuando la empresa está en alcance o vende a entidades que sí lo están.
El ciclo de ISO 27005: seis fases que definen un marco operativo
La revisión 2022 de ISO/IEC 27005 reorganiza el proceso en fases que se ejecutan en paralelo más que en cascada estricta. Son el núcleo metodológico que recomendamos usar al crear una evaluación de riesgos según ISO 27001, porque cada fase produce un artefacto que el auditor puede verificar.
1. Establecimiento del contexto. Define alcance (sistemas, procesos, ubicaciones), criterios de aceptación de riesgo, apetito de riesgo aprobado por dirección y roles (propietarios de activos, propietarios de riesgo, responsable del SGSI). Sin contexto documentado, el resto del marco carece de límites.
2. Identificación de riesgos. Dos enfoques válidos según la norma: basado en activos (amenaza + vulnerabilidad sobre un activo) o basado en escenarios (evento de riesgo con consecuencias definidas). El error frecuente es mezclar ambos en el mismo registro sin criterio, lo que hace el inventario inconsistente.
3. Análisis de riesgos. Asigna valores de probabilidad e impacto con escala documentada (cualitativa, semicuantitativa o cuantitativa). El resultado es el nivel de riesgo antes del tratamiento. La escala debe ser la misma en todo el registro y estar justificada en la metodología.
4. Evaluación de riesgos. Compara el nivel analizado con los criterios de aceptación definidos en el contexto. Decide qué riesgos requieren tratamiento, cuáles se aceptan y cuáales se escalan a dirección. La evaluación es una decisión, no un cálculo automático.
5. Tratamiento de riesgos. Selecciona opciones: modificar (controles), retener, evitar o compartir. Los controles elegidos deben trazarse al Statement of Applicability (SoA) y al Anexo A de ISO 27001. El propietario del riesgo aprueba el plan de tratamiento y acepta el riesgo residual documentado.
6. Comunicación, consulta, supervisión y revisión. El marco no termina con el tratamiento: exige comunicar resultados a las partes interesadas, monitorizar indicadores y revisar el registro cuando hay cambios significativos (nuevo sistema, incidente grave, cambio regulatorio, fusión). La cláusula A.5.30 de ISO 27001:2022 exige revisión ante cambios; NIS2 exige gestión de riesgos continua, no un ejercicio anual aislado.
Los seis componentes que debe tener cualquier marco creíble
Independientemente de si la empresa cita ISO 27005, NIST o un marco interno, un auditor o un cliente sofisticado busca estos elementos:
- Política de gestión de riesgos aprobada por dirección, con apetito y criterios de aceptación explícitos.
- Metodología documentada (escalas, fórmulas o matrices, definiciones de probabilidad e impacto).
- Registro de riesgos vivo con identificador, descripción, propietario, nivel actual, tratamiento y fecha de revisión.
- Plan de tratamiento vinculado a controles implementados y plazos de remediación.
- Procedimiento de revisión con triggers (incidentes, cambios, auditorías) además de la revisión periódica programada.
- Evidencias de supervisión (informes a dirección, actas, indicadores de riesgo residual).
Un marco que solo contiene la metodología en PowerPoint y un Excel desactualizado falla en el componente 3 y, por extensión, en todos los demás.
Cómo conectar el marco con NIS2, RGPD y auditorías
El marco de gestión de riesgos de seguridad no opera en vacío: alimenta y recibe información de otros programas.
NIS2 exige en el artículo 21 un análisis de riesgos de ciberseguridad documentado, políticas de seguridad y medidas proporcionales al riesgo. Un registro ISO 27005 bien mantenido cubre la mayor parte del análisis; NIS2 añade obligaciones de notificación de incidentes, gestión de cadena de suministro y responsabilidad directiva que el marco debe referenciar en el contexto y en los planes de tratamiento. Para mantener el ciclo activo tras la primera implantación, el artículo sobre cómo mantener el cumplimiento NIS2 describe los triggers de revisión que conviene integrar en el procedimiento de supervisión del marco.
RGPD exige evaluaciones de impacto (EIPD) cuando el tratamiento de datos implica riesgo alto para los derechos de las personas. El marco de riesgos de seguridad y el análisis de impacto de privacidad son complementarios: un riesgo de brecha de datos puede aparecer en ambos, pero la EIPD evalúa impacto sobre personas, no solo sobre activos TI.
Auditorías ISO 27001 verifican que el proceso de evaluación de riesgos se ejecutó, que el SoA refleja decisiones de tratamiento y que los controles del Anexo A están justificados. Un autoevaluación previa ayuda a detectar si el marco está listo antes de invertir en auditoría externa.
Cinco errores que convierten el marco en papel mudo
1. Registro sin propietarios de riesgo. Si nadie es responsable de cada entrada, el tratamiento no ocurre y el riesgo residual no se acepta formalmente.
2. Escalas cambiadas entre revisiones. Recalcular con una matriz distinta invalida comparaciones históricas y genera dudas en auditoría.
3. Tratar todo como «alto». Priorizar sin discriminación agota recursos y demuestra que la evaluación no distingue criticidad real.
4. Ignorar riesgos de terceros. Proveedores cloud, SaaS críticos y subcontratas aparecen en NIS2 y en ISO 27001 (A.5.19-A.5.23). Un marco que solo cubre infraestructura interna deja un hueco visible.
5. Revisión solo anual por calendario. Sin triggers por incidente o cambio de sistema, el marco queda desalineado con la realidad operativa entre dos revisiones formales.
Mejores prácticas para implantar y mantener el marco
Empezar por el contexto y el apetito de riesgo, no por la herramienta. La herramienta (GRC, Excel, registro en el SGSI) viene después de definir criterios.
Limitar el alcance inicial a un dominio acotado (un producto, una unidad de negocio, un entorno cloud) y expandir cuando el ciclo funcione.
Usar escenarios para riesgos de negocio y enfoque por activos para inventario técnico, documentando qué enfoque se usa en cada parte del registro.
Vincular cada control del SoA a un riesgo o a una decisión de aplicabilidad justificada. Controles sin trazabilidad son el hallazgo más común en auditorías de primera certificación.
Reportar riesgo residual a dirección con periodicidad fija (trimestral o semestral en entidades reguladas), no solo cuando llega la auditoría.
Integrar hallazgos de incidentes y pentests como input obligatorio del ciclo de revisión.
Evitar duplicar marcos para ISO 27001, NIS2 y clientes: un registro maestro con vistas por marco regulatorio reduce trabajo y inconsistencias.
Cómo puede ayudar PrivaLex
Implantar un marco de gestión de riesgos desde cero, o rescatar uno que existe pero no aguanta auditoría, es uno de los proyectos donde la metodología importa más que el software. PrivaLex trabaja con organizaciones que necesitan un marco operativo, no un documento de consultoría que nadie usa después de la entrega.
Diagnóstico del marco actual. Revisamos política, metodología, registro, SoA y evidencias de revisión. Identificamos huecos frente a ISO 27001 cláusula 6.1.2, ISO 27005 y, cuando aplica, artículo 21 de NIS2. El output es una lista priorizada de correcciones con estimación de esfuerzo, no un informe genérico de madurez.
Diseño de metodología y plantillas. Definimos escalas, criterios de aceptación, plantillas de registro y flujo de aprobación de tratamientos adaptados al tamaño y sector de la organización. Si ya existe un Excel o una herramienta GRC, adaptamos el marco a lo que hay en lugar de imponer un formato nuevo sin transición.
Construcción del primer ciclo completo. Acompañamos la primera identificación y evaluación de riesgos con el equipo interno, formamos a propietarios de riesgo en su rol y dejamos el registro en estado auditable. Incluye alineación del SoA y priorización de controles del Anexo A.
Preparación para auditoría o supervisión. Simulamos la pregunta del auditor sobre el ciclo de gestión de riesgos: contexto, muestra de riesgos tratados, evidencia de revisión tras incidentes, aceptación de riesgo residual por dirección. Ajustamos documentación antes de que llegue el auditor externo o la autoridad supervisora.
Trabajamos con empresas en primera certificación ISO 27001, entidades que deben demostrar gestión de riesgos bajo NIS2, y proveedores que necesitan un registro coherente para due diligence de clientes enterprise en sectores regulados.
Conclusión
Un marco de gestión de riesgos no es un documento de metodología archivado: es el ciclo que conecta lo que puede fallar en la organización con lo que la organización decide hacer para controlarlo. ISO 27005 ofrece el proceso; ISO 27001 exige que ese proceso produzca evidencias; NIS2 y el mercado B2B exigen que el resultado sea creíble ante terceros. Elegir el marco correcto, implantar las seis fases con propietarios y revisiones reales, y evitar los errores que vacían el registro de significado, es lo que separa una gestión de riesgos decorativa de una que sostiene certificaciones, contratos y supervisión regulatoria.
Si quieres saber si tu marco actual aguantaría una auditoría ISO 27001 o una revisión NIS2, solicita tu risk assessment gratuito o reserva una sesión con nuestro equipo.
Preguntas Frecuentes
No. ISO 27001 define los requisitos del sistema de gestión de seguridad de la información (SGSI) y es certificable. ISO 27005 es una guía que describe cómo realizar la gestión de riesgos de seguridad de la información, que ISO 27001 exige en su cláusula 6.1.2 pero no detalla. En la práctica, casi todas las organizaciones certificadas en ISO 27001 usan ISO 27005 (o una metodología equivalente documentada) para construir su evaluación de riesgos y el Statement of Applicability.
Cuando la organización opera en el sector público estadounidense, presta servicios a agencias federales estadounidenses, o sus clientes exigen explícitamente alineación con NIST SP 800-53 o el Cybersecurity Framework. Para cumplimiento ante autoridades europeas o certificación ISO 27001 en la UE, NIST RMF no sustituye ISO 27005: puede complementar el mapa de controles, pero el auditor europeo esperará metodología y registro alineados con ISO 27001/27005.
ISO 27001 exige revisión ante cambios significativos y revisión periódica planificada; la frecuencia la define la organización según su contexto (semestral o anual es habitual en empresas medianas). Además del calendario, el registro debe actualizarse cuando ocurre un incidente significativo, se despliega un sistema nuevo, cambia un proveedor crítico, entra en vigor una normativa relevante o un pentest revela vulnerabilidades materialmente nuevas. NIS2 y entidades supervisadas suelen requerir ciclos más cortos y reporting a dirección documentado.
El riesgo inherente es el nivel antes de aplicar controles. El riesgo residual es el que queda después del tratamiento y operación de controles. El apetito de riesgo es el umbral que dirección aprueba como aceptable para la organización; los criterios de aceptación concretos por tipo de riesgo derivan de ese apetito. Un marco coherente documenta los tres: inherente en el análisis, residual tras tratamiento con aceptación formal del propietario del riesgo, y criterios de aceptación vinculados al apetito definido por dirección.
No es obligatorio. Muchas organizaciones medianas mantienen un registro válido en hojas de cálculo controladas con versionado y aprobaciones documentadas. El software GRC aporta valor cuando el número de riesgos, controles y marcos regulatorios hace insostenible el mantenimiento manual, o cuando se necesita integración continua con herramientas de TI para monitorización. Lo que el auditor verifica es metodología, propietarios, decisiones y revisiones, no la marca del software.
Cubre la parte de análisis y tratamiento de riesgos de ciberseguridad, que es central en NIS2, pero no todo el artículo 21. NIS2 añade obligaciones específicas de notificación de incidentes a CSIRT, gestión de cadena de suministro, formación de dirección y cooperación con autoridades. El marco de riesgos debe referenciar esos requisitos en el contexto y en planes de tratamiento; un registro ISO 27005 bien hecho es la base, no el programa NIS2 completo.