Gobierno de la seguridad: políticas, roles y métricas

Una organización puede tener el mejor SOC del mercado, EDR de última generación y un equipo técnico brillante, y aun así estar mal gobernada en materia de seguridad. El síntoma es siempre el mismo: nadie en el comité de dirección sabe explicar el nivel de riesgo real de la empresa, las decisiones de seguridad se toman en el departamento de TI sin visibilidad del negocio, y cuando llega la auditoría de certificación aparece una política de treinta páginas que firmó alguien hace tres años y que nadie ha vuelto a mirar. El gobierno de la seguridad de la información es la disciplina que evita exactamente ese escenario: pone a la alta dirección al mando, traduce el riesgo técnico a lenguaje de negocio y construye la estructura —estrategia, políticas, roles, comités, métricas— que hace que la seguridad deje de ser «cosa de informática» y pase a ser una función de gestión con la misma seriedad que las finanzas o el cumplimiento legal.

Este módulo construye esa estructura pieza a pieza, con el mismo rigor documental de ISO/IEC 27001:2022 (cláusula 5, Liderazgo) que exigirá después un auditor de certificación, y con las plantillas —matriz RACI, cuadro de mando, acta de comité— que necesitarás para implantarlo en una organización real, no solo para aprobar un examen.

Qué aprenderás

Qué es el gobierno de la seguridad de la información, en qué se diferencia de la gestión de la seguridad, y por qué ISO 27001:2022 lo sitúa como responsabilidad indelegable de la alta dirección en su cláusula 5.
Cómo se define una estrategia de seguridad con horizonte plurianual, alineada con la estrategia de negocio y no al revés.
La jerarquía documental completa del gobierno: política de seguridad, políticas específicas, normas, procedimientos y registros, con quién aprueba cada nivel y qué debe contener la política de alto nivel.
Cómo construir una matriz RACI de roles y responsabilidades de seguridad, y por qué la segregación de funciones (SoD) es un principio de gobierno, no un capricho de auditoría.
Cómo diseñar un comité de seguridad de la información que funcione de verdad: composición, funciones, periodicidad y conexión con el consejo.
La diferencia real entre KPI y KRI, con ejemplos de métricas de seguridad que un consejero de administración puede entender en diez segundos, y cómo montar un cuadro de mando.
Cómo reportar seguridad a la dirección y al consejo en lenguaje de riesgo y negocio, con qué frecuencia y con qué estructura.
Por qué la cultura de seguridad es un pilar de gobierno y no solo un programa de formación anual.

1. Qué es el gobierno de la seguridad de la información

El gobierno de la seguridad de la información es el sistema mediante el cual la alta dirección de una organización dirige y controla la seguridad: define qué se quiere proteger y por qué, cuánto riesgo está dispuesta a asumir, quién es responsable de qué, y cómo se comprueba que todo eso funciona. Gobernar no es ejecutar: gobernar es decidir el rumbo, asignar autoridad y exigir cuentas. La ejecución del día a día —parchear, monitorizar, responder a incidentes, revisar reglas de firewall— es gestión, y ocurre un nivel por debajo del gobierno, dentro del marco que el gobierno ha definido.

Esta distinción no es semántica, la marca la propia norma de referencia. ISO/IEC 27001:2022, en su cláusula 5 (Liderazgo), no habla de firewalls ni de controles técnicos: habla de que la alta dirección debe garantizar que la política y los objetivos de seguridad son compatibles con la dirección estratégica de la organización, que los requisitos del sistema de gestión se integran en los procesos de negocio, que hay recursos suficientes, y que se promueve la mejora continua. Es, literalmente, un capítulo sobre gobernanza corporativa aplicada a la seguridad, no sobre tecnología. El estándar es taxativo en un punto que muchas organizaciones todavía tratan como opcional: estas responsabilidades no son delegables íntegramente en el CISO. La alta dirección puede apoyarse en roles técnicos para ejecutar, pero la accountability —la responsabilidad última ante el consejo, los reguladores y los accionistas— permanece en la cúpula.

El marco COBIT 2019 de ISACA formaliza esta misma idea con un modelo de dos capas que conviene interiorizar porque aparece constantemente en el lenguaje profesional de GRC: el dominio EDM (Evaluate, Direct, Monitor — Evaluar, Dirigir, Monitorizar), que es puramente de gobierno y corresponde al órgano de gobierno (consejo, comité ejecutivo), y los dominios APO, BAI, DSS y MEA, que son de gestión y corresponden a la dirección ejecutiva. En EDM, el órgano de gobierno evalúa las opciones estratégicas disponibles, dirige a la dirección ejecutiva hacia la opción elegida marcando prioridades y asignando recursos, y monitoriza que el desempeño y el cumplimiento van conforme a lo dirigido. Es exactamente el mismo ciclo evaluar–dirigir–monitorizar que debería aplicar cualquier consejo de administración a la función de seguridad: no se meten a configurar el SIEM, pero sí deciden cuánto riesgo de ciberseguridad es aceptable para la empresa y exigen que se les informe si se está superando.

