La función GOVERN del NIST CSF 2.0: la novedad que reordena tu programa

La mayoría de los programas de ciberseguridad tienen controles de sobra y gobierno de menos. Hay herramientas para detectar anomalías, procedimientos para responder a incidentes y cuadros de mando llenos de porcentajes. Lo que suele faltar es una respuesta convincente a tres preguntas incómodas: qué riesgo acepta la organización, quién tiene autoridad para decidir y qué ocurre cuando el problema está en un proveedor que no controlas.

La función GOVERN del NIST Cybersecurity Framework 2.0 intenta resolver precisamente ese vacío. No añade otra colección de controles técnicos. Cambia el punto de partida: la ciberseguridad deja de presentarse como una actividad del departamento de sistemas y pasa a tratarse como una disciplina de gobierno, riesgo y responsabilidad empresarial.

Ese giro importa especialmente en Europa. DORA exige que la dirección de las entidades financieras apruebe y supervise el marco de gestión del riesgo TIC; NIS2 sitúa la responsabilidad de las medidas de gestión del riesgo en los órganos de dirección; el artículo 32 del RGPD obliga a implantar medidas técnicas y organizativas adecuadas al riesgo. GOVERN no sustituye ninguna de estas normas. Pero ofrece una arquitectura bastante más útil que una colección de políticas desconectadas para demostrar que las obligaciones forman parte de un sistema de decisión.

Aquí está el quid: una entidad puede tener un inventario de activos impecable y seguir sin saber quién decide aceptar una vulnerabilidad crítica en un proveedor estratégico. Puede haber comprado un servicio de detección 24/7 y no tener definido cuándo una alerta se convierte en una crisis para el comité ejecutivo. GOVERN pone esas decisiones delante del negocio. Y eso, en ciberseguridad, suele ser más transformador que comprar otra consola.

GOVERN no es una séptima capa de controles

NIST publicó el CSF 2.0 el 26 de febrero de 2024. La revisión amplió el alcance del marco más allá de las infraestructuras críticas y lo presentó como un recurso aplicable a organizaciones de cualquier tamaño y sector. La modificación más visible fue la incorporación de GOVERN como sexta función, junto a IDENTIFY, PROTECT, DETECT, RESPOND y RECOVER.

La posición de GOVERN en el modelo es deliberada. No aparece como una fase que se ejecuta después de identificar o proteger. Funciona como una capa transversal: establece cómo se decide el riesgo y cómo se supervisa el resto del programa. Sin esa capa, las otras cinco funciones pueden convertirse en un inventario técnico razonable pero estratégicamente huérfano.

El CSF 2.0 organiza GOVERN en seis categorías:

• GV.OC, Organizational Context: define las circunstancias internas y externas que condicionan el riesgo, incluidos objetivos, obligaciones, partes interesadas y dependencias.
• GV.RM, Risk Management Strategy: conecta la estrategia de riesgo de ciberseguridad con la tolerancia al riesgo empresarial, la priorización y las líneas de negocio.
• GV.RR, Roles, Responsibilities, and Authorities: asigna funciones, responsabilidades y autoridad para decidir.
• GV.PO, Policy: establece, comunica y revisa políticas de ciberseguridad.
• GV.OV, Oversight: supervisa el desempeño del programa y comprueba si las decisiones siguen alineadas con la estrategia.
• GV.SC, Cybersecurity Supply Chain Risk Management: integra el riesgo de la cadena de suministro en el gobierno de la organización.

La diferencia con una política corporativa convencional es práctica, no semántica. Una política puede decir que los proveedores deben cumplir requisitos de seguridad. GV.SC obliga a preguntarse cómo se clasifica a cada proveedor, quién aprueba una excepción, qué evidencias se revisan, qué ocurre durante la terminación del contrato y cómo se integra la información del tercero en el riesgo global.

NIST tampoco presenta GOVERN como un estándar de certificación ni como una lista cerrada de controles. Esa es una virtud, siempre que la organización no lo utilice como una excusa para quedarse en el lenguaje abstracto. El CSF ofrece resultados deseables; corresponde a cada entidad traducirlos en decisiones, controles, evidencias y métricas proporcionales a su exposición.

