Evaluación del desempeño ISO 27001: métricas y eficacia

Un Sistema de Gestión de la Seguridad de la Información (SGSI) puede contar con políticas formalmente aprobadas, una rigurosa evaluación de riesgos, controles técnicos avanzados y procedimientos operativos detallados. Sin embargo, en algún momento del ciclo de vida del sistema surgirá la pregunta fundamental de cualquier comité o dirección:

¿Está funcionando realmente la seguridad de la información?

Esa es la esencia de la evaluación del desempeño. No basta con afirmar que un control existe. No basta con contabilizar cuántas políticas se han publicado ni con mostrar un panel lleno de gráficos vistosos. La organización necesita disponer de un mecanismo metódico que le permita comprender si la seguridad alcanza los resultados previstos, si los controles operan como se diseñaron, si los riesgos permanecen bajo control y si el SGSI es eficaz en su conjunto.

Como vimos al abordar los términos de medición, desempeño y auditoría en ISO 27001 y cómo se integran en la planificación del SGSI, la norma ISO/IEC 27001:2022 estructura esta necesidad en la Cláusula 9.1 mediante cuatro acciones clave que debemos distinguir con precisión: seguimiento, medición, análisis y evaluación.

Qué significa evaluar el desempeño de un SGSI (y el error de empezar por el dashboard)

Evaluar el desempeño de la seguridad de la información no consiste en recopilar datos para llenar un informe mensual. Consiste en construir una capacidad organizativa orientada a responder preguntas de gestión estratégicas y operativas. Por ejemplo:

¿La cobertura de MFA es suficiente para mitigar el riesgo de acceso no autorizado en identidades privilegiadas?
¿Los backups pueden recuperarse con garantías dentro del objetivo de tiempo de recuperación (RTO) acordado?
¿Los incidentes de seguridad críticos se detectan y contienen dentro de los plazos esperados?
¿Las vulnerabilidades críticas permanecen expuestas más tiempo del permitido por nuestra política?
¿Los controles implementados tras un análisis de riesgos y oportunidades en ISO 27001 están reduciendo efectivamente el nivel de riesgo residual?

Una métrica solo es útil cuando contribuye a responder una pregunta relevante para el negocio o el gobierno del SGSI.

El error recurrente: empezar por el dashboard

Muchas organizaciones caen en la trampa de adquirir una plataforma de ciberseguridad o Business Intelligence, activar todos sus paneles por defecto, recopilar cientos de datos inconexos y luego intentar averiguar qué significan o qué decisiones tomar con ellos.

La metodología adecuada exige invertir el orden: primero identifique la decisión que debe tomar, luego determine qué información necesita para respaldarla y, finalmente, defina cómo obtenerla y visualizarla.

Seguimiento, medición, análisis y evaluación: diferencias fundamentales según la Cláusula 9.1

Para implementar con éxito la Cláusula 9.1 de ISO/IEC 27001:2022, es vital entender las cuatro etapas del ciclo de evaluación:

Concepto	Definición en la gestión del SGSI	Ejemplo práctico
Seguimiento (Monitoring)	Observar el estado, la evolución o la continuidad de un proceso o actividad a lo largo del tiempo. Puede ser cualitativo o cuantitativo.	Revisar mensualmente el estado de ejecución de las actividades del plan de tratamiento de riesgos.
Medición (Measurement)	Proceso para determinar un valor numérico o cuantitativo preciso sobre un aspecto específico del SGSI.	Calcular el porcentaje de servidores de producción con parches críticos instalados.
Análisis (Analysis)	Examinar e interpretar los datos obtenidos para identificar patrones, tendencias, causas raíz o correlaciones.	Identificar que el 80% de los parches retrasados se concentran en una arquitectura heredada específica.
Evaluación (Evaluation)	Comparar los resultados del análisis contra criterios, metas o umbrales predefinidos para emitir un juicio de valor y tomar decisiones.	Concluir que el tiempo de parcheo en la arquitectura heredada supera el SLA aceptable y requiere una acción correctiva o aislamiento.

Observe cómo se encadenan estos cuatro elementos: medimos para obtener datos, los analizamos para entender su contexto y los evaluamos frente a nuestros objetivos de seguridad de la información para fundamentar la toma de decisiones.

