~/blog $ cat ens-ayuntamiento-pequeno.mdx

Esquema Nacional de Seguridad en un ayuntamiento pequeño: qué implica de verdad

28 · 08 · 2026 12 min de lectura #ayuntamientos #seguridad

La conversación siempre empieza igual: «nos han dicho que tenemos que cumplir el ENS y no sabemos ni por dónde». A veces lo ha dicho la diputación, a veces el auditor, a veces un proveedor que quiere vender un certificado. Este artículo es lo que le contamos a un ayuntamiento de dos mil, cinco mil o quince mil habitantes cuando nos lo pregunta, escrito desde el lado de quien construye software para ayuntamientos y tiene que acreditar su parte.

No es un manual de seguridad informática. Es el mapa de qué os obliga, quién firma cada cosa y dónde está el gasto real.

Qué es el ENS y por qué os afecta aunque no tengáis informático

El Esquema Nacional de Seguridad está regulado por el Real Decreto 311/2022, de 3 de mayo, que sustituyó al de 2010. Su artículo 2.1 dice que se aplica «a todo el sector público, en los términos en que este se define por el artículo 2 de la Ley 40/2015». Las entidades locales están dentro de esa definición. No hay umbral de habitantes, ni de presupuesto, ni de número de equipos.

Lo segundo que conviene saber es que el reloj ya corrió. La disposición transitoria única dio veinticuatro meses a los sistemas que existían cuando entró en vigor la norma —el 5 de mayo de 2022— para alcanzar su plena adecuación. Ese plazo venció en mayo de 2024. Los sistemas nuevos, en cambio, deben nacer ya conformes.

Y lo tercero, que es donde se rompen las expectativas: el ENS no es un producto. No se compra un antivirus y se cierra el expediente. Es un sistema de gestión: papeles, decisiones y revisiones periódicas, con una parte técnica detrás. La mayor parte del trabajo del primer año es organizativa.

Lo primero no es técnico: es decidir quién responde de qué

El artículo 13 del real decreto reparte el proceso de seguridad entre cuatro figuras diferenciadas. En un ayuntamiento pequeño la reacción natural es asignárselas todas a la misma persona, y ahí hay un límite legal.

La regla que casi todo el mundo incumple sin saberlo está en el artículo 13.3: el responsable de la seguridad será distinto del responsable del sistema, y no debe existir dependencia jerárquica entre ambos. Si la misma persona instala los servidores y certifica que están bien instalados, no hay control. La norma prevé excepciones motivadas con medidas compensatorias, pero es una excepción documentada, no el punto de partida.

Encima de los cuatro roles va la política de seguridad, que el artículo 12 exige aprobar formalmente en cada órgano o entidad con personalidad jurídica propia. Y aquí está la única buena noticia de verdad de todo el artículo:

Esa frase, combinada con el artículo 36.1.g) de la Ley 7/1985 —que atribuye a las diputaciones «la prestación de los servicios de administración electrónica y la contratación centralizada en los municipios con población inferior a 20.000 habitantes»—, es la vía realista para un ayuntamiento sin departamento de informática. La primera llamada no es a un consultor: es a la diputación, a preguntar qué tienen montado y a qué se pueden adherir. Muchas tienen política común, herramientas y hasta el plan de adecuación redactado.

Lo que no desaparece con esa adhesión es la titularidad. El ayuntamiento sigue siendo el responsable de su información y de sus servicios, aunque la infraestructura la opere otro.

Categorizar el sistema: BÁSICA, MEDIA o ALTA

La categoría es la pieza que determina cuántas medidas hay que aplicar y cuánto cuesta acreditarlo. Se fija con el procedimiento del anexo I del real decreto, valorando el impacto que tendría un incidente sobre cinco dimensiones: disponibilidad, autenticidad, integridad, confidencialidad y trazabilidad. La categoría del sistema es la más alta de las que salgan.

Un detalle importante para no delegar esto por comodidad: según el artículo 41, la facultad de efectuar esas valoraciones corresponde al responsable o responsables de la información o servicios afectados. Es decir, al ayuntamiento. No la fija el proveedor, ni el auditor.