El cambio real: del inventario de controles a la autoridad para decidir

En muchas organizaciones, el programa de ciberseguridad se evalúa por su actividad: número de vulnerabilidades corregidas, porcentaje de empleados formados, cobertura de EDR o tiempo medio de respuesta. Son indicadores útiles, pero describen movimiento, no necesariamente control. Una organización puede mejorar todos esos números y continuar sin un criterio documentado para aceptar riesgos que no se pueden eliminar.

GV.RM introduce una pregunta más exigente: ¿cómo se relaciona cada decisión de ciberseguridad con la estrategia de gestión del riesgo empresarial? La respuesta no debería limitarse a una matriz con colores. Tiene que explicar qué activos, procesos y servicios son críticos; qué interrupción es tolerable; qué escenarios pueden provocar un impacto financiero, prudencial, legal o reputacional; y qué nivel de riesgo requiere la intervención del comité de dirección.

Para una entidad financiera sujeta a DORA, esta conexión no es opcional. El artículo 5 del Reglamento exige que el órgano de dirección sea responsable último del riesgo TIC y apruebe la estrategia de resiliencia operativa digital. Los artículos 6 a 16 detallan elementos del marco de gestión del riesgo TIC, como la identificación, protección, detección, respuesta, recuperación, aprendizaje y comunicación. El CSF no reemplaza esas exigencias, pero puede servir para ordenar el marco y evitar que cada requisito se gestione como un expediente separado.

Un buen registro de riesgo debería mostrar, por ejemplo, que una interrupción del sistema de pagos durante cuatro horas afecta a una capacidad empresarial concreta, depende de determinados proveedores, activa un umbral de escalado y tiene un propietario con autoridad para aceptar o rechazar la exposición residual. Decir que el riesgo es «medio-alto» aporta poco si nadie sabe qué decisión debe tomar después.

En este punto, el vínculo entre GOVERN y las otras funciones es esencial. IDENTIFY debe producir una visión suficientemente fiable de activos, dependencias y escenarios; PROTECT debe traducir esa visión en salvaguardas; DETECT debe definir qué señales importan; RESPOND y RECOVER deben probar que la organización puede mantener o recuperar sus servicios prioritarios. GOVERN determina quién decide si el nivel resultante es aceptable y qué sucede cuando no lo es.

GV.RR: el antídoto contra el «eso lo lleva IT»

La categoría GV.RR es probablemente la más incómoda para las organizaciones maduras en tecnología. Obliga a separar tres conceptos que suelen mezclarse: responsabilidad, autoridad y ejecución.

El equipo de seguridad puede ser responsable de diseñar un control, pero no necesariamente tiene autoridad para aceptar el riesgo de no implantarlo. El propietario de un proceso puede responder por la continuidad de un servicio, aunque no gestione los sistemas que lo soportan. El consejo puede tener la responsabilidad última de supervisión sin participar en cada decisión operativa. Si el modelo no distingue estos planos, la accountability se evapora en cuanto llega un incidente.

Una aplicación operativa de GV.RR exige, como mínimo, un mapa de decisiones. Debe identificar quién:

• aprueba la tolerancia al riesgo y sus límites;
• acepta una excepción de control y durante cuánto tiempo;
• decide la clasificación de un servicio como crítico;
• autoriza la activación de la respuesta a incidentes;
• comunica con el regulador, los clientes y otros grupos afectados;
• puede suspender una integración o un proveedor cuando la exposición supera el umbral establecido.

Esto conecta directamente con NIS2. El artículo 20 de la Directiva exige que los órganos de dirección de las entidades esenciales e importantes aprueben las medidas de gestión de riesgos de ciberseguridad y supervisen su aplicación. También prevé responsabilidad por el incumplimiento de esas obligaciones. La traducción operativa no consiste en enviar al consejo un curso anual de dos horas. Consiste en demostrar que el órgano recibe información útil, entiende los riesgos relevantes y tiene un mecanismo para cuestionar decisiones.

