Marco organizativo del ENS: políticas, normativa y procedimientos

Cuatro medidas. Solo cuatro de las 73 del Anexo II forman el marco organizativo del ENS — y sin embargo son las que sostienen todo lo demás. La política de seguridad, la normativa, los procedimientos y el proceso de autorización definen quién decide, qué está permitido y cómo se aprueban los sistemas. Cuando fallan, ninguna medida técnica las compensa: un sistema sin gobierno es un sistema sin rumbo, por muy cifrado que esté.

Segundo capítulo de nuestra serie sobre el Esquema Nacional de Seguridad. Aquí bajamos al detalle de las medidas org.1 a org.4: qué exige exactamente cada una, cómo se documentan sin burocracia y qué busca el auditor de conformidad — con la vista puesta, como siempre, en el proveedor tecnológico que necesita cumplir sin montar un ministerio.

1. El marco organizativo dentro del ENS

Recordemos el mapa: el Anexo II del RD 311/2022 organiza sus 73 medidas en tres marcos — organizativo (org), operacional (op) y de protección (mp). El organizativo es el más pequeño en número y el primero en importancia lógica: establece el gobierno de la seguridad del que cuelgan todos los demás. Las cuatro medidas aplican a todas las categorías (básica, media y alta): no hay sistema ENS, por modesto que sea, sin política, normativa, procedimientos y proceso de autorización.

Si vienes del mundo ISO 27001, este marco te resultará familiar: es el equivalente directo de los controles organizativos del Anexo A. La diferencia es de estilo: donde la ISO deja margen («políticas apropiadas al contexto»), el ENS concreta contenidos mínimos que cada documento debe incluir. Menos debate, más checklist — y documentación reutilizable en un 80% si ya tienes el otro marco.

2. org.1 — La política de seguridad

La política es el documento fundacional: la declaración aprobada al máximo nivel que fija objetivos, marco de gobierno y compromiso con la seguridad. El ENS espera de ella unos contenidos mínimos claros:

• Los objetivos y la misión de la organización respecto a la seguridad de la información.
• El marco legal y regulatorio en el que se presta el servicio (el propio ENS, RGPD, normativa sectorial).
• Los roles de seguridad —responsables de la información, del servicio, de la seguridad y del sistema— con sus deberes y la regla de separación entre quien opera y quien supervisa.
• La estructura de gestión: comités o mecanismos de coordinación y cómo se resuelven conflictos.
• Las directrices para estructurar la documentación del sistema (los tres niveles que veremos abajo).

En una entidad pública la aprueba el órgano superior correspondiente; en un proveedor privado, la dirección de la empresa — y conviene que la firma sea visible (CEO, no «el departamento»). Extensión sana: 2-4 páginas. La política no describe cómo se hacen las cosas; declara qué importa y quién responde. El error clásico es convertirla en un manual técnico de 30 páginas que nadie aprueba de verdad ni lee jamás.

3. org.2 — La normativa de seguridad

El segundo nivel documental: la normativa define el uso correcto e incorrecto de los sistemas, equipos e información — lo que en el mundo anglosajón sería la «acceptable use policy» ampliada. Debe cubrir, como mínimo, el uso adecuado de los activos, los deberes y responsabilidades del personal respecto a la seguridad, y las consecuencias del incumplimiento (régimen disciplinario aplicable).

Piezas típicas de la normativa en un proveedor tecnológico: uso de equipos corporativos y teletrabajo, uso del correo y herramientas colaborativas, gestión de credenciales (prohibición de compartirlas, gestor de contraseñas, MFA), clasificación y manejo de la información, uso de servicios cloud aprobados, y política de dispositivos personales si aplica. Cada pieza en una o dos páginas, con lenguaje directo — la normativa la tiene que entender todo el equipo, no solo el responsable de seguridad.

Detalle que el auditor verifica siempre: la normativa debe estar comunicada y aceptada. La evidencia habitual es la aceptación en el onboarding (firma o clic registrado) y los recordatorios en la formación periódica. Una normativa impecable que el equipo no conoce es una no conformidad de manual — la misma «política fantasma» que vimos en el bloque organizativo de la ISO.

4. org.3 — Los procedimientos de seguridad

Tercer nivel: los procedimientos describen cómo se ejecutan las tareas — paso a paso, con responsables y evidencias. El ENS espera procedimientos para las actividades relevantes del sistema: cómo se dan de alta y baja usuarios y accesos, cómo se gestionan los cambios y despliegues, cómo se hacen y prueban las copias de seguridad, cómo se responde a un incidente (con su circuito de notificación), cómo se gestiona el ciclo de vida de soportes y equipos, y cómo se monitoriza el sistema.

La buena noticia para equipos técnicos: si tu operación ya está automatizada y documentada (runbooks, pipelines, plantillas de ticket), tus procedimientos ya existen — solo hay que darles forma referenciable: título, versión, responsable, pasos y evidencia que genera cada ejecución. El formato da igual (Git, Notion, wiki interna) mientras esté controlado: versionado, con dueño y accesible para quien lo necesita.