La expectativa realista en un ayuntamiento es que el sistema que sostiene la sede electrónica, el registro y el padrón salga MEDIA. Es exactamente lo que asume el perfil de cumplimiento del Centro Criptológico Nacional para municipios de menos de 20.000 habitantes. Conviene decirlo pronto porque cambia el presupuesto: MEDIA significa auditoría de tercero, no autoevaluación.

Y una advertencia que ahorra disgustos: categorizar a la baja para evitar la auditoría no sale bien. La valoración tiene que sostenerse por escrito frente a un auditor, y no se sostiene explicando que la caída del padrón durante una semana sería un perjuicio meramente limitado.

Los perfiles de cumplimiento: la parte que hace esto asumible

Aplicar el catálogo completo del anexo II a un ayuntamiento de tres mil habitantes sería absurdo, y la norma lo prevé. El artículo 30 permite implementar perfiles de cumplimiento específicos «en virtud del principio de proporcionalidad», con el conjunto de medidas que resulten idóneas para una categoría concreta, y encarga al Centro Criptológico Nacional validarlos y publicarlos.

Para entidades locales existen ya, dentro de la serie de guías CCN-STIC 800:

• CCN-STIC 883A — perfil para ayuntamientos de menos de 5.000 habitantes, pensado para los que tienen recursos muy limitados.
• CCN-STIC 883B — perfil para ayuntamientos de menos de 20.000 habitantes, con necesidades de categoría MEDIA.
• CCN-STIC 883C — perfil para el tramo de 20.000 a 75.000 habitantes.
• CCN-STIC 890A — perfil de requisitos esenciales, el suelo por el que empezar cuando no hay nada hecho.

Estos perfiles funcionan en los dos escenarios habituales: cuando el servicio lo presta directamente el ayuntamiento y cuando lo presta por él la diputación, el cabildo o el consejo insular. Si vais a contratar consultoría, la primera pregunta es cuál de estos perfiles va a usar. Si no sabe contestarla, seguid buscando.

Los seis papeles que hay que tener

Esto es lo que un auditor pide ver, en este orden:

1. Política de seguridad aprobada por el órgano competente (artículo 12), propia o la común de la entidad provincial.
2. Nombramiento de los cuatro responsables, por escrito y con la separación del artículo 13.3 respetada o motivada.
3. Análisis de riesgos, que es el que justifica todo lo demás y hay que repetir cuando cambia algo relevante.
4. Declaración de aplicabilidad, que es el documento clave y lleva firma nominativa.
5. Plan de adecuación y de mejora continua: el artículo 27 exige que el proceso de seguridad se actualice y mejore de forma continua.
6. Procedimiento de gestión y notificación de incidentes.

Sobre los incidentes: el artículo 33 obliga a las entidades públicas a notificar al Centro Criptológico Nacional aquellos incidentes que tengan un impacto significativo, a través del CCN-CERT. Las entidades del sector privado notifican al INCIBE-CERT. Escribir ese procedimiento cuesta una tarde; improvisarlo con los servidores ya cifrados, mucho más.

Y hay una obligación periódica que se olvida siempre: el artículo 32 articula la recogida de información sobre el estado de la seguridad, que en la práctica se canaliza a través de la plataforma INES del Centro Criptológico Nacional. Es un cuestionario, no una auditoría, pero hay que rellenarlo.

Herramientas gratuitas que ya tenéis pagadas

El Centro Criptológico Nacional pone a disposición de las administraciones un conjunto de herramientas sin coste de licencia que cubren buena parte del ciclo: PILAR para el análisis de riesgos, AMPARO para la implantación y la declaración de aplicabilidad, CLARA para auditar la configuración técnica de los equipos, ANA para automatizar auditorías, INES para el informe del estado de la seguridad y LUCIA para la gestión y notificación de incidentes. Hay además formación específica para entidades locales sobre el perfil de requisitos esenciales. Antes de contratar plataformas, merece la pena mirar esto.

Autoevaluación o auditoría: la diferencia que decide el presupuesto

Es la pregunta que de verdad importa cuando hay que consignar una partida. La respuesta está en el artículo 38.1:

