La respuesta corta
Si construyes software para una administración pública española, el Esquema Nacional de Seguridad te aplica a ti también, no solo a tu cliente.
El Real Decreto 311/2022 lo dice explícitamente: entra en su ámbito «los sistemas de información de las entidades del sector privado… cuando… presten servicios a las entidades del sector público para el ejercicio por estas de sus competencias». Y añade la consecuencia contractual: los contratos públicos deben exigir conformidad con el ENS y extender esos requisitos a la cadena de suministro según el análisis de riesgos.
Traducido: no es un anexo del pliego que rellena el cliente. Es un requisito que condiciona cómo construyes, qué documentas y qué entregas.
Lo primero: la categoría
El ENS clasifica los sistemas en tres categorías —BÁSICA, MEDIA y ALTA—, y la categoría se determina valorando el impacto potencial sobre cuatro dimensiones: disponibilidad, integridad, confidencialidad y autenticidad.
- BÁSICA: impacto limitado.
- MEDIA: impacto significativo en las operaciones.
- ALTA: sistemas críticos cuyo fallo afecta gravemente a los objetivos de la organización.
Esa categoría no la decides tú: la determina el responsable del sistema en el organismo, y de ella depende todo lo demás. Es la primera pregunta de la primera reunión, y sorprende la frecuencia con la que nadie la ha hecho.
Qué cambia según la categoría: la conformidad
Aquí está la diferencia que más afecta al calendario y al presupuesto:
| Categoría | Cómo se acredita |
|---|---|
| ALTA y MEDIA | Auditoría de certificación |
| BÁSICA | Autoevaluación declarativa |
Y la periodicidad: auditoría regular al menos cada dos años. Las declaraciones de conformidad se publican en portales públicos.
Es decir: si el sistema es de categoría media o alta, hay un auditor externo mirando, con su calendario y sus hallazgos. Planificar el proyecto sin reservar tiempo para eso es planificarlo mal.
Los principios que se traducen en decisiones de arquitectura
El ENS establece principios básicos —seguridad como proceso integral, gestión basada en riesgos, prevención, detección y respuesta, líneas de defensa múltiples, vigilancia continua, reevaluación periódica y diferenciación de responsabilidades— y un conjunto de requisitos mínimos que incluye política de seguridad formal, organización de roles, gestión de riesgos, gestión de personal, control de accesos, protección de instalaciones, integridad de los sistemas, protección de la información, gestión de incidentes y continuidad de la actividad.
Para un equipo que construye una app, eso se traduce en cosas muy concretas:
- Control de accesos con roles definidos, y el principio de mínimo privilegio aplicado también a vuestro equipo.
- Trazabilidad: registros de acceso y de acción, con retención decidida y protegidos frente a modificación.
- Gestión de identidades documentada: quién da de alta, quién revoca, en cuánto tiempo.
- Cifrado en reposo y en tránsito, con gestión de claves separada de los datos.
- Gestión de incidentes con procedimiento escrito y responsable nombrado, no un canal de chat.
- Continuidad: copias, restauración probada y tiempos objetivo acordados.
- Diferenciación de responsabilidades: quién decide, quién opera y quién audita no pueden ser la misma persona.
Lo que hay que entregar, además del software
Esta es la parte que casi nunca está presupuestada y suele costar tanto como un módulo funcional:
- Documentación de arquitectura y de flujos de datos.
- Análisis de riesgos del sistema, o la aportación técnica al que hace el organismo.
- Evidencias de las medidas implantadas, en el formato que pida el auditor.
- Procedimientos operativos: despliegue, gestión de cambios, respuesta a incidentes.
- Registro de accesos consultable.
Y una honestidad que conviene poner por escrito desde la oferta: la certificación la obtiene el sistema del organismo, no el proveedor de desarrollo. Vosotros entregáis el sistema y las evidencias que la sostienen. Un proveedor que promete «te certifico el ENS» está vendiendo algo que no le corresponde.
Errores caros
- Descubrir la categoría tarde. Un sistema que resulta ser MEDIA cuando ya está construido implica rehacer decisiones de arquitectura, no añadir un módulo.
- Confundir ENS con RGPD. Son cosas distintas y ambas aplican. Uno protege el sistema; el otro, los datos personales.
- Tratar la documentación como el último sprint. Se genera durante el proyecto o se inventa al final, y un auditor distingue las dos cosas.
- Olvidar la cadena de suministro. Si usáis servicios de terceros, entran en el análisis. Esa dependencia hay que declararla antes, no cuando el auditor la encuentre.
Antes de estimar
- ¿Qué categoría tiene el sistema, y quién la ha determinado?
- ¿Hay ya política de seguridad y análisis de riesgos del organismo a los que engancharse?
- ¿Quién es el responsable de seguridad del cliente y cuándo entra en el proyecto?
- ¿Qué evidencias exige su auditor, y en qué formato?
- ¿Qué servicios de terceros vamos a usar, y encajan en el ámbito?
Las cinco son del cliente y las cinco cambian el presupuesto. La primera lo cambia por un múltiplo.
Es parte del trabajo previo en cualquier proyecto de apps para el sector público: saber en qué régimen estás antes de decidir cómo se construye.
Fuente primaria, consultada el 14 de agosto de 2026: Real Decreto 311/2022, por el que se regula el Esquema Nacional de Seguridad.