Consejo de campo: escribe los procedimientos a la altura real de tu operación. Si el procedimiento dice «toda alta de acceso pasa por ticket con aprobación del responsable» y el auditor encuentra altas por mensaje de Slack sin rastro, el problema no es el papel — pero el hallazgo te lo llevas igual. Documenta lo que haces, haz lo que documentas: la regla de oro de toda la serie.

5. org.4 — El proceso de autorización

La medida menos intuitiva para quien viene del sector privado, y una de las más características del ENS: debe existir un proceso formal de autorización que apruebe la entrada en producción de los elementos del sistema — nuevas aplicaciones o servicios, cambios significativos de arquitectura, la utilización de instalaciones, la incorporación de equipos o soportes, y el uso de servicios de terceros (cloud incluido).

Traducido a la práctica de un proveedor tecnológico: antes de que algo relevante entre en producción, alguien con autoridad (el responsable de seguridad, o el del sistema según el reparto de roles) revisa que cumple los requisitos de seguridad y deja constancia de la aprobación. En un equipo con buen flujo de despliegue, esto se materializa de forma natural: la aprobación del PR y el checklist de puesta en producción son el proceso de autorización para cambios ordinarios, y las incorporaciones mayores (un servicio cloud nuevo, una integración con terceros) pasan por una revisión documentada específica.

Lo que el ENS añade respecto a tu flujo actual probablemente sea solo la formalización: quién puede autorizar qué, y dónde queda el registro. Una tabla de «elementos que requieren autorización + autorizador + evidencia» de una página cierra la medida con solvencia.

6. Los roles: la pieza que cruza todo el marco

Aunque los roles se definen en la política (org.1), merecen sección propia porque son el eje del marco organizativo y lo primero que el auditor quiere ver claro. El ENS distingue cuatro:

• Responsable de la información: decide sobre los datos — su valoración en las cinco dimensiones, sus requisitos. En la relación con la administración, este rol suele quedarse en la entidad pública cliente.
• Responsable del servicio: decide sobre el servicio — niveles, disponibilidad requerida, ventanas aceptables. También habitualmente del lado del cliente público.
• Responsable de la seguridad: determina las decisiones de seguridad para satisfacer los requisitos anteriores, supervisa la implantación y reporta. Es el rol que el proveedor suele compartir o asumir operativamente según contrato.
• Responsable del sistema: desarrolla, opera y mantiene el sistema — tu equipo técnico.

La regla innegociable: seguridad y operación separadas — el responsable de la seguridad debe ser distinto del responsable del sistema. En una empresa pequeña esto exige diseño: si tu CTO lidera la plataforma, la función de seguridad la asume otra persona (un lead senior, o un apoyo externo con mandato formal). Documenta el reparto en la política y en el contrato con tu cliente público: la frontera de responsabilidades proveedor-administración es de las primeras cosas que revisa una auditoría de conformidad.

Un matiz práctico sobre el reparto con el cliente: no lo des por entendido. Hemos visto proyectos donde proveedor y entidad asumían cada uno que el otro gestionaba la valoración de la información, y el hueco apareció en auditoría. La herramienta que funciona es una matriz de responsabilidades de una página anexa al contrato: cada rol del ENS, quién lo ejerce, y los puntos de contacto para incidentes y cambios. Cinco minutos de leer, meses de discusiones evitadas — y de paso cumples la parte contractual de op.ext que verás en el próximo capítulo.

7. La pirámide documental completa (y sus plantillas)

Juntando las cuatro medidas, la documentación organizativa del ENS forma tres niveles + registro:

• Nivel 1 — Política (org.1): el qué y el quién. 2-4 páginas firmadas por dirección.
• Nivel 2 — Normativa (org.2): el qué se puede y qué no. 5-8 documentos de 1-2 páginas, aceptados por el personal.
• Nivel 3 — Procedimientos (org.3): el cómo, paso a paso. Vivos, versionados, generando evidencia en cada ejecución.
• Transversal — Autorizaciones (org.4): el registro de aprobaciones de entrada en producción.

Sobre plantillas: la guía CCN-STIC 805 desarrolla específicamente la política de seguridad, y la serie 800 completa da estructura para el resto. Úsalas como esqueleto, no como texto final: el auditor distingue a la primera una política redactada para tu organización de una plantilla con el nombre cambiado — el mismo antipatrón de la «documentación de plantilla» que arruina auditorías ISO.

8. Caso aterrizado: el marco organizativo de una agencia proveedora

Para que no quede abstracto, así resolvió este marco una agencia de desarrollo de 16 personas que mantiene la sede electrónica y varios portales de dos ayuntamientos (sistema de categoría media):

