Gestión de riesgos en ciberseguridad: entre el absurdo y el cumplimiento vacío
Matrices de 5.000 líneas o de un solo riesgo. Después de 18 años, estas son las claves para hacer gestión de riesgos real: escenarios de negocio, agrupación inteligente y dueños que no sean TI.
Dos extremos del mismo problema
Me ha tocado revisar matrices de riesgo con 5.000 líneas llenas de entradas repetidas. También he visto el otro extremo: una matriz con un solo riesgo para toda una organización.
Ambos casos reflejan el mismo problema — no se entiende el propósito real del ejercicio.
Después de 18 años trabajando en esto, comparto lo que considero las claves para hacerlo bien.
Un riesgo NO es una vulnerabilidad
El error más común es volcar el reporte de un scanner en la matriz y llamarlo “gestión de riesgos”.
Un riesgo es un escenario de negocio: qué amenaza podría materializarse, sobre qué activo o proceso crítico, y qué consecuencia tendría para la organización.
Si tu matriz tiene más de 120 riesgos, probablemente estás mezclando niveles.
Ciberseguridad no es el negocio
Por mucho que nos apasione, la ciberseguridad es un habilitador, no el fin.
La organización tiene riesgos:
- Operacionales
- Financieros
- Regulatorios
- Reputacionales
- De continuidad
- De mercado
- Ambientales
- Laborales
Los riesgos de ciberseguridad son un subconjunto que debe integrarse al mapa de riesgos corporativo, no vivir en una isla.
El rango óptimo existe
Para una organización mediana-grande, una matriz bien construida suele tener entre 25 y 80 riesgos.
Esto no es un número mágico, sino el resultado de agrupar escenarios por procesos de negocio y no por cada puerto abierto o hallazgo técnico.
| Tamaño de matriz | Diagnóstico |
|---|---|
| 1-10 riesgos | Subestimación grave o ejercicio cosmético |
| 25-80 riesgos | Rango saludable para organización mediana-grande |
| 80-120 riesgos | Aceptable si hay diversidad real de escenarios |
| 120+ riesgos | Probablemente mezclando vulnerabilidades con riesgos |
| 1.000+ riesgos | El scanner habla, nadie escucha |
La fórmula de un riesgo bien escrito
Amenaza + Activo/Proceso expuesto + Impacto al negocio.
Así NO se escribe un riesgo:
“Falta parche en servidor X”
Eso es un hallazgo técnico. No es un riesgo.
Así SÍ se escribe un riesgo:
“Explotación de vulnerabilidad conocida en sistema SCADA de planta, causando interrupción operacional con pérdida estimada de $X por hora de downtime”
La diferencia es clara: el segundo habla el idioma del negocio. El primero solo le dice algo a TI.
Agrupa, no acumules
Las 200 vulnerabilidades críticas de tu infraestructura OT pueden ser 5 escenarios de riesgo.
Las 15 observaciones de la auditoría de accesos son probablemente 2 riesgos.
La clave es elevar la abstracción al lenguaje que entiende quien toma las decisiones.
Ejemplo de agrupación
| Hallazgos técnicos | Escenario de riesgo |
|---|---|
| 47 servidores sin parches críticos, 12 con servicios expuestos, 8 con credenciales por defecto | Compromiso masivo de infraestructura por explotación de vulnerabilidades conocidas, con impacto en continuidad operacional |
| Cuentas compartidas en SCADA, sin MFA en VPN industrial, acceso remoto sin segmentar | Acceso no autorizado a red OT por debilidades en gestión de identidades, con riesgo de manipulación de procesos industriales |
De 67 hallazgos técnicos a 2 escenarios de riesgo que un directorio puede entender y decidir.
El dueño del riesgo no es el área de TI
Si todos los riesgos tienen como responsable al CISO o al jefe de infraestructura, la matriz ya fracasó.
El dueño del riesgo es quien sufre la consecuencia:
- El gerente de operaciones
- El CFO
- El gerente de planta
- El gerente comercial
Ciberseguridad asesora y gestiona controles, pero el riesgo lo asume el negocio.
Cuando el dueño del riesgo es negocio:
- Las decisiones de inversión tienen respaldo
- La aceptación de riesgo es informada y firmada
- Los planes de tratamiento tienen presupuesto real
Cuando el dueño del riesgo es TI:
- Nadie más se siente responsable
- El presupuesto nunca llega
- Ante un incidente, todos miran al CISO
Revisión viva, no documento muerto
Una matriz que se actualiza una vez al año para la auditoría no gestiona nada.
El ciclo mínimo razonable es trimestral, con gatillos de revisión ante:
- Incidentes de seguridad
- Cambios regulatorios
- Transformaciones tecnológicas relevantes
- Cambios en la estructura organizacional
- Nuevos servicios o procesos de negocio
El puente entre técnica y negocio
La diferencia entre cumplir y gestionar es enorme.
La matriz de riesgos no es un entregable para el auditor — es el puente entre la realidad técnica y las decisiones de negocio.
Y ese puente debe hablar el idioma del negocio, no el nuestro.
¿Cuántos riesgos tiene tu matriz? Si la respuesta es 1 o 5.000, tenemos que conversar.