Estado normativo: ISO 27001:2022, ISO 27004:2016 y DIS 27004

Al diseñar el sistema de medición del SGSI, es imperativo fundamentar el trabajo en los estándares vigentes a septiembre de 2026:

ISO/IEC 27001:2022 + Amd 1:2024: La norma de requisitos establece en la Cláusula 9.1 la obligación general de determinar qué medir, los métodos, el calendario, los responsables y la conservación de evidencias sobre el desempeño de la seguridad y la eficacia del SGSI.
ISO/IEC 27000:2026: La sexta edición del estándar de vocabulario proporciona las definiciones formales del marco SGSI.
ISO/IEC 27004:2016: Es la guía directa para el seguimiento, medición, análisis y evaluación de la seguridad de la información. Aunque fue publicada para acompañar la versión 2013 de la norma, continúa siendo una referencia técnica de gran valor práctico.
ISO/IEC DIS 27004 (3.ª edición en desarrollo): A fecha de septiembre de 2026, la tercera edición de ISO 27004 se encuentra en fase de borrador (Draft International Standard - DIS, etapa 40.60, tras finalizar votación en septiembre de 2026). No debe citarse como una norma publicada, sino como un trabajo normativo en evolución alineado con ISO 27001:2022.
ISO 19011:2026: Ofrece directrices para la auditoría de sistemas de gestión (revisada en su 4.ª edición en mayo de 2026). Sirve para diferenciar el monitoreo continuo de la evaluación mediante auditorías internas.

Metodología paso a paso para construir un sistema de medición y evaluación

Para construir una arquitectura de evaluación sólida y escalable conforme al marco de qué es un SGSI y cómo definir su alcance, recomendamos seguir una secuencia pedagógica de 8 pasos:

Partir de objetivos, riesgos y procesos críticos: No intente medirlo todo. Seleccione los puntos de control que sustentan la estrategia de la organización, los riesgos de mayor impacto y los requisitos legales o contractuales.
Formular la pregunta de gestión: Transforme la necesidad de control en una pregunta clara. En lugar de "medir vulnerabilidades", pregunte: ¿estamos corrigiendo las vulnerabilidades críticas expuestas a Internet antes de que superen el plazo de remediación estipulado?
Definir el parámetro o métrica: Determine con precisión la variable objeto de observación (por ejemplo, número de días de exposición, porcentaje de activos cubiertos, etc.).
Establecer el método y la fórmula: Documente de manera unívoca cómo se calcula el indicador, especificando numerador, denominador, exclusiones autorizadas y fuentes de datos de origen.
Verificar la calidad de las fuentes de datos: Una métrica basada en inventarios desactualizados o logs incompletos generará evaluaciones erróneas y falsas sensaciones de seguridad.
Fijar frecuencias y responsabilidades: Asigne quién captura la información, quién la analiza y quién tiene la responsabilidad de decidir ante desviaciones.
Establecer la línea base (baseline) y el criterio de evaluación: Compare la medición actual contra metas numéricas, SLAs, límites de apetito de riesgo o tendencias históricas.
Definir la acción y registrar la evidencia: Vincule la evaluación a decisiones operativas o estratégicas y conserve la informacion documentada y evidencias necesarias para demostrar la eficacia del proceso.

Métricas, KPIs y KRIs: tipos de indicadores y calidad de datos

Aunque la norma ISO/IEC 27001 no obliga a emplear una terminología rígida de gestión, en la práctica profesional es muy provechoso categorizar los indicadores según su función:

Métrica: Un dato cuantitativo bruto observado en el entorno operativo. Ejemplo: 1.500 servidores activos.
KPI (Key Performance Indicator): Mide el grado de desempeño o cumplimiento de un objetivo o proceso. Ejemplo: 98,5% de servidores con agente de detección EDR actualizado y reportando.
KRI (Key Risk Indicator): Advierte sobre cambios en la exposición al riesgo o el incremento de vulnerabilidad antes de que se produzca un impacto grave. Ejemplo: Número de servidores críticos con parches de seguridad pendientes durante más de 30 días.

Factores clave para la calidad de los datos

Para asegurar la comparabilidad y la reproducibilidad de las mediciones en el tiempo, los datos deben ser:

