Metricas de Compliance: KPIs para Medir el Cumplimiento Normativo

Por que medir el compliance

Cumplir con ENS, NIS2, ISO 27001 o DORA no es un evento puntual. Es un proceso continuo que requiere evidencias, trazabilidad y capacidad de demostrar ante auditores, reguladores y dirección que los controles funcionan. Sin metricas, el cumplimiento normativo se convierte en una declaracion de intenciones: "creemos que cumplimos" en lugar de "demostramos que cumplimos".

Las metricas de compliance cumplen cuatro funciones fundamentales. Primera, proporcionan visibilidad objetiva del estado real de cumplimiento frente a cada marco normativo. Segunda, permiten detectar degradaciones antes de que se conviertan en incumplimientos. Tercera, justifican inversiones en seguridad con datos cuantificables. Cuarta, alimentan el ciclo de mejora continua que exigen todas las normas modernas.

El problema habitual es que muchas organizaciones miden lo que pueden, no lo que importa. Contadores de eventos sin contexto, porcentajes que nadie revisa, dashboards decorativos que no influyen en decisiones. Una buena estrategia de metricas empieza por definir que preguntas necesita responder la organización y, a partir de ahi, seleccionar los indicadores que las responden.

Categorías de metricas de compliance

Las metricas de cumplimiento normativo se organizan en cuatro grandes categorías, cada una orientada a responder preguntas distintas.

Efectividad de controles

Miden si los controles de seguridad implementados funcionan como se espera. No basta con tener un firewall: hay que demostrar que bloquea lo que debe bloquear, que sus reglas están actualizadas y que no tiene bypasses conocidos.

Ejemplos: porcentaje de controles operativos sobre controles requeridos, tasa de falsos positivos en detección, tiempo medio de detección (MTTD), efectividad de las reglas de correlación del SIEM.

Postura de riesgo

Evaluan el nivel de exposicion de la organización en un momento dado. Son metricas dinamicas que cambian con cada vulnerabilidad descubierta, cada activo nuevo y cada amenaza emergente.

Ejemplos: número de vulnerabilidades criticas sin parchear, superficie de ataque expuesta, porcentaje de activos sin inventariar, riesgo residual por dominio.

Preparacion para auditoria

Indican la capacidad de la organización para superar una auditoria o inspeccion regulatoria sin hallazgos criticos. Son especialmente relevantes en marcos como ENS Alto, donde las auditorias bienales son obligatorias.

Ejemplos: porcentaje de evidencias generadas automaticamente, antiguedad media de las evidencias, número de hallazgos abiertos de auditorias anteriores, tiempo medio de cierre de no conformidades.

Cobertura regulatoria

Miden el grado de alineamiento con cada marco normativo aplicable. En organizaciones sujetas a multiples regulaciones (ENS + NIS2 + DORA + ISO 27001), esta categoría permite identificar solapamientos y gaps cruzados.

Ejemplos: porcentaje de requisitos cubiertos por marco, controles compartidos entre marcos, requisitos sin propietario asignado, regulaciones nuevas pendientes de evaluar.

Top 15 metricas de compliance

La siguiente tabla recoge las 15 metricas más relevantes para un programa de compliance en ciberseguridad, con formula de calculo, objetivo recomendado y frecuencia de medicion.

#	Metrica	Formula	Objetivo	Frecuencia
1	Cobertura de controles	Controles conformes / Controles aplicables x 100	>= 90%	Mensual
2	Tasa de parcheado critico	Parches criticos aplicados en SLA / Total parches criticos x 100	>= 95% en 72h	Semanal
3	MTTD (Mean Time to Detect)	Suma tiempos detección / Número incidentes	< 4 horas	Mensual
4	MTTR (Mean Time to Respond)	Suma tiempos respuesta / Número incidentes	< 24 horas	Mensual
5	Vulnerabilidades criticas abiertas	Count(vulns CVSS >= 9.0 AND estado = abierta)	0 > 30 dias	Semanal
6	Cobertura de activos inventariados	Activos en CMDB / Activos detectados en red x 100	>= 98%	Mensual
7	Tasa de completion formación	Empleados formados en plazo / Total empleados requeridos x 100	>= 95%	Trimestral
8	Hallazgos de auditoria abiertos	Count(hallazgos estado != cerrado)	0 criticos	Mensual
9	Antiguedad media de evidencias	AVG(fecha_actual - fecha_evidencia) en dias	< 90 dias	Mensual
10	Índice de riesgo residual	SUM(riesgo_inherente - efecto_controles) / Num dominios	< umbral apetito	Trimestral
11	Cobertura de logs	Activos con logging activo / Total activos criticos x 100	>= 99%	Semanal
12	Incidentes notificados en plazo	Notificaciones dentro de SLA regulatorio / Total notificables x 100	100%	Por evento
13	Controles automatizados	Controles con verificación automática / Total controles x 100	>= 60%	Trimestral
14	Tasa de excepciones activas	Excepciones vigentes / Total controles x 100	< 5%	Mensual
15	Cobertura multi-marco	Requisitos cubiertos union marcos / Total requisitos union x 100	>= 85%	Trimestral