Por qué importa esto en la práctica: cuando una brecha de seguridad grave llega a los tribunales, a un regulador (AEPD, Banco de España) o a la prensa, la pregunta que se hace no es «¿qué hizo el CISO?» sino «¿qué sabía y qué decidió el consejo?». El gobierno de la seguridad es, en el fondo, la evidencia documental de que la dirección ejerció una diligencia debida razonable. Sin gobierno, no hay defensa posible ante esa pregunta.

2. La estrategia de seguridad

La estrategia de seguridad es el puente entre «lo que la empresa quiere lograr como negocio» y «lo que el programa de seguridad va a hacer durante los próximos años para no ser un obstáculo —o, mejor, para ser un habilitador— de ese objetivo». Una estrategia de seguridad que no se puede conectar en una frase con la estrategia de negocio está mal planteada, por sofisticada que sea técnicamente.

2.1 Cómo se define

El proceso de definición de la estrategia, en organizaciones maduras, sigue un orden reconocible:

Entender la estrategia de negocio y el apetito de riesgo. ¿La empresa va a expandirse a nuevos mercados, lanzar un canal digital, hacer una adquisición, migrar a la nube? Cada movimiento de negocio tiene una sombra de riesgo de seguridad que la estrategia debe anticipar, no descubrir a posteriori.
Evaluar la postura actual. Un diagnóstico de madurez (frente a ISO 27001/27002, NIST CSF 2.0 o un modelo propio) que dé una fotografía honesta de dónde está la organización, no de dónde cree que está.
Identificar la brecha y priorizar. La diferencia entre la postura actual y la postura objetivo, filtrada por el apetito de riesgo y por los requisitos regulatorios aplicables (ENS, RGPD, NIS2, DORA, según el sector).
Formular objetivos estratégicos plurianuales, normalmente entre 3 y 5, medibles y con dueño, del tipo «reducir el tiempo medio de detección de incidentes a menos de 4 horas en 24 meses» o «certificar ISO 27001 el alcance de producción SaaS antes de que finalice el ejercicio fiscal».
Traducir en programa y presupuesto. Cada objetivo estratégico se descompone en iniciativas con presupuesto, responsable y hitos anuales, que es lo que efectivamente ejecuta el equipo de seguridad.
Revisar con periodicidad fija, normalmente anual, y siempre que haya un cambio material de negocio (fusión, nuevo mercado, incidente grave).

2.2 Horizonte temporal

La práctica habitual distingue tres horizontes que conviene no mezclar en un mismo documento: la estrategia propiamente dicha tiene un horizonte de 3 a 5 años y fija la dirección general (a qué nivel de madurez queremos llegar, qué riesgos son innegociables); el plan o roadmap táctico tiene horizonte anual y concreta qué iniciativas se ejecutan ese ejercicio con qué presupuesto; y la operación es el día a día, sin horizonte fijo, ejecutando lo que el plan anual marca. Un error de gobierno muy común es tratar el roadmap anual como si fuera la estrategia: se pierde la visión de largo plazo y cada año se reinventa la rueda sin acumular progreso hacia un objetivo mayor.

2.3 Alineación con la estrategia de negocio: el criterio de la «prueba del ascensor»

Un buen test para validar una estrategia de seguridad es si el CISO puede explicar, en el tiempo de un trayecto de ascensor, cómo cada uno de sus 3-5 objetivos estratégicos apoya un objetivo de negocio concreto (crecer en un mercado regulado, lanzar un producto digital, reducir el coste de las primas de ciberseguro, cumplir un requisito contractual de un cliente grande). Si la respuesta es genérica («mejorar la seguridad en general»), la estrategia no está verdaderamente alineada: está redactada desde el departamento de TI hacia arriba, en lugar de derivada desde el negocio hacia abajo. Esta alineación es, precisamente, lo primero que exige la cláusula 5.1.a de ISO 27001:2022: que la política y los objetivos de seguridad sean compatibles con la dirección estratégica de la organización.

3. La jerarquía documental de la seguridad

Todo sistema de gobierno de la seguridad madura se apoya en una pirámide documental con niveles claramente diferenciados por su nivel de abstracción, su estabilidad en el tiempo y quién tiene autoridad para aprobarlo. Confundir estos niveles —meter procedimientos técnicos dentro de la política, o no tener normas intermedias— es la causa número uno de que la documentación de seguridad sea inmanejable.

