El Esquema Nacional de Seguridad obliga a definir y mantener la seguridad de determinados sistemas de información del sector público y de sus proveedores. Para decidir qué exige a una organización hay que identificar el sistema afectado, su relación con el servicio público, su categoría y la vía de conformidad. Una certificación comercial, un contrato público o la presencia de datos personales, considerados aisladamente, no resuelven esas cuatro cuestiones.
Esta guía se apoya en el Real Decreto 311/2022, en su texto consolidado, comprobado el 28 de septiembre de 2026. Su finalidad es ayudar a preparar el alcance, las responsabilidades y las evidencias. La decisión sobre un expediente concreto requiere también sus pliegos, las instrucciones técnicas aplicables y las características reales del sistema.
A qué sistemas se aplica el ENS
El artículo 2 comprende el sector público definido por la Ley 40/2015. También alcanza a sistemas de entidades privadas cuando, conforme a la normativa aplicable y a una relación contractual, prestan servicios o proporcionan soluciones a entidades públicas para el ejercicio de sus competencias y potestades. Por tanto, el análisis del proveedor empieza por la prestación y sus sistemas de soporte. No se extiende automáticamente a cualquier departamento o producto de la misma sociedad.
Los pliegos deben recoger los requisitos necesarios para asegurar la conformidad de los sistemas que sustentan los servicios contratados, incluida la presentación de declaraciones o certificaciones. El análisis puede alcanzar la cadena de suministro cuando resulte necesario según los riesgos. Un proveedor principal no debería dar por resuelto este punto porque un subcontratista tenga un certificado: debe comprobar qué sistema cubre, qué servicios aparecen en el alcance y qué responsabilidades conserva cada parte.
Pensemos en una empresa que ofrece un portal municipal y, además, una aplicación comercial independiente. El expediente del portal exige estudiar la aplicación, su alojamiento, los administradores, las integraciones y la recuperación del servicio. La aplicación comercial no queda incluida por compartir accionistas. Sin embargo, si ambos servicios utilizan la misma administración privilegiada o infraestructura, esa dependencia puede afectar al perímetro y a las medidas del sistema público.
La delimitación tiene consecuencias económicas y operativas. Un alcance demasiado estrecho deja fuera funciones que pueden comprometer el servicio; uno artificialmente amplio incorpora entornos que no aportan valor a esa evaluación. Conviene conservar un diagrama comprensible, un inventario de activos y una explicación de las exclusiones. El contrato y la arquitectura deben describir la misma realidad.
Cómo se determina la categoría
El ENS diferencia las categorías BÁSICA, MEDIA y ALTA. No equivalen a tamaños de empresa ni a una clasificación automática de los datos. El anexo I examina las consecuencias de un incidente sobre disponibilidad, autenticidad, integridad, confidencialidad y trazabilidad. Para cada dimensión se valora si el perjuicio sería limitado, grave o muy grave; la categoría del sistema viene determinada por el nivel más elevado obtenido.
La evaluación debe explicar los efectos sobre las funciones de la organización, sus activos, el cumplimiento de obligaciones y los derechos de las personas. Decir que una plataforma es «crítica» sin describir esos efectos dificulta justificar la categoría. Resulta más útil explicar cuánto tiempo podría interrumpirse el servicio, qué decisiones quedarían afectadas o qué consecuencias tendría atribuir una actuación a una persona equivocada.
Tratar datos personales no impone por sí mismo una categoría ALTA. Tampoco un volumen reducido permite concluir que el sistema es BÁSICO. Una herramienta pequeña puede sostener una función de elevada importancia, mientras que una plataforma grande puede tener impactos diferentes según sus dimensiones. La categorización debe revisarse al menos una vez al año y cuando se produzcan modificaciones relevantes, conforme al anexo I.
Debe distinguirse esa categoría del análisis de riesgos. La primera expresa las consecuencias que justifican una exigencia de seguridad; el segundo estudia amenazas, vulnerabilidades y medidas en el contexto concreto. Una clasificación correcta no demuestra que los accesos estén controlados o que una copia de seguridad pueda recuperarse. Ambos trabajos se necesitan y deben mantener una relación coherente.
Responsabilidades y decisiones que deben quedar claras
Los artículos 11 y 13 distinguen responsables de la información, del servicio, de la seguridad y del sistema. Los primeros determinan los requisitos de protección de la información y del servicio. El responsable de seguridad decide y supervisa las medidas dentro de su función. El responsable del sistema desarrolla, opera y mantiene el sistema, aplicando las medidas correspondientes.
La función de seguridad debe diferenciarse de la responsabilidad sobre la prestación y operación del sistema. El real decreto prevé la separación entre responsable de seguridad y responsable del sistema, sin dependencia jerárquica entre ambos. Las excepciones por falta justificada de recursos requieren medidas compensatorias documentadas. No basta con poner cuatro nombres en un organigrama si una misma persona aprueba y ejecuta todas las decisiones sin mecanismos de control.
Cuando se externaliza un servicio debe identificarse el punto de contacto de seguridad del proveedor, salvo la justificación prevista en el artículo 13. La externalización no desplaza la responsabilidad última de la entidad pública. Por eso el contrato necesita establecer cómo se comunican incidentes, quién autoriza cambios sensibles y cómo se entrega la información necesaria para supervisar el servicio.
El delegado de protección de datos cumple otra función. Asesora y supervisa el cumplimiento de protección de datos; no sustituye automáticamente al responsable de seguridad ni asume la operación del sistema. Si una persona reúne funciones, debe evaluarse su compatibilidad y evitar que supervise decisiones propias que generen conflicto de intereses.
De los riesgos a la declaración de aplicabilidad
El artículo 14 exige una gestión de riesgos proporcionada mediante una metodología reconocida internacionalmente. No convierte una marca de herramienta o una única metodología en la solución obligatoria para cualquier organización. La elección debe permitir entender los activos, los escenarios relevantes, las medidas existentes y el riesgo que permanece después de aplicarlas.
La declaración de aplicabilidad identifica las medidas y refuerzos del anexo II que corresponden al sistema. Es una pieza técnica de justificación, distinta de la declaración de conformidad. Debe relacionarse con la categoría, el análisis de riesgos y las características del servicio, y estar firmada por el responsable de seguridad. Una lista marcada sin evidencias no demuestra que las medidas funcionen.
El artículo 28 permite medidas compensatorias cuando se justifica documentalmente que protegen igual o mejor, respetando los principios y requisitos mínimos. Esa posibilidad no equivale a excluir controles por comodidad. Hay que identificar la medida sustituida, explicar la alternativa, valorar su efecto y obtener la aprobación formal correspondiente. El auditor debe poder seguir esa relación sin reconstruirla a partir de conversaciones.
Por ejemplo, una aplicación heredada puede no admitir directamente un mecanismo de autenticación previsto en el diseño objetivo. La evaluación tendría que estudiar el acceso mediante una pasarela, la restricción de redes, la administración privilegiada y la supervisión. La aceptación depende de la protección obtenida y de la justificación, no de que el software sea antiguo. También debe fijarse quién revisará la solución si cambia la exposición.
Qué evidencias conviene preparar
Cuando el sistema usa repositorios para producir configuraciones o aplicaciones, documente también qué ramas permiten llegar al despliegue. La ficha de cobertura de protección de ramas distingue política, regla efectiva, bypass y prueba de cumplimiento para que una captura general no oculte una ruta sin control.
Las evidencias útiles muestran una actividad real: altas y bajas de usuarios, revisiones de permisos, cambios autorizados, restauraciones comprobadas, formación del personal y seguimiento de vulnerabilidades. Cada evidencia debe corresponder al sistema incluido en el alcance y al periodo examinado. Un procedimiento corporativo puede servir de marco, pero necesita registros que acrediten su aplicación al servicio evaluado.
Para los accesos privilegiados, interesa saber quién puede administrarlos, con qué autorización y cómo se detecta un uso indebido. Para la continuidad, importa comprobar que la restauración recupera un servicio utilizable y sus dependencias. Para los proveedores, conviene disponer de contactos, compromisos, delimitación de responsabilidades y evidencia de seguimiento. La recopilación debe ser suficiente y proporcionada, evitando crear repositorios indiscriminados de datos personales.
La infraestructura como código y la trazabilidad de cambios pueden ayudar a vincular configuraciones, revisiones y despliegues. Ese enfoque aporta evidencia si las autorizaciones y los registros son fiables; no convierte automáticamente una configuración en conforme con el ENS. También hay que controlar quién puede modificar el repositorio y cómo se gestionan cambios urgentes fuera del procedimiento habitual.
Declaración, certificación y auditoría
El artículo 38 y el anexo III establecen vías distintas. Los sistemas de categoría BÁSICA pueden acreditar la conformidad mediante autoevaluación y declaración de conformidad. La autoevaluación debe documentar la implantación de las medidas y las evidencias. Es posible acudir voluntariamente a una certificación, pero no debe presentarse como requisito general de la categoría BÁSICA.
Los sistemas de categoría MEDIA o ALTA requieren auditoría para la certificación de conformidad. El artículo 31 establece auditorías ordinarias al menos cada dos años y extraordinarias cuando existan modificaciones sustanciales que puedan repercutir en las medidas. La extraordinaria determina el nuevo inicio del cómputo. La posibilidad excepcional de ampliación por fuerza mayor no debe confundirse con una prórroga rutinaria para preparar documentación.
La información oficial sobre certificación del CCN distingue las entidades de certificación y los órganos de auditoría técnica que actúan dentro de sus competencias. Antes de contratar, debe comprobarse la habilitación concreta en el listado oficial de entidades. No todos los informes privados ni todas las auditorías de seguridad producen una certificación ENS válida.
El objeto certificado es el sistema, con su alcance y servicios asociados. Una empresa que exhibe un distintivo debe permitir comprobar qué cubre. El artículo 38 prevé la publicación de las declaraciones y certificaciones en las sedes o páginas correspondientes. Para un comprador, la fecha, la categoría, el alcance y la correspondencia con el servicio contratado resultan más útiles que una afirmación genérica de «empresa certificada».
La auditoría debe generar decisiones posteriores. Las deficiencias requieren responsables, prioridades y evidencia de corrección. El anexo III contempla la revisión y aprobación anual del análisis de riesgos, además de otros elementos de gestión. Mantener esa actividad entre auditorías evita que la siguiente evaluación se convierta en una reconstrucción retrospectiva de dos años de operaciones.
Relación con el RGPD y con ISO 27001
El artículo 3 mantiene las obligaciones de protección de datos. El ENS aporta un marco de seguridad, pero no determina por sí solo la base jurídica, la transparencia, los plazos de conservación o la licitud de una cesión. Si el análisis de riesgos de protección de datos o una evaluación de impacto exige medidas reforzadas, deben aplicarse las que correspondan.
La evaluación de impacto relativa a la protección de datos estudia riesgos para las personas. Puede reutilizar información técnica del ENS, aunque su objeto y sus conclusiones no son idénticos. Un sistema puede disponer de controles sólidos y, aun así, recoger información excesiva o conservarla sin justificación. La conformidad de seguridad no sanea esos tratamientos.
Cuando el proveedor actúa como encargado, también necesita un contrato u otro acto jurídico vinculante admisible conforme al artículo 28 del RGPD. El modelo de contrato de encargado del tratamiento ayuda a revisar instrucciones, asistencia y subencargados. La documentación ENS puede acreditar medidas, pero no reemplaza esas estipulaciones ni decide por sí sola la condición de responsable o encargado.
Una certificación ISO 27001 puede facilitar estructuras de gestión y evidencias, pero no sustituye automáticamente la conformidad ENS. El análisis de ISO 27001 y RGPD para empresas españolas permite separar esos objetivos. Conviene reutilizar controles compatibles y documentar las diferencias de alcance, requisitos y evaluación.
Incidentes: rutas y obligaciones diferentes
El artículo 33 regula la comunicación de incidentes con impacto significativo y la coordinación correspondiente. Las entidades públicas notifican al CCN conforme a las condiciones aplicables. Para proveedores privados incluidos en el ámbito, el artículo contempla la comunicación a INCIBE-CERT y la información inmediata de este al CCN-CERT, con las precisiones del propio régimen y del Real Decreto 43/2021. Los supuestos de servicios esenciales, infraestructuras críticas o defensa requieren atender a sus reglas de coordinación.
No existe en el Real Decreto 311/2022 una escala general que permita asignar sin más veinticuatro horas, setenta y dos horas o cinco días a cualquier incidente ENS. El procedimiento debe identificar la norma, la instrucción técnica, el contrato y la autoridad que correspondan. Un directorio desactualizado o la dependencia de una sola persona puede impedir cumplir incluso si la organización detecta bien el incidente.
Si también existe una violación de datos personales, hay que evaluar separadamente el RGPD. La notificación a la autoridad de control se realiza sin dilación indebida y, de ser posible, dentro de las setenta y dos horas desde que se tiene constancia, salvo que sea improbable que exista riesgo para las personas. Si se retrasa, deben explicarse los motivos. Toda violación de datos personales se documenta; la comunicación a afectados depende del alto riesgo y de sus excepciones. La guía sobre brechas de seguridad RGPD desarrolla esa decisión.
Cómo organizar un proyecto de adecuación
El primer entregable debería fijar alcance, categoría y responsables. Después se contrasta la situación existente con las medidas aplicables y se priorizan carencias según riesgo y dependencias. La fase de implantación debe producir evidencias utilizables, no únicamente políticas aprobadas. Finalmente se prepara la autoevaluación o auditoría pertinente y se organiza el mantenimiento posterior.
No hay un precio o duración universal defendible sin conocer esas condiciones. Para comparar presupuestos, pida que separen diagnóstico, implantación, asistencia, evaluación y seguimiento. Compruebe qué sistemas, sedes y proveedores incluye cada propuesta y quién conserva las evidencias. Una oferta barata puede excluir precisamente las integraciones que hacen complejo el servicio; una más extensa puede duplicar trabajo ya realizado.
La situación de la transposición española de NIS2 debe seguirse por separado. Un proyecto legislativo no modifica por sí solo las obligaciones vigentes del ENS ni convierte una certificación en cumplimiento integral de NIS2. La preparación común puede aprovechar inventarios, gestión de riesgos y respuesta a incidentes, manteniendo identificada la fuente de cada obligación.
El resultado práctico es un sistema cuyo alcance se entiende, cuyas decisiones tienen responsables y cuya seguridad puede demostrarse. La lista de comprobación RGPD para España completa las cuestiones de protección de datos. La renovación de un certificado será entonces una verificación de trabajo mantenido, en lugar del único momento en que la organización examina su seguridad.