La misma lógica aparece en DORA, cuyo artículo 5 atribuye la responsabilidad última al órgano de dirección. Una presentación con el porcentaje de parches instalados no demuestra supervisión. Un informe que muestre los servicios críticos, los riesgos fuera de tolerancia, las excepciones vencidas, las dependencias de terceros y las decisiones pendientes se acerca mucho más a lo que un órgano de gobierno necesita para ejercer su función.

Para el CISO, esta distinción tiene una consecuencia profesional importante: dejar de ser el propietario informal de todo riesgo digital. Si el área de seguridad aparece como responsable de aceptar cualquier exposición, el negocio puede delegarle de facto una decisión que corresponde a la dirección. GV.RR ofrece una base para corregir ese diseño y documentar qué decisiones pertenecen al propietario del servicio, al comité de riesgos, a la dirección o al consejo.

GV.SC: la cadena de suministro deja de ser una nota al pie

La inclusión explícita de GV.SC no es decorativa. Durante años, muchas organizaciones trataron el riesgo de proveedores como una revisión previa a la contratación: cuestionario, informe SOC, certificado ISO 27001 y poco más. El problema es que el riesgo no termina cuando se firma el contrato. Empieza una relación operativa que puede durar años, cambiar de alcance y acumular subcontratistas.

DORA dedica los artículos 28 a 30 a la gestión del riesgo de terceros proveedores de servicios TIC. El artículo 28 exige que las entidades gestionen el riesgo contractual y operativo, mantengan una estrategia sobre terceros y conserven la responsabilidad por el cumplimiento de sus obligaciones. El artículo 30 establece elementos contractuales esenciales, incluidos derechos de auditoría, acceso a información, asistencia durante incidentes y condiciones de terminación. Para proveedores TIC considerados críticos, el capítulo V introduce además una supervisión específica a escala europea.

GOVERN ayuda a ordenar ese ciclo completo, pero exige salir del enfoque de «vendor due diligence» como trámite de compras. Un programa alineado con GV.SC debería poder contestar, para cada tercero relevante:

• qué servicio empresarial soporta y qué impacto tendría su indisponibilidad;
• qué datos, privilegios, interfaces y ubicaciones están implicados;
• qué subcontratistas intervienen y cómo se controla la cadena posterior;
• qué nivel de resiliencia, notificación y cooperación exige el contrato;
• qué pruebas se realizan y qué deficiencias siguen abiertas;
• qué alternativa existe si el proveedor falla o termina la relación;
• quién acepta el riesgo residual y con qué fecha de revisión.

La pregunta decisiva no es si el proveedor tiene una certificación. Es qué capacidad de recuperación conserva la entidad si el proveedor deja de prestar el servicio durante un periodo relevante. Un certificado puede ser una evidencia útil; no es un plan de salida, una prueba de concentración ni una garantía de que el subcontratista crítico está bajo control.

La Directiva NIS2 también refuerza la lógica de cadena de suministro. Su artículo 21 incluye la seguridad de la cadena de suministro entre las medidas de gestión del riesgo de ciberseguridad. El artículo 23 exige notificación de incidentes significativos a la autoridad competente o al CSIRT en plazos que incluyen una alerta temprana en 24 horas y una notificación de incidente en 72 horas, según las condiciones de la Directiva. Una entidad que depende de proveedores incapaces de aportar información rápida puede incumplir no por su propio centro de operaciones, sino por la opacidad de su ecosistema.

El GDPR aporta otra capa. El artículo 28 exige garantías suficientes por parte del encargado del tratamiento y un contrato que regule, entre otros extremos, seguridad, asistencia y subcontratación. El artículo 32 obliga a valorar medidas apropiadas al riesgo, mientras que el artículo 33 fija, cuando procede, el plazo de 72 horas para notificar una violación de datos personales a la autoridad de control. Si el proveedor informa tarde o de forma incompleta, el responsable del tratamiento sigue teniendo un problema regulatorio. GOVERN hace visible esa dependencia antes del incidente.