Nivel	Qué es y qué contiene	Quién lo aprueba	Estabilidad / revisión
1. Política de seguridad de la información (nivel superior, «master policy»)	Documento único, breve (2-4 páginas), de intención y compromiso: por qué la seguridad importa para el negocio, principios generales, alcance, roles de alto nivel y compromiso de cumplimiento normativo. No entra en detalle técnico.	Alta dirección / CEO (a menudo ratificada por el consejo o comité ejecutivo)	Muy estable: revisión anual o ante cambio material; rara vez cambia de contenido sustantivo
2. Políticas específicas (o «temáticas»)	Una por dominio: control de acceso, clasificación de la información, uso aceptable, teletrabajo, dispositivos móviles, criptografía, copias de seguridad, gestión de proveedores, gestión de incidentes… Fijan el «qué» y el «por qué» de cada dominio, sin procedimiento paso a paso.	CISO / dirección de seguridad, con visto bueno de la dirección afectada (RR. HH. en la política de uso aceptable, IT en la de copias, etc.)	Estable, revisión anual o cuando cambia el riesgo o la normativa del dominio
3. Normas (standards)	Requisitos concretos y medibles que desarrollan una política: longitud mínima de contraseña, algoritmos criptográficos permitidos, tiempo máximo de retención de logs, baseline de hardening de un sistema operativo.	CISO / arquitectura de seguridad	Media, revisión cuando cambia la tecnología o el estado del arte
4. Procedimientos	El «cómo» paso a paso: procedimiento de alta/baja de usuarios, procedimiento de respuesta a incidentes, procedimiento de solicitud de excepción a una norma.	Responsable del proceso / mandos operativos de seguridad o IT	Baja, se actualiza con frecuencia según cambios operativos
5. Registros y guías	Evidencia de que el sistema funciona (actas de comité, registros de incidentes, resultados de auditoría, logs de aprobación de excepciones) y material de apoyo no normativo (guías, plantillas, FAQ internas).	Generado por quien ejecuta el proceso; no requiere aprobación formal, pero sí custodia y trazabilidad	Continua, se genera constantemente como subproducto de la operación

3.1 Qué debe incluir la política de seguridad de alto nivel

ISO/IEC 27001:2022, cláusula 5.2, exige que la política de seguridad de la información sea apropiada al propósito de la organización, incluya los objetivos de seguridad (o el marco para fijarlos), incluya el compromiso de satisfacer los requisitos aplicables relacionados con la seguridad de la información, e incluya el compromiso de mejora continua del sistema de gestión. En la práctica profesional, una política de alto nivel bien construida —y que un auditor de certificación aprobará sin objeciones— contiene:

Propósito y alcance: por qué existe esta política y a quién obliga (empleados, contratistas, proveedores con acceso).
Compromiso de la dirección, firmado, con fecha y con la persona concreta que lo suscribe (no «la dirección», sino el CEO o el consejero delegado nombrado).
Principios generales de seguridad: confidencialidad, integridad, disponibilidad, y cualquier principio propio de la cultura de la organización (p. ej. «seguridad por diseño» si es una empresa de producto digital).
Marco de objetivos de seguridad, o remisión a dónde se fijan y revisan esos objetivos.
Roles de alto nivel: quién es el propietario de la política, quién aprueba las políticas específicas, mención del comité de seguridad.
Compromiso de cumplimiento normativo: mención expresa de las obligaciones legales y contractuales aplicables (RGPD, ENS si aplica, sectoriales) sin necesidad de detallarlas.
Compromiso de mejora continua del sistema de gestión de seguridad.
Consecuencias del incumplimiento, remitiendo al régimen disciplinario correspondiente.
Gobernanza del propio documento: versión, fecha, periodicidad de revisión, aprobador.

Lo que no debe llevar: requisitos técnicos concretos (eso va en normas), procedimientos paso a paso (van en procedimientos) ni nada que obligue a reeditar el documento cada vez que cambia una herramienta o un proveedor. Si la política menciona un producto o proveedor por su nombre, algo está mal diseñado.

4. Roles y responsabilidades: la matriz RACI

Una jerarquía documental impecable no sirve de nada si nadie sabe quién hace qué. La herramienta estándar de gobierno para fijar esto sin ambigüedad es la matriz RACI: para cada actividad, se asigna exactamente un R (Responsable/Responsible, quien ejecuta), como mínimo un A (Aprobador/Accountable, quien rinde cuentas del resultado —y solo puede haber uno por actividad, nunca dos—), cero o más C (Consultado), a quien se pide input antes de decidir, y cero o más I (Informado), a quien se comunica el resultado después.

4.1 Ejemplo de matriz RACI de gobierno de seguridad

