En casi todos los proyectos de adecuación al ENS llega un momento en que alguien hace la misma pregunta: «¿qué proveedor de VPN necesito para certificarme en categoría ALTA?». Cámbiala por un antivirus, por una solución de segmentación de red o por un servicio de sellado de tiempo, y el patrón se repite. Se da por hecho que la medida hay que implantarla, y que lo único que queda por decidir es con qué producto.
Con frecuencia, la respuesta más rentable y más conforme es la que menos se espera: ninguno.
No porque la seguridad no importe, sino precisamente porque importa. El Esquema Nacional de Seguridad no obliga a implantar todas las medidas de su catálogo: obliga a aplicar las que corresponden a tu sistema, y a justificar por escrito las que no. Un «no aplica» bien argumentado no es una laguna en tu cumplimiento; es una decisión de seguridad legítima, prevista por la propia norma, que ahorra coste y complejidad.
Esta guía explica dónde lo dice el RD 311/2022, cómo se documenta en la Declaración de Aplicabilidad, qué medidas se excluyen con más frecuencia y con qué argumento, y, sobre todo, cómo sostener cada exclusión si un auditor la discute.
La premisa que casi nadie cuestiona
Cuando alguien pregunta qué producto necesita para el ENS, asume que la medida es obligatoria y que solo falta elegir proveedor. El ENS no funciona así.
El Anexo II del RD 311/2022 no es una lista de la compra obligatoria. Es un catálogo de medidas del que se seleccionan las que corresponden a tu sistema, en función de tres cosas que fija el artículo 28.1: los activos que lo constituyen, su categoría de seguridad y las decisiones que tomes para gestionar los riesgos.
La consecuencia es contraintuitiva pero muy rentable: la medida más barata, más simple y perfectamente conforme es, a menudo, la que puedes justificar que no necesitas.
En el ENS, «no aplica» no es una laguna: es una decisión
El primer error conceptual es pensar que una medida marcada como «no aplica» es un agujero en el cumplimiento. No lo es. La propia norma lo dice con todas las letras.
En la leyenda de las tablas del Anexo II, el RD 311/2022 define la abreviatura «n.a.» de forma explícita:
«n.a.» significa «no aplica» a efectos de cumplimiento normativo, por lo que no es exigible, sin perjuicio de que su implantación en el sistema pudiera ser beneficioso técnicamente.
Es decir: la norma contempla, de fábrica, que hay medidas que legítimamente no se aplican a un sistema concreto. La no aplicabilidad es una respuesta prevista por el esquema, no una anomalía.
El motivo de fondo es el principio rector de todo el ENS. El artículo 7.2, «Gestión de la seguridad basada en los riesgos», ordena que la reducción de riesgos se haga:
mediante una apropiada aplicación de medidas de seguridad, de manera equilibrada y proporcionada a la naturaleza de la información tratada, de los servicios a prestar y de los riesgos a los que estén expuestos.
Y el Anexo II, en sus disposiciones generales, repite la idea: las medidas serán proporcionales a las dimensiones de seguridad relevantes en el sistema y a su categoría. Aplicar una medida que no protege ningún activo tuyo no es «ir sobrado de seguridad»: es incumplir el principio de proporcionalidad, además de gastar dinero sin retorno.
Dos vías distintas para llegar a «no aplica»
Aquí conviene una precisión que separa a quien conoce la norma de quien la recita. Hay dos caminos diferentes para que una medida no sea exigible, y confundirlos es lo que hace que un auditor levante la ceja.
Vía 1: el «no aplica» que asigna la propia tabla. Para ciertas combinaciones de categoría o de nivel de dimensión, el Anexo II ya marca la medida como «n.a.». No decides tú nada: la medida no es exigible por definición y no necesitas justificar nada. Ejemplos: op.cont.2 «Plan de continuidad» solo aplica cuando la dimensión de disponibilidad es de nivel ALTO (en BAJO y MEDIO figura «n.a.»); op.ext.3 «Protección de la cadena de suministro» solo aplica en categoría ALTA.
Vía 2: la exclusión por inexistencia del activo o del escenario. Una medida que, según tu categoría y niveles, sí tocaría aplicar, pero cuyo activo o escenario protegido no existe en tu arquitectura. Esta exclusión la declaras tú, y aquí la carga de la prueba es tuya: tienes que apoyarla en el juicio de aplicabilidad por activos del artículo 28.1.a) y dejarla motivada en la Declaración de Aplicabilidad.
Casi todos los ejemplos interesantes (la VPN, los sellos de tiempo, la criptografía de soportes) son de la vía 2. Y es la vía 2 la que hay que saber defender.
El documento que lo legitima todo: la Declaración de Aplicabilidad
La Declaración de Aplicabilidad (DdA) es la pieza jurídica central. El artículo 28.2 la define sin ambigüedad:
La relación de medidas de seguridad seleccionadas se formalizará en un documento denominado Declaración de Aplicabilidad, firmado por el responsable de la seguridad.
Dos matices importantes sobre las fuentes, para citar bien:
Primero, la DdA no es una guía CCN-STIC con número propio. Es un documento que define el artículo 28 del RD. La guía CCN-STIC 806 (cuyo título real es «Plan de Adecuación», no «Declaración de Aplicabilidad») describe la DdA como el apartado 3.7 de ese plan de adecuación, y establece la regla que aquí nos interesa: «Cuando una medida requerida por el Anexo II en función de la valoración del sistema no [se] considere aplicable, esta no-aplicabilidad debe estar motivada». La edición pública de la 806 es de 2011 y se apoya en el derogado RD 3/2010; la fuerza normativa vigente hoy está en el artículo 28 del RD 311/2022, así que ancla siempre el argumento en el Real Decreto.
Segundo, el RD 311/2022 derogó por completo el RD 3/2010. Si alguien cita articulados antiguos del ENS, están obsoletos. Ojo también con los nombres de las medidas: varias se renombraron (por ejemplo, la actual mp.com.4 «Separación de flujos de información en la red» se llamaba «Segregación de redes» en el RD 3/2010), y muchas Declaraciones de Aplicabilidad heredadas todavía arrastran los nombres antiguos.
La DdA hace, por tanto, tres cosas: enumera las medidas seleccionadas, motiva las que no aplican y, cuando una medida se sustituye por otra equivalente, documenta la medida compensatoria. Este último caso lo regula el artículo 28.3:
Las medidas de seguridad referenciadas en el anexo II podrán ser reemplazadas por otras compensatorias, siempre y cuando se justifique documentalmente que protegen, igual o mejor, del riesgo sobre los activos (anexo I) y se satisfacen los principios básicos y los requisitos mínimos previstos en los capítulos II y III.
Fíjate en el estándar: «igual o mejor». Ese es el listón que superan las exclusiones bien planteadas.
Un catálogo de exclusiones bien fundadas
Estos son los casos que aparecen una y otra vez en proyectos reales. Para cada uno: qué protege la medida, en qué escenario deja de tener objeto y con qué frase se justifica.
«No tengo red local que proteger»
Es el grupo más rentable en organizaciones que operan 100% en la nube y en teletrabajo, sin oficina ni red corporativa propia.
mp.com.2, Protección de la confidencialidad. Es la medida que la gente traduce como «la VPN», pero su redacción es condicional:
Se emplearán redes privadas virtuales cifradas cuando la comunicación discurra por redes fuera del propio dominio de seguridad.
La palabra clave es «cuando». La VPN se exige en un escenario concreto: que las comunicaciones salgan de tu dominio de seguridad para alcanzar recursos internos a través de redes públicas. Es el caso clásico del teletrabajador que se conecta a la LAN de la oficina. Si no hay red local ni recursos internos accedidos por redes públicas (toda la infraestructura vive en cloud, con acceso nativo por TLS/SSL y autenticación multifactor), ese escenario no ocurre. No hay un «dentro» de red al que tunelar desde «fuera». Un apunte de vocabulario: mp.com.2 se aplica por el nivel de la dimensión de confidencialidad (BAJO, MEDIO o ALTO), no por la categoría; en nivel ALTO añade refuerzos (algoritmos autorizados por el CCN, dispositivos hardware para la VPN, productos conformes con op.pl.5), pero todos operan sobre el mismo supuesto condicional.
mp.com.4, Separación de flujos de información en la red. Su objetivo, según la norma: «La segmentación acota el acceso a la información y, consiguientemente, la propagación de los incidentes de seguridad, que quedan restringidos al entorno donde ocurren». Presupone una red propia que segmentar. En la nube, esa segmentación la implementan los mecanismos nativos del proveedor (VPC, subredes, security groups, IAM), no appliances de red propios. Se aplica por categoría: no aplica en BÁSICA; en ALTA exige refuerzos de segmentación y puntos de interconexión controlados.
mp.eq.4, Otros dispositivos conectados a la red. Exige que los dispositivos del sistema (multifuncionales, IoT, equipos de invitados) tengan una configuración que garantice el control del flujo de entrada y salida de información. Sin oficina ni LAN corporativa, no hay «otros dispositivos» periféricos conectados a una red que no existe; los únicos equipos son los portátiles cifrados de cada persona.
Un apunte honesto sobre la compensación: el RD no dice que op.nub.1 «Protección de servicios en la nube» sustituya a las medidas de red. Ese mapeo vive en las guías CCN-STIC (para cloud, la 823 «Seguridad en entornos cloud», con perfiles específicos 887 para AWS y 888 para Google Cloud), no en el articulado. La vía formal es la medida compensatoria del artículo 28.3: documentas que la protección equivalente la aportan op.nub.1, los controles nativos del proveedor y el cifrado TLS extremo a extremo, y demuestras que protegen «igual o mejor».
«No manejo soportes físicos»
mp.si.2, Criptografía. Dentro del marco de protección de los soportes de información, esta medida, según la norma, «se aplica, en particular, a todos los dispositivos removibles cuando salen de un área controlada. Se entenderán por dispositivos removibles, los CD, DVD, discos extraíbles, pendrives, memorias USB u otros de naturaleza análoga». Si la política de seguridad prohíbe los soportes extraíbles y toda la información se gestiona en servicios cloud cifrados, no existe el activo «dispositivo removible que sale de un área controlada». Se aplica por nivel de confidencialidad e integridad (en nivel BAJO ya figura «n.a.» por tabla; en MEDIO y ALTO es exclusión de vía 2, a motivar por inexistencia del soporte).
En la misma familia, mp.si.4 «Transporte» (garantizar la seguridad de los soportes desplazados fuera de las zonas controladas) queda sin objeto si no se transportan soportes físicos. Cuidado en cambio con mp.si.5 «Borrado y destrucción»: la norma la extiende a «todo tipo de equipos y soportes… medios electrónicos y no electrónicos», así que es prácticamente inexcluible y no conviene proponerla como exclusión.
«No genero evidencias electrónicas con valor probatorio»
mp.info.4, Sellos de tiempo. La norma exige que «los sellos de tiempo se aplicarán a aquella información que sea susceptible de ser utilizada como evidencia electrónica en el futuro», empleando «sellos cualificados de tiempo electrónicos» conforme al Reglamento (UE) n.º 910/2014 (eIDAS). Se activa por el nivel de la dimensión de trazabilidad: solo se exige en nivel ALTO. Si tu sistema no emite documentos electrónicos dirigidos a terceros que requieran un sello de tiempo cualificado para su validez legal (por ejemplo, una API que opera máquina a máquina y entrega resultados al sistema integrador, que es quien sellaría si su normativa lo exige), la medida no tiene objeto. La trazabilidad temporal interna se cubre con marcas de tiempo sincronizadas por NTP en los registros de actividad (op.exp.8) y la monitorización (op.mon), sin necesidad de una autoridad de sellado cualificada.
«No desarrollo software propio»
mp.sw.1, Desarrollo de aplicaciones. Exige aplicar seguridad al ciclo de desarrollo. No aplica en categoría BÁSICA por tabla; y en MEDIA o ALTA es una exclusión de vía 2 perfectamente defendible si la organización no programa software propio y se limita a producto de terceros o SaaS: no existe entorno de desarrollo al que aplicar la medida.
«No presto ni uso el servicio que activa la medida»
op.nub.1, Protección de servicios en la nube. Es el ejemplo inverso, y una trampa frecuente. Esta medida se aplica en todas las categorías (no tiene ninguna casilla «n.a.»), pero solo tiene contenido si existe el activo «servicio en la nube»: que la organización suministre cloud al sector público o utilice cloud de terceros. Si el sistema declarado no usa ni presta servicios en la nube, se excluye, pero como la tabla dice «aplica», es una exclusión de vía 2 que sí hay que motivar, no un «no aplica» automático.
mp.s.4, Protección frente a denegación de servicio. Protege los servicios expuestos a redes públicas. Si el sistema no expone servicios a Internet, no hay superficie de ataque de denegación de servicio que proteger (en nivel de disponibilidad BAJO, además, ya figura «n.a.» por tabla).
Resumen
| Medida | Título en el RD 311/2022 | Se exige según | Cuándo puedes excluirla |
|---|---|---|---|
| mp.com.2 | Protección de la confidencialidad | Nivel de confidencialidad | Sin recursos internos accedidos por redes públicas; acceso por TLS + MFA (vía 2) |
| mp.com.4 | Separación de flujos de información en la red | Categoría | Sin red propia que segmentar; segmentación nativa del proveedor cloud (vía 2) |
| mp.eq.4 | Otros dispositivos conectados a la red | Categoría | Sin LAN corporativa ni dispositivos periféricos (vía 2) |
| mp.si.2 | Criptografía | Nivel de confidencialidad e integridad | Sin dispositivos extraíbles que salgan de área controlada (vía 2) |
| mp.info.4 | Sellos de tiempo | Nivel de trazabilidad | Sin documentos electrónicos a terceros que exijan sello cualificado (vía 2) |
| mp.sw.1 | Desarrollo de aplicaciones | Categoría | Sin desarrollo de software propio; solo producto de terceros (vía 2) |
| op.nub.1 | Protección de servicios en la nube | Categoría | Si no se usan ni prestan servicios en la nube (vía 2) |
| mp.s.4 | Protección frente a denegación de servicio | Nivel de disponibilidad | Sin servicios expuestos a Internet (vía 2) |
| op.cont.2 | Plan de continuidad | Nivel de disponibilidad | Automático: «n.a.» salvo disponibilidad ALTA (vía 1) |
| op.ext.3 | Protección de la cadena de suministro | Categoría | Automático: «n.a.» salvo categoría ALTA (vía 1) |
Cómo lo ve el auditor (y por qué no te va a poner una no-conformidad)
Aquí está la parte que da tranquilidad, y que conviene tener por escrito antes de la auditoría.
La conformidad con el ENS se articula en tres guías CCN-STIC sobre el RD 311/2022: la 802 («Auditoría del ENS», la metodología), la 808 («Verificación del cumplimiento de las medidas en el ENS») y la 809 («Declaración, Certificación y Aprobación Provisional de conformidad con el ENS y distintivos de cumplimiento»). El marco legal que obliga a auditar es el artículo 31 y el Anexo III; la determinación y publicidad de la conformidad, el artículo 38 (recuerda: categoría BÁSICA admite declaración; MEDIA y ALTA requieren certificación por entidad acreditada por ENAC conforme a UNE-EN ISO/IEC 17065:2012).
La regla que necesitas conocer está en la guía CCN-STIC 808, y es literal:
con independencia de que sea de aplicación o no la medida de seguridad (si no es de aplicación la medida de seguridad, la auditoría debe verificar en este caso que el motivo de que no aplique sigue siendo vigente).
Léelo despacio. El auditor no penaliza que la medida no esté implantada. Ante un «no aplica», su trabajo es comprobar que el motivo de la no aplicabilidad sigue siendo cierto. La misma guía prevé, en su formato de verificación, marcar «No» en la aplicabilidad como respuesta válida: «Marque “Sí” en caso de que la medida de seguridad sea de aplicación al sistema que está auditando. En caso contrario marque “No”. Algunas medidas no permiten marcar “No”, ello se debe a que son medidas que siempre se deben aplicar».
De ahí sale, combinando tres fuentes, la conclusión de que un «no aplica» motivado no es una no-conformidad: el Anexo II dice que lo «n.a.» «no es exigible»; la DdA firmada por el responsable de seguridad lo legitima (art. 28.2); y la 808 instruye al auditor a validar el motivo, no a exigir la medida.
Playbook: cómo blindar una exclusión en cinco pasos
Este es el argumentario que conviene tener listo, medida por medida, para que la exclusión aguante cualquier revisión.
-
Ánclala en el activo, no en la comodidad. Nombra el activo o el escenario que la medida protege y demuestra que no existe dentro de tu alcance. La base legal es el artículo 28.1.a): las medidas se seleccionan «teniendo en cuenta los activos que constituyen los sistemas de información concernidos». «No lo necesitamos» no vale; «no existe el activo que esta medida protege» sí.
-
Hazla coherente con tu análisis de riesgos. El escenario que excluyes debe estar ausente o cubierto en tu análisis de riesgos (MAGERIT). Un auditor cruza la DdA con el análisis de riesgos y con el alcance: si el análisis identifica una red interna y la DdA dice que no la tienes, tienes una incoherencia, y las incoherencias sí generan hallazgos.
-
Escríbela y fírmala. La motivación va en la Declaración de Aplicabilidad, firmada por el responsable de la seguridad (art. 28.2). Una exclusión que solo vive en la cabeza del equipo técnico no existe para el auditor. La guía 806 lo exige: «esta no-aplicabilidad debe estar motivada».
-
Si sustituyes, documenta la compensación. Cuando no eliminas el objetivo de seguridad sino que lo cubres de otro modo (TLS, MFA, IAM, op.nub.1 en lugar de una VPN de red interna), documéntalo como medida compensatoria y describe la correspondencia con la medida del Anexo II que reemplaza, demostrando protección «igual o mejor» (art. 28.3).
-
Mantén el motivo vivo. La regla de la 808 es que el auditor verifica que el motivo «sigue siendo vigente». Revisa las exclusiones en cada actualización de la DdA. Si mañana abres una oficina con red local, la exclusión de mp.com.4 y mp.eq.4 deja de ser válida. Una exclusión es una fotografía de tu arquitectura actual, no un cheque en blanco.
Los cuatro errores que convierten una exclusión en no-conformidad
Por contraste, esto es lo que sí cuesta un hallazgo:
- Excluir una medida cuyo activo sí existe. Es el error más grave. Si tienes red local y excluyes la separación de flujos, no estás optimizando: estás incumpliendo. Y hay medidas (buena parte del marco organizativo, org.*) que la propia 808 marca como de aplicación obligatoria y no permiten marcar «No».
- Excluir sin motivar o sin firmar. Un «no aplica» sin justificación escrita en la DdA es, a efectos de auditoría, una medida no implantada y no explicada.
- Contradecir tu propio alcance o análisis de riesgos. La DdA no se audita en el vacío. Si no cuadra con el alcance certificado y con el análisis de riesgos, cae.
- Confundir las dos vías. Declarar unilateralmente «me marco n.a.» en una medida que la tabla sí exige para tu categoría o nivel, sin pasar por el juicio de aplicabilidad por activos ni por la medida compensatoria, es saltarse el procedimiento.
Lo que ganas
Cada medida que excluyes con fundamento es coste y complejidad que no asumes: un proveedor que no contratas, un appliance que no despliegas, un procedimiento que no mantienes, una superficie de auditoría que no tienes que defender año tras año.
Por eso, cuando en un proyecto de adecuación alguien pregunta qué proveedor de VPN, de segmentación o de sellado de tiempo necesita para su ENS ALTA, la respuesta más rentable y más conforme es, a menudo, «ninguno». No porque se renuncie a la seguridad, sino porque el ENS premia proteger lo que realmente tienes de forma proporcionada, no acumular controles que no protegen nada.
El mejor proveedor, muchas veces, es ninguno. La habilidad, y buena parte del trabajo del responsable de seguridad, está en saber justificarlo.
Fuentes
- Real Decreto 311/2022, por el que se regula el Esquema Nacional de Seguridad. Texto consolidado en el BOE: BOE-A-2022-7191. Artículos 7.2, 28.1, 28.2, 28.3, 31 y 38; Anexo II (disposiciones generales, selección de medidas, leyenda «n.a.» y medidas mp.com.2, mp.com.4, mp.eq.4, mp.si.2, mp.si.4, mp.si.5, mp.info.4, mp.sw.1, mp.s.4, op.cont, op.ext.3, op.nub.1); disposición derogatoria única.
- Guía CCN-STIC 806, «Plan de Adecuación del ENS» (la Declaración de Aplicabilidad es su apartado 3.7).
- Guía CCN-STIC 808, «Verificación del cumplimiento de las medidas en el ENS» (regla de auditoría del «no aplica» y formato de aplicabilidad).
- Guía CCN-STIC 809, «Declaración, Certificación y Aprobación Provisional de conformidad con el ENS y distintivos de cumplimiento», y guía CCN-STIC 802, «Auditoría del ENS».
- Guía CCN-STIC 823, «Seguridad en entornos cloud», con perfiles específicos 887 (AWS) y 888 (Google Cloud).
- Reglamento (UE) n.º 910/2014 (eIDAS), para los sellos cualificados de tiempo electrónicos referidos en mp.info.4.
- Portal oficial del ENS del Centro Criptológico Nacional: ens.ccn.cni.es.