La política deja de ser un PDF que nadie consulta

GV.PO suele parecer la parte menos novedosa. Todas las organizaciones tienen políticas. Algunas tienen demasiadas. El problema está en que una política puede existir y no gobernar nada.

Una política útil debe establecer el resultado que se espera, el propietario de la decisión, el ámbito de aplicación, las excepciones y la consecuencia de incumplirla. También debe tener una relación explícita con los riesgos y obligaciones que pretende cubrir. Una regla que exige autenticación multifactor para «sistemas críticos» es débil si nadie ha definido qué es crítico, quién puede conceder una excepción o cuándo debe revisarse.

La diferencia se observa en la gestión de excepciones. En un modelo inmaduro, una unidad solicita una prórroga indefinida porque una aplicación antigua no soporta el control. En un modelo gobernado por GV.PO y GV.RR, la excepción incluye propietario, justificación, riesgo residual, controles compensatorios, fecha de caducidad y autoridad que la aprueba. Si la fecha expira sin renovación, el sistema escala la decisión. No es burocracia: es impedir que una desviación temporal se convierta en arquitectura permanente.

Las políticas también deben hablar el idioma de la empresa. Una norma de clasificación de activos no debería existir aislada de la continuidad de negocio, la protección de datos o la contratación tecnológica. El valor de GOVERN está en conectar documentos que normalmente viven en departamentos distintos y se revisan con calendarios incompatibles.

GV.OV: supervisar no es recibir un cuadro de mando

La supervisión eficaz requiere información que permita actuar. Muchos cuadros de mando fallan porque mezclan indicadores de actividad con indicadores de riesgo y ofrecen una falsa sensación de precisión. «98 % de cobertura de EDR» puede ser una buena noticia o una distracción si el 2 % restante corresponde a los servidores que ejecutan el proceso de liquidación más crítico.

GV.OV debería traducirse en una cadencia de revisión proporcional al riesgo. El comité de dirección puede recibir trimestralmente la evolución de los riesgos estratégicos, pero ciertos eventos requieren escalado inmediato: una intrusión confirmada en un proveedor crítico, una pérdida de una capacidad de recuperación probada, una excepción de control que afecta a un servicio esencial o una concentración no mitigada en un único proveedor.

El cuadro de mando debería combinar al menos cuatro tipos de información:

1. Exposición: servicios críticos, activos sensibles, dependencias externas y vulnerabilidades relevantes.
2. Capacidad: cobertura de controles, preparación de respuesta, resultados de pruebas y disponibilidad de recursos.
3. Decisiones: riesgos fuera de tolerancia, excepciones abiertas, acciones vencidas y responsables.
4. Resultado: incidentes, interrupciones, tiempos de detección, recuperación y lecciones incorporadas.

No se trata de imponer una métrica universal. El CSF 2.0 no prescribe un cuadro de mando único porque el riesgo depende del contexto de la organización. Para un banco minorista, el tiempo de recuperación de una plataforma de pagos puede ser decisivo. Para una aseguradora, la disponibilidad de un sistema de tarificación y la integridad de los datos de pólizas pueden pesar más. Para un proveedor SaaS, la segregación de clientes y la capacidad de rotar credenciales quizá sean indicadores centrales.

La supervisión también debe incluir una comprobación incómoda: si el control se ha probado en las condiciones que importan. Un plan de continuidad validado únicamente con un escenario de caída de un servidor no demuestra resiliencia frente a una cuenta privilegiada comprometida, un ataque de ransomware o la indisponibilidad del proveedor de identidad. La función GOVERN debe cuestionar la calidad del supuesto, no solo registrar que se realizó un ejercicio.

Cómo encaja GOVERN con NIST CSF 2.0 sin crear otra burocracia

El riesgo de adoptar un marco adicional es acabar con una capa más de correspondencias, hojas de cálculo y reuniones. La solución no es ignorar GOVERN, sino usarlo como estructura de conexión.