Actividad	Consejo / Comité ejecutivo	CISO	Comité de seguridad	Responsable de TI	Propietario del riesgo (área de negocio)	Auditoría interna
Aprobar la política de seguridad de alto nivel	A	R	C	I	I	I
Definir y aprobar el apetito de riesgo	A	C	R	I	C	I
Aceptar formalmente un riesgo residual alto	I	C	C	I	A/R	I
Ejecutar el análisis de riesgos anual	I	A	I	C	C	I
Implantar controles técnicos aprobados	I	A	I	R	I	I
Auditar el cumplimiento del SGSI	I	C	I	C	I	A/R

Dos lecturas de esta matriz que suelen sorprender en la práctica de consultoría: primero, el CISO casi nunca es «A» en la aceptación de un riesgo alto —esa responsabilidad recae en el propietario del riesgo de negocio, que es quien sufre el impacto si el riesgo se materializa; el CISO informa, asesora y documenta, pero no debe cargar con la decisión de negocio de aceptar un riesgo que no le pertenece—. Segundo, auditoría interna nunca debe aparecer como «R» en actividades que audita: si el mismo equipo diseña el control y lo audita, la auditoría pierde todo valor.

4.2 Segregación de funciones (SoD)

La segregación de funciones (Segregation of Duties, SoD) es el principio de gobierno que impide que una sola persona o rol concentre suficiente poder como para cometer o encubrir un fraude o un fallo grave sin que nadie más lo detecte. En seguridad de la información se traduce en reglas muy concretas y verificables en auditoría:

Quien solicita un acceso no debe ser quien lo aprueba, ni quien lo concede técnicamente.
Quien desarrolla código no debe tener permisos para desplegarlo directamente en producción sin revisión de un tercero.
Quien administra los sistemas no debe ser quien audita los logs de esos mismos sistemas.
Quien diseña un control no debe ser el único que evalúa su eficacia.
La gestión de identidades y accesos (altas, bajas, cambios de rol) debe estar separada de quien usa esos accesos en el día a día.

Cuando la segregación total no es viable —típicamente en empresas pequeñas con equipos de seguridad de una o dos personas—, ISO 27002:2022 (control 5.3) admite controles compensatorios: supervisión reforzada, revisión periódica por un tercero externo, registro y alertado de acciones privilegiadas, o doble aprobación puntual en las operaciones más críticas. Lo que no es aceptable es no documentar la limitación ni el compensatorio: un auditor entiende que una pyme no pueda segregar perfectamente, pero exige ver que el riesgo se ha identificado y mitigado conscientemente.

5. El comité de seguridad de la información

El comité de seguridad es el órgano donde el gobierno se hace tangible: es el punto de encuentro periódico entre quienes deciden (dirección) y quienes ejecutan (seguridad, TI, negocio), y es también la evidencia documental —actas, acuerdos, seguimiento de acciones— que un auditor pedirá para comprobar que el gobierno de la cláusula 5 no es papel mojado.

5.1 Composición

La composición varía con el tamaño de la organización, pero un comité de seguridad funcional en una empresa mediana-grande suele incluir: el CISO (normalmente quien preside o secreta el comité), un representante de la alta dirección con autoridad real para decidir presupuesto y aceptar riesgos (director general, COO o un miembro del comité ejecutivo, no un delegado sin poder de decisión), el responsable de TI/infraestructura, el DPO cuando el riesgo tratado tiene componente de datos personales, representantes de las áreas de negocio más expuestas (rotando o fijos según el orden del día), legal/cumplimiento, y en organizaciones con función de auditoría interna, un representante en calidad de observador (nunca como miembro con voto, para preservar su independencia).

5.2 Funciones

Revisar y proponer para aprobación la estrategia y las políticas de seguridad.
Revisar el mapa de riesgos y decidir o elevar al consejo la aceptación de riesgos que superan el apetito definido.
Revisar el cuadro de mando de KPIs/KRIs y el estado de los incidentes relevantes del periodo.
Aprobar o priorizar el presupuesto y las iniciativas del roadmap de seguridad.
Hacer seguimiento de auditorías (internas y de certificación), no conformidades y planes de acción correctiva.
Servir de foro de escalado para decisiones que requieren perspectiva de negocio, no solo técnica (por ejemplo, si se retrasa un lanzamiento de producto por un hallazgo de seguridad crítico).

5.3 Periodicidad y relación con el consejo

La periodicidad habitual del comité de seguridad operativo es mensual o bimestral; en organizaciones sometidas a alta presión regulatoria (banca, seguros, infraestructuras críticas bajo NIS2) o tras un incidente grave, puede pasar a periodicidad mensual estricta o incluso quincenal durante un periodo de remediación. El comité de seguridad no sustituye al consejo: es el filtro y preparador de la información que sube al consejo o a su comité de riesgos/auditoría, que normalmente recibe un resumen ejecutivo con periodicidad trimestral, salvo evento material que exija informar de inmediato. En organizaciones cotizadas o muy reguladas, es cada vez más frecuente que exista un consejero con responsabilidad explícita de supervisión de ciberseguridad, y que el propio consejo reciba formación específica sobre ciberriesgo al menos una vez al año.