Consistentes: Utilizar las mismas definiciones e intervalos de tiempo de un periodo a otro.
Completos: Abarcar la totalidad del alcance definido del SGSI sin omitir activos o delegaciones.
Incorruptibles: Obtenidos de forma automatizada o mediante fuentes verificables siempre que sea posible, reduciendo el sesgo de la manipulación manual.

Indicadores de actividad vs. indicadores de eficacia de controles y del SGSI

Uno de los mayores escollos en la evaluación del SGSI es confundir la actividad ejecutada con la eficacia alcanzada. La siguiente diferenciación resulta crítica:

Tipo de indicador	Enfoque habitual	Ejemplo de Actividad (Superficial)	Ejemplo de Eficacia (Real)
Concienciación	Medir esfuerzo vs. cambio de conducta	12 cursos de seguridad impartidos durante el año.	Reducción del 45% en la tasa de clics en simulaciones de phishing y aumento del 60% en el reporte voluntario por parte de los empleados.
Gestión de accesos	Medir existencia de control vs. cobertura y rigor	MFA está configurado en la plataforma de correo.	100% de los accesos administrativos y remotos protegidos por MFA con resistencia a phishing, con 0 cuentas huérfanas activas.
Gestión de incidentes	Medir recuento de eventos vs. velocidad de respuesta	Se registraron 120 alertas en el SIEM este mes.	Reducción del tiempo medio de detección (MTTD) a ≤ 15 min y del tiempo medio de respuesta/contención (MTTR) a ≤ 45 min en incidentes de severidad alta.

La evaluación de la eficacia del SGSI exige analizar si el conjunto del sistema está cumpliendo su política y protegiendo los activos de información, no solo si los equipos están trabajando o generando registros de actividad.

Ejemplos prácticos de indicadores por dominio de seguridad

A continuación se proponen ejemplos de indicadores por dominios de control del Anexo A de ISO/IEC 27001:2022. No deben aplicarse como una lista obligatoria, sino adaptarse al contexto de cada organización:

1. Control de Accesos e Identidades (Dominios 5.15, 8.2, 8.5)

Porcentaje de cuentas de usuarios dados de baja cuyos accesos fueron revocados dentro de las 24 horas posteriores al cese.
Número de cuentas privilegiadas activas que no han sido sometidas a recertificación en los últimos 90 días.

2. Gestión de Vulnerabilidades y Parcheo (Dominio 8.8)

Porcentaje de vulnerabilidades de severidad Crítica/Alta remediadas dentro del plazo definido por la directiva interna (SLA).
Tiempo medio de permanencia de vulnerabilidades conocidas en activos expuestos a redes públicas.

3. Seguridad Operativa y Copias de Seguridad (Dominio 8.13)

Porcentaje de pruebas de restauración de copias de seguridad ejecutadas con éxito conforme a los RTO y RPO planificados.
Porcentaje de sistemas críticos con logs de auditoría centralizados e ingeridos sin interrupción en el SIEM.

4. Seguridad en las Relaciones con Proveedores (Dominios 5.19, 5.21)

Porcentaje de proveedores críticos evaluados en materia de seguridad antes de la firma del contrato y en revisiones anuales.
Número de hallazgos de seguridad no resueltos por terceros fuera del plazo contractual establecido.

Diseño de dashboards ejecutivos, uso de semáforos y trampas del promedio

El propósito de un cuadro de mando o dashboard es sintetizar la complejidad técnica para facilitar la toma de decisiones. Para diseñar dashboards ejecutivos eficaces:

Evite la sobrecarga visual: Limite el cuadro de mando a 6-10 indicadores clave vinculados directamente a los objetivos de seguridad y a los riesgos principales.
Criterios objetivos para semáforos (RAG): Los colores Verde, Amarillo y Rojo solo aportan valor si obedecen a reglas numéricas preestablecidas. Por ejemplo: Verde (≥ 98%), Amarillo (90-97,9%), Rojo (< 90%). Sin criterios formales, los semáforos responden a valoraciones subjetivas.
Cuidado con las trampas del promedio: Un indicador como el "Tiempo medio de respuesta a incidentes de 2 horas" puede resultar engañoso si el 95% de las alertas menores se cierran en 5 minutos pero un incidente crítico requirió 48 horas de contención. Utilice percentiles (p. ej., percentil 95), medianas o desglose por severidad cuando la distribución sea irregular.
Muestre tendencias, no solo fotos fijas: Acompañe los valores del periodo con su evolución histórica (3, 6 o 12 meses) para valorar si el control mejora, se degrada o permanece estable.

