Cómo crear un programa de métricas de seguridad (paso a paso)

La mayoría de los programas de métricas de seguridad fracasan de la misma forma: alguien exporta todos los números que produce una herramienta, los pone en un panel y, seis meses después, nadie lo mira porque ninguno de esos números cambió nunca una decisión. Un programa que funciona se construye en la dirección contraria, de las decisiones hacia los datos, y se construye en un orden deliberado. Estos son los siete pasos, más cómo incorporar las métricas de la era de la IA que necesita un programa en 2026.

Paso 1: vincula las métricas a decisiones y objetivos

Empieza por las decisiones, no por los datos. Anota las decisiones que toman de verdad tu dirección y tu equipo de seguridad: qué financiar el próximo trimestre, qué riesgos aceptar formalmente, dónde añadir plantilla, cuándo escalar, qué contar al consejo. Después trabaja hacia atrás: para cada decisión, ¿qué uno o dos números la informarían de verdad? Esa es tu lista de candidatas. Todo lo que no alimente una decisión no entra en el programa, por fácil que sea de medir. Esta sola disciplina evita la mayor parte de la proliferación de paneles antes de que empiece.

Paso 2: elige un conjunto pequeño por audiencia

No estás construyendo una lista; estás construyendo tres vistas de un mismo programa para tres audiencias:

• Consejo: unos pocos indicadores de riesgo y tendencia en términos de negocio: postura, tendencia, principales riesgos y su coste aproximado, cobertura de los controles críticos y avance de la hoja de ruta.
• CISO / dirección de seguridad: los KPI de salud del programa en todo el conjunto.
• SOC: números operativos: MTTD, MTTR, volumen de alertas, tasa de falsos positivos y cobertura de detección.

Mantén cada vista corta. Unos pocos números fiables sobre los que la gente actúa valen más que un muro de gráficos que nadie lee. Si no tienes claro qué métricas pertenecen al conjunto principal, nuestra guía complementaria sobre buenas métricas de seguridad en la era de la IA repasa el conjunto principal clásico y las incorporaciones de la IA.

Paso 3: define cada métrica con precisión

Es el paso que los equipos se saltan, y el que te ahorra la discusión de «tres presentaciones, tres números». Da a cada métrica una definición de una página con cinco partes:

• Fórmula / definición: qué se cuenta exactamente, en qué periodo, con inclusiones y exclusiones explícitas.
• Fuente: el sistema del que salen los datos.
• Responsable: la persona o el equipo con nombre que responde del número y de moverlo.
• Cadencia: con qué frecuencia se mide y se informa.
• Objetivo: cómo es un buen resultado, y el razonamiento que lo respalda.

La ambigüedad es como una métrica se convierte en silencio en varias. Si tres equipos cuentan los «incidentes» cada uno a su manera, tendrás tres recuentos de incidentes y una reunión sobre cuál es el bueno. Una definición escrita acaba con eso.

Paso 4: primero la línea base, después los objetivos

No fijes un objetivo antes de saber dónde estás. Mide la métrica tal como está hoy: esa es tu línea base. Después decide dónde dice tu tolerancia al riesgo que tiene que estar y fija un objetivo que cierre la brecha en un plazo realista. Resiste la tentación de importar una «media del sector» de la diapositiva de un proveedor: esas cifras rara vez son comparables con tu alcance, tus definiciones y tu madurez, y perseguirlas te lleva hacia un número desconectado de tu riesgo real. Cuando el consejo pregunte «¿y cuánto nos cuesta este riesgo?», un método de cuantificación como FAIR ayuda a traducir un riesgo a un rango en dólares; para los objetivos de cobertura de controles, apóyate en un marco como NIST CSF o ISO 27001. Vuelve a medir la línea base periódicamente para que los objetivos sigan siendo honestos a medida que madura el programa.

Paso 5: automatiza la recogida

Una métrica que depende de que alguien rellene a mano una hoja de cálculo una vez por trimestre llegará tarde, será incoherente y acabará abandonada. Conecta cada métrica a su sistema de origen para que el número se produzca siempre de la misma forma, con su cadencia, sin heroicidades. La automatización también hace honesta la definición: si no puedes automatizar la recogida, suele ser señal de que la definición es demasiado difusa para calcularla de forma fiable. Empieza por las métricas cuyos datos ya están en un sistema que se puede consultar (tu escáner de vulnerabilidades, la consola de EDR, el proveedor de identidad, el sistema de tickets) y amplía a partir de ahí.