6. Métricas: KPI frente a KRI

Confundir KPI y KRI es uno de los errores de comunicación más frecuentes entre seguridad y dirección, y sin embargo la diferencia es simple una vez se fija bien:

Un KPI (Key Performance Indicator) mide rendimiento: si el programa de seguridad está haciendo bien lo que se supone que debe hacer. Responde a «¿estamos ejecutando según lo planeado?».
Un KRI (Key Risk Indicator) mide exposición al riesgo: una señal temprana de que el nivel de riesgo de la organización se está moviendo, típicamente al alza. Responde a «¿deberíamos preocuparnos más de lo que nos preocupamos ayer?».

Un KPI puede estar en verde (el equipo ha parcheado el 98 % de las vulnerabilidades críticas del mes) mientras el KRI asociado se dispara (el número de vulnerabilidades críticas nuevas detectadas ese mes se ha triplicado): el rendimiento del equipo es excelente, pero el riesgo de la organización está subiendo igualmente porque la superficie de ataque crece más rápido de lo que se puede remediar. Un buen cuadro de mando de dirección necesita ambos tipos, y necesita que quien lo lee entienda cuál es cuál.

6.1 Ejemplos de KPI de seguridad útiles para dirección

% de activos críticos con copia de seguridad verificada en los últimos 30 días.
% de empleados que han completado la formación de concienciación obligatoria del periodo.
Tiempo medio de aplicación de parches críticos (MTTP) desde su publicación.
% de proyectos nuevos que han pasado por revisión de seguridad antes de salir a producción.
% de acciones correctivas de auditoría cerradas dentro del plazo comprometido.

6.2 Ejemplos de KRI de seguridad útiles para dirección

Número de vulnerabilidades críticas abiertas con más de 30 días de antigüedad en sistemas expuestos a internet.
Número de cuentas con privilegios administrativos fuera de la línea base aprobada.
Número de incidentes de seguridad con impacto en clientes o en la disponibilidad del servicio, por trimestre, con tendencia.
Número de terceros críticos sin evaluación de riesgo vigente (caducada o inexistente).
Tiempo medio de detección (MTTD) y de contención (MTTC) de incidentes, con tendencia frente al trimestre anterior.
Volumen de datos que sale por canales no controlados (shadow IT, SaaS no aprobado) detectado por CASB/DLP.

6.3 El cuadro de mando (dashboard) y la característica SMART

Un cuadro de mando de seguridad para dirección no debe parecerse a la consola de un SIEM. Las prácticas que separan un buen dashboard de uno inservible para el consejo son: una página única con semáforo (verde/ámbar/rojo) por objetivo estratégico, no cien filas de detalle técnico; tendencia siempre visible (¿mejora o empeora respecto al periodo anterior?), no solo la foto del momento; umbral explícito para cada indicador, de modo que cualquiera vea de un vistazo si está dentro o fuera de tolerancia; y una frase de contexto de negocio junto a cada dato en rojo (qué significa, qué se está haciendo, para cuándo se espera la mejora).

Toda métrica que entra en ese cuadro de mando debería superar el filtro SMART, adaptado a métricas de seguridad:

Specific (Específica): mide una cosa concreta, no «la seguridad en general».
Measurable (Medible): se puede calcular de forma objetiva y repetible a partir de una fuente de datos fiable.
Achievable (Alcanzable): el equipo tiene capacidad real de influir en el resultado (una métrica que depende de un tercero fuera de tu control no debería ser un KPI tuyo).
Relevant (Relevante): conecta con un objetivo estratégico o un riesgo real, no se mide «porque se puede».
Time-bound (Temporal): tiene una cadencia de medición y un horizonte de mejora definidos.

7. Reporting a la dirección y al consejo

El error más costoso al reportar seguridad hacia arriba es hablar el idioma equivocado. Un consejo de administración no necesita saber cuántas alertas generó el SIEM esta semana; necesita saber si el riesgo de la empresa está subiendo o bajando, si hay algo que pueda materializarse en pérdida económica, reputacional o legal, y si el dinero invertido en seguridad está reduciendo ese riesgo de forma demostrable.

7.1 Qué contar

Postura de riesgo agregada: cómo ha evolucionado el riesgo global desde el último informe, con los KRI clave y su tendencia.
Incidentes relevantes: qué pasó, impacto real (no potencial exagerado), qué se ha aprendido y qué cambia como consecuencia.
Estado de los objetivos estratégicos: avance del roadmap plurianual, en semáforo, con motivo si algo está en rojo.
Cumplimiento normativo: estado frente a las obligaciones aplicables (ENS, RGPD, NIS2, sectoriales) y hallazgos de auditorías, internas o externas.
Riesgos que requieren decisión del consejo: peticiones concretas de aceptación de riesgo o de presupuesto, nunca enterradas en un anexo.
Comparativa con el sector cuando sea posible (benchmarking), porque ayuda a calibrar si la inversión es proporcionada.