• Política (org.1): tres páginas firmadas por el CEO. Objetivos, marco legal (ENS + RGPD), los cuatro roles con nombres y apellidos —la función de seguridad la asumió una lead senior con el 20% de dedicación, separada del equipo que opera los portales— y la estructura documental. Una tarde de redacción sobre la CCN-STIC 805, dos iteraciones con dirección.
• Normativa (org.2): seis documentos cortos ya existentes en su wiki (equipos y teletrabajo, credenciales y MFA, correo y herramientas, clasificación de información, cloud aprobado, consecuencias), reetiquetados como normativa y con aceptación añadida al onboarding. Los empleados existentes la aceptaron en la formación anual.
• Procedimientos (org.3): sus runbooks de siempre —altas/bajas, despliegues, backups con restauración trimestral, respuesta a incidentes con el circuito de notificación al ayuntamiento— convertidos a formato controlado en el mismo repositorio Git del equipo, con versión y dueño.
• Autorizaciones (org.4): dos vías: los cambios ordinarios quedan autorizados por el flujo de PR + checklist de despliegue (documentado como tal), y las incorporaciones mayores (nuevo servicio cloud, nueva integración) pasan por una plantilla de aprobación de una página que firma la responsable de seguridad. Registro: una carpeta con las plantillas firmadas.

Tiempo total del marco organizativo: unas 30 horas repartidas en tres semanas. En la auditoría de conformidad, cero hallazgos en este bloque — el auditor destacó precisamente que la documentación «olía a real»: versionada donde trabaja el equipo, con registros que se generaban solos.

9. Qué revisa el auditor de conformidad en este marco

• La política: aprobada formalmente, con fecha y firma del nivel adecuado, con los roles definidos y la separación seguridad/operación respetada en la práctica.
• La normativa: cobertura de los usos relevantes, y —sobre todo— evidencia de comunicación y aceptación por el personal.
• Los procedimientos: muestreo puro. Elige dos o tres («enséñame el procedimiento de baja de usuarios y la última baja ejecutada») y comprueba la coherencia procedimiento-registro-realidad.
• Las autorizaciones: el registro de las últimas entradas en producción relevantes con su aprobación. «¿Quién autorizó este servicio cloud y dónde está la constancia?»
• La vigencia: fechas de revisión — documentación de hace tres años sin revisar señala un sistema muerto.

10. Errores típicos del marco organizativo

• La política-manual. Treinta páginas mezclando declaración, normativa y procedimientos. Resultado: nadie la aprueba de verdad, nadie la mantiene y todo cambio menor exige re-aprobación de dirección. Separa los niveles.
• Copiar la política de una administración. Las plantillas públicas están pensadas para entidades públicas; un proveedor que las copia hereda roles y órganos que no existen en su empresa. Adapta el fondo, no solo el membrete.
• Normativa sin aceptación registrada. Existir en la wiki no es comunicar. Onboarding con aceptación + refuerzo anual en formación, con registro.
• El proceso de autorización decorativo. Una tabla preciosa que nadie usa: el último servicio cloud entró en producción porque «lo necesitábamos ya». Integra la autorización en tu flujo real (el ticket de compra, el checklist de despliegue) o no ocurrirá.
• Roles nominales. Un «responsable de seguridad» que no dedica ni una hora al mes. El ENS pide función real con dedicación real — proporcional, pero real.

11. Mini-FAQ del marco organizativo

¿Puedo reutilizar mis políticas ISO 27001 tal cual?

Casi. La base sirve (es el mismo gobierno), pero el ENS pide contenidos mínimos concretos —los cuatro roles con su separación, el marco legal del esquema, la referencia a la estructura documental— y el auditor de conformidad los buscará literalmente. Una pasada de adaptación de unas horas cierra la brecha.

¿Quién debe firmar la política en un proveedor privado?

La dirección efectiva de la empresa — en la práctica, CEO o administrador. La firma de un mando intermedio transmite exactamente el mensaje contrario al que la medida busca: que la seguridad tiene respaldo del máximo nivel.

¿El responsable de seguridad puede ser externo?

Sí, es habitual en pymes: un perfil externo con mandato formal, dedicación pactada y acceso a dirección. Lo que no puede ser es decorativo — debe ejercer la supervisión de verdad y constar en la política y en el reparto contractual con tu cliente.

¿Cada cuánto se revisa esta documentación?

Práctica sana: revisión anual programada de política y normativa (aunque sea para confirmar vigencia, con constancia), y procedimientos actualizados de forma continua conforme cambia la operación. Documentos con fecha de revisión vencida son el hallazgo fácil que ningún auditor perdona.

Conclusión: cuatro medidas, todo el gobierno

El marco organizativo es corto de leer y decisivo de implantar: política que declara, normativa que regula, procedimientos que ejecutan y autorizaciones que controlan la puerta de producción. Para un proveedor tecnológico con buena disciplina operativa, el 80% ya existe en forma de runbooks, flujos de PR y procesos de onboarding — el trabajo es darle la forma documental que el esquema espera y cerrar el reparto de roles con tu cliente público.

En el próximo capítulo entramos en la sala de máquinas: el marco operacional — planificación, control de acceso, explotación, cloud, continuidad y monitorización. Y si te incorporas ahora a la serie, empieza por la guía completa del ENS o, si tu camino es la certificación internacional, por la guía de la ISO 27001.