KPIs de seguridad para el directorio sí entiende

Tres KPIs que transforman la conversación entre TI y el directorio.

Existe una escena que conozco bien. El equipo de TI entra a la sala directiva con su informe mensual, diapositivas llenas de números, gráficos de barras, conteo de eventos, y al final de la presentación, el directorio hace preguntas sobre presupuesto, no sobre riesgos. No porque no les importe la seguridad. Sino porque nadie les habló en su idioma.

En entornos con infraestructura Fortinet y Cisco operando 24/7, los datos de seguridad nunca faltan. Lo que escasea es la traducción: la capacidad de convertir un log de FortiGate o una alerta de IPS en algo que un gerente general pueda leer y usar para tomar decisiones. Esa brecha no es técnica. Es comunicacional.

Hay tres indicadores que, bien presentados, cambian el nivel de la conversación. No simplifican la realidad, la enfocan hacia donde importa.

---

1. MTTR: el tiempo que el directorio sí entiende

Mean Time to Resolve — Tiempo Medio de Resolución

El MTTR mide cuánto tarda el equipo de TI en resolver un incidente desde que es detectado. No cuántos ocurrieron, cuánto tiempo estuvo el problema activo. Y ahí está la clave: el tiempo tiene un costo que cualquier directivo entiende.

Un MTTR de 4 horas en un activo crítico (un servidor ERP, un firewall perimetral FortiGate, un switch de core Cisco) no es un número técnico. Es tiempo de operación interrumpida o en riesgo, posibles cláusulas contractuales activadas y exposición regulatoria bajo marcos como ISO 27001 o la normativa local de datos. Cuando el MTTR sube de un mes a otro, hay algo que justifica atención e inversión.

Cómo presentarlo: Mostrar el MTTR promedio del mes, segmentado por tipo de activo (crítico vs. estándar), con tendencia de los últimos 3 meses. Si el MTTR en activos críticos supera las 4 horas, encenderlo en rojo en el dashboard. Eso genera preguntas. Las preguntas generan conversación. La conversación genera presupuesto.

2. Cobertura de parches: no como porcentaje, sino como exposición

Decir "tenemos 73% de cobertura de parches" suena bien. Pero si lo reformulas así: "el 27% de nuestra infraestructura crítica tiene vulnerabilidades conocidas sin parchear", la conversación cambia completamente.

En entornos mixtos (pfSense/OPNsense gestionando segmentación de red, Ubiquiti en capas de acceso, Fortinet en el perímetro) la cobertura de parches rara vez es homogénea. Cada fabricante tiene su propio ciclo de actualizaciones, y cuando hay hardware EOL en la ecuación, el gap se amplía. Eso es exactamente lo que el directorio necesita saber, expresado en riesgo de negocio, no en versiones de firmware.

Cómo presentarlo: Segmentar la cobertura entre sistemas críticos (ERP, bases de datos, infraestructura de red) y sistemas estándar (equipos de usuario). El 27% sin parchear en servidores críticos no es lo mismo que el 27% en estaciones de trabajo. La segmentación convierte el dato en decisión.

3. Incidentes por activo crítico: dónde está el riesgo real

Presentar "tuvimos 19 incidentes este mes" no dice nada útil. Presentar "2 de esos incidentes afectaron el servidor ERP y 1 involucró el firewall perimetral" —eso sí dice algo.

El volumen total de incidentes tiende a ser ruidoso. Los ataques de fuerza bruta contra el firewall, las alertas de antivirus en endpoints, los escaneos de red automatizados —todo eso genera eventos que técnicamente son "incidentes" pero que operacionalmente no tienen el mismo peso que un intento de acceso no autorizado al sistema financiero. Separar el ruido de la señal es una de las funciones más importantes del IT Manager como comunicador ejecutivo.

Cómo presentarlo: Clasificar activos en tres niveles (crítico, importante, estándar) y reportar incidentes por nivel. Agregar el indicador de tendencia: ¿el número de incidentes en activos críticos subió, bajó o se mantuvo respecto al mes anterior? Una tendencia al alza en activos críticos —aunque sean solo 2 o 3 eventos— es exactamente el tipo de señal que debe llegar a nivel directivo.

---

El dashboard que cambia la conversación

Juntar estos tres indicadores en una sola vista ejecutiva —una página, sin tecnicismos, con colores de estado y tendencia de tres meses— es lo que separa al IT Manager que pide presupuesto del que justifica inversión. La diferencia no está en los datos. Está en cómo se organizan y para quién se construyen.

En entornos que siguen NIST CSF 2.0, estos KPIs encajan directamente en la función IDENTIFY (gestión de activos y evaluación de riesgo) y en la función RESPOND (análisis de incidentes, mitigación). No son métricas aisladas. Son parte de una narrativa de madurez en ciberseguridad que el directorio puede seguir en el tiempo.

La ciberseguridad no necesita más tecnicismo hacia arriba en la organización. Necesita más claridad. Y la claridad empieza por elegir bien qué se mide y cómo se comunica.

¿Te fue útil este análisis?

Suscríbete al newsletter Cybersecurity Insights en LinkedIn y recibe cada semana contenido orientado a profesionales de TI que trabajan con enfoque directivo. Sin spam. Solo análisis que puedes aplicar.

#Ciberseguridad #KPIs #MTTR #GestiónDeRiesgos #CIO #ITManager #Fortinet #Cisco #pfSense #ISO27001 #NISTCSF #InfraestructuraCrítica #CyberLeadership #TI #Chile