Casos prácticos de aplicación por sector (SaaS, Hospital, Pyme)

Caso 1: Empresa SaaS Tecnológica

Desafío: Garantizar la seguridad del pipeline de desarrollo y la resistencia de la infraestructura en la nube.

Enfoque de medición: Cobertura de escaneo de código estático (SAST) y dependencias (SCA) en el 100% de los repositorios de producción; porcentaje de secretos detectados y rotados en < 4 horas; cobertura de MFA resistente a phishing en todos los accesos a la consola cloud (AWS/GCP/Azure).

Caso 2: Centro Hospitalario o Sanitario

Desafío: Proteger la confidencialidad de los datos de salud e imposibilitar la interrupción de la asistencia médica por malware/ransomware.

Enfoque de medición: Tasa de éxito y tiempo de recuperación en simulacros de aislamiento de red y restauración de sistemas de historias clínicas; porcentaje de dispositivos médicos conectados inventariados y segmentados por VLANs restringidas; auditorías de accesos no autorizados a expedientes sensibles.

Caso 3: Pequeña y Mediana Empresa (Pyme)

Desafío: Recursos limitados para la gestión y seguimiento continuo.

Enfoque de medición: Cuadro de mando simplificado de 6 indicadores: 1) Cobertura de antivirus/EDR en puestos de trabajo, 2) Estado diario de copias de seguridad fuera de línea, 3) Porcentaje de usuarios con formación básica completada, 4) Estado del parcheo del sistema operativo, 5) Número de incidentes notificados, 6) Avance de acciones pendientes del plan de riesgos.

Matriz práctica de medición y ficha modelo de indicador

Para asegurar la formalización del proceso de medición sin incurrir en burocracia excesiva, se recomienda mantener una Matriz de Medición del SGSI estructurada como la siguiente:

Pregunta de Gestión	Indicador (KPI/KRI)	Fuente de Datos	Frecuencia	Responsable	Criterio / Meta	Decisión / Acción Esperada
¿Se corrigen a tiempo las vulnerabilidades críticas?	% de vulnerabilidades críticas cerradas dentro del SLA (15 días)	Escáner de vulnerabilidades + Gestor de tickets (Jira/ServiceNow)	Mensual	Responsable de SecOps	≥ 95%	Si es < 95%, reasignar recursos de ingeniería o exigir plan de mitigación compensatorio.
¿Es eficaz la recuperación de datos ante un ransomware?	% de pruebas de restauración exitosas dentro del RTO (< 4h)	Informes de pruebas de restauración y logs del sistema de backup	Trimestral	Administrador de Sistemas / IT Operations	100% en sistemas críticos	Si falla una prueba, abrir incidente de infraestructura y revisar la integridad de la copia en < 48h.
¿Se controlan los accesos de personal saliente?	Tiempo transcurrido hasta la revocación completa de cuentas tras baja	Directorio Activo / IdP + Registro de bajas de Recursos Humanos	Mensual	Administrador de Identidades (IAM)	≤ 24 horas (0 desviaciones en privilegiadas)	Si supera las 24h, iniciar investigación de auditoría e implementar automatización entre HR e IdP.

Modelo de Ficha de Indicador del SGSI

Para cada indicador clave del sistema conviene documentar una ficha simplificada:

Nombre del indicador: [Denominación clara]
Objetivo / Pregunta: [Propósito de la medición]
Fórmula de cálculo: [Numerador / Denominador x 100 o métrica directa]
Fuente de información: [Herramienta, base de datos o informe de origen]
Frecuencia de captura y reporte: [Diaria, mensual, trimestral]
Responsables: Captura (Técnico), Análisis (CISO/Security Manager), Decisión (Comité SGSI)
Umbral / Criterio de aceptación: [Meta numérica o rango de tolerancia]
Plan de contingencia ante desviación: [Canal de escalado y tipo de acción remedial]

Evidencias a conservar y conexión con auditoría y dirección

De acuerdo con la Cláusula 9.1 de ISO/IEC 27001:2022, la organización debe conservar información documentada adecuada como evidencia de los resultados de seguimiento, medición, análisis y evaluación.