Cada metrica debe tener un propietario (persona o equipo responsable de su medicion y seguimiento), un umbral de alerta (cuando pasa de verde a ambar o rojo) y un canal de escalado (que ocurre cuando se supera el umbral).

Diseño de dashboards de compliance

Un dashboard de compliance efectivo no es un panel con 50 gráficos. Es una herramienta de decisión que responde a tres preguntas: ¿cumplimos?, ¿donde están los gaps?, ¿vamos mejorando o empeorando?

Estructura recomendada

Nivel ejecutivo (una pantalla). Semaforo global por marco normativo (ENS, NIS2, ISO 27001, DORA). Tendencia de los últimos 6 meses. Número de hallazgos criticos abiertos. Proxima auditoria programada.

Nivel operativo (tres a cinco pantallas). Una por categoría de metricas. Gráficos de tendencia temporal (no solo el valor actual). Drill-down desde metrica hacia los controles o activos específicos que la componen.

Nivel técnico (bajo demanda). Detalle de cada control: estado, evidencia, responsable, fecha de última verificación, historico de cambios. Enlace directo al artefacto o herramienta que genera la evidencia.

Principios de visualización

Los semaforos (rojo, ambar, verde) son útiles para el nivel ejecutivo, pero insuficientes para el operativo. Un indicador en ambar no dice nada si no muestra la tendencia: ¿lleva tres meses en ambar y mejorando, o acaba de caer desde verde?

Los gráficos de linea temporal son más informativos que los valores puntuales. Un 87% de cobertura de controles puede ser excelente (si hace 6 meses era 72%) o preocupante (si hace 6 meses era 94%).

Las tablas de calor (heatmaps) funcionan bien para mostrar cobertura por dominio y marco normativo simultaneamente. El eje X representa los marcos (ENS, NIS2, DORA) y el eje Y los dominios de control (gestión de accesos, cifrado, continuidad, respuesta a incidentes).

Reporting a dirección

Las metricas de compliance tienen dos audiencias con necesidades radicalmente diferentes. El equipo técnico necesita detalle para actuar. La dirección necesita contexto para decidir.

Que incluir en el informe para el comite de dirección

El informe trimestral de compliance para la alta dirección debe responder a cinco preguntas. ¿Cumplimos con nuestras obligaciones legales? ¿Cual es nuestro nivel de exposicion regulatoria? ¿Que ha cambiado desde el último informe? ¿Que inversiones son necesarias? ¿Estamos preparados para la proxima auditoria?

La estructura recomendada incluye un resumen ejecutivo de una página con los semaforos por marco, la evolucion trimestral de las 5 metricas más relevantes, los 3 riesgos regulatorios principales con propuesta de mitigación y el estado de los hallazgos de auditoria.

Errores comunes en el reporting

Primer error: presentar metricas técnicas sin traduccion a impacto de negocio. "Tenemos 47 vulnerabilidades CVSS 9+" no significa nada para un consejero. "Tenemos 47 vulnerabilidades que podrian permitir acceso no autorizado a datos de clientes, con una multa potencial de hasta 10M EUR bajo RGPD" si comunica el riesgo.

Segundo error: reportar solo el estado actual sin tendencia. La dirección quiere saber si la situacion mejora o empeora, no solo donde esta hoy.

Tercer error: no incluir recomendaciones accionables. Cada gap identificado debe ir acompanado de una propuesta de remediación con coste estimado y plazo.

Modelo de madurez de compliance

Medir el cumplimiento como un porcentaje binario (cumple/no cumple) es insuficiente. Un modelo de madurez permite evaluar no solo si se cumple, sino con que robustez, repetibilidad y capacidad de mejora.

Niveles de madurez

Nivel 1: Inicial. Los controles existen de forma ad hoc. No hay procesos documentados. El cumplimiento depende de individuos, no de procedimientos. La organización reacciona a incumplimientos cuando los detecta un auditor externo.

Nivel 2: Repetible. Existen procesos documentados para los controles principales. Hay responsables asignados. La medicion es manual y periodica. Se reacciona a los hallazgos de auditoria con planes de accion.