7.2 Cómo contarlo

En lenguaje de negocio y de riesgo, no técnico: en vez de «detectamos una vulnerabilidad crítica CVSS 9.8 en el servidor Exchange perimetral sin parchear durante 45 días», el informe al consejo dice «durante 45 días existió una vía de entrada de alta probabilidad que podría haber permitido a un atacante tomar el control del correo corporativo; se ha corregido; se está revisando el proceso de parcheo porque el plazo excedió nuestro objetivo interno de 15 días». Misma información, cero jerga, con la implicación de negocio explícita y una acción de mejora concreta.

7.3 Frecuencia

Como regla general: el comité de seguridad opera con periodicidad mensual o bimestral; el comité de dirección/ejecutivo recibe un resumen mensual o trimestral según el nivel de riesgo de la organización; y el consejo (directamente o vía su comité de auditoría/riesgos) recibe un informe trimestral, con un informe anual más extenso de revisión de la estrategia, y siempre ad hoc e inmediato ante cualquier incidente material o brecha con obligación de notificación regulatoria (72 horas a la AEPD bajo RGPD, plazos de NIS2 para entidades esenciales/importantes).

8. Cultura de seguridad y concienciación como pilar de gobierno

Ninguna política, por bien redactada que esté, sobrevive al contacto con un empleado que no la conoce, no la entiende o no le importa. Por eso ISO 27001:2022 no trata la concienciación como un anexo de formación: la incluye dentro del control de la cláusula 7.3 (Toma de conciencia) y la refuerza en ISO 27002:2022 con el control 6.3, dedicado específicamente a la formación y concienciación en seguridad. Desde el punto de vista de gobierno, la cultura de seguridad es tan importante como la propia política, porque es el mecanismo que convierte el papel en comportamiento real.

Un programa de cultura de seguridad gobernado correctamente, y no simplemente «cumplido» con un vídeo anual obligatorio, se caracteriza por:

Patrocinio visible de la alta dirección: el CEO comunicando personalmente por qué importa, no un correo automático de RR. HH.
Segmentación por riesgo del rol: no es lo mismo la formación de un desarrollador (seguridad en el ciclo de vida del software) que la de finanzas (fraude del CEO, ingeniería social en pagos) o la de un administrador de sistemas (gestión segura de privilegios).
Medición del comportamiento real, no solo de la finalización del curso: tasa de clics en simulacros de phishing, tasa de reporte de correos sospechosos, tiempo medio hasta el primer reporte de un incidente por parte de un empleado.
Refuerzo continuo, no un evento anual: micro-formación, comunicaciones periódicas, simulacros recurrentes.
Vínculo explícito con las métricas de gobierno: la tasa de clics en phishing y el % de formación completada son KPI/KRI que deberían aparecer en el mismo cuadro de mando que llega al comité de seguridad, no en un informe aparte de RR. HH.

El indicador más fiable de que la cultura de seguridad funciona no es el porcentaje de aprobados en el test final del curso: es que un empleado, sin que nadie se lo pida, reporte un correo sospechoso o pregunte antes de hacer clic. Eso es cultura; lo demás es cumplimiento formal.

Caso práctico

Contexto: «Distribuidora Ibérica de Componentes, S.A.» (nombre ficticio), fabricante y distribuidora industrial con 400 empleados, facturación de 60 millones de euros, presencia en España y Portugal, y un ERP crítico expuesto parcialmente a proveedores externos. La empresa ha decidido iniciar la certificación ISO 27001:2022 tras perder un contrato importante por no poder acreditarla, y te contrata como consultor de GRC para diseñar el gobierno de la seguridad desde cero.

Diseño del comité de seguridad

Elemento	Decisión de diseño
Nombre	Comité de Seguridad de la Información (CSI)
Composición	Director General (patrocinador y con voto de calidad), Responsable de Seguridad/CISO (recién creado, preside y convoca), Director de Sistemas, Director Financiero (por el riesgo de fraude en pagos y el ERP), Responsable de Operaciones/Producción (por el riesgo OT en planta), asesoría externa de protección de datos actuando como DPO
Periodicidad	Mensual los primeros 12 meses (fase de implantación del SGSI); bimestral una vez certificados y estabilizados
Reporting ascendente	Resumen trimestral al Consejo de Administración (empresa familiar con consejo reducido de 4 miembros), con informe anual de revisión de la estrategia coincidiendo con la revisión por la dirección del SGSI (cláusula 9.3 de ISO 27001)
Primer orden del día	Aprobar la política de seguridad de alto nivel, fijar el apetito de riesgo preliminar y aprobar los 3 KRI iniciales de seguimiento

