CCN-STIC 805 ENS. Política de Seguridad de la Información
El documento que el ENS exige primero. Y el que más se copia mal.
♙Miguel Ángel Carriazo
▣18 junio 2026
◷13 min de lectura
LEE ESTA GUÍA CUANDO...
Necesites trabajar sobre política de seguridad 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 805 · Política de seguridad
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 805 marca qué debe contener la Política de Seguridad de la Información que exige el ENS: alcance, principios, estructura de roles y responsabilidades, marco normativo y el modo en que se aprueba y se revisa. Su versión de 2025 la alinea con el modelo de gobernanza actualizado de la 801 y con el RD 311/2022.
Es uno de los primeros documentos del proyecto y un requisito explícito del Esquema. Una política aprobada por el órgano competente es condición para avanzar; sin ella, el resto del expediente cojea. El error habitual es copiar una plantilla genérica sin adaptar alcance ni roles, y que la apruebe el técnico en lugar del órgano de dirección.
El artículo 12 del ENS establece que cada administración pública contará con una política de seguridad formalmente aprobada por el órgano competente. La política debe ser conocida por todas las personas que formen parte de la organización e identificar de forma inequívoca a los responsables de velar por su cumplimiento.
Mi lectura
Una política de seguridad no debería sonar como una introducción genérica a la ciberseguridad.
La política es uno de los documentos más copiados de cualquier sistema de gestión. Frases impecables, compromiso de la dirección, mejora continua y protección de la información. El problema aparece cuando intento utilizarla para entender cómo gobierna esa organización la seguridad y no encuentro ninguna decisión propia.
La 805 debe leerse como una pieza de gobierno. La política establece principios, organización y marco de responsabilidades. No necesita bajar a parámetros técnicos, pero sí debe ser reconocible. Debería explicar qué se protege, quién tiene autoridad, cómo se organiza la función y qué compromisos condicionan las decisiones posteriores.
Si cambio el nombre de la entidad y la política sigue valiendo igual para cualquier empresa, probablemente todavía no cuenta suficiente sobre el gobierno real.
CCN-STIC 805 · Política y gobierno
Cómo una política se traduce en decisiones repetibles
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 política de seguridad parece una pieza institucional, pero también tiene una traducción técnica indirecta. Establece principios, roles y compromisos que después deben reflejarse en procedimientos, criterios de diseño, contratación, tratamiento de riesgos y excepciones. Si la política promete supervisión, gestión de riesgos y revisión periódica, esos compromisos deberían poder reconocerse en los procesos que sostienen el sistema.
Yo la evaluaría no por su retórica, sino por su capacidad de gobierno. ¿Está conectada con el resto de normativa interna? ¿Define responsabilidades de manera reconocible? ¿Condiciona la forma en la que se aprueban excepciones o se priorizan medidas? Una política técnicamente pobre suele quedarse en un manifiesto genérico sin impacto observable.
Cuando el documento está bien planteado, sirve como ancla para explicar por qué existen determinadas obligaciones internas y quién debe responder por ellas.
Cómo comprobaría el despliegue
Trazaría cada compromiso de política hacia normas, procedimientos y controles. Después seleccionaría decisiones reales: excepción, aceptación de riesgo, incorporación de proveedor o cambio sensible. La política debería ayudar a explicar quién decidió y bajo qué criterio.
También revisaría coherencia entre texto, workflows, grupos de aprobación y responsabilidades técnicas.
Error habitual
Dónde suele torcerse en proyectos reales
DONDE SUELE TORCERSE
Copiar una política “correcta” pero intercambiable. Es decir, un texto que suena profesional, cumple con la forma y podría pertenecer a cualquier organización sin necesidad de cambiar más que el logotipo.
El efecto secundario es que la política deja de ser una referencia viva. Nadie la usa para decidir porque no describe realmente el modelo de gobierno de la entidad.
Ejemplo práctico
Cómo lo aterrizaría en un caso real
CASO
Si la política establece que las excepciones de seguridad deben aprobarse formalmente, deberías poder seguir esa promesa hasta un procedimiento, un responsable y una evidencia de casos reales. Si habla de mejora continua, deberías encontrar revisiones, resultados y acciones tomadas. Y si define roles, esos roles deberían aparecer en comités, tickets, cambios o informes.
Mi forma de aterrizarla es muy directa: elegir tres decisiones de seguridad recientes y comprobar si la política ayuda a explicarlas o si en realidad nadie la utiliza para nada.
Ejemplo técnico de infraestructura
La política exige segregación, pero el administrador puede aprobar su propio cambio
EJEMPLO TÉCNICO · INFRAESTRUCTURA
Componentes implicados en el caso
INFRA
La política establece separación de funciones, aunque la herramienta ITSM permite que el mismo administrador cree, apruebe y cierre un cambio urgente sobre infraestructura crítica.
Arquitectura técnica: ITSM, directorio, grupos de aprobación y plataforma administrada. Fallo: el compromiso de política no está reflejado en el workflow ni en los permisos. Evidencia: configuración del proceso, grupos, cambios recientes y excepciones. Qué haría: separar aprobación y ejecución, registrar emergencia, revisión posterior obligatoria y alertar sobre autocierre o autoaprobación.
Pregunta incómoda
¿Qué decisión concreta cambia en la organización porque esta política existe?
NO RESPONDAS CON LA POLÍTICA
Buscaría consecuencias: quién aprueba excepciones, cómo se eleva un riesgo, qué obligación tienen los propietarios, qué principios condicionan diseño y contratación. Si la política solo declara buenas intenciones, su capacidad de gobierno es baja.
También comprobaría que los roles y nombres organizativos siguen vigentes. Una política aprobada hace tres años con comités desaparecidos puede seguir formalmente publicada y haber dejado de describir la realidad.
Ref.
Qué pediría
Qué necesito ver
GR-01
Aprobación
Órgano competente, fecha y versión vigente.
GR-02
Identidad organizativa
Roles, principios y alcance propios de la entidad.
GR-03
Despliegue
Normativa y procedimientos que desarrollan sus compromisos.
GR-04
Revisión
Cambios relevantes que provocan actualizar la política.
Mi enfoque
Cómo la aterrizaría yo en un entorno real
GRCREAL
Leeré primero la política y después pediré que me expliquen el gobierno sin mirar el documento. Las diferencias entre ambos relatos son muy útiles. Si todos describen un modelo que la política no refleja, está desactualizada. Si la política describe un modelo que nadie reconoce, quizá nunca se implantó.
La política no debe impresionar al auditor. Debe orientar a la organización.
Contenido
Qué contiene la guía
El contenido mínimo obligatorio de la Política de Seguridad de la Información.
El alcance, los principios de seguridad y los objetivos.
La estructura de roles y responsabilidades (en coherencia con la 801).
El marco normativo de segundo y tercer nivel (normativa y procedimientos).
El procedimiento de aprobación, comunicación y revisión periódica.
Pautas de elaboración: lenguaje claro, neutralidad tecnológica, adaptabilidad.
Un ejemplo completo de Política de Seguridad (Anexo C) y herramientas para implementarla (Anexo D).
Conceptos
Conceptos clave que debes manejar
Política de Seguridad
Documento de primer nivel que fija principios, alcance y responsabilidades; lo aprueba la dirección. Define el significado de "seguridad de la información" en la organización y tiene carácter de obligado cumplimiento.
Marco normativo en niveles
Política (qué), normativa (qué se debe/no se debe) y procedimientos (cómo). La política es el nivel más abstracto; los procedimientos son los más concretos.
Órgano competente
La instancia con autoridad para aprobar la política; no es el área técnica. En la AGE, cada ministerio aprueba su política (titular del Departamento). Los organismos públicos pueden tener su propia política coherente con la del Departamento del que dependan.
Revisión periódica
La política debe revisarse y mantenerse vigente, no aprobarse y olvidarse. La guía recomienda una revisión regular que adapte la política a nuevas circunstancias técnicas u organizativas.
Alcance
A quién aplica y cuándo entra en juego
Aplica al inicio del proyecto y de forma continua. Es uno de los primeros entregables y un requisito que el auditor comprueba sin falta. Encadena con los roles de la 801 y precede al despliegue de medidas de la 804. La política es obligatoria para todas las entidades del sector público y también para los prestadores privados que provean servicios o soluciones al sector público (art. 2.3 del ENS).
Implantación
Cómo lo implanta una empresa, paso a paso
Redacta con el contenido mínimoParte del índice de contenidos que marca la 805: alcance, principios, roles, marco normativo. No te dejes apartados obligatorios. La guía incluye un ejemplo completo en el Anexo C.
Adapta alcance y roles a tu organizaciónUna política copiada sin adaptar es papel mojado. Concreta el alcance real y los roles según tu estructura (801). La política debe identificar a los responsables de velar por su cumplimiento.
Apruébala en el órgano competenteLa aprobación la hace la dirección/órgano competente, con evidencia (acta), no el técnico. En la AGE, cada ministerio aprueba su política; los organismos públicos pueden tener la suya propia o adherirse a la del Departamento.
Comunícala a la organizaciónDifúndela y asegúrate de que el personal afectado la conoce. Una política que nadie ha visto no protege. Debe ser accesible y conocida por todos los miembros de la organización.
Establece su revisiónFija periodicidad de revisión y responsable. La versión y la fecha deben estar siempre visibles. La política debe adaptarse a nuevas circunstancias técnicas u organizativas.
Auditoría
Para qué sirve en una auditoría
El auditor pedirá la política aprobada y la evidencia de su aprobación.
Verificará que cubre el contenido mínimo y que está vigente.
Comprobará la coherencia con el modelo de roles (801).
Una política genérica, sin alcance ni aprobación, es no conformidad.
La ausencia de revisión periódica también se señala.
El auditor verificará que la política ha sido comunicada y es conocida por el personal.
Serie 800
Relación con otras guías de la serie
CCN-STIC 801801 — Formaliza el modelo de roles y responsabilidades definido en la 801.
CCN-STIC 804804 — Encabeza el marco organizativo de las medidas de implantación.
CCN-STIC 806806 — Es un entregable temprano del Plan de Adecuación.
CCN-STIC 802802 — La auditoría verifica que la política existe y está aprobada.
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
Política de Seguridad ENS
ISO 27001: política de seguridad (5.2)
NIS2: políticas de seguridad de la información (art. 21.2.a)
Aprobación por la dirección
ISO 27001: liderazgo y compromiso (5.1)
DORA: aprobación por el órgano de dirección
Marco normativo en niveles
ISO 27001: información documentada (7.5)
DORA: políticas y procedimientos TIC
Revisión periódica
ISO 27001: mejora continua (10.2)
DORA: revisión periódica del marco de gestión de riesgos
Comunicación a la organización
ISO 27001: concienciación (7.3)
NIS2: cultura de ciberseguridad
Sin humo
Errores típicos
Copiar una plantilla sin adaptar alcance ni roles.
Que la apruebe el técnico y no el órgano competente.
No comunicarla a la organización.
No revisarla nunca tras su aprobación inicial.
Redactarla en lenguaje técnico incomprensible para la dirección y el personal.
No incluir el contenido mínimo exigido por el artículo 12 del ENS.
Checklist
Checklist práctico
Política con el contenido mínimo de la 805 (art. 12 ENS).
Alcance y roles adaptados a la organización.
Aprobada formalmente por el órgano competente.
Comunicada a la organización.
Con periodicidad de revisión y versión visibles.
Incluye los principios básicos del ENS (art. 5 a 11).
Define el marco legal y regulatorio aplicable.
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 Sep 2011, actualizada Jun 2025).
El artículo 12 del ENS establece el contenido mínimo que debe incluir la Política de Seguridad de la Información:
a) Los objetivos o misión de la organización — Describe la razón de existencia de la entidad y los servicios que presta.
b) El marco regulatorio — Normas que afectan a la entidad (ENS, RGPD, NIS2, etc.).
c) Los roles o funciones de seguridad — Define deberes, responsabilidades y el procedimiento de designación y renovación.
d) La estructura del Comité de Seguridad — Composición, ámbito de responsabilidad y relación con otros elementos.
e) Directrices para la estructuración documental — Gestión y acceso a la documentación de seguridad.
f) Los riesgos derivados del tratamiento de datos personales — Integración con RGPD y LOPDGDD.
Además, la política debe desarrollarse aplicando los requisitos mínimos del artículo 12.6: organización e implantación, análisis de riesgos, gestión de personal, control de accesos, protección de instalaciones, adquisiciones, mínimo privilegio, integridad y actualización, protección de la información, prevención ante sistemas interconectados, registro de actividad, incidentes, continuidad y mejora continua.
Principios
Principios básicos del ENS en la política
La guía recuerda que la Política de Seguridad debe reflejar los principios básicos del ENS (artículos 5 a 11):
Art. 5 — Seguridad como un proceso integral: La seguridad debe considerarse en todas las fases del ciclo de vida del sistema.
Art. 6 — Gestión de la seguridad basada en los riesgos: Las medidas de seguridad son proporcionales a los riesgos identificados.
Art. 7 — Prevención, detección, respuesta y conservación: La seguridad actúa en todas las fases del incidente.
Art. 8 — Existencia de líneas de defensa: La estrategia de seguridad se diseña en capas.
Art. 9 — Vigilancia continua y reevaluación periódica: La seguridad se mantiene mediante monitorización y revisiones.
Art. 10 — Diferenciación de responsabilidades: Los roles de seguridad están separados y claramente definidos.
Herramientas
Herramientas para implementar la política (Anexo D)
La guía (tomando referencia del NIST SP 800-100) identifica tres tipos de herramientas para desarrollar la política:
Normas de seguridad (security standards): Uniformizan el uso de aspectos concretos del sistema. Indican el uso correcto y las responsabilidades. Son de carácter obligatorio.
Guías de seguridad (security guides): Tienen carácter formativo y buscan ayudar a los usuarios a aplicar correctamente las medidas de seguridad. Proporcionan razonamientos donde no existen procedimientos precisos.
Procedimientos de seguridad (security procedures): Afrontan tareas concretas, indicando lo que hay que hacer paso a paso. Son útiles en tareas repetitivas.
La guía recomienda distinguir claramente entre lo que es política (abstracta) y su aplicación concreta, para ser más flexible y conseguir uniformidad de resultados incluso cuando cambia la tecnología.
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.