Nivel 3: Definido. Los procesos están estandarizados en toda la organización. Las metricas se recogen de forma sistematica. Hay un programa de compliance formal con presupuesto y equipo dedicado. Las auditorias internas son regulares.

Nivel 4: Gestionado. Las metricas se recogen de forma automatizada. Los controles se verifican continuamente (Compliance-as-Code). Hay KPIs con umbrales y alertas. La mejora continua esta integrada en el ciclo operativo.

Nivel 5: Optimizado. La organización anticipa cambios regulatorios. Los controles se adaptan proactivamente. Hay benchmarking con el sector. La inteligencia regulatoria alimenta la estrategia de seguridad. El compliance es un diferenciador competitivo.

Evaluación práctica

Para cada dominio de control (gestión de accesos, cifrado, continuidad, respuesta a incidentes, etc.), se evalua el nivel de madurez en cuatro dimensiones: procesos (documentación y estandarizacion), personas (formación y responsabilidades), tecnología (herramientas y automatización) y medicion (metricas y mejora continua).

La media ponderada por criticidad del dominio da un score global de madurez que puede compararse entre periodos y, si se dispone de datos sectoriales, con organizaciones similares.

Integracion con marcos normativos específicos

Cada marco normativo tiene requisitos concretos de medicion y reporte que deben reflejarse en el programa de metricas.

ENS (Esquema Nacional de Seguridad)

El ENS en categoría Alta exige auditorias bienales y un sistema de gestión de la seguridad con indicadores. Las metricas deben cubrir las 75 medidas del Anexo II, agrupadas en los marcos organizativo, operacional y de protección. El CCN proporciona guías (serie CCN-STIC 800) con indicadores recomendados.

NIS2

La directiva NIS2 exige a las entidades esenciales e importantes reportar incidentes significativos en plazos específicos (24 horas para alerta inicial, 72 horas para notificación, un mes para informe final). Las metricas deben incluir la capacidad de cumplir estos plazos y la cobertura de las medidas del artículo 21.

ISO 27001:2022

El anexo A de ISO 27001:2022 tiene 93 controles organizados en 4 temas. La clausula 9 (Evaluación del desempeno) exige explicitamente "lo que necesita ser monitorizado y medido" y "los métodos para monitorizar, medir, analizar y evaluar". Las metricas de compliance deben alinearse con esta clausula.

DORA

El reglamento DORA para el sector financiero tiene requisitos específicos de testing de resiliencia operativa digital, gestión de riesgos TIC y reporte de incidentes. Las metricas deben incluir resultados de TLPT (Threat-Led Penetration Testing), estado de los contratos con proveedores TIC criticos y capacidad de recuperacion.

Automatización de la recogida de metricas

La recogida manual de metricas es el principal cuello de botella de los programas de compliance. Cada ciclo de reporting consume dias de trabajo que se dedican a recopilar datos en lugar de analizarlos.

La automatización se aplica en tres niveles. Primero, integracion directa con herramientas de seguridad: el SIEM, el escaner de vulnerabilidades, el sistema de parcheado y la CMDB exportan metricas automaticamente. Segundo, Compliance-as-Code: las politicas se codifican como checks ejecutables que generan resultados en formato procesable. Tercero, consolidacion en un data warehouse o data lake de seguridad que alimenta los dashboards.

Las herramientas como GRC platforms (ServiceNow GRC, Archer, OneTrust), SOAR (Splunk SOAR, Cortex XSOAR) y plataformas de compliance especializadas (Drata, Vanta, Secureframe) permiten automatizar gran parte de la recogida. En entornos con requisitos de soberania como ENS Alto, las soluciones self-hosted o europeas son preferibles a las SaaS estadounidenses.

Recursos y referencias

Para profundizar en metricas de compliance y ciberseguridad:

• NIST SP 800-55 Rev. 2: Performance Measurement Guide for Information Security. El documento de referencia para metricas de seguridad, con taxonomia y ejemplos.
• ENISA Measurement Framework: Guía de ENISA para medir la ciberresiliencia, alineada con NIS2.
• CIS Controls v8 Measures and Metrics: Metricas asociadas a cada uno de los 18 CIS Controls, con formulas y objetivos.
• ISO 27004:2016: Monitoring, measurement, analysis and evaluation. El estandar ISO específico para medicion en seguridad de la información.
• CCN-STIC 815: Metricas e indicadores en el ENS. Guía del CCN para el contexto español.
• FAIR (Factor Analysis of Information Risk): Modelo cuantitativo de riesgo que permite expresar el riesgo en términos economicos, útil para reporting a dirección.
• OpenSCAP: Herramienta open source para automatizar la evaluación de cumplimiento contra perfiles de seguridad (CIS Benchmarks, STIG, PCI DSS).