Tres KRI iniciales con umbral

KRI	Por qué se elige	Umbral (verde / ámbar / rojo)
Nº de accesos de proveedores externos al ERP sin revisión de permisos en los últimos 90 días	El ERP es el activo crítico más expuesto a terceros; un acceso de proveedor mal revisado es la vía de entrada más probable identificada en el análisis de riesgos inicial	Verde: 0 · Ámbar: 1-2 · Rojo: 3 o más
Nº de equipos de planta (OT) con parches de seguridad críticos pendientes de más de 60 días	Producción no puede parar para parchear en cualquier momento, lo que genera una ventana de exposición estructural que dirección debe conocer y aceptar conscientemente	Verde: 0-2 · Ámbar: 3-5 · Rojo: más de 5
Tasa de clics en el simulacro trimestral de phishing dirigido a Finanzas y Dirección	El fraude del CEO/proveedor falso es el escenario de mayor impacto económico directo identificado para esta empresa, y Finanzas/Dirección son el objetivo más probable	Verde: menos del 5 % · Ámbar: 5-15 % · Rojo: más del 15 %

Con estos tres KRI, más dos KPI operativos (% de formación de concienciación completada y tiempo medio de revisión de accesos de terceros), el CISO recién nombrado tiene un cuadro de mando mínimo viable que puede llevar al primer Comité de Seguridad sin necesidad de esperar a tener todo el SGSI implantado: el gobierno empieza a funcionar desde el primer mes, en paralelo a la implantación técnica.

Errores comunes

La política de 80 páginas que nadie lee. Mezclar en un solo documento la intención de alto nivel con normas técnicas y procedimientos operativos produce un mamotreto que ni los empleados leen ni la propia dirección puede aprobar con conocimiento real de causa. La política de nivel superior debe caber en 2-4 páginas; todo lo demás pertenece a los niveles inferiores de la jerarquía documental.
Métricas técnicas que la dirección no entiende. Llevar al consejo el número de alertas del SIEM, el CVSS medio del parque o el número de firmas IDS activas es, en la práctica, no comunicar nada: la dirección no puede tomar ninguna decisión con esos datos. Cada métrica que sube debe traducirse a impacto de negocio.
El comité que no se reúne, o que se reúne pero no decide. Un comité de seguridad convocado en el papel de la política pero que lleva ocho meses sin reunirse (o que se reúne y genera un acta sin acuerdos ni fechas) es, para un auditor, evidencia de que el gobierno declarado no es el gobierno real. Es uno de los hallazgos más frecuentes en auditorías de certificación.
Roles sin dueño. Una matriz RACI donde una actividad crítica no tiene «A» asignado, o donde el «A» recae en un rol genérico («el departamento de IT») en lugar de una persona identificable, garantiza que esa actividad no se hará cuando de verdad importe, porque nadie individual rendirá cuentas por ella.
Confundir el roadmap anual con la estrategia. Sin un horizonte de 3-5 años, el programa de seguridad reacciona proyecto a proyecto y nunca acumula progreso medible hacia un objetivo mayor; cada año se justifica solo, sin narrativa de conjunto ante el consejo.
Delegar la aceptación de riesgo en quien no lo sufre. Cuando el CISO acepta riesgos que en realidad pertenecen a una unidad de negocio, se rompe la cadena de accountability: el propietario del riesgo debe ser siempre quien sufre el impacto si el riesgo se materializa, no el equipo de seguridad.
Tratar la concienciación como un trámite de cumplimiento. Un curso anual obligatorio con test al final cumple el papel, pero no cambia comportamiento. Sin medición del comportamiento real (clics en phishing, tasa de reporte), la organización no sabe si su cultura de seguridad existe de verdad o solo existe en el LMS de formación.

Ejercicio

Para una organización real o ficticia de tu elección (recomendable: tu propia empresa, o una pyme de un sector que conozcas bien):

Redacta el índice completo (solo los epígrafes, sin desarrollar el contenido) de una política de seguridad de alto nivel que cumpla los requisitos de la cláusula 5.2 de ISO 27001:2022, en no más de una página.
Construye una matriz RACI de al menos 6 actividades de gobierno de seguridad (puedes partir de la del apartado 4.1 y adaptarla) para los roles reales de tu organización, verificando que ninguna actividad tiene más de un «A».
Diseña la composición y periodicidad de un comité de seguridad para esa organización, justificando cada miembro incluido: ¿qué aporta y qué riesgo representa a su área si no está en la sala?
Define 3 KPI y 3 KRI de seguridad relevantes para esa organización concreta (no genéricos), con umbral verde/ámbar/rojo para cada uno.
Redacta un párrafo de reporting ejecutivo (máximo 150 palabras) dirigido al consejo, en lenguaje de negocio, usando uno de los KRI en estado «rojo» como ejemplo.

