Quién responde de qué. Sin esto, el ENS no tiene dueño.
♙Miguel Ángel Carriazo
▣18 junio 2026
◷14 min de lectura
LEE ESTA GUÍA CUANDO...
Necesites trabajar sobre gobierno y responsabilidades dentro del ENS.
En vez de buscar una frase aislada, sigue el recorrido de la guía y relaciona cada conclusión con el sistema, el responsable y la evidencia que debería existir.
CCN-STIC 801 · Gobierno y responsabilidades
Dónde encaja esta guía en una revisión práctica
Utiliza la guía para orientar la revisión y contrasta siempre la versión vigente en el portal oficial del CCN-CERT.
Qué es
Qué es y para qué vale
La CCN-STIC 801 define el modelo de gobernanza del ENS: los roles obligatorios, qué decide cada uno y cómo deben separarse para que las decisiones de seguridad no recaigan, de facto, en «el de informática». Su actualización de 2025 reordena estos roles alineándolos con los modelos de gobierno de ciberseguridad actuales y con el RD 311/2022.
Es, posiblemente, la guía que más errores estructurales evita. El fallo clásico del sector público y de sus proveedores es que la seguridad «sea cosa de sistemas» y que nadie de negocio asuma la responsabilidad de valorar la información y los servicios. La 801 deja claro que esa valoración es una decisión de negocio, no técnica, y que el Responsable de Seguridad no puede ser la misma persona que el Responsable del Sistema. El ENS exige esta separación, y cuando por ausencia justificada de recursos no pueda cumplirse, se deben aplicar medidas compensatorias para garantizar la finalidad del principio de diferenciación de responsabilidades.
Mi lectura
Los organigramas quedan muy bien hasta que hay que decidir quién firma, quién acepta y quién responde.
La 801 es una de esas guías que parecen «de gobierno» y por eso muchos proyectos la dejan para después. Yo haría lo contrario. Antes de discutir herramientas, medidas o evidencias, necesito saber quién puede tomar una decisión y quién tiene la obligación de mantenerla.
He visto demasiados RACI perfectos donde todos son consultados y nadie decide. También funciones de seguridad que detectan una desviación, la escalan y pasan meses esperando porque el propietario real del riesgo nunca estuvo identificado. La separación de responsabilidades no consiste en repartir nombres por una tabla; consiste en evitar que quien ejecuta, aprueba y revisa una decisión crítica sea siempre la misma persona sin contrapeso.
La 801, leída desde operación, es una guía para seguir la autoridad. Yo cogería una excepción, una aceptación de riesgo o un cambio sensible y reconstruiría quién pudo hacer qué.
CCN-STIC 801 · Autoridad y separación
De la designación formal a la decisión trazable
Lectura técnica GRCREAL: una manera práctica de conectar la guía con arquitectura, operación y evidencia.
Explicación técnica
Qué me interesa técnicamente de esta guía
La 801 tiene un componente organizativo, pero su lectura útil es operativa. Lo que realmente modela es el flujo de autoridad sobre el sistema: quién define el criterio, quién ejecuta, quién supervisa, quién acepta el riesgo y quién responde ante una desviación. Técnicamente esto afecta a segregación de funciones, aprobaciones, control de cambios, gestión de excepciones y tratamiento de incidentes.
Cuando estas fronteras no están claras, aparecen decisiones huérfanas. El equipo técnico detecta el problema pero no puede priorizar inversión; Seguridad recomienda una corrección pero nadie asume la exposición; un proveedor administra un control crítico sin que exista un propietario interno capaz de exigir o revisar su funcionamiento.
Yo leería la guía como un mapa de responsabilidad efectiva. No basta con saber quién es el responsable nominal; necesito ver cómo se materializa en aprobaciones, comités, excepciones y escalados recientes.
Qué revisaría técnicamente
Segregación en cuentas y perfiles, matrices de aprobación, permisos de cambio, ownership de repositorios, trazabilidad de excepciones y capacidad real de escalado. Compararía además el organigrama con los grupos de privilegios y los workflows de aprobación.
Una incoherencia muy reveladora es encontrar a un rol sin autoridad formal pero con privilegios técnicos suficientes para tomar decisiones de facto, o al contrario: un responsable nominal sin acceso a la información necesaria.
Error habitual
Dónde suele torcerse en proyectos reales
DONDE SUELE TORCERSE
Confundir “estar informado” con “tener responsabilidad” y “ser responsable” con “tener autoridad”. Esto crea matrices RACI aparentes donde todos participan y nadie decide. También ocurre lo contrario: un único rol acumula diseño, ejecución y verificación del mismo control, y la organización lo normaliza porque “siempre se ha hecho así”.
El problema no es solo de gobierno. También afecta a la calidad de la evidencia: una misma persona genera el dato, lo aprueba y lo presenta como prueba suficiente.
Ejemplo práctico
Cómo lo aterrizaría en un caso real
CASO
Piensa en una excepción a MFA para un servicio legado. Seguridad puede advertir del riesgo, Infraestructura puede necesitar mantener el servicio y negocio puede presionar por continuidad. La pregunta clave es quién tiene autoridad para aceptar la exposición residual y con qué condiciones temporales.
Si esa decisión no deja trazabilidad clara —fecha, responsable, alcance, controles compensatorios y revisión— la organización no tiene un modelo de responsabilidad robusto, aunque su organigrama parezca impecable.
Ejemplo técnico de infraestructura
Cuenta privilegiada administrada por un proveedor sin propietario interno claro
EJEMPLO TÉCNICO · INFRAESTRUCTURA
Componentes implicados en el caso
INFRA
Un proveedor opera la plataforma de virtualización con una cuenta privilegiada compartida. Seguridad revisa alertas, Infraestructura coordina cambios y Compras gestiona el contrato, pero nadie tiene autoridad explícita para aprobar excepciones o revocar el acceso de emergencia.
Arquitectura técnica: hipervisores, bastión, directorio corporativo, PAM y acceso remoto del proveedor. Fallo: la responsabilidad contractual y la autoridad técnica están separadas sin un workflow común. Consecuencia: privilegios persistentes, baja trazabilidad y respuesta lenta ante una desvinculación o incidente. Qué haría: propietario interno por servicio, cuentas nominativas, acceso JIT, aprobación trazable y revisión periódica de privilegios.
Pregunta incómoda
Cuando el riesgo no se puede cerrar, ¿quién tiene autoridad para aceptarlo?
NO RESPONDAS CON LA POLÍTICA
No me sirve «el comité». Necesito saber qué órgano, qué rol y qué evidencia deja la decisión. Si el responsable de Seguridad recomienda, Sistemas ejecuta y Dirección acepta, esa cadena debe poder verse. Si todo termina en un correo reenviado durante semanas, la responsabilidad existe en el papel pero no en el proceso.
La otra pregunta incómoda es qué ocurre cuando los roles están externalizados. El proveedor puede operar controles, pero la organización sigue necesitando propietarios internos capaces de supervisar y decidir.
Ref.
Qué pediría
Qué necesito ver
GR-01
Designaciones
Nombramientos, alcance y autoridad de los responsables.
GR-02
Decisiones reales
Actas, aceptaciones, excepciones y escalados recientes.
GR-03
Segregación
Conflictos de función identificados y controles compensatorios.
GR-04
Terceros
Responsabilidad interna sobre actividades externalizadas.
Mi enfoque
Cómo la aterrizaría yo en un entorno real
GRCREAL
Elegiría tres decisiones de los últimos seis meses: una aceptación de riesgo, una excepción y un incidente relevante. Seguiría la cadena de responsabilidad completa. Si el rol existe pero nunca aparece en decisiones reales, revisaría el modelo.
La responsabilidad se demuestra en las decisiones difíciles, no en el organigrama.
Contenido
Qué contiene la guía
Los cuatro roles del ENS: Responsable de la Información, Responsable del Servicio, Responsable de la Seguridad y Responsable del Sistema.
La función del Comité de Seguridad y su papel en la gobernanza.
La separación obligatoria entre el Responsable de la Seguridad y el Responsable del Sistema.
El reparto de decisiones: quién valora, quién aprueba, quién opera, quién supervisa.
La articulación de estos roles con la política de seguridad (CCN-STIC 805).
En sistemas que tratan datos personales, la integración del Delegado de Protección de Datos como figura asesora.
Los bloques de responsabilidad: Gobierno (dirección y responsables de información/servicio), Supervisión (Responsable de Seguridad y DPD) y Operativo (Responsable del Sistema).
Conceptos
Conceptos clave que debes manejar
Responsable de la Información
Rol de negocio que decide los requisitos de seguridad de la información y la valora. No es un técnico. Puede ser una persona física o un órgano colegiado (Comité de Seguridad de la Información). Establece los niveles de seguridad en las dimensiones C, I, T y A.
Responsable del Servicio
Define los niveles de servicio requeridos y valora la dimensión de Disponibilidad. Puede coincidir con el Responsable de la Información.
Responsable de la Seguridad
Determina las medidas y supervisa su cumplimiento; debe ser independiente del Responsable del Sistema. Una Instrucción Técnica de Seguridad regulará su certificación. En servicios externalizados, el Responsable de Seguridad actúa como Punto de Contacto (POC).
Responsable del Sistema
Opera el sistema y aplica las medidas; no puede coincidir con el Responsable de la Seguridad. En categoría ALTA, puede suspender temporalmente el tratamiento de información si una auditoría aprecia deficiencias graves.
Alcance
A quién aplica y cuándo entra en juego
Aplica desde el minuto cero de cualquier adecuación. Antes de valorar, implantar o auditar nada, el ENS exige saber quién responde de qué. Es la base sobre la que se construyen la política (805), la valoración (803) y todo el expediente. La guía es de aplicación a todas las entidades del sector público y, en general, a todas las organizaciones comprendidas en el ámbito de aplicación del ENS (art. 2 del RD 311/2022), incluyendo prestadores privados de servicios o soluciones al sector público.
Implantación
Cómo lo implanta una empresa, paso a paso
Nombra los cuatro roles por escritoDesigna formalmente Responsable de la Información, del Servicio, de la Seguridad y del Sistema. Sin nombramiento documentado, el rol no existe a efectos de auditoría. La dirección de la entidad o el órgano competente debe hacer la designación formal.
Separa Seguridad de SistemaAsegúrate de que el Responsable de la Seguridad y el del Sistema son personas distintas. Es un requisito, no una recomendación, y un punto que el auditor verifica siempre. Tampoco debe haber dependencia jerárquica entre ambos.
Sitúa la valoración en negocioEl Responsable de la Información (negocio) valora la información; el del Servicio valora la disponibilidad. Nunca dejes esa decisión en manos del técnico.
Constituye el Comité de SeguridadCrea el Comité, define sus funciones (art. 24 del ENS) y llévalo a acta. Es el órgano donde se aprueban política, riesgos y decisiones relevantes. El Responsable de Seguridad actuará como Secretario.
Comunica y manténComunica los roles a la organización y revísalos cuando cambie la estructura. Roles «de papel» sin vigencia real no sirven.
Auditoría
Para qué sirve en una auditoría
El auditor pedirá los nombramientos formales de los cuatro roles.
Comprobará la separación efectiva entre Seguridad y Sistema.
Verificará que la valoración la ha hecho negocio, no el técnico.
Revisará las actas del Comité de Seguridad como evidencia de gobernanza.
Roles sin nombramiento ni acta se traducen en no conformidades.
Serie 800
Relación con otras guías de la serie
CCN-STIC 805805 — Los roles definidos aquí se formalizan en la Política de Seguridad.
CCN-STIC 803803 — El Responsable de la Información y del Servicio son quienes valoran.
CCN-STIC 802802 — La auditoría verifica que el modelo de responsabilidades es real y está vigente.
Mapeo
Equivalencia con otros marcos
Cómo se conecta esta guía con los marcos que probablemente ya manejas:
Aspecto en el ENS
ISO 27001
NIS2 / DORA
Responsable de la Seguridad
ISO 27001: liderazgo y roles (5.1, 5.3)
NIS2: responsabilidad del órgano de dirección (art. 20)
Comité de Seguridad
ISO 27001: revisión por la dirección (9.3)
DORA: órgano de dirección y riesgo TIC (art. 5)
Separación de funciones
ISO 27001: A.5.3 (segregación de funciones)
DORA: gobernanza y segregación
Modelo de gobernanza en tres bloques
ISO 27001: contexto y liderazgo (4, 5)
NIS2: estructura de gobierno de ciberseguridad
Sin humo
Errores típicos
Que el Responsable de Seguridad y el del Sistema sean la misma persona (viola el artículo 11 del ENS).
Dejar la valoración de la información en manos del área técnica.
Roles «de papel» sin nombramiento, acta ni vigencia.
No constituir el Comité de Seguridad o no documentar sus decisiones.
No considerar al Delegado de Protección de Datos cuando se tratan datos personales.
Que el Comité de Seguridad no tenga actas que reflejen las decisiones en materia de seguridad.
Checklist
Checklist práctico
Los cuatro roles ENS están nombrados por escrito.
Seguridad y Sistema están separados en personas distintas.
Existe Comité de Seguridad con actas.
Negocio (no TI) ha valorado la información y los servicios.
Los nombramientos están vigentes y comunicados.
La política de seguridad refleja el modelo de responsabilidades.
En servicios externalizados, el CSP tiene un Punto de Contacto (POC) designado.
Cuando se tratan datos personales, el DPD asesora en el análisis de riesgos.
Ficha
Ficha y enlace oficial
Esta es una lectura práctica de GRCreal, no la guía oficial. Consulta siempre la versión vigente en el portal del CCN-CERT, ya que estas guías se actualizan periódicamente (esta ficha: publicada Abr 2010, actualizada Jun 2025).
La guía también define la figura del Administrador, que puede depender funcionalmente del Responsable del Sistema o del Responsable de la Seguridad, pero no de ambos simultáneamente.
Administrador del Sistema: implementa, gestiona y mantiene las medidas de seguridad aplicables; aplica los Procedimientos Operativos de Seguridad (POS); informa al Responsable del Sistema de cualquier anomalía o vulnerabilidad.
Administrador de Seguridad: comprueba que los controles de seguridad se observan; gestiona autorizaciones y privilegios de usuarios; monitoriza el estado de seguridad; informa al Responsable de la Seguridad.
En sistemas complejos pueden existir administradores delegados, que dependen funcionalmente del administrador que los designa.
El número de personas con derechos de administración debe ser lo más reducido posible, siempre que no menoscabe la usabilidad del sistema.
Los administradores no deben tener capacidad para autorizarse a sí mismos ni para modificar datos de explotación si son desarrolladores.
RGPD y NIS2
Concurrencia con otras normativas
La CCN-STIC 801 también aborda cómo encaja el modelo de gobernanza del ENS con otras normas que pueden aplicar a la entidad.
RGPD: cuando se tratan datos personales, el Responsable de Seguridad debe contar con el asesoramiento del Delegado de Protección de Datos (DPD). El DPD puede coincidir con el Responsable de Seguridad en organizaciones pequeñas, siempre que se garantice su independencia y ausencia de conflicto de intereses. En estos casos, deberá documentarse la excepción y las medidas que garantizan la independencia del DPD.
NIS2: el Responsable de Seguridad del ENS puede desplegar las funciones del Responsable de Seguridad de la Información exigidas por la Directiva NIS2, cuando cuente con habilitación suficiente. Las funciones deberán tener en cuenta las regulaciones de la Directiva NIS2 y la normativa nacional de transposición.
Inteligencia Artificial: para sistemas de IA de alto riesgo, el Responsable de Seguridad deberá conocer el sistema antes de su implementación y valorar los riesgos de seguridad, en coordinación con el resto de roles (Responsable de la Información, del Servicio, del Sistema y DPD).
Infraestructuras Críticas: cuando el sistema contribuya a servicios esenciales de terceros, deberán añadirse medidas adicionales requeridas por la normativa de infraestructuras críticas (Ley 8/2011, de 28 de abril).
Seguridad Física: el Responsable de Seguridad Física adoptará las medidas que le competan, informando al Responsable de Seguridad de la Información de su grado de implantación, eficacia e incidentes.
Riesgos y RACI
Gestión de riesgos y matriz RACI
La guía incluye un proceso detallado de gestión de riesgos y una matriz RACI (Responsible, Accountable, Consulted, Informed) que asigna responsabilidades a cada rol.
Propietario del riesgo: el Responsable de la Información es propietario de los riesgos sobre la información; el Responsable del Servicio, de los riesgos sobre los servicios.
Monitorización del riesgo: el Responsable de la Seguridad monitoriza el riesgo y reporta desviaciones significativas.
Aceptación del riesgo residual: debe ser formalizada por los responsables de la información y del servicio antes de que el sistema entre en operación.
Matriz RACI: la guía proporciona una matriz orientativa que asigna responsabilidades (A-Responsable último, R-Ejecuta, C-Consultado, I-Informado) para tareas como valoración, análisis de riesgos, declaración de aplicabilidad, configuración de seguridad, aceptación del riesgo residual y suspensión cautelar del servicio.
La suspensión cautelar del servicio debe ser una respuesta ágil y de corta duración; si es prolongada, debe ser aprobada por la Dirección de la organización.
Ficha y enlace oficial
Contrasta esta lectura con la publicación del CCN-CERT
La guía oficial sigue mandando. Aquí queda la ficha documental y el acceso directo a la fuente para cerrar la lectura con el contraste adecuado.
ℹ️ Resumen práctico de GRCreal. Consulta siempre la versión oficial vigente en el portal del CCN-CERT.
Resumen realizado a fecha 29/06/2026 con la información disponible en https://www.ccn-cert.cni.es/es/guias.html. Las fechas de publicación y actualización proceden del portal oficial.