A eso se añade el artículo 31.1, que exige una auditoría regular ordinaria al menos cada dos años para los sistemas incluidos en el ámbito de aplicación, más una auditoría extraordinaria siempre que se produzcan modificaciones sustanciales que puedan repercutir en las medidas de seguridad. Cuando concurren impedimentos de fuerza mayor no imputables a la entidad, el plazo puede extenderse tres meses.

Dos consecuencias prácticas:

• Esto no es un gasto de una sola vez. Es un ciclo bianual. Consignadlo como tal y no como una inversión puntual de un ejercicio.
• La conformidad se publica. El artículo 38.2 obliga a dar publicidad a las declaraciones y certificaciones de conformidad en los portales de internet o sedes electrónicas correspondientes. La certificación, según la instrucción técnica de seguridad que regula la materia, tiene una vigencia de dos años salvo que sea necesaria una auditoría extraordinaria.

Lo que os afecta al contratar (y a nosotros también)

Aquí es donde el ENS deja de ser un asunto interno. El artículo 2.3 extiende la norma a las empresas privadas que trabajan para vosotros:

Y añade que esa cautela «se extenderá también a la cadena de suministro de dichos contratistas», en la medida en que sea necesario según el análisis de riesgos. Traducido: no basta con que vuestro proveedor esté conforme; también importa dónde aloja los datos y con quién.

De ahí salen tres cosas que deben ir en el pliego —cómo se redactan las tenéis en cómo redactar el pliego técnico de una app municipal—:

• Exigencia expresa de conformidad con el ENS del servicio contratado, con la categoría que corresponda y el medio de acreditarlo.
• Declaración de subcontratistas e infraestructura: quién opera qué y en qué país están los datos.
• Obligación de notificar incidentes al ayuntamiento sin dilación, con contacto y plazo, para que podáis cumplir el artículo 33 en tiempo.

La duda que más se repite: el certificado del proveedor no os certifica a vosotros. Son dos conformidades distintas. La suya es un requisito que exigís; la vuestra es la del sistema de información municipal. Hay quien vende la primera como si resolviera la segunda.

Los cinco errores que vemos una y otra vez

• Creer que con el certificado del proveedor está hecho. Ya está explicado arriba, pero es, de largo, el primero.
• Certificar «la app» o «la web» en vez del sistema. El alcance se define sobre información y servicios, no sobre una pieza suelta de software.
• Nombrar a la misma persona responsable de seguridad y del sistema. Choca con el artículo 13.3 y sale en la primera auditoría.
• Bajar la categoría para ahorrarse la auditoría. Hay que sostenerlo por escrito, y no se sostiene.
• Tener los papeles impecables y las copias de seguridad sin probar. Es el error más caro de todos: el expediente aguanta la auditoría y no aguanta un cifrado un martes por la mañana. Copias probadas, doble factor en los accesos administrativos y actualizaciones al día valen más que cualquier carpeta.

Qué cuesta y cuánto tiempo lleva

Damos rangos porque es lo que hacemos siempre, con una advertencia: son órdenes de magnitud de mercado, no un presupuesto. Dependen del tamaño, de cuántos sistemas haya y, sobre todo, de cuánto asuma la diputación.

En plazo: entre cuatro y ocho meses desde que se arranca en serio hasta tener la declaración o la certificación, y la mayor parte de ese tiempo no es trabajo técnico. Es esperar a plenos, a nombramientos y a que cada área conteste qué datos maneja.

Si estáis mirando también el coste anual del resto de la digitalización, la cuenta completa está en cuánto cuesta mantener una app municipal al año, y las vías de financiación en subvenciones de digitalización para ayuntamientos.

Cómo lo planteamos nosotros

No somos una consultora de ENS y no vendemos certificaciones. Hacemos la parte que nos toca como proveedores: entregar el software con los datos alojados en la Unión Europea, documentar qué trata cada componente, declarar los subencargados y responder por escrito al cuestionario que os pase vuestro auditor o vuestra diputación. Cuando redactáis el pliego, os decimos qué cláusulas de seguridad tienen sentido pedir y cuáles solo encarecen sin aportar.

Es la misma lógica del artículo sobre RGPD en una app municipal: lo barato es decidirlo antes de escribir código. Y si estáis evaluando proveedores, las preguntas que conviene hacer están en qué preguntarle a un proveedor antes de firmar.

Preguntas frecuentes