Preguntas frecuentes

¿El gobierno de la seguridad es lo mismo que la gestión de la seguridad?

No, y la distinción es central en toda la disciplina de GRC. El gobierno decide el rumbo: qué se protege, cuánto riesgo se acepta, quién es responsable y cómo se rinden cuentas; corresponde a la alta dirección y, en último término, al consejo. La gestión ejecuta ese rumbo en el día a día: aplicar parches, configurar controles, responder a incidentes; corresponde al CISO y a los equipos técnicos. COBIT 2019 formaliza esta separación en dos capas distintas de dominios: EDM (Evaluate, Direct, Monitor) para gobierno, y APO/BAI/DSS/MEA para gestión. Confundirlas suele producir consejos que se meten a discutir configuraciones técnicas, o equipos técnicos que toman decisiones de apetito de riesgo que no les corresponden.

¿Puede el CISO ser también el propietario del riesgo que acepta un riesgo residual alto?

Como norma general, no debería. El propietario del riesgo (risk owner) tiene que ser quien sufre realmente el impacto de negocio si el riesgo se materializa: el director de una línea de producto, el responsable de una planta, el director financiero. El CISO asesora, cuantifica el riesgo, propone opciones de tratamiento y documenta la decisión, pero la aceptación formal de un riesgo alto debe firmarla quien tiene autoridad de negocio sobre el activo o proceso afectado. Si el CISO acepta sistemáticamente riesgos ajenos, la organización pierde la trazabilidad de responsabilidad que exige un buen gobierno, y en caso de incidente, la pregunta «¿quién aceptó este riesgo y con qué autoridad?» no tendrá una respuesta defendible.

¿Cada cuánto hay que revisar la política de seguridad de alto nivel?

Como mínimo, con periodicidad anual, coincidiendo habitualmente con la revisión por la dirección del sistema de gestión (cláusula 9.3 de ISO 27001:2022). Además de esa revisión programada, debe revisarse siempre que ocurra un cambio material: una fusión o adquisición, la entrada en un nuevo mercado o sector regulado, un cambio significativo en la normativa aplicable (por ejemplo, la transposición de NIS2), o un incidente de seguridad grave que revele que los principios declarados en la política ya no reflejan la realidad de la organización. Una política que lleva más de dos años sin revisarse es, por defecto, sospechosa para cualquier auditor.

¿Qué diferencia hay realmente entre un KPI y un KRI si al final ambos son «números que se miden»?

La diferencia no está en el formato del dato sino en la pregunta que responde. Un KPI responde «¿estamos ejecutando bien lo que nos propusimos hacer?» —mide desempeño frente a un objetivo interno—. Un KRI responde «¿está subiendo el riesgo al que está expuesta la organización?» —mide una señal de alerta temprana, a menudo sobre algo que no controla del todo el equipo de seguridad, como el ritmo al que aparecen vulnerabilidades nuevas en el software de terceros que usa la empresa—. En la práctica, muchas organizaciones maduras usan el mismo dato base de dos formas: el % de parches críticos aplicados a tiempo es un KPI de rendimiento del equipo, mientras que el número absoluto de vulnerabilidades críticas abiertas más de 30 días es un KRI de exposición, aunque ambos salgan del mismo sistema de gestión de vulnerabilidades.

¿Es obligatorio tener un comité de seguridad formal para certificar ISO 27001:2022?

La norma no exige literalmente un órgano llamado «comité de seguridad», pero sí exige, en la cláusula 5.3, que los roles y responsabilidades relevantes para la seguridad de la información estén asignados y comunicados, y en la cláusula 9.3, que la alta dirección revise el sistema de gestión a intervalos planificados. En la práctica de auditoría, casi ninguna organización de tamaño medio o grande puede demostrar ese cumplimiento sin algún tipo de foro periódico y documentado —lo llame comité, reunión de gobierno o de otra forma— con actas, asistentes y acuerdos de seguimiento. En pymes muy pequeñas, ese foro puede integrarse en el comité de dirección general, pero debe quedar constancia igualmente de que la seguridad se trata con la periodicidad y el rigor que la norma exige.

«Top management shall demonstrate leadership and commitment with respect to the information security management system by: a) ensuring the information security policy and the information security objectives are established and are compatible with the strategic direction of the organization; b) ensuring the integration of the information security management system requirements into the organization’s processes…»

— ISO/IEC 27001:2022, Cláusula 5.1 (Liderazgo y compromiso), International Organization for Standardization / International Electrotechnical Commission.

Módulo 2: Gobierno de la seguridad de la información