Paso 6: informa de forma distinta al consejo y al SOC

Los mismos datos, a tres alturas. El consejo recibe riesgo y tendencia vinculados al dinero y a las decisiones que le pides que tome, no una consola de SOC. La vista del CISO incluye los KPI de salud del programa que conectan el relato del consejo con la realidad sobre el terreno. El SOC recibe el detalle operativo que impulsa el ajuste y la dotación diarios. El error recurrente es entregar al consejo un panel hecho para analistas, o pedir a los analistas que actúen sobre una línea de tendencia de nivel de consejo. Construye las agregaciones una vez, de forma deliberada, para que los mismos números de base digan a cada una de las tres audiencias lo que necesita.

Paso 7: revisa con una cadencia fija y retira las métricas de vanidad

Un programa de métricas que solo crece se convierte en ruido. Pon una revisión periódica en el calendario y, en cada una, pregunta de cada métrica: ¿sigue impulsando una decisión, sigue teniendo responsable, sigue siendo difícil de manipular? Retira las que se hayan quedado obsoletas con la misma deliberación con la que las añadiste. Vigila en especial las métricas de vanidad (números que suben de forma tranquilizadora, como alertas gestionadas o formaciones impartidas, pero que no cambian nada) y las métricas que han perdido en silencio a su responsable. Podar no es señal de que el programa haya fracasado; es señal de que alguien lo gestiona.

Añadir métricas de IA al programa

Una vez que la disciplina anterior esté implantada, extiéndela a la capa de IA, definiendo cada métrica de IA de la misma forma (fórmula, fuente, responsable, cadencia, objetivo) en lugar de añadirlas a posteriori. Empieza por la que condiciona todas las demás:

• Cobertura del inventario de IA y de modelos: no puedes medir ni defender una IA que no ves, así que la cobertura va primero.
• Detecciones de IA en la sombra: un indicador de riesgo de la adopción de herramientas sin gobierno.
• Tasa de superación de las pruebas de inyección de prompts: de las aplicaciones expuestas a IA, cuántas superan un conjunto de pruebas de inyección de prompts.
• Cobertura de AIBOM y de procedencia de los modelos: si puedes producir una lista de materiales de tus componentes de IA.
• Tasa de cierre de los hallazgos del red team de IA y nivel de autonomía de los agentes: los hallazgos adversarios y cuánto hacen tus agentes sin un humano en el bucle.
• Incidentes de fuga de datos por IA: datos sensibles expuestos a través de una herramienta o integración de IA.

Para la mayoría de ellas, el primer objetivo honesto es «medirla, sin más», después «alcanzar un X % de cobertura» y después afinar. Mide la línea base de cada una; no importes un objetivo de otra parte.

Empieza aquí

No tienes que construir el catálogo de métricas desde una página en blanco. Explora la biblioteca completa de métricas y construye una puntuación de riesgo ponderada: selecciona las métricas que encajan con cada audiencia, defínelas y mide su línea base, fija tus propios objetivos y pondéralas en una única puntuación de postura que puedas seguir en el tiempo. A partir de ahí, estas herramientas apoyan los pasos anteriores (la evaluación de madurez del SOC es gratuita; el NIST CSF Toolkit es una herramienta Pro que puedes probar gratis: una cuenta gratuita incluye 3 usos de herramientas Pro):

• Evaluación de madurez del SOC: mide la línea base de tu operación de detección y respuesta antes de fijar objetivos operativos.
• NIST CSF Toolkit: ancla tus métricas de cobertura de controles a un marco reconocido.
• Todas las herramientas de PlayCISO: escáneres, cuadros de mando y generadores para todo el programa.

Este artículo es una orientación educativa y neutral respecto a los proveedores para responsables de seguridad, no una auditoría, una certificación ni asesoramiento legal. Los nombres de marcos (NIST CSF, ISO 27001, FAIR) se citan solo como orientación; fija tus propios objetivos según tu propia tolerancia al riesgo.