En muchas empresas, la gestión del riesgo ciber nace con una pregunta aparentemente sencilla y es que ¿debemos adoptar una única metodología para toda la organización o permitir que coexistan varias? Lo cierto es que la respuesta no debería reducirse a una elección rígida entre orden y flexibilidad, pues en ciberseguridad, donde conviven riesgos técnicos, regulatorios, operativos, financieros y reputacionales, lo más eficaz suele ser un modelo híbrido, es decir, una metodología común de gobierno y lenguaje, complementada por metodologías especializadas conectadas entre sí.
El atractivo de una única metodología
Tener una sola metodología de riesgos ciber tiene ventajas evidentes, pues facilita la comparación entre áreas, evita duplicidades, estandariza el reporting y permite que la alta dirección reciba una visión homogénea del riesgo.
Además, una metodología única puede reducir la confusión pues cuando cada equipo utiliza escalas distintas, criterios diferentes o vocabulario propio, el resultado suele ser una torre de Babel del riesgo en el sentido de que lo que para un área es “alto”, para otra puede ser “crítico”, lo que para tecnología es una vulnerabilidad urgente, para negocio puede no tener prioridad si no se traduce en impacto operativo o económico.
Por eso, toda empresa necesita una columna vertebral metodológica, lo que se traduce en una forma común de clasificar activos, valorar impactos, definir apetito de riesgo, registrar riesgos, asignar propietarios y reportar al comité de dirección, pues sin esa base común, la gestión del riesgo se fragmenta y pierde capacidad de decisión.
El límite de la metodología única
Sin embargo, el riesgo ciber no es un fenómeno único ni uniforme, pues no se analiza igual el riesgo de una aplicación en desarrollo que el riesgo de un proveedor crítico, una exposición en cloud, una vulnerabilidad explotada activamente, un incidente de ransomware, un modelo de inteligencia artificial o una planta industrial conectada.
Pretender que una sola metodología sirva con la misma precisión para todos estos casos puede generar una falsa sensación de control y las metodologías demasiado generales suelen ser útiles para reportar, pero insuficientes para decidir, porque pueden decir que un riesgo es “alto”, pero no siempre explican por qué, qué ruta de ataque lo hace probable, qué controles fallan, cuánto dinero puede costar o qué debe corregirse primero y, aquí es cuando aparece el valor de permitir la coexistencia de varias metodologías.
Cómo montar un modelo de coexistencia metodológica que aporte valor
La coexistencia de varias metodologías de riesgos ciber no debe entenderse como una acumulación de marcos, herramientas y criterios independientes y su valor aparece cuando se diseña como un ecosistema metodológico conectado, donde cada enfoque cumple una función específica y todos alimentan una visión común del riesgo, por lo que la pregunta clave no es cuántas metodologías puede usar una empresa, sino qué problema resuelve cada una, cómo se relacionan entre sí y cómo sus resultados ayudan a tomar mejores decisiones.
Una organización madura debería evitar dos extremos, pues si el modelo es excesivamente centralizado, los resultados serán demasiado generalistas, mientras que si nos vamos a uno fragmentado, donde cada área usa sus propios criterios, perdemos coherencia, trazabilidad y capacidad de priorización.
La alternativa más sólida es un modelo de coexistencia gobernada en el que haya varias metodologías especializadas, pero conectadas por principios comunes, datos compartidos y mecanismos claros de traducción hacia el lenguaje de negocio.
La lógica del modelo es una arquitectura por capas
Para que varias metodologías convivan de forma ordenada, conviene estructurarlas por capas en donde cada una tiene un propósito distinto y evita que todas las metodologías compitan por ocupar el mismo espacio.
1. Capa de gobierno: el marco común
Esta es la capa que da coherencia al conjunto, por lo que no tiene que ser la metodología más detallada, pero sí debe ser la referencia común para toda la empresa.
Aquí se definen:
- La taxonomía de riesgos.
- Las escalas de impacto (1 a 5, por ejemplo)
- Los criterios de probabilidad o exposición.
- El apetito de riesgo.
- Los roles y responsabilidades;
- Los criterios de aceptación, mitigación, transferencia o escalado;
- El modelo de reporting a dirección.
EPor ejemplo, un equipo técnico puede evaluar una vulnerabilidad con criterios propios, pero el resultado debe poder traducirse a las categorías corporativas: impacto en disponibilidad, impacto económico, afectación regulatoria, criticidad del proceso, responsable del riesgo y decisión esperada.
Es decir, la capa de gobierno responde a la pregunta: ¿cómo entiende la empresa el riesgo ciber y cómo decide sobre él?
2. Capa de análisis especializado: profundidad donde hace falta
La segunda capa está formada por metodologías concretas para dominios específicos y aquí es donde la coexistencia aporta verdadero valor, porque no todos los riesgos se pueden analizar con la misma lente.
Por ejemplo, para riesgos con impacto económico, metodologías como FAIR o el análisis de escenarios ayudan a traducir el riesgo a pérdidas probables y a justificar inversiones. Para vulnerabilidades, conviene combinar severidad técnica, explotación activa, exposición del activo y criticidad del servicio, evitando priorizar solo por CVSS. Para amenazas reales, MITRE ATT&CK permite conectar el riesgo con técnicas usadas por atacantes y revisar si existen controles de prevención, detección y respuesta.
Esta capa responde a la pregunta, ¿Qué método proporciona la mejor lectura del riesgo en este contexto concreto?
3. Capa de conexión: el verdadero punto de madurez
La coexistencia solo funciona si existe una capa intermedia que conecte los resultados y lo cierto es que esta capa suele ser la más débil en muchas organizaciones, pero es precisamente la que convierte metodologías aisladas en un sistema de gestión del riesgo.
Su función es traducir hallazgos técnicos, escenarios, vulnerabilidades, controles y amenazas en una visión integrada de riesgo.
Por ejemplo:
Una vulnerabilidad crítica no debería quedarse solo como “CVSS 9.8” debe conectarse con el activo afectado, el proceso de negocio soportado, la exposición a internet…
Del mismo modo, una brecha de detección identificada con MITRE ATT&CK no debería quedarse como una carencia técnica del SOC, por lo que debe traducirse a una pregunta de riesgo: ¿Qué escenario de ataque relevante para la empresa no seríamos capaces de detectar a tiempo?
Y un hallazgo en un proveedor no debería quedarse como una mala puntuación en un cuestionario, sino ¿Qué proceso crítico depende de ese proveedor y qué pasaría si sufre una interrupción, fuga de datos o compromiso?
Esta capa de conexión necesita varios elementos.
Taxonomía común
Todas las metodologías deben mapearse contra un vocabulario compartido, lo que no implica que todas usen las mismas métricas, sino de que sus resultados puedan converger en categorías comunes (me lo invento, fraude, continuidad, reputación…)
Inventario relacional de activos
El inventario no debe limitarse a servidores, aplicaciones o dispositivos, sino que debe relacionar activos técnicos con servicios, procesos, datos, identidades, terceros y responsables de negocio.
Sin esa relación, el análisis de riesgo queda atrapado en el plano técnico, mientras que con ella la empresa puede saber qué vulnerabilidad afecta a qué servicio, qué servicio soporta qué proceso, qué proceso impacta a qué unidad de negocio y qué riesgo merece prioridad.
Criterios de traducción
La organización debe definir cómo se convierte un resultado especializado en un nivel de riesgo corporativo (similar a los playbooks). Por ejemplo:
- Una vulnerabilidad con explotación activa en un activo expuesto y crítico puede escalar automáticamente.
- Una brecha de control en un sistema que soporta un proceso regulado puede requerir aceptación formal.
Estos criterios evitan que el riesgo dependa únicamente del juicio subjetivo de cada equipo.
Registro federado de riesgos
No siempre es necesario que todo viva en una única herramienta, pero sí debe existir una trazabilidad común, pues un hallazgo técnico relevante debe poder seguirse hasta su riesgo asociado, su plan de tratamiento, su responsable, su fecha objetivo y su estado.
El modelo puede ser federado porque los equipos trabajan en sus herramientas especializadas, pero los riesgos relevantes se consolidan en una vista corporativa y así se mantiene la profundidad operativa sin perder visión ejecutiva.
4. Capa de decisión
El objetivo de coexistir no es producir más informes, sino tomar mejores decisiones y por eso, el modelo debe definir qué tipo de decisión habilita cada metodología, por ejemplo, la cuantificación económica ayuda a priorizar inversiones, la gestión de vulnerabilidades permite decidir qué corregir primero y MITRE ATT&CK y la validación de controles ayudan a reforzar prevención, detección y respuesta.
Esta es una diferencia fundamental entre una empresa que “evalúa riesgos” y una empresa que gestiona riesgos, pues evaluar es clasificar, mientras que gestionar es decidir, financiar, corregir, aceptar o transformar.
5. Capa de validación continua
Una coexistencia metodológica madura no puede basarse solo en análisis declarativos, sino que debe incorporar validación continua, lo que significa comprobar si las hipótesis de riesgo son ciertas:
- ¿La vulnerabilidad es realmente explotable?
- ¿El plan de continuidad funciona en una crisis realista?
- ¿La mitigación redujo el riesgo o solo cerró una tarea?
Aquí entran prácticas como purple teaming, breach and attack simulation, ejercicios de crisis, pruebas de recuperación, validación de controles, revisión de configuraciones cloud, simulaciones de ransomware y pruebas de respuesta a incidentes.
La validación continua evita que el modelo de riesgo se convierta en una fotografía estática y el riesgo ciber cambia con cada nuevo activo, cada nueva vulnerabilidad, cada cambio en los atacantes, cada integración con terceros y cada transformación del negocio.
Principios para que la coexistencia no se convierta en caos
Para que este modelo funcione, la empresa debería aplicar algunos principios de diseño:
Cada metodología debe tener dueño. Es decir, debe existir claridad sobre quién la mantiene, quién la aplica, quién interpreta sus resultados y quién decide cuándo se actualiza.
Cada metodología debe tener un propósito, pues no se incorporan metodologías por moda, sino porque mejoran una decisión concreta.
Cada resultado debe ser traducible, ya que el análisis técnico debe poder convertirse en lenguaje de negocio; un riesgo de negocio debe poder descomponerse en causas técnicas.
Debe existir una fuente común de activos críticos, pues sin activos y procesos conectados, las metodologías trabajan sobre realidades distintas.
El reporting debe estar integrado, ya que la dirección no necesita ver todas las métricas técnicas, pero sí necesita entender exposición, tendencia, impacto, decisiones pendientes y riesgos fuera de apetito.
El modelo debe ser proporcional, pues no todos los riesgos requieren análisis cuantitativo avanzado, threat modeling profundo o simulaciones complejas. La intensidad metodológica debe depender de la criticidad del activo, la exposición, la incertidumbre y el impacto potencial.
En conclusión, en ciberseguridad la madurez no consiste en tener una metodología perfecta, sino en lograr que distintas formas de analizar el riesgo conversen entre sí y ayuden a tomar mejores decisiones, pues una empresa no necesita uniformidad absoluta, sino coherencia, trazabilidad y capacidad de decisión.