Esta evidencia puede almacenarse en forma de cuadros de mando consolidados, informes de evaluación periódicos, exportaciones históricas de herramientas GRC/SIEM o actas de comités de seguridad. No es preciso imprimir ni archivar la totalidad de las mediciones brutas diarias, sino garantizar la trazabilidad de los análisis y de las decisiones adoptadas.

Integración con la Auditoría Interna y la Revisión por la Dirección

La evaluación del desempeño alimenta de forma directa las dos etapas posteriores del ciclo del SGSI:

Auditoría Interna (Cláusula 9.2): El programa de auditoría utilizará los resultados del seguimiento y las mediciones para seleccionar las áreas de mayor riesgo o menor desempeño que requieran una comprobación en profundidad. (Este proceso se abordará en detalle en nuestra futura guía sobre la auditoría interna del SGSI).
Revisión por la Dirección (Cláusula 9.3): La alta dirección no revisa logs ni métricas operativas aisladas; examina los informes consolidados de evaluación del desempeño, el grado de cumplimiento de los objetivos y las tendencias de la eficacia para asignar presupuesto, recursos y aprobar cambios estratégicos. (Proceso que analizaremos en nuestra futura publicación sobre la revisión por la dirección).

Errores frecuentes, checklist de verificación y FAQs

Errores frecuentes en la evaluación del desempeño

Medir lo que es fácil de medir en lugar de lo que es importante: Contar correos electrónicos enviados en lugar de evaluar el impacto real de la formación.
Acumular métricas sin asignación de responsables: Indicadores que se calculan automáticamente pero que nadie revisa ni analiza.
Modificar continuamente los criterios de cálculo: Cambiar la fórmula del indicador de un mes a otro impidiendo analizar tendencias a largo plazo.
Desconexión con la gestión de riesgos: Mantener indicadores genéricos que no reflejan los riesgos reales identificados en la organización.

Checklist de verificación de la Cláusula 9.1

[ ] Se han identificado las necesidades de seguimiento y medición asociadas a objetivos, riesgos y controles críticos.
[ ] Se han documentado las fórmulas, fuentes y métodos de cálculo para cada indicador.
[ ] Se han definido frecuencias razonables adaptadas a la velocidad de cambio de cada variable.
[ ] Se han asignado roles explícitos para la captura, el análisis y la toma de decisiones.
[ ] Se dispone de líneas base y criterios numéricos u objetivos para evaluar la eficacia.
[ ] Los resultados de las evaluaciones se registran y conservan como información documentada.
[ ] Los informes de desempeño se presentan periódicamente a los responsables del SGSI y a la dirección.

Preguntas frecuentes (FAQs)

¿ISO 27001 exige disponer de un número determinado de KPIs?

No. La norma ISO/IEC 27001:2022 no especifica una cantidad fija de indicadores ni exige emplear la denominación "KPI". Lo exigido es disponer de un método estructurado de seguimiento, medición, análisis y evaluación adaptado al tamaño y contexto de la organización.

¿Es obligatorio aplicar la norma ISO/IEC 27004?

No. ISO/IEC 27004 es una norma de directrices (código de buenas prácticas) no certificable. Sin embargo, utilizar sus recomendaciones facilita enormemente el diseño y la justificación del sistema de medición ante auditores de certificación.

¿Es necesario medir la totalidad de los 93 controles del Anexo A?

No necesariamente mediante métricas numéricas individuales. Muchos controles se evalúan mediante verificaciones periódicas, revisiones de diseño o pruebas de auditoría. La organización debe seleccionar los parámetros de medición que aporten valor real al control del riesgo y del SGSI.

Formación especializada en Gobierno, Riesgo y Cumplimiento (GRC)

Si deseas profundizar en la estructuración de métricas de seguridad, la gestión de riesgos, la implementación de controles y la preparación de evidencias para auditorías en entornos corporativos reales, te invitamos a explorar nuestro curso profesional:

Ver curso: Analista GRC. Gobernanza de IT, Riesgo y Cumplimiento

Sobre el autor: Álvaro Chirou

Consultor e instructor especializado en Ciberseguridad, ISO 27001 y Gobierno de TI. Con cientos de miles de estudiantes en Udemy, imparte formación práctica orientada a certificaciones e implementación de marcos de seguridad en empresas.