Hasta ahora este curso ha trabajado con marcos de adopción voluntaria: ISO 27001 se certifica porque una organización decide diferenciarse o porque un cliente lo exige contractualmente, pero nadie va a un juzgado por no tenerla. El Esquema Nacional de Seguridad es distinto: es legislación. Un Real Decreto publicado en el BOE, con artículos numerados, disposiciones transitorias y un régimen de exigibilidad que alcanza no solo a la Administración, sino —y esto sorprende a muchas empresas la primera vez que lo descubren— a buena parte del sector privado que quiere venderle algo al sector público. Si tu empresa aspira a un contrato con un ayuntamiento, una consejería, una universidad pública o cualquier organismo estatal, y ese contrato implica tratar información o prestar un servicio TIC, es más que probable que el pliego exija acreditar conformidad con el ENS. Este módulo explica qué es exactamente esa obligación, cómo se determina su alcance y cómo se demuestra el cumplimiento ante un poder adjudicador o ante el propio Centro Criptológico Nacional.
El enfoque de este módulo es marcadamente normativo: a diferencia de ISO 27001, donde hay margen de interpretación y buenas prácticas, aquí trabajamos con texto legal vigente. Cada categoría, cada dimensión, cada plazo de auditoría tiene un artículo del Real Decreto 311/2022 que lo respalda, y ese rigor es exactamente lo que se espera de un profesional de GRC que se sienta ante un auditor de certificación del ENS o ante el responsable de contratación de un organismo público.
Qué aprenderás
- La base legal del ENS: el Real Decreto 311/2022, su origen en la Ley 40/2015 y su relación con el derogado Real Decreto 3/2010.
- El ámbito de aplicación real del ENS —por qué afecta también a empresas privadas que no son Administración.
- Los principios básicos y requisitos mínimos que estructuran todo el modelo.
- Las cinco dimensiones de seguridad (DICAT) y cómo se valoran en la práctica.
- Cómo se determina la categoría de un sistema —básica, media o alta— y qué implica cada una.
- La estructura del catálogo de medidas del Anexo II: marco organizativo, marco operacional y medidas de protección.
- Los perfiles de cumplimiento específicos y el mapa de guías CCN-STIC de la serie 800 que hay que conocer.
- Las herramientas gratuitas del CCN-CERT (PILAR, INÉS, CLARA, ROCÍO, ANA, GLORIA, LUCÍA, CARMEN) y para qué sirve cada una.
- La diferencia entre declaración y certificación de conformidad, y cómo se articula la auditoría periódica.
- Cómo se relaciona el ENS con ISO 27001 y por qué muchas organizaciones acaban gestionando ambos marcos a la vez.
Qué es el ENS y su base legal
El Esquema Nacional de Seguridad (ENS) es el conjunto de principios básicos, requisitos mínimos y medidas de protección que deben adoptar los sistemas de información del sector público español —y de determinados operadores privados— para garantizar un nivel adecuado de seguridad. No es una guía de buenas prácticas ni una certificación voluntaria de mercado: es una norma jurídica de obligado cumplimiento.
El Real Decreto 311/2022, de 3 de mayo
La regulación vigente es el Real Decreto 311/2022, de 3 de mayo, por el que se regula el Esquema Nacional de Seguridad, publicado en el Boletín Oficial del Estado número 106, de 4 de mayo de 2022 (referencia BOE-A-2022-7191). Este Real Decreto deroga expresamente el Real Decreto 3/2010, de 8 de enero, que había sido la norma reguladora del ENS durante más de una década, dentro del ámbito de la administración electrónica regulada entonces por la Ley 11/2007.
El fundamento habilitante del RD 311/2022 es el artículo 156.2 de la Ley 40/2015, de 1 de octubre, de Régimen Jurídico del Sector Público, que ordena la existencia de un Esquema Nacional de Seguridad «constituido por los principios básicos y requisitos mínimos que garanticen adecuadamente la seguridad de la información tratada». La actualización de 2022 no es cosmética: responde a la necesidad de adaptar el modelo al incremento cuantitativo y cualitativo de las ciberamenazas, incorporar la experiencia de más de diez años de aplicación del ENS de 2010, y alinear el esquema con el resto del marco europeo y nacional de ciberseguridad (Estrategia Nacional de Ciberseguridad, Directiva NIS y su evolución posterior).
Una particularidad procedimental relevante: la disposición transitoria única del RD 311/2022 concede a los sistemas ya existentes y adecuados al RD 3/2010 un plazo de veinticuatro meses desde la entrada en vigor para alcanzar la plena adecuación al nuevo esquema. Ese plazo transitorio ya ha vencido con creces a la fecha de este módulo, por lo que cualquier sistema dentro del ámbito de aplicación debe estar ya adecuado al texto de 2022, no al de 2010.
Principios básicos
El RD 311/2022 articula el ENS sobre un conjunto de principios básicos que orientan cualquier decisión de seguridad dentro de su ámbito. No son una lista decorativa: cada uno tiene consecuencias prácticas directas en cómo se diseñan los sistemas y se justifican las medidas.
- Seguridad como proceso integral. La seguridad no es un producto que se compra ni una casilla que se marca una vez: es un proceso continuo que involucra a todos los elementos técnicos, humanos, materiales y organizativos del sistema, desde su concepción hasta su retirada.
- Gestión de la seguridad basada en los riesgos. Las decisiones de protección deben derivarse de un análisis de riesgos real sobre el sistema, no de un catálogo aplicado sin criterio —el mismo principio que trabajamos en el Módulo 3 de este curso para ISO 31000 y MAGERIT, y que aquí se traduce en la categorización que veremos más adelante.
- Prevención, detección, respuesta y conservación. El modelo exige capacidades en las cuatro fases del ciclo de un incidente: evitarlo cuando sea posible, detectarlo cuando ocurra, responder con rapidez y conservar la capacidad de recuperación y continuidad del servicio.
- Existencia de líneas de defensa. El sistema de protección debe articularse en varias capas o líneas sucesivas, de forma que el fallo de una no comprometa la totalidad de la seguridad del sistema —el principio de defensa en profundidad aplicado normativamente.
- Vigilancia continua y reevaluación periódica. La seguridad de un sistema no se certifica una vez y se olvida: exige vigilancia constante y reevaluación periódica de su estado, adaptándose a la evolución de amenazas, vulnerabilidades y del propio sistema.
- Diferenciación de responsabilidades. Deben quedar diferenciadas la responsabilidad sobre la información, sobre los servicios, sobre la seguridad y sobre la operación del sistema, cada una asignada a un responsable identificable —una estructura de roles análoga a la que vimos en el Módulo 2 sobre gobierno de la seguridad.
A partir de estos principios, el ENS fija requisitos mínimos de seguridad (organización, análisis y gestión de riesgos, gestión de personal, profesionalidad, autorización y control de los accesos, protección de las instalaciones, adquisición de productos, seguridad por defecto, integridad y actualización del sistema, protección de la información almacenada y en tránsito, prevención ante otros sistemas interconectados, registro de la actividad, incidentes de seguridad, continuidad de la actividad y mejora continua del proceso de seguridad) que se materializan en el catálogo de medidas del Anexo II que veremos más abajo.
Ámbito de aplicación: no solo la Administración
Este es, con diferencia, el punto que más sorprende a quien se acerca al ENS por primera vez desde el sector privado. El artículo 2 del RD 311/2022 define el ámbito de aplicación en dos bloques:
- Todo el sector público, en el sentido definido por la Ley 40/2015: Administración General del Estado, comunidades autónomas, entidades locales, organismos públicos, universidades públicas, entidades de derecho público vinculadas o dependientes de cualquiera de las administraciones anteriores, y también las corporaciones de derecho público (colegios profesionales, cámaras) en el ejercicio de sus funciones públicas.
- Sistemas de información del sector privado que prestan servicios o proveen soluciones a entidades del sector público para el ejercicio de sus competencias, cuando esos servicios o soluciones estén dentro del ámbito de aplicación del ENS. En estos casos, los pliegos de condiciones de la contratación pública deben incluir los requisitos necesarios para asegurar la conformidad con el ENS, y el operador privado queda obligado a acreditarla.
La consecuencia práctica de este segundo punto es enorme para el tejido empresarial TIC español: cualquier proveedor de software, hosting, servicios cloud, desarrollo a medida, outsourcing de TI o servicios gestionados de seguridad que quiera contratar con una Administración Pública española necesita, en la inmensa mayoría de los pliegos actuales, acreditar conformidad con el ENS en la categoría que corresponda al sistema afectado. Esto ha convertido al ENS en un requisito de acceso a mercado, no solo en una obligación regulatoria pasiva: empresas que nunca habían tenido contacto con la Administración se ven obligadas a implantarlo si quieren optar a un concurso público con componente TIC.
Las cinco dimensiones de seguridad: DICAT
El ENS valora la seguridad de un sistema de información a través de cinco dimensiones, cuyo acrónimo —DICAT— es de uso constante en toda la documentación del CCN-CERT y en cualquier informe de categorización. A diferencia del clásico triángulo CIA (confidencialidad, integridad, disponibilidad) que domina buena parte de la literatura anglosajona de seguridad, el ENS añade dos dimensiones propias: autenticidad y trazabilidad.
| Dimensión | Sigla | Qué protege | Ejemplo de incidente que la compromete |
|---|---|---|---|
| Disponibilidad | D | Que la información y los servicios sean accesibles y utilizables cuando los usuarios legítimos lo necesitan | Ataque de denegación de servicio (DoS/DDoS) que tumba la sede electrónica durante un plazo de presentación de solicitudes |
| Integridad | I | Que la información y los métodos de proceso sean exactos y completos, sin alteraciones no autorizadas | Modificación no autorizada de un expediente administrativo o de una base de datos de subvenciones |
| Confidencialidad | C | Que la información solo sea accesible para quienes están autorizados a conocerla | Filtración de datos personales de ciudadanos contenidos en un padrón municipal |
| Autenticidad | A | Que la identidad de quien genera, envía o accede a la información o al servicio sea la que dice ser | Suplantación de identidad de un funcionario para firmar electrónicamente un documento en su nombre |
| Trazabilidad | T | Que las acciones de una entidad puedan imputarse exclusivamente a ella, con capacidad de reconstruir qué ocurrió, cuándo y quién lo hizo | Imposibilidad de determinar quién accedió y modificó un registro tras detectarse una filtración, por falta de logs de auditoría |
Cada dimensión se valora de forma independiente para cada sistema, en una escala que en la práctica se expresa como BAJO, MEDIO o ALTO (con matices adicionales según la metodología de valoración, típicamente apoyada en herramientas como PILAR, que veremos más adelante). Esta valoración por dimensión —y no un valor único agregado— es lo que permite después determinar la categoría del sistema, siguiendo el procedimiento descrito en el Anexo I del RD 311/2022.
Las categorías de seguridad: BÁSICA, MEDIA y ALTA
El artículo 40 del RD 311/2022 establece que la categoría de seguridad de un sistema de información modula el equilibrio entre la importancia de la información y los servicios que maneja y el esfuerzo de seguridad requerido, en función del impacto que tendría un incidente que afectara a la seguridad del sistema. La determinación se efectúa valorando el impacto que causaría sobre la organización un incidente que perjudicara cada una de las cinco dimensiones DICAT, según el procedimiento del Anexo I.
La regla del máximo
La regla de determinación es sencilla de enunciar y decisiva en la práctica: la categoría del sistema es la que corresponde a la valoración más alta de entre sus cinco dimensiones. Si un sistema tiene disponibilidad BAJA, integridad MEDIA, confidencialidad ALTA, autenticidad MEDIA y trazabilidad BAJA, la categoría global del sistema es ALTA, determinada íntegramente por la dimensión de confidencialidad. No hay promedios ni compensaciones entre dimensiones: una sola dimensión valorada en ALTO obliga a categorizar todo el sistema como ALTO, con el consiguiente nivel de exigencia en el catálogo de medidas completo, no solo en las medidas relacionadas con esa dimensión concreta.
| Categoría | Cuándo se aplica | Qué implica |
|---|---|---|
| BÁSICA | Ninguna dimensión alcanza el nivel ALTO ni MEDIO; el impacto máximo de un incidente es limitado | Catálogo de medidas mínimo del Anexo II; conformidad mediante autoevaluación y declaración de conformidad |
| MEDIA | Al menos una dimensión se valora como MEDIA, y ninguna alcanza ALTA | Catálogo de medidas ampliado respecto a básica, con refuerzos específicos; conformidad mediante auditoría y certificación por entidad acreditada |
| ALTA | Al menos una dimensión se valora como ALTA | Catálogo de medidas completo, con los refuerzos más exigentes (redundancia, cifrado reforzado, segregación de funciones estricta); conformidad mediante auditoría y certificación por entidad acreditada |
La categoría no es un ejercicio académico: determina directamente qué medidas del Anexo II son exigibles (muchas medidas solo aplican, o se refuerzan, a partir de categoría media o alta), qué tipo de procedimiento de conformidad corresponde (declaración frente a certificación, que veremos más abajo) y con qué periodicidad hay que auditar el sistema. Categorizar mal —habitualmente por defecto, asignando BÁSICA sin un análisis real— es uno de los errores más comunes y más graves que se detectan en las auditorías, como veremos en la sección de errores comunes.
El catálogo de medidas: el Anexo II del RD 311/2022
El Anexo II del RD 311/2022 contiene el catálogo completo de medidas de seguridad exigibles, organizado en tres grandes marcos o familias, cada una identificada con un prefijo de dos letras que aparece en toda la documentación CCN-STIC y en las herramientas de gestión del cumplimiento.
| Marco | Prefijo | Qué cubre | Ejemplos de medidas |
|---|---|---|---|
| Marco organizativo | org | La organización global de la seguridad: gobierno, normativa interna y procedimientos operativos de seguridad | org.1 Política de seguridad; org.2 Normativa de seguridad; org.3 Procedimientos de seguridad; org.4 Proceso de autorización |
| Marco operacional | op | Las medidas a adoptar para proteger la operación del sistema como conjunto integral de componentes destinado a un fin | op.pl (planificación), op.acc (control de acceso), op.exp (explotación), op.ext (servicios externalizados), op.cont (continuidad del servicio), op.mon (monitorización del sistema) |
| Medidas de protección | mp | La protección de activos concretos, según su naturaleza y la calidad exigida por el nivel de seguridad de las dimensiones afectadas | mp.if (protección de las instalaciones); mp.per (gestión del personal); mp.eq (protección de los equipos); mp.com (protección de las comunicaciones); mp.si (protección de los soportes de información); mp.sw (protección de las aplicaciones informáticas); mp.info (protección de la información); mp.s (protección de los servicios) |
Cada medida individual del catálogo se aplica o refuerza en función de la categoría del sistema (básica, media o alta) y, en ocasiones, de la dimensión de seguridad específica que protege —una medida puede ser exigible desde categoría básica en su forma mínima y llevar refuerzos adicionales obligatorios solo a partir de categoría media o alta. Esta graduación es la que traduce en la práctica el principio de proporcionalidad del ENS: no se exige el mismo esfuerzo de seguridad a la sede electrónica de un ayuntamiento pequeño que gestiona trámites de bajo impacto que al sistema que soporta la historia clínica electrónica de un servicio autonómico de salud.
Cómo se aplica en la práctica
El proceso operativo habitual es: (1) categorizar el sistema según el procedimiento del Anexo I; (2) identificar, dentro del catálogo del Anexo II, qué medidas y qué refuerzos corresponden a esa categoría; (3) para cada medida, declarar su estado de implantación y, si no aplica, justificarlo de forma motivada (el ENS admite la no aplicación justificada de medidas concretas cuando el sistema no presenta el riesgo que la medida mitiga); y (4) documentar todo el proceso en la Declaración de Aplicabilidad de medidas del sistema, un artefacto que cualquier profesional familiarizado con la SoA de ISO 27001 (vista en el módulo anterior de este curso) reconocerá de inmediato por su lógica idéntica: control por control, aplica o no aplica, con justificación y evidencia.
Perfiles de cumplimiento específicos y guías CCN-STIC serie 800
Perfiles de cumplimiento específicos
El RD 311/2022 introduce la figura de los perfiles de cumplimiento específicos: instrumentos que, para determinados tipos de entidad, sector de actividad o tipo de sistema, concretan qué medidas y refuerzos del catálogo general son aplicables, o qué criterios seguir para determinarlos, adaptando el ENS genérico a un contexto particular. El CCN ha publicado perfiles de este tipo para universidades, para servicios cloud concretos contratados como CUC (Catálogo de Servicios en la Nube del CCN), y para requisitos esenciales de seguridad en determinados escenarios, entre otros. Estos perfiles no sustituyen al Anexo II: lo particularizan, facilitando la adecuación de organizaciones con características comunes sin que cada una tenga que repetir desde cero el ejercicio de interpretación del catálogo genérico.
Las guías CCN-STIC de la serie 800
El Centro Criptológico Nacional publica y mantiene la serie CCN-STIC 800, dedicada íntegramente a la implantación y verificación del ENS. Son documentos técnicos gratuitos, de referencia obligada para cualquier profesional que trabaje en un proyecto de adecuación. Las más relevantes para el trabajo del día a día son:
| Guía | Título / contenido |
|---|---|
| CCN-STIC 800 | Glosario de términos y abreviaturas del ENS —referencia terminológica común para todo el resto de la serie |
| CCN-STIC 801 | Responsables y funciones en el ENS —quién es responsable de la información, del servicio, de la seguridad y del sistema, y qué le corresponde a cada uno |
| CCN-STIC 804 | Medidas de implantación del ENS —guía práctica para desplegar el catálogo del Anexo II en un sistema real |
| CCN-STIC 806 | Plan de adecuación del ENS —cómo estructurar el proyecto de adecuación, desde el análisis de brechas hasta el cierre |
| CCN-STIC 808 | Verificación del cumplimiento de las medidas en el ENS —metodología de comprobación previa a una auditoría formal |
| CCN-STIC 823 | Utilización de servicios en la nube (cloud computing) en el ámbito del ENS |
| CCN-STIC 825 | Mapeo entre los requisitos del RD 311/2022 y los controles del Anexo A de ISO/IEC 27001:2022 —pieza clave para quien gestiona ambos marcos a la vez |
Además de estas, existe una amplia familia de guías de la serie 800 dedicadas a perfiles de cumplimiento específico para sectores o servicios concretos (identificadas normalmente en el rango 880-890 y siguientes, con numeración que el CCN va ampliando a medida que publica nuevos perfiles), así como guías de configuración segura de productos concretos fuera ya de la serie 800 propiamente dicha. La recomendación práctica es consultar siempre el portal oficial de la serie 800 del CCN-CERT para verificar la versión vigente antes de citar un número de guía en un informe formal, porque el CCN revisa y renumera estos documentos con cierta frecuencia.
Herramientas del CCN-CERT que apoyan el ENS
El CCN-CERT distribuye gratuitamente (con condiciones de acceso que varían según sean entidades públicas o privadas) un conjunto de herramientas de nombre propio —popularmente conocidas por sus nombres en femenino— que cubren distintas fases del ciclo de vida de la seguridad bajo el ENS. Conocer su propósito exacto es útil para cualquier profesional de GRC que trabaje con Administraciones españolas, porque son las herramientas que un auditor o un responsable de seguridad de un organismo público dará por conocidas.
| Herramienta | Propósito |
|---|---|
| PILAR | Análisis y gestión de riesgos según la metodología MAGERIT; la herramienta de referencia para categorizar sistemas y sustentar la Declaración de Aplicabilidad del ENS. Existen variantes PILAR Basic (pymes y entidades locales) y µPILAR (análisis rápidos) |
| INÉS | Informe Nacional del Estado de Seguridad; recopila y agrega el nivel de cumplimiento del ENS de las entidades del sector público a nivel nacional, sirviendo de base al informe anual que se eleva a la Comisión Sectorial de Administración Electrónica |
| CLARA / µCLARA | Auditoría automatizada del grado de cumplimiento del ENS/CCN-STIC en sistemas Windows, comprobando configuraciones de seguridad frente al bastionado de referencia |
| ROCÍO | Apoyo a la elaboración de configuraciones de seguridad (bastionado) de los principales componentes tecnológicos del sistema, integrada con otras soluciones del ecosistema CCN-CERT |
| ANA | Sistema de auditoría continua y gestión centralizada de vulnerabilidades, con detección y notificación de alertas para su tratamiento prioritario |
| GLORIA | Gestión de incidentes y amenazas mediante correlación de eventos de seguridad, apoyando la capacidad de detección y respuesta exigida por el ENS |
| LUCÍA | Listado Unificado de Coordinación de Incidentes y Amenazas; plataforma de gestión de ciberincidentes para entidades del ámbito del ENS, con taxonomía común y trazabilidad del ciclo de vida del incidente |
| CARMEN | Detección de amenazas persistentes avanzadas (APT) mediante análisis de tráfico de red, minería de datos y detección de anomalías significativas |
Ninguna de estas herramientas es obligatoria por sí misma —el ENS no exige el uso de un producto concreto— pero su adopción generalizada en el sector público español las convierte en un estándar de facto, y conocerlas facilita enormemente la interlocución con clientes públicos y con auditores del esquema.
Conformidad con el ENS: declaración frente a certificación
El artículo 38 del RD 311/2022 regula cómo se demuestra formalmente la conformidad de un sistema con el esquema, y el mecanismo depende directamente de la categoría determinada previamente.
| Categoría | Mecanismo de conformidad | Quién lo realiza |
|---|---|---|
| BÁSICA | Declaración de conformidad, basada en autoevaluación | La propia entidad responsable del sistema, sin intervención de un tercero externo obligatorio |
| MEDIA | Certificación de conformidad, basada en auditoría formal | Entidad de certificación acreditada conforme a la normativa aplicable (habitualmente acreditada por ENAC bajo el esquema correspondiente) |
| ALTA | Certificación de conformidad, basada en auditoría formal | Entidad de certificación acreditada; con exigencias de auditoría más estrictas que en categoría media |
Tanto la declaración como la certificación de conformidad deben hacerse públicas, y se materializan en un distintivo de conformidad específico según la categoría, que la entidad puede exhibir en su sede electrónica o en su documentación comercial (en el caso de proveedores privados) como acreditación frente a terceros. Este distintivo es, en la práctica, lo primero que pide un departamento de contratación pública cuando evalúa una oferta que declara cumplimiento con el ENS.
Periodicidad de la auditoría
El artículo 31 del RD 311/2022 establece que los sistemas de información dentro del ámbito de aplicación del esquema serán objeto de una auditoría regular ordinaria al menos cada dos años, con independencia de que corresponda declaración o certificación. Adicionalmente, procede una auditoría extraordinaria siempre que se produzcan modificaciones sustanciales en el sistema que puedan afectar a las medidas de seguridad requeridas, cuyo resultado condiciona la vigencia de la certificación o declaración existente. El informe de auditoría debe dictaminar sobre el grado de cumplimiento del Real Decreto, identificando los hallazgos concretos y las deficiencias detectadas, en un formato análogo —de nuevo— al informe de no conformidades de una auditoría ISO 27001 que trabajamos en el módulo anterior.
El ENS y su relación con ISO 27001
ENS e ISO 27001 no son marcos competidores: son complementarios y, en gran medida, mapeables entre sí. Ambos comparten filosofía (gestión de la seguridad basada en riesgos, mejora continua, catálogo de controles/medidas seleccionable según análisis de riesgos) y ambos exigen artefactos de gobierno muy similares (política de seguridad, roles y responsabilidades definidos, análisis de riesgos, declaración de aplicabilidad de controles, auditoría periódica). La propia guía CCN-STIC 825, mencionada más arriba, existe precisamente para facilitar ese mapeo entre los requisitos del RD 311/2022 y los controles del Anexo A de ISO/IEC 27001:2022.
En la práctica, muchas organizaciones que ya tienen un SGSI certificado en ISO 27001 —especialmente proveedores TIC que atienden tanto a clientes privados como públicos— reutilizan buena parte de su documentación, su registro de riesgos y su estructura de gobierno para construir encima la adecuación al ENS, en lugar de levantar dos sistemas de gestión paralelos y desconectados. Las diferencias más relevantes a tener en cuenta al hacer esa integración son: el ENS es de aplicación obligatoria (no voluntaria) dentro de su ámbito; su unidad de análisis es el sistema de información categorizado individualmente, no una organización completa dentro de un alcance definido como en ISO 27001; y el ENS incorpora las dos dimensiones propias de autenticidad y trazabilidad que no tienen un equivalente de nombre directo en el triángulo CIA clásico de ISO 27001, aunque sus objetivos de protección subyacentes están cubiertos por controles del Anexo A (gestión de identidades, registro y monitorización).
Caso práctico: categorizar la sede electrónica de un ayuntamiento
Un ayuntamiento de tamaño medio (unos 45.000 habitantes) está renovando su sede electrónica, a través de la cual los ciudadanos presentan solicitudes, consultan el estado de sus expedientes, pagan tasas municipales, acceden a su padrón y reciben notificaciones electrónicas de procedimientos administrativos, incluyendo expedientes sancionadores y de servicios sociales. El ayuntamiento encarga a su responsable de seguridad la categorización del sistema conforme al ENS antes de sacar a licitación el contrato de desarrollo y mantenimiento, precisamente para poder incluir en el pliego el nivel de exigencia correcto.
Valoración de las cinco dimensiones
| Dimensión | Valoración | Razonamiento |
|---|---|---|
| Disponibilidad (D) | MEDIA | Una caída de varias horas afecta a la tramitación de plazos administrativos, pero no compromete servicios esenciales de emergencia; el impacto es relevante pero no catastrófico |
| Integridad (I) | MEDIA | Una alteración no autorizada de un expediente (por ejemplo, cambiar el estado de una solicitud de ayuda social) tendría consecuencias administrativas y de confianza pública significativas, aunque recuperables con el respaldo documental físico existente |
| Confidencialidad (C) | ALTA | El sistema trata datos de categoría especial: expedientes de servicios sociales que pueden incluir información de salud o situación de vulnerabilidad, y datos del padrón municipal. Una filtración masiva tendría un impacto grave sobre los derechos de los afectados |
| Autenticidad (A) | MEDIA | La suplantación de identidad de un ciudadano para presentar solicitudes en su nombre, o de un funcionario para resolver expedientes, tiene un impacto administrativo y legal notable, mitigable en parte por los sistemas de identificación electrónica (Cl@ve, certificado digital) ya integrados |
| Trazabilidad (T) | MEDIA | La imposibilidad de determinar quién accedió o modificó un expediente dificultaría gravemente la instrucción de cualquier procedimiento disciplinario o judicial derivado de un incidente, aunque no es por sí sola la dimensión más crítica del sistema |
Determinación de la categoría
Aplicando la regla del máximo del artículo 40: cuatro dimensiones se valoran como MEDIA y una —confidencialidad— como ALTA. Por tanto, la categoría del sistema es ALTA, determinada íntegramente por el tratamiento de datos de servicios sociales y de salud dentro de los expedientes. Esto implica que el ayuntamiento debe exigir en el pliego de contratación el catálogo completo de medidas del Anexo II en su nivel más exigente, que el sistema deberá someterse a certificación de conformidad por una entidad acreditada (no basta la autoevaluación), y que la auditoría de certificación deberá repetirse, como mínimo, cada dos años conforme al artículo 31. El proveedor que resulte adjudicatario del desarrollo y mantenimiento deberá, a su vez, poder acreditar su propia adecuación al ENS en la categoría correspondiente, conforme al régimen de aplicación a proveedores del sector privado del artículo 2.
Errores comunes
- Creer que el ENS solo afecta a la Administración Pública. Es, de lejos, el malentendido más extendido en el sector privado. Cualquier empresa TIC que quiera contratar con el sector público —desde una pyme de desarrollo web hasta un integrador de sistemas de gran tamaño— puede quedar obligada a acreditar el ENS si el pliego lo exige, algo cada vez más frecuente.
- Categorizar «a ojo» sin análisis real de las cinco dimensiones. Asignar categoría BÁSICA por defecto, sin valorar formalmente disponibilidad, integridad, confidencialidad, autenticidad y trazabilidad según el procedimiento del Anexo I, es un error que un auditor detecta de inmediato y que puede invalidar toda la adecuación posterior, porque el catálogo de medidas aplicado no corresponderá a la categoría real del sistema.
- No mantener vivo el plan de adecuación. Tratar la adecuación al ENS como un proyecto cerrado tras la primera auditoría, en lugar de un proceso continuo de vigilancia, reevaluación y actualización de medidas (uno de los principios básicos del propio esquema), deja a la organización con una certificación formalmente vigente pero materialmente desactualizada frente a nuevas amenazas o cambios en el sistema.
- Confundir declaración con certificación, o asumir que la autoevaluación de una categoría básica es válida para un sistema que, tras un cambio de alcance o de servicios, ha pasado a categoría media o alta y requeriría ya una certificación por entidad acreditada.
- No documentar la justificación de las medidas no aplicadas en la Declaración de Aplicabilidad de medidas del ENS, dejando huecos en el catálogo sin motivación trazable —el mismo error, con el mismo nombre de artefacto casi calcado, que vimos para la SoA de ISO 27001 en el módulo anterior.
- Ignorar el impacto de una sola dimensión alta sobre la categoría global, tratando el ENS como si las dimensiones se promediaran o compensaran entre sí, cuando la regla normativa es estrictamente la del valor máximo.
Ejercicio
Una empresa de desarrollo de software está a punto de presentarse a un concurso público para desarrollar y alojar el sistema de gestión de citas de una consejería de sanidad autonómica. El sistema permitirá a los ciudadanos reservar citas médicas, consultar su historial resumido de citas previas y recibir recordatorios por SMS y correo electrónico. No almacenará historia clínica completa, solo metadatos de las citas (especialidad, centro, fecha, y un campo de observaciones que en ocasiones el personal administrativo usa para anotar motivos de consulta).
- Valora, con tu propio criterio razonado, las cinco dimensiones DICAT de este sistema, siguiendo el mismo formato de tabla del caso práctico (dimensión, valoración, razonamiento en una frase).
- Determina la categoría resultante aplicando la regla del máximo, e identifica qué dimensión concreta la determina.
- Indica si correspondería declaración o certificación de conformidad, y con qué periodicidad debería auditarse el sistema una vez en producción.
- Redacta dos frases justificando por qué la empresa de desarrollo —siendo una entidad privada— queda igualmente obligada por el ENS en este contrato, citando el artículo del RD 311/2022 que lo sustenta.
- Identifica al menos tres medidas concretas del catálogo del Anexo II (con su prefijo org/op/mp) que consideres especialmente críticas para este sistema, y razona brevemente por qué.
Preguntas frecuentes
¿El ENS obliga a mi empresa si nunca voy a trabajar con la Administración Pública?
No directamente. El ámbito de aplicación del artículo 2 del RD 311/2022 alcanza al sector público y a las entidades privadas que prestan servicios o proveen soluciones a entidades del sector público. Si tu empresa no tiene ni prevé tener ningún contrato, colaboración o suministro con un organismo público que implique el tratamiento de información o la prestación de un servicio TIC dentro del alcance del ENS, no estás obligado. Ahora bien, conviene tener presente que el ámbito de «prestar servicios a entidades del sector público» es amplio y puede incluir situaciones no evidentes a primera vista, como ser subcontratista de un proveedor principal que sí tiene un contrato público directo.
¿Qué diferencia hay entre la categoría BÁSICA del ENS y la aceptación de riesgo de ISO 27001?
Son conceptos de naturaleza distinta. La categoría BÁSICA del ENS es una clasificación del nivel de exigencia del sistema completo, determinada objetivamente por la valoración de sus dimensiones de seguridad, y conlleva un catálogo de medidas mínimo pero igualmente obligatorio. La aceptación de riesgo en ISO 27001, que vimos en el módulo anterior, es una decisión de tratamiento sobre un riesgo individual concreto dentro del registro de riesgos, tomada caso por caso por el propietario del riesgo. No son equivalentes: un sistema de categoría BÁSICA sigue teniendo que implantar su catálogo de medidas correspondiente, no puede «aceptar» no aplicar el ENS.
¿Es obligatorio usar PILAR para categorizar un sistema conforme al ENS?
No hay obligación normativa de usar una herramienta concreta: el RD 311/2022 no menciona productos específicos. PILAR es, no obstante, la herramienta de referencia del CCN, de uso extendido en el sector público español precisamente por estar alineada con la metodología MAGERIT y con el propio ENS, lo que facilita enormemente el trabajo y la interlocución con auditores y con otras Administraciones. Una organización puede categorizar sus sistemas con cualquier metodología documentada y trazable al procedimiento del Anexo I, pero en la práctica, no usar PILAR ni ninguna herramienta equivalente suele traducirse en más trabajo manual de justificación durante la auditoría.
¿Puede un sistema de categoría ALTA rebajarse a MEDIA si se reduce el volumen de datos que trata?
Sí, si ese cambio afecta realmente a la valoración de alguna de las cinco dimensiones DICAT y esa nueva valoración se documenta formalmente con la misma metodología del Anexo I usada originalmente. La categoría no es una etiqueta fija de por vida: debe reevaluarse cuando cambian de forma sustancial el sistema, los datos que trata o los servicios que presta, y ese cambio debe registrarse y, si corresponde, dar lugar a una auditoría extraordinaria conforme al artículo 31 antes de que el nuevo nivel de conformidad pueda considerarse vigente.
¿Qué pasa si un sistema categoría MEDIA o ALTA no supera la auditoría de certificación cada dos años?
El sistema queda sin certificación de conformidad vigente, lo que en la práctica significa incumplimiento de la obligación legal del RD 311/2022 mientras esa situación se mantenga. Para una entidad del sector público esto puede acarrear responsabilidad administrativa y, en determinados supuestos, cuestionar la validez de actos administrativos electrónicos soportados por ese sistema. Para un proveedor privado, la pérdida de la certificación puede suponer el incumplimiento de las condiciones del contrato público que la exigía, con las consecuencias contractuales —incluida la resolución del contrato— que correspondan según sus cláusulas y la normativa de contratación pública aplicable.
«El presente real decreto tiene por objeto regular el Esquema Nacional de Seguridad establecido en el artículo 156.2 de la Ley 40/2015, de 1 de octubre, de Régimen Jurídico del Sector Público, constituido por los principios básicos y requisitos mínimos que garanticen adecuadamente la seguridad de la información tratada.»