El CSF 2.0 permite trabajar con Current Profiles y Target Profiles: una fotografía del estado actual y una descripción del resultado deseado. Para un programa europeo de cumplimiento, el perfil actual debería reflejar no solo controles técnicos, sino obligaciones y evidencias. El perfil objetivo debería priorizar las capacidades que reducen riesgos relevantes y cierran brechas regulatorias. La comparación entre ambos perfiles proporciona una base más útil para decidir inversiones que una lista genérica de buenas prácticas.

Una entidad puede, por ejemplo, vincular:

• GV.OC con el inventario de servicios críticos, el registro de actividades de tratamiento y el análisis de impacto de continuidad;
• GV.RM con el apetito de riesgo, el registro de riesgos y la metodología de evaluación de DORA o NIS2;
• GV.RR con el modelo RACI, el reglamento del comité de riesgos y las responsabilidades del órgano de dirección;
• GV.PO con las políticas de acceso, vulnerabilidades, incidentes, continuidad y proveedores;
• GV.OV con los indicadores dirigidos al comité de riesgos, auditoría interna y consejo;
• GV.SC con el inventario de terceros, la clasificación de proveedores TIC, las cláusulas contractuales y las pruebas de salida.

Esta correspondencia no debe convertirse en una promesa de equivalencia legal. Que una práctica esté mapeada a GV.SC no prueba por sí misma el cumplimiento del artículo 30 de DORA. El mapeo sirve para localizar evidencias, asignar propietarios y detectar contradicciones. La obligación sigue siendo la obligación.

También conviene distinguir entre madurez y cumplimiento. El CSF puede ayudar a una organización a progresar desde prácticas informales hasta un programa repetible, adaptable y supervisado. Pero ningún nivel del CSF garantiza que una autoridad considere cumplidos DORA, NIS2 o el RGPD. El regulador mirará la norma aplicable, la evidencia y la eficacia del control, no la elegancia del diagrama.

Qué debería cambiar en la agenda del CISO y del responsable de cumplimiento

La primera decisión es revisar el lenguaje. Si el programa sigue describiéndose como una cartera de herramientas y proyectos, GOVERN no ha hecho su trabajo. La conversación debe pasar a capacidades empresariales, riesgos aceptados, dependencias y decisiones pendientes.

La segunda es identificar los vacíos de autoridad. Para cada riesgo material, pregunta quién puede aceptarlo, quién debe ser informado y qué sucede si el propietario no actúa. Si la respuesta termina en «lo verá el CISO», probablemente hay una asignación defectuosa.

La tercera es rehacer la visión de terceros alrededor de servicios, no de proveedores. Un mismo proveedor puede prestar un servicio de bajo riesgo y otro esencial. Una clasificación única por nombre comercial oculta esa diferencia. El análisis debe partir de la capacidad empresarial soportada, los datos tratados, los privilegios y la posibilidad de sustitución.

La cuarta es revisar las evidencias que llegan a dirección. Sustituye, cuando sea posible, el porcentaje aislado por una explicación causal: qué riesgo se ha reducido, qué permanece fuera de tolerancia, quién debe decidir y qué coste tiene la alternativa. El consejo no necesita saber cuántas reglas tiene el firewall. Necesita saber qué servicio no puede permitirse perder y por qué la exposición restante es aceptable.

La quinta es probar el vínculo entre gobierno y respuesta. Un ejercicio de crisis debería verificar no solo si el equipo técnico puede contener el incidente, sino si la organización sabe quién autoriza apagar un servicio, cuándo se activa la notificación regulatoria, cómo se informa al órgano de dirección y qué proveedor debe aportar datos. El artículo 33 del RGPD, el artículo 23 de NIS2 y las obligaciones de comunicación de DORA hacen que esta coordinación sea una capacidad operativa, no un ejercicio de redacción posterior.

La objeción razonable: ¿no basta con ISO 27001, DORA o NIS2?

La objeción tiene sentido. Una organización regulada no necesita coleccionar marcos como si fueran cromos. ISO 27001 aporta un sistema de gestión certificable; DORA impone requisitos específicos a entidades financieras; NIS2 fija obligaciones para entidades esenciales e importantes; el RGPD regula la protección de datos personales. ¿Para qué añadir NIST CSF 2.0?

La respuesta depende del uso. Si la entidad utiliza el CSF para duplicar controles, la objeción gana. Si lo emplea para ordenar decisiones y conectar obligaciones que ya existen, GOVERN puede actuar como una capa de traducción especialmente útil.

ISO 27001 puede demostrar que existe un sistema de gestión, pero no prescribe por sí sola cómo debe presentarse ante el consejo la concentración en proveedores críticos. DORA tiene requisitos detallados, pero no ofrece necesariamente el lenguaje más manejable para comparar la exposición tecnológica de una entidad con la de otras unidades de negocio. NIS2 establece medidas y responsabilidades, pero una organización multinacional seguirá necesitando una forma común de describir perfiles actuales y objetivos. GOVERN ocupa ese espacio de articulación.

La regla práctica es sencilla: no crear un control porque lo diga el marco; reutilizar un control existente y asignarlo a la decisión que GOVERN exige hacer visible. Si ya existe un proceso de gestión de proveedores, úsalo para demostrar GV.SC. Si ya existe un comité de riesgo tecnológico, comprueba si cubre GV.OV y si tiene autoridad real. Si ya existe un sistema de excepciones, verifica que contiene caducidad y aprobación ejecutiva.

El límite del marco: GOVERN no arregla una mala información

Hay una advertencia que merece más espacio del habitual. Un marco de gobierno no compensa datos deficientes. Si el inventario de activos está incompleto, el mapa de dependencias es ficticio o la clasificación de servicios se basa en opiniones, las decisiones de GOVERN tendrán una precisión teatral.

La calidad mínima de los datos importa especialmente en tres zonas. La primera es la relación entre activos y servicios: no basta saber que existe una base de datos; hay que saber qué proceso depende de ella y qué impacto tiene su indisponibilidad o alteración. La segunda es la cadena de suministro: el proveedor directo puede ocultar una subcontratación crítica. La tercera es la medición de recuperación: un RTO declarado no demuestra que la recuperación sea técnicamente posible bajo presión.

Por eso, el despliegue de GOVERN debe ir acompañado de controles de calidad: propietarios de datos, fecha de actualización, fuente de evidencia, nivel de confianza y tratamiento de conflictos. Una decisión marcada como «aceptada» porque nadie quiso discutirla no es gobierno; es archivo.

También hay que evitar la teatralidad de la madurez. Etiquetar una práctica como «optimizada» no mejora la resiliencia. La prueba está en si la organización puede explicar una decisión difícil y aportar evidencia de que la ejecutó. Si no puede, el nivel de madurez es irrelevante.

La conclusión que incomoda

GOVERN es la novedad más importante del CSF 2.0 porque cambia quién debe sentirse interpelado por el marco. Ya no es solo una herramienta del equipo de seguridad. Es una invitación al consejo, al comité de riesgos, a compras, a continuidad de negocio, a privacidad y a los propietarios de producto para asumir que la ciberseguridad se decide también fuera del SOC.

Su valor para las organizaciones europeas no está en ofrecer otro sello de cumplimiento. Está en ayudar a construir una línea de trazabilidad: una obligación regulatoria conduce a un riesgo; ese riesgo afecta a un servicio; el servicio depende de controles y proveedores; alguien tiene autoridad para decidir; la dirección recibe evidencia y revisa el resultado.

Si esa cadena no existe, la entidad puede tener políticas impecables y seguir operando a base de intuición. Si existe, el CISO deja de ser la persona a la que se envían todos los problemas y pasa a ser quien diseña un sistema para que las decisiones correctas se tomen a tiempo.

La pregunta para 2026 no es si tu organización ha «adoptado» NIST CSF 2.0. Es más concreta: cuando un riesgo tecnológico supera la tolerancia, ¿puedes demostrar quién lo sabe, quién decide, qué alternativa existe y cuándo se revisará? Si la respuesta es no, GOVERN no es una función que falte en el documento. Es la función que falta en el gobierno de la empresa.