Muchas organizaciones disponen de un registro de riesgos formalmente correcto, pero carecen de un control operativo fiable en el día a día. En la práctica no determina la cantidad de riesgos documentados, sino si los responsables detectan con antelación dónde se está acumulando el riesgo y si las medidas son efectivas. Exactamente aquí interviene la gobernanza de riesgos basada en KPIs: traduce riesgos abstractos en pocas métricas medidas de forma consistente, comparables entre equipos, sistemas y proveedores — y que desembocan en decisiones sobre presupuesto, prioridades, excepciones y escaladas.
El punto crítico: KPIs (Key Performance Indicators) miden rendimiento y ejecución, KRIs (Key Risk Indicators) miden la exposición al riesgo. En muchos informes ambos se mezclan. Eso provoca paneles aparentemente „verdes“, aunque la empresa siga siendo en la práctica vulnerable (por ejemplo, buena tasa de parches en general, pero alta vulnerabilidad en sistemas expuestos a Internet). Este artículo muestra qué métricas han demostrado ser útiles para riesgos de TI, cómo debe definirlas, qué fuentes de datos son típicamente necesarias y cómo establecer la gobernanza para que auditorías y realidad operativa encajen.
Por qué las métricas en la gobernanza de riesgos suelen fracasar
Los patrones de error típicos son sorprendentemente constantes, independientemente del sector o de las herramientas:
- Demasiadas métricas: los equipos reportan 30–60 valores, pero nadie puede derivar decisiones de ellos. Consecuencia: la elaboración de informes se convierte en un trámite, no en una herramienta de gestión.
- Definiciones inconsistentes: „sistemas críticos“, „estado de parches“ o „incidente“ significan en operaciones, security y auditoría cosas distintas. Eso hace que las tendencias carezcan de valor.
- Sin vinculación con responsabilidades: sin una lógica RACI‑Logik (Responsible, Accountable, Consulted, Informed) clara, no queda claro quién debe actuar — ni quién asume el riesgo.
- Métricas sin higiene de datos: si el inventario de activos y las identidades no están correctos, las métricas se vuelven una pseudo‑precisión. Las preguntas de auditoría no se podrán responder.
- Sin umbrales ni rutas de escalado: un valor „rojo“ sin una decisión definida a seguir genera solo discusión, no reducción del riesgo.
Una lógica de KPIs fiable es menos un asunto de dashboard que un asunto de gobernanza: definiciones, fuentes de datos, valores límite, catálogo de medidas, procedimientos de excepción y evidencia de auditoría deben encajar entre sí.
Gobernanza de riesgos basada en KPIs: modelo básico, roles y lógica de decisión
Para los riesgos de TI ha demostrado su eficacia un modelo de tres niveles, que además resulta fácilmente verificable en auditorías:
1) Exposición al riesgo (KRIs): „¿Qué tamaño tiene el riesgo ahora?“
Los KRIs muestran la superficie de ataque o de fallo actual, p. ej. vulnerabilidades críticas sin parchear en sistemas productivos expuestos a Internet. Son indicadores líderes, porque aumentan antes de los incidentes.
2) Kontrollwirksamkeit (Control KPIs): „¿Funcionan nuestros controles?“
Ejemplos son la cobertura de MFA, pruebas de RESTauración exitosas o la tasa de éxito de cambios. Estos KPIs muestran si los controles de gobernanza actúan efectivamente en el funcionamiento operativo.
3) Resultado (Outcome KPIs): „¿Qué daños/interrupciones se producen?“
Ejemplos son el tiempo de inactividad no planificado, incidentes de seguridad con fuga de datos o costes derivados de medidas de emergencia. Estas métricas son importantes, pero a menudo llegan demasiado tarde para permitir la toma de control.
Importa la asignación de roles: Accountable suele ser típicamente un propietario del servicio o del sistema (Service‑Owner o System‑Owner) responsable del riesgo en el scope correspondiente, Responsible son las funciones de Operaciones/Security, y Consulted/Informed son Compliance, Protección de datos, Compras y Dirección. Sin esta asignación, los KPIs se convierten en „cifras de seguridad“ que pueden ser correctas técnicamente pero carecen de efecto organizativo.
Principios de selección: Qué métricas necesitan realmente los responsables
Si solo puede seleccionar pocas métricas, deben cumplir estos cuatro criterios:
- Capacidad de decisión: El valor debe poder desencadenar una acción concreta (priorizar, aprobar, detener, exceptuar, escalar).
- Comparabilidad: El valor debe ser consistente a lo largo del tiempo y entre unidades (equipos/servicios/ubicaciones).
- Resistencia a la manipulación: La métrica no debe poder «reportarse en verde» desplazando definiciones o cerrando tickets sin reducir el riesgo.
- Evidencia de auditoría: Fuente de datos, método de cálculo, responsabilidad y evidencia deben ser reproducibles.
En la práctica esto significa: mejor 10–15 métricas núcleo con límites claros y lógica de acción que un conjunto inabarcable de KPIs. Métricas de detalle complementarias pueden existir a nivel operativo, pero no pertenecen al órgano de dirección.
Métricas núcleo para riesgos de TI (con definiciones, umbrales y fuentes de datos típicas)
A continuación se presenta un conjunto práctico de métricas. Puede usarlo como plantilla y adaptarlo por empresa según criticidad, regulación y arquitectura (On‑Prem, Cloud, Hybrid).
1) Cobertura de activos: ¿Qué tan completa es nuestra visibilidad?
Por qué es relevante: Sin un inventario de activos fiable (dispositivos, servidores, recursos en la nube, aplicaciones, interfaces) todos los KPIs posteriores son inciertos. En las auditorías suele ser el primer punto vulnerable.
- KPI: Grado de cobertura de activos gestionados = (activos en inventario/CMDB con propietario + criticidad + estado del ciclo de vida) / (total de activos detectados)
- Umbrales: Valores objetivo de gestión por alcance (p. ej. Producción/Internet) más estrictos que para redes de laboratorio
- Fuentes de datos: CMDB, escáneres de discovery, inventario de activos en la nube, MDM/EDR, inventario de red
Nota de gobernanza: Defina «Asset» y «Owner» de forma inequívoca. Para software de negocio y soluciones de software cercanas al proceso, el Service‑Owner (funcional/operativo) suele ser más apropiado que un mero host‑owner técnico.
2) Cobertura de criticidad: ¿Dónde falta contexto de negocio?
KPI: Porcentaje de Assets/Servicios con criticidad clasificada (p. ej. según disponibilidad, confidencialidad, integridad) y categoría de datos (datos personales, confidencial, público)
Por qué es relevante: Los plazos de parcheo, la densidad de monitorización y las barreras para cambios deben vincularse a la criticidad; de lo contrario se genera o bien sobrecarga o bien vuelo a ciegas.
3) Cumplimiento de parches como KRI: Riesgo por rezagos en zonas críticas
Importante: «Patch‑Compliance» solo es relevante para el riesgo si se segmenta (p. ej. expuestos a Internet, sistemas privilegiados, OT/producción, bases de datos de las joyas de la corona).
- KRI: Porcentaje de sistemas con actualizaciones de seguridad vencidas en clases de criticidad definidas (p. ej. > 14/30/60 días por encima del SLA)
- KPI complementario: Tiempo mediano hasta aplicar el parche (MTTP: Mean Time To Patch) para actualizaciones críticas
- Fuentes de datos: Gestión de parches, Configuration Management, escáneres de vulnerabilidades, pipelines de imágenes en la nube
Lógica de umbrales: Defina para cada zona valores límite estrictos y un procedimiento formal de excepciones. «No se puede parchear actualmente» es una decisión con aceptación de riesgo —no un estado.
4) Vulnerabilidades: Vulnerabilidades críticas expuestas (riesgo de explotación)
Los recuentos de vulnerabilidades sin contexto son inútiles. Lo determinante es la combinación de severidad, explotabilidad y exposición.
- KRI: Número/porcentaje de «vulnerabilidades críticas y explotables» en sistemas productivos accesibles desde el exterior
- Opcional: Porcentaje de hallazgos con plan de remediación definido y Owner
- Fuentes de datos: Escáneres de vulnerabilidades, EDR, inventario WAF/Ingress, escáneres de seguridad en la nube
Perspectiva de auditoría: Documente cómo se operacionaliza «explotable» (p. ej. Known Exploited Vulnerabilities, indicios de exploit, flags de threat‑intel). Sin definición, en la auditoría será una cuestión de opinión.
5) Seguridad de identidades y accesos: Cobertura de MFA y acceso privilegiado
Muchos ataques exitosos se basan en la identidad. Por eso las métricas IAM (Identity and Access Management) deben formar parte de la gobernanza de riesgos.
- KPI: Cobertura de MFA para cuentas privilegiadas y accesos remotos (cuentas admin, VPN, consola cloud, O365/Workspace)
- KRI: Número de cuentas privilegiadas sin Owner rastreable o sin recertificación periódica
- KPI: Tiempo hasta desprovisionamiento (offboarding) para roles críticos
- Fuentes de datos: IAM/IdP, PAM (Privileged Access Management), sistema de RR.HH., ticketing
Decisión de gobernanza: Defina qué roles son «privilegiados» (administradores locales, administradores de BD, Cloud‑Owner, administrador CI/CD, administrador de backups). Esta lista es un artefacto de auditoría y debe versionarse.
6) Registro y detección: Cobertura, calidad, capacidad de respuesta
«Tenemos un SIEM» no es un indicador. Lo medible es si las fuentes relevantes están conectadas y si las alertas conducen a decisiones.
- KPI: Cobertura de fuentes de logs en servicios críticos (autenticación, acciones de administración, accesos a datos, egreso de red)
- KPI: MTTD/MTTA (Mean Time To Detect/Acknowledge) para alertas de seguridad de gravedad definida
- KRI: Proporción de alertas sin triage dentro del SLA o con causa recurrente sin medidas
- Datenquellen: SIEM, EDR, registros de IdP, Cloud‑Audit‑Logs, plataforma de ticketing/IR
Consecuencias operativas: Un elevado número de alertas no es automáticamente negativo; lo negativo es que las alertas no se gestionen o que no se realice una corrección sostenible de las causas.
7) Riesgo de backup y recuperación: tasa de pruebas, cumplimiento de RPO/RTO
El éxito de los backups por sí solo no constituye una red de seguridad. Lo decisivo es si la RESTauración funciona en condiciones reales.
- KPI: Porcentaje de sistemas críticos con prueba de RESTauración periódica (según plan, con protocolo)
- KPI: Cumplimiento de RPO/RTO (Recovery Point/Time Objective) en pruebas y en incidentes reales
- KRI: Número de trabajos de backup con errores recurrentes o sin cifrado/inalterabilidad verificados (Immutable Backup)
- Datenquellen: sistema de backup, runbooks de prueba, protocolos de emergencia, monitorización
Evidencia de auditoría: Los protocolos de pruebas de RESTauración son un fuerte objeto de prueba. Importante: alcance, estado de los datos, duración, desviaciones, aprobación por el propietario.
8) Riesgo de cambios: los cambios como principal impulsor de fallos
El Change‑Management es una palanca de riesgo, no solo un proceso ITIL. Para soluciones empresariales digitales con múltiples interfaces, esto es especialmente relevante.
- KPI: Change‑Failure‑Rate (proporción de cambios con rollback/incidente dentro de un periodo definido)
- KPI: Proporción de cambios con verificación completa de riesgos (impacto, plan de reversión, evidencia de pruebas, revisión de seguridad en clases relevantes)
- KRI: Proporción de «Emergency Changes» sin evaluación posterior ni análisis de causas
- Datenquellen: ITSM, logs de despliegue, monitorización, post‑incident reviews
Práctica de gobernanza: Defina clases de cambio (standard/normal/emergency) y vincule a ellas los requisitos mínimos y las obligaciones de evidencia. Esto reduce las discusiones caso por caso.
9) Madurez del Incident‑Response: velocidad, calidad, efecto de aprendizaje
Los outcome‑KPI (número de incidentes) dependen en gran medida de la capacidad de detección. La madurez se refleja en los tiempos de respuesta y en el aprendizaje a partir de los incidentes.
- KPI: MTTR (Mean Time To RESTore) para fallos de servicio definidos
- KPI: Proporción de incidentes de seguridad con análisis de causa raíz completo y seguimiento de medidas
- KRI: Tasa de repetición de las mismas clases de incidentes (indica falta de prevención)
- Datenquellen: herramienta ITSM/IR, postmortems, gestión de problemas
10) Riesgo de terceros y de la cadena de suministro: controlabilidad en lugar de intuición
El Third‑Party‑Risk suele ser el ámbito en el que la gobernanza existe formalmente, pero no se mantiene operativamente.
- KRI: Proporción de proveedores críticos sin evaluación de seguridad actual, sin cláusulas contractuales sobre notificación de incidentes/SLAs o sin plan de salida
- KPI: Tiempo hasta el cierre de hallazgos identificados en proveedores
- Datenquellen: gestión de proveedores, datos contractuales, informes de auditoría, ticketing
Perspectiva de auditoría: Lo importante no es tanto un «score» como la trazabilidad: clasificación, requisitos mínimos, desviaciones, aceptación del riesgo, seguimiento.
Plantilla: ficha KPI (definición, propietario, umbrales, evidencia)
Para que los indicadores no den lugar a interpretaciones, cada indicador de gestión necesita una ficha descriptiva. La siguiente estructura es útil en auditorías:
- Nombre y propósito (¿qué decisión apoya?)
- Alcance (qué sistemas/servicios, qué zonas, qué intervalos temporales)
- Definición/Fórmula (incl. filtros de datos, excepciones, redondeo)
- Owner (Accountable) y responsables de datos (Responsible)
- Umbrales (verde/amarillo/rojo) y ruta de escalación
- Catálogo de medidas (¿qué es obligatorio en amarillo/rojo?)
- Evidencia (qué logs/informes sirven como prueba, dónde se almacenan, durante cuánto tiempo)
- Ciclo de revisión (mensual/trimestral, además de revisión tras un incidente mayor)
Ficha KPI (plantilla breve)
KPI-Name:
Objetivo/Decisión:
Alcance (Servicios/Zonas):
Definición/Fórmula:
Fuentes de datos (sistemas, informes):
Calidad de datos/Validación:
Propietario (Accountable):
Gestión (Responsible):
Umbrales (G/Y/R):
Escalación (comité, plazo):
Medidas obligatorias en amarillo:
Medidas obligatorias en rojo:
Evidencia (almacenamiento, retención):
Ciclo de revisión:
Última modificación/versión:De los indicadores a las decisiones: umbrales, excepciones, aceptación de riesgos
Los indicadores solo son aptos para la gobernanza cuando está claro qué decisión se toma en cada valor. Esto puede operacionalizarse con tres componentes:
Los umbrales deben vincularse a la criticidad
Un SLA de parcheo de 30 días puede ser adecuado en sistemas internos de backoffice, pero suele ser demasiado largo para interfaces de administración expuestas a Internet. Defina umbrales por clase de criticidad, no una solución única para todos.
Las excepciones necesitan una fecha de caducidad y compensación
Si un sistema no es parcheable (legacy, dependencia del fabricante, ventanas de producción), la excepción debe incluir:
- Justificación del riesgo y aprobación del propietario del negocio (Accountable)
- Fecha de finalización (p. ej. 60/90 días) o plan de migración
- Controles compensatorios (p. ej. segmentación de red, detección adicional, acceso solo vía Jump‑Host)
- Obligación de demostrar (evidencia de quién aprobó)
La aceptación del riesgo es una decisión, no un estado
En la práctica los riesgos desaparecen en columnas de «Aceptado» sin que esté claro quién asume qué riesgo residual. Establezca un formato en el que la aceptación del riesgo quede documentada explícitamente (alcance, periodo, riesgo residual, responsable). Esto reduce los riesgos «silenciosos» que luego escalan en un incidente.
Preparación para auditoría: qué cuestionan típicamente los auditores sobre la gobernanza de KPIs
Independientemente de si se orienta por ISO‑27001, BSI‑Grundschutz, requisitos próximos a NIS2 o sistemas de control internos: los auditores suelen plantear las mismas preguntas. Una gobernanza de riesgos basada en KPIs puede ser muy eficaz aquí, siempre que esté documentada de forma rigurosa.
1) Nachvollziehbarkeit der Datenkette
¿De dónde proviene el valor, cómo se genera y es reproducible? Si consolida datos de varias herramientas, documente la lógica de transformación (incluso si se trata solo de un Reporting‑Job).
2) Vollständigkeit und Scope
¿Qué sistemas están incluidos, cuáles no y por qué? Un alcance definido de manera consciente es auditable; un alcance aleatorio parece una brecha de control.
3) Evidenz für Maßnahmen
No basta con «hemos priorizado». Los auditores quieren ver que, ante violaciones de umbrales, se han tomado decisiones (tickets, aprobaciones de cambios, autorizaciones de excepción, actas de comités).
4) Regelmäßige Wirksamkeitsprüfung
Los KPIs deben revisarse y ajustarse ante cambios en la arquitectura (migración a la nube, nueva plataforma IAM, nuevo software de negocio). Sin un protocolo de revisión, el conjunto de KPIs parece rápidamente obsoleto.
Kosten- und Kapazitätsperspektive: Kennzahlen als Budget- und Priorisierungswerkzeug
La gobernanza de riesgos suele fracasar no por la voluntad, sino por los recursos. Buenas métricas ayudan a destinar capacidad donde generan mayor palanca de riesgo. Tres patrones prácticos:
- Risikobasiertes Backlog: Las medidas se priorizan no por volumen, sino por su contribución al KRI (p. ej., reducción de «vulnerabilidades críticamente explotables en sistemas expuestos»).
- Finanzierbare Mindestkontrollen: Para cada clase de criticidad defina estándares mínimos (MFA, logging, pruebas de backup). Todo lo que exceda eso se gestiona como proyecto con caso de negocio.
- Transparente Tech‑Debt: Si los sistemas heredados generan excepciones de forma persistente, se convierte en una decisión de la dirección: modernizar, reemplazar o asumir un riesgo residual consciente. Las métricas proporcionan la justificación.
Es importante que los KPIs no se introduzcan como «instrumento de castigo». De lo contrario, los equipos optimizarán para las cifras en lugar de para el riesgo (por ejemplo, reduciendo el alcance). Por ello, la gobernanza debe mantener siempre la integridad de los datos y los incentivos adecuados en el foco.
Implementierungsfahrplan in 6 Wochen: Von Null zu belastbarer KPI‑Governance
Si hoy dispone de reporting fragmentado, un inicio ágil y realista es crucial. Un plan típico:
Woche 1: Scope und Risikoentscheidungen festlegen
- Definir clases de criticidad (servicios/aplicaciones, no solo servidores)
- Determinar el órgano de dirección (p. ej., Security‑/Risk‑Board) y establecer los tipos de decisión
- Seleccionar los 10 principales riesgos que pueden ser gestionados mediante métricas
Woche 2: KPI‑Set auswählen und Steckbriefe schreiben
- 10–15 métricas (KRIs + KPIs de control + pocos resultados)
- Para cada métrica: ficha, responsable, umbrales, lógica de medidas
Woche 3: Datenquellen anbinden und Datenqualität prüfen
- Conciliar inventario de activos/CMDB con discovery/inventario en la nube
- Probar definiciones (p. ej., «expuesto», «crítico», «vencido»)
Woche 4: Reporting und Evidence‑Ablage standardisieren
- Formato de reporting uniforme (mensual) incl. tendencia y estado de medidas
- Ubicación de almacenamiento para evidencias (actas, excepciones, informes de prueba) con retención
Woche 5: Pilot‑Gremium durchführen und Eskalationspfade üben
- Simular 2–3 casos reales aplicando los umbrales
- Probar el proceso de excepciones y las aprobaciones
Semana 6: Estabilizar y transferir a operación regular
- Ajustar definiciones, eliminar riesgos de „gaming“
- Documentar RACI de forma clara, informar a los responsables
- Establecer ciclo de revisión y desencadenantes de cambio para ajustes de KPI
Lista de verificación para gerentes: KPI‑Governance que funciona en la operación
- ¿Están KRIs y KPIs claramente separados (riesgo vs. rendimiento)?
- ¿Existe por cada indicador un Owner (Accountable) con mandato de decisión?
- ¿Están los umbrales vinculados a la criticidad y la exposición?
- ¿Existe un procedimiento formal de excepciones con fecha de finalización y compensación?
- ¿Está la cadena de datos documentada y auditable (fuente, obtención, evidencia)?
- ¿Existe una rutina de gobernanza estable (agenda, acta, seguimiento de acciones)?
- ¿Se incorporan las lecciones aprendidas de los incidentes en los umbrales/controles?
Conclusión: Pocas métricas, decisiones claras, evidencia verificable
La gobernanza de riesgos basada en KPI no es un proyecto de reporting, sino un mecanismo de control: conecta la realidad técnica (activos, vulnerabilidades, identidades, cambios) con las decisiones de gestión (prioridades, presupuestos, excepciones, aceptación del riesgo). El mayor beneficio se obtiene cuando no «mide todo», sino que se definen pocas métricas sólidas, vinculadas a la criticidad, que ante el incumplimiento de umbrales desencadenen consecuencias vinculantes. Así, el riesgo no solo queda documentado, sino que se gestiona realmente: en la operación, en proyectos y en auditorías.
Para este tema también son importantes la gestión de riesgos de TI y la gobernanza de TI. El artículo sitúa estos aspectos de forma comprensible y muestra en qué hay que centrarse en la práctica diaria.