Un SGSI no mejora simplemente porque una organización publique documentos formales o implemente salvaguardas técnicas de forma aislada. Como explicamos en nuestra guía completa de ISO 27001, el sistema necesita determinar con claridad qué resultados pretende alcanzar, quién responderá por ellos, qué recursos requerirá y de qué forma evaluará si progresa de manera sostenida.
Ese es precisamente el cometido de los objetivos de seguridad de la información (Cláusula 6.2 de la norma).
Un objetivo práctico responde a una pregunta sencilla pero potente:
¿Qué resultado concreto de seguridad queremos lograr y cómo sabremos si lo estamos alcanzando?
Responder con rigor permite pasar de intenciones vagas como “mejorar la cultura de seguridad” a compromisos gestionables acompañados de recursos, plazos y métricas verificables.
Qué es un objetivo de seguridad de la información
Un objetivo es un resultado que la organización pretende alcanzar dentro de su sistema de gestión. Como revisamos al explorar los términos de organización, gobierno y objetivos dentro del SGSI, estos pueden abordar aspectos muy diversos:
- Reducción del tiempo de exposición frente a vulnerabilidades críticas.
- Elevación de la cobertura de autenticación robusta en identidades administrativas.
- Fortalecimiento de la capacidad de contención frente a incidentes.
- Garantía de disponibilidad en servicios esenciales dentro de compromisos SLA.
- Cumplimiento estricto de requisitos legales o contractuales de custodia de datos.
- Mejora en la calidad y automatización de las evidencias de cumplimiento.
La clave reside en la palabra resultado. Un objetivo no debe confundirse con una mera actividad. Decir “Realizar un taller de concienciación sobre phishing” describe lo que se va a hacer, pero no aclara qué cambio se pretende lograr en la organización.
Una formulación enfocada a resultados sería: “Reducir del 14 % al 7 % la tasa de interacción con simulaciones de phishing antes del 31 de diciembre, manteniendo una cobertura de formación superior al 95 %.” Aquí contamos con un punto de partida (línea base), una meta cuantitativa, un plazo temporal y un indicador de avance.
Qué exige ISO 27001 sobre los objetivos (Cláusula 6.2)
ISO/IEC 27001:2022 estipula en su Cláusula 6.2 que los objetivos deben establecerse en las funciones y niveles pertinentes. Para ser conformes, dichos objetivos deben:
- Ser coherentes con la política de seguridad de la información aprobada por la dirección (desarrollada al detallar la política de seguridad de la información).
- Tener en cuenta los requisitos aplicables (legales, reglamentarios y contractuales) analizados en el contexto de la organización en ISO 27001.
- Considerar los resultados de la evaluación y tratamiento de riesgos en ISO 27001.
- Ser medibles (si es practicable).
- Ser objeto de seguimiento y monitorización.
- Ser comunicados a las partes interesadas y personal pertinente.
- Ser actualizados cuando sea necesario.
- Conservarse como información documentada.
Además, al planificar cómo alcanzarlos, la norma exige determinar formalmente: qué se hará, qué recursos se requerirán, quién será el responsable, cuándo se completará y cómo se evaluarán los resultados.
Política, objetivo, control, actividad y KPI: no son lo mismo
Es habitual observar cierta confusión entre estos cinco términos. Conviene delimitar su papel dentro del SGSI:
| Elemento | Definición en el SGSI | Ejemplo Práctico |
|---|---|---|
| Política | Declaración de intención y dirección estratégica aprobada por la Alta Dirección. | “La organización protegerá los accesos a datos sensibles garantizando el principio de mínimo privilegio.” |
| Objetivo | Resultado concreto que se pretende alcanzar en un periodo determinado. | “Alcanzar el 100 % de cobertura de MFA resistente a phishing en cuentas de administradores antes del 30 de noviembre.” |
| Control | Salvaguarda o medida implementada para modificar o mantener el riesgo. | Control A.8.5 (Autenticación segura) mediante llaves FIDO2 / WebAuthn. |
| Actividad / Tarea | Acción u operación ejecutada por el equipo para implementar o mantener el control. | Configurar la directiva de acceso condicional en el proveedor de identidad y distribuir llaves hardware. |
| Indicador / KPI | Medida o ratio que permite evaluar el avance o grado de consecución del objetivo. | Porcentaje de identidades privilegiadas activas con MFA FIDO2 configurado e identificado en logs. |
¿Los objetivos deben ser SMART y obligatoriamente numéricos?
El modelo SMART (Específico, Medible, Alcanzable, Relevante y Temporal) es una herramienta excelente para estructurar metas corporativas, pero ISO 27001 no exige utilizar la metodología SMART como requisito obligatorio.
Del mismo modo, la norma especifica que los objetivos deben ser medibles si es practicable. Aunque cuantificar numéricamente aporta claridad en muchos casos, forzar métricas porcentuales artificiales puede distorsionar la realidad operativa.
Un objetivo puede evaluarse también mediante hitos verificables o criterios de aceptación cualitativos explícitos:
- Evaluación cuantitativa: “Reducir el tiempo medio de contención (MTTR) de incidentes críticos a menos de 45 minutos durante el próximo trimestre.”
- Evaluación basada en hitos: “Diseñar, probar y validar un plan de continuidad de operaciones ante ransomware con participación del comité ejecutivo antes del cierre del semestre.” (Verificable mediante acta firmada y resultados de simulación).
De dónde salen los objetivos: contexto, política y riesgos
Como recordamos al repasar qué es un SGSI y cómo definir su alcance, los objetivos de seguridad no nacen en el vacío. Deben alimentarse de cinco fuentes clave del sistema:
- Dirección Estratégica (Política): Los compromisos del liderazgo enunciados bajo el liderazgo y compromiso de la alta dirección.
- Resultados del Análisis de Riesgos: Las opciones de mitigación seleccionadas tras la evaluación de amenazas e impactos.
- Requisitos de Partes Interesadas: Exigencias contractuales de clientes clave o mandatos regulatorios (como NIS2, DORA o GDPR).
- Incidentes y Tendencias de Desempeño: Lecciones aprendidas derivadas de fallos de seguridad u observaciones de auditoría interna.
- Revisión por la Dirección: Decisiones tomadas por los ejecutivos para adaptar la seguridad a nuevos modelos de negocio.
Cómo diseñar un objetivo de seguridad paso a paso
Para construir un objetivo bien definido, se recomienda estructurar la planificación en 6 pasos:
- Definir el resultado buscado: Describir el estado futuro deseado (ej. reducir la ventana de exposición a vulnerabilidades).
- Establecer el alcance aplicable: Delimitar los sistemas, servicios o departamentos incluidos (ej. servidores web de producción).
- Determinar la línea base: Medir la situación inicial de partida (ej. actualmente se tardan 28 días de media en aplicar parches críticos).
- Fijar la meta y el plazo: Establecer el valor objetivo y la fecha límite (ej. reducir el tiempo a menos de 7 días antes de 60 días).
- Asignar responsable y recursos: Designar al Risk Owner o líder técnico y asignar presupuesto o herramientas.
- Definir la fórmula de evaluación y frecuencia: Acordar cómo y cada cuánto se recogerán las métricas (ej. informe semanal extraído del scanner de vulnerabilidades).
Métricas, indicadores, KPIs, línea base y tolerancias
Para monitorizar eficazmente la evolución del SGSI, debemos apoyarnos en los términos estudiados sobre medición, desempeño e indicadores en ISO 27001:
- Métrica: Dato cuantitativo bruto (ej. 45 vulnerabilidades detectadas).
- Indicador: Ratio o dato procesado en contexto (ej. % de vulnerabilidades críticas subsanadas dentro de plazo).
- Línea Base: Valor de referencia inicial frente al cual se mide la mejora o el retroceso.
- Tolerancia o Umbral de Alerta: Margen de desvío aceptable antes de activar medidas de corrección o escalado (ej. si el cumplimiento cae por debajo del 90 %, se convoca una reunión extraordinaria de revisión).
Cómo evitar métricas vanidosas y falsos indicadores
Un peligro recurrente en la gobernanza de TI es el uso de métricas vanidosas: indicadores que parecen muy llamativos en un informe visual pero que no aportan información real sobre el nivel de protección de la organización.
| Métrica Vanidosa o Engañosa | Por qué puede ser contraproducente | Indicador Centrado en Resultados Reales |
|---|---|---|
| “Cero incidentes de seguridad reportados en el año” | Incentiva la falta de reporte o el miedo a declarar incidentes reales, ocultando la visibilidad del riesgo. | Tiempo medio de detección (MTTD) y contención (MTTR), junto con el % de incidentes con análisis de causa raíz cerrado. |
| “Número de alertas de seguridad procesadas en el SOC” | Mide volumen de actividad, no eficacia. Puede reflejar simplemente un exceso de falso positivo o ruido en las reglas. | Porcentaje de alertas críticas investigadas dentro de la ventana SLA de 15 minutos con triage verificado. |
| “100 % del personal ha asistido a la charla de seguridad” | La asistencia no garantiza cambios de comportamiento ni aprendizaje efectivo. | Reducción en la tasa de clics en campañas de simulaciones de ingeniería social y aumento en el reporte voluntario de correos sospechosos. |
Ejemplos prácticos por sector (SaaS, SOC, Hospital, Terceros)
Presentamos cuatro modelos de objetivos diseñados para distintos entornos operativos:
Ejemplo 1 — Empresa SaaS (Gestión de Código Seguro)
- Objetivo: Eliminar la presencia de credenciales o secretos expuestos en repositorios de código fuente de producción.
- Meta: 0 secretos detectados en ramas principales (main/master) sin excepción explícita aprobada.
- Acciones: Implementación de herramientas de Secret Scanning en pipelines CI/CD y bloqueos mediante pre-commit hooks.
- Indicador: Hallazgos semanales detectados por la herramienta de escaneo estático.
Ejemplo 2 — Centro de Operaciones de Seguridad (SOC)
- Objetivo: Reducir el tiempo de contención inicial ante alertas de filtración de credenciales en endpoints corporativos.
- Meta: Aislamiento de red automático del endpoint afectado en menos de 20 minutos desde la generación de la alerta de severidad alta.
- Responsable: Responsable de Respuesta a Incidentes / Lider del SOC.
Ejemplo 3 — Sector Sanitario / Hospitalario (Continuidad)
- Objetivo: Garantizar la disponibilidad de los sistemas de historia clínica electrónica ante caídas de infraestructura.
- Meta: Restauración completa del servicio en entorno secundario en menos de 2 horas (RTO ≤ 2h) con una pérdida máxima de datos de 15 minutos (RPO ≤ 15m).
- Evidencia: Informe de simulación de desastre con firma de la dirección médica y TI.
Ejemplo 4 — Gestión de Riesgos de Terceros / Proveedores
- Objetivo: Asegurar que la totalidad de los proveedores críticos cuenten con evaluación de riesgo de ciberseguridad vigente.
- Meta: 100 % de proveedores Nivel 1 (acceso a datos sensibles o infraestructura crítica) homologados antes de la firma o renovación de contrato.
- Indicador: % de proveedores críticos con cuestionario de seguridad y evidencias de cumplimiento validadas.
Evidencias de auditoría, plantilla y actualización de objetivos
Frente a una auditoría interna o de certificación ISO 27001, no basta con mostrar una lista de intenciones. El auditor solicitará la trazabilidad completa mediante la siguiente cadena de evidencias:
Documento de Objetivos Aprobado → Plan de Acción (Recursos/Fechas) → Informes de Medición Periódicos → Actas de Revisión por la Dirección → Registro de Ajustes o Acciones Correctivas
Los objetivos deben actualizarse cuando cambie el contexto o tras la revisión por la dirección. Si un objetivo no se alcanza, no se debe ocultar el resultado; el SGSI exige analizar las causas, ajustar las actividades o recursos, y dejar constancia de la decisión de gestión tomadas.
Relación con la guía de medición ISO/IEC 27004
Para profundizar en los métodos de medición, las organizaciones pueden consultar la norma técnica de orientación ISO/IEC 27004 (Monitoring, measurement, analysis and evaluation).
Nota de actualización normativa: La versión publicada vigente es ISO/IEC 27004:2016. A fecha de septiembre de 2026, la tercera edición (ISO/IEC DIS 27004) se encuentra en fase avanzada de desarrollo (tras el cierre del periodo de votación DIS en septiembre de 2026). Se aconseja verificar la publicación formal de la edición 3 para adoptar sus modelos actualizados de métricas.
Al estructurar tus tableros de control y planificar el seguimiento del desempeño, conviene revisar cómo se conectan los conceptos del SGSI para garantizar una alineación perfecta entre la evaluación estratégica y la mejora continua.
Preguntas frecuentes
¿Es obligatorio que todos los objetivos de seguridad sean cuantitativos?
No. ISO 27001 exige que sean medibles si es practicable. Muchos objetivos pueden evaluarse mediante hitos verificables, pruebas de auditoría o estados de implementación cualitativos claramente definidos.
¿Debe el CISO asumir la responsabilidad de todos los objetivos del SGSI?
No. Los objetivos deben asignarse a las funciones pertinentes. Por ejemplo, los objetivos de parcheo corresponden a Infraestructura/TI, los de concienciación a RR. HH. o Formación, y los de evaluación de proveedores a Compras o Riesgo de Terceros.
¿Qué diferencia hay entre la Cláusula 6.2 (Objetivos) y la Cláusula 9.1 (Seguimiento y Medición)?
En la Cláusula 6.2 se planifican y definen los objetivos y los recursos necesarios. En la Cláusula 9.1 se ejecuta el proceso global de seguimiento, medición, análisis y evaluación del desempeño de todo el SGSI.
De la definición de objetivos a la planificación global
Definir objetivos de seguridad claros y medibles proporciona al SGSI la orientación necesaria para tomar decisiones basadas en datos objetivos. En el próximo artículo analizaremos cómo coordinar objetivos, riesgos y gestión de cambios dentro de la planificación integral del sistema de gestión.
Si deseas aprender a estructurar sistemas de gobernanza, definir cuadros de mando GRC y preparar tu organización para auditorías de certificación, te invitamos a explorar el curso Analista GRC. Gobernanza de IT, Riesgo y Cumplimiento.
