Sí, se puede cumplir el ENS en la nube, pero no basta con contratar un proveedor «seguro». La referencia es la guía CCN-STIC 823 (utilización de servicios en la nube); la medida op.nub.1 del Anexo II te obliga a exigir conformidad al proveedor según el modelo de servicio (SaaS, PaaS, IaaS), y el organismo sigue siendo responsable de su parte dentro del modelo de responsabilidad compartida.
Este artículo trata una cosa concreta: cómo se cumple el ENS en la nube. No es lo mismo que la seguridad cloud en general. Si buscas cómo proteger los datos de tu empresa en la nube —cifrado, copias, control de accesos, RGPD— lo cuento en mi guía sobre seguridad en la nube para empresas. Lo de aquí es más específico y más exigente: el cumplimiento del Esquema Nacional de Seguridad cuando el servicio vive en la nube, con la guía CCN-STIC 823 como referencia y con el sector público de por medio. Lo veo tanto desde el lado del organismo que quiere migrar como desde el del proveedor SaaS que quiere entrar en un pliego.
¿Se puede cumplir el ENS en la nube? (respuesta rápida)
Sí, y no es una interpretación: el propio ENS lo contempla. Estos son los cinco puntos que resumen todo lo demás:
- Hay una guía específica. La CCN-STIC 823 orienta el uso de servicios en la nube dentro del ámbito del ENS: modelos de servicio, modelos de despliegue y condiciones para consumir nube con garantías.
- Hay una medida específica. La familia op.nub del Anexo II —en concreto op.nub.1, «Protección de los servicios en la nube»— aplica desde la categoría BÁSICA y obliga a que el servicio cloud cumpla el ENS o las medidas de la guía CCN-STIC correspondiente.
- La responsabilidad no se externaliza. El organismo propietario de la información sigue respondiendo del cumplimiento aunque contrate a un tercero.
- Los grandes proveedores tienen recorrido hecho. Azure, Microsoft 365 o AWS cuentan con perfiles de cumplimiento CCN-STIC (884, 885, 887), pero cubren su parte, no la tuya.
- La conformidad se acredita. Por declaración en categoría BÁSICA o por certificación en MEDIA y ALTA, con un alcance que debe cubrir de verdad el servicio prestado.
El resto del artículo desarrolla cada punto y lo baja a decisiones concretas según estés en el lado del comprador público o en el del proveedor.
Qué es la guía CCN-STIC 823 y qué resuelve
La CCN-STIC 823, «Utilización de servicios en la nube», es la guía de la serie 800 del Centro Criptológico Nacional dedicada a llevar el ENS a los entornos cloud. Nace de un problema real: el Anexo II se pensó para sistemas donde la organización controla la infraestructura, y en la nube ese control se reparte con el proveedor. La guía traduce ese reparto a criterios operativos.
Lo que ordena la 823, en la práctica:
- Modelos de servicio. Distingue IaaS (el cliente controla sistemas operativos, almacenamiento y aplicaciones), PaaS (controla las aplicaciones, no la infraestructura) y SaaS (consume el software sin administrar la plataforma). Cuanto más «arriba» está el servicio, más responsabilidad asume el proveedor.
- Modelos de despliegue. Nube pública, privada, comunitaria e híbrida, cada una con implicaciones distintas de aislamiento y de control.
- Niveles y dimensiones de seguridad. El servicio se valora en las cinco dimensiones del ENS —disponibilidad, integridad, confidencialidad, autenticidad y trazabilidad— y se le asigna un nivel que arrastra las medidas exigibles.
- Qué exigir al proveedor por contrato. Descripción del servicio, niveles de seguridad, localización de los datos, procedimientos de respaldo y borrado, y conformidad con las medidas del Anexo II según la categorización.
Un matiz útil de la guía: si cifras la información antes de transferirla a la nube y gestionas tú las claves, buena parte de los requisitos sobre el proveedor se concentran en la dimensión de disponibilidad, porque el proveedor no puede acceder al contenido. No elimina obligaciones, pero cambia el foco.
La medida op.nub del Anexo II: qué obliga en la nube
La reforma del Real Decreto 311/2022 incorporó al Anexo II una familia de medidas nueva dentro del marco operacional: op.nub, servicios en la nube. Es el punto donde el ENS deja de tratar la nube como un caso particular de «servicios externos» y le da entidad propia.
La medida op.nub.1, «Protección de los servicios en la nube», aplica desde la categoría BÁSICA —es decir, en todas— y viene a decir esto: los sistemas que suministran servicios en la nube al sector público se atienen al conjunto de medidas de seguridad según el modelo de servicio (SaaS, PaaS, IaaS), conforme a las guías CCN-STIC aplicables. Y cuando se usan servicios en la nube de terceros, los sistemas que los soportan deben ser conformes con el ENS o cumplir las medidas de una guía CCN-STIC que incluye, entre otros, requisitos de pruebas de auditoría.
La consecuencia práctica es doble. Para el organismo, op.nub.1 convierte «contratar nube» en «contratar nube conforme»: la exigencia deja de ser opcional. Para el proveedor, marca el estándar que tendrá que demostrar. Y como la propia medida remite a las guías CCN-STIC, la 823 y los perfiles específicos de cada plataforma dejan de ser recomendaciones para convertirse en el camino esperado.
Responsabilidad compartida: qué puedes delegar y qué no
El modelo de responsabilidad compartida es donde más proyectos se tuercen. La idea que repite la CCN-STIC 823 es tajante: la responsabilidad del cumplimiento del ENS recae siempre sobre el organismo propietario de la información. Puedes delegar la operación; no puedes delegar la responsabilidad.
La línea que separa lo que asume el proveedor de lo que sigue siendo tuyo depende del modelo de servicio:
- En IaaS, el proveedor responde del centro de datos, la virtualización y la disponibilidad física; tú respondes del sistema operativo hacia arriba: parcheo, configuración, identidades, datos.
- En PaaS, el proveedor sube un escalón y gestiona la plataforma; tú sigues respondiendo de la aplicación, de sus accesos y de la información.
- En SaaS, el proveedor asume casi toda la pila técnica, pero tú nunca dejas de responder de la gestión de identidades, la configuración del servicio, la clasificación de la información y su ciclo de vida.
Hay una constante en los tres modelos: la identidad, la configuración y los datos casi siempre se quedan de tu lado. El error clásico es dar por hecho que «como el proveedor tiene el ENS, yo ya cumplo». No: su conformidad cubre su parte del reparto. La tuya la sigues teniendo que implantar y demostrar.
Si eres una Administración: cómo contratar nube conforme al ENS
Cuando un organismo quiere consumir nube sin salirse del ENS, el trabajo empieza antes de elegir proveedor. La secuencia que recomiendo:
- Categoriza el sistema primero. Valora la información y los servicios en las cinco dimensiones y determina la categoría (BÁSICA, MEDIA o ALTA). Esa categoría fija qué le puedes exigir a la nube.
- Traslada la categoría al pliego. No pidas «un proveedor con ENS»: pide conformidad en la categoría que corresponde y con un alcance que cubra el servicio concreto que vas a usar, no otra unidad del proveedor.
- Fija la localización de los datos. Según la categoría y el tipo de información, exige tratamiento en la UE y, cuando proceda, en territorio nacional, con la jurisdicción aclarada por contrato.
- Reserva tus responsabilidades. Deja por escrito qué medidas implantas tú (identidad, cifrado con claves bajo tu control, registro de actividad, continuidad) y cuáles el proveedor.
- Pide evidencias auditables. Informes de conformidad, registros accesibles, resultados de las pruebas de auditoría que la propia op.nub.1 menciona.
Si vas a exigir el ENS a tus proveedores en un pliego, conviene tener claro antes quién está obligado a cumplir el ENS y en qué condiciones, para no pedir de más ni de menos.
Si eres un SaaS o proveedor cloud: cómo vender a la Administración con el ENS
Desde el otro lado de la mesa, la pregunta cambia: ¿qué necesito para que un organismo público pueda contratarme sin incumplir? La respuesta corta es acreditar la conformidad ENS de tu servicio en la categoría que te pidan los pliegos, y tener el alcance bien definido.
Lo que suelo ver que marca la diferencia:
- Alcance de la declaración o certificación. El certificado tiene que cubrir el servicio que vendes y la plataforma desde la que lo prestas. Un certificado real cuyo alcance no incluye tu producto no te sirve para licitar.
- Categoría adecuada. BÁSICA se puede acreditar por declaración de conformidad; MEDIA y ALTA exigen certificación por una entidad acreditada. Apunta a la que te van a pedir tus clientes públicos.
- Herencia de controles. Si te apoyas en un hiperescalar con perfil CCN-STIC, puedes heredar parte de sus controles, pero tienes que documentar qué añades tú por encima.
- Auditoría preparada. El proceso incluye pruebas de auditoría; llegar con la documentación y las evidencias ordenadas acorta plazos y coste. Te cuento el recorrido en el proceso y costes de la certificación ENS.
Si te mueves habitualmente en licitaciones públicas, en ENS para proveedores de la Administración desarrollo cómo aparece esta exigencia en los pliegos y cómo se traslada en cascada a los subcontratistas.
Servicios cloud en el CPSTIC y los perfiles CCN-STIC 884-887
Aquí es donde muchos proveedores se pierden, porque conviven dos mecanismos distintos.
Por un lado, el catálogo CPSTIC del CCN incluye una taxonomía de servicios en la nube: recoge productos y servicios cualificados para sistemas afectados por el ENS en categorías MEDIA y ALTA. Que un servicio figure en el CPSTIC da al comprador público una confianza mínima verificada por el propio Centro. El acceso al catálogo completo requiere registro como usuario del CCN.
Por otro, existen los perfiles de cumplimiento específicos: guías CCN-STIC que detallan cómo desplegar un hiperescalar concreto de forma conforme al ENS. Los que conviene conocer:
- CCN-STIC 884 — perfil de cumplimiento específico para Azure (servicio de cloud corporativo).
- CCN-STIC 885 — perfil para Microsoft 365, con sus guías de configuración segura asociadas.
- CCN-STIC 886 — perfil para nubes privadas y comunitarias.
- CCN-STIC 887 — perfil de cumplimiento específico para AWS (servicio de cloud corporativo), con su guía de configuración.
La idea de estos perfiles es que no partas de cero: si despliegas sobre Azure o AWS siguiendo su guía, heredas una base de controles ya trabajada y te concentras en tu parte. Ahora bien, un perfil de plataforma no es un certificado de tu servicio: acredita cómo usar la nube de forma conforme, no que tu SaaS lo sea. Esa distinción evita muchos malentendidos en la negociación.
Medidas del Anexo II con lectura cloud: cifrado, datos y ubicación
Las medidas de seguridad del Anexo II no cambian en la nube, pero sí cómo se aplican y quién responde de cada una. Esta tabla resume la lectura cloud de las que más peso tienen en un proyecto real.
| Aspecto de seguridad | Lectura en la nube | Qué exigir o verificar |
|---|---|---|
| Cifrado de la información | Datos cifrados en tránsito y en reposo; cifrarlos antes de subirlos concentra el riesgo del proveedor en la disponibilidad | Gestión de claves bajo tu control siempre que sea posible |
| Localización de los datos | Dónde se procesan y almacenan, y bajo qué jurisdicción | Región UE o nacional según categoría y pliego, aclarada por contrato |
| Segregación y multi-tenencia | Aislamiento entre clientes que comparten infraestructura | Evidencia de separación; en niveles altos, no compartir recursos con comunidades de menor nivel |
| Identidad y control de acceso | Federación, autenticación reforzada y gestión de identidades | Sigue siendo tu responsabilidad configurarla y gobernarla |
| Trazabilidad y registro | Los registros de actividad se generan en la plataforma del proveedor | Acceso a los logs, su retención y su exportabilidad |
| Continuidad y salida | Disponibilidad, copias reversibles y reversibilidad del servicio | Objetivos de recuperación medibles, devolución de datos y borrado certificado |
La lectura transversal es la de siempre en la nube: el proveedor pone la capacidad técnica; tú pones el gobierno. Cifrado, identidad y datos rara vez dejan de ser tu responsabilidad, aunque los ejecute su plataforma.
Pasos para un SaaS que parte de cero
Si tienes un producto y quieres venderlo a la Administración pero nunca has tocado el ENS, este es el orden que funciona:
- 1. Delimita el alcance. Qué servicio exacto vas a acreditar y sobre qué infraestructura corre. Todo lo demás depende de esta frase.
- 2. Categoriza. Valora tu servicio en las cinco dimensiones y fija la categoría objetivo según lo que pidan tus clientes potenciales.
- 3. Elige base de nube. Si vas a apoyarte en un hiperescalar, adopta su perfil CCN-STIC (884, 885, 887) y hereda lo que puedas heredar.
- 4. Análisis de riesgos y declaración de aplicabilidad. Documenta qué medidas del Anexo II aplican y cómo las cubres, distinguiendo lo heredado de lo propio.
- 5. Implanta lo que falte. Identidad, cifrado, registro, continuidad y gestión de incidentes en tu capa de servicio.
- 6. Audita y acredita. Declaración de conformidad en BÁSICA o certificación por entidad acreditada en MEDIA y ALTA, tras superar la auditoría de conformidad.
No hay atajos, pero sí un orden que evita rehacer el trabajo: alcance, categoría, herencia, documentación, implantación y auditoría. Saltarse el alcance al principio es el error que más caro sale.
Conclusión: la nube no te saca del ENS, te cambia el reparto
Migrar a la nube no diluye el Esquema Nacional de Seguridad; redistribuye quién hace cada cosa. La guía CCN-STIC 823 y la medida op.nub.1 fijan las reglas, los perfiles CCN-STIC y el CPSTIC te ahorran camino, pero la responsabilidad de la información no se sube a ningún servidor ajeno: se queda contigo. Un organismo que lo entiende contrata mejor; un proveedor que lo entiende vende antes.
Si estás valorando llevar un sistema público a la nube, o tienes un SaaS y te acaban de pedir el ENS para entrar en un pliego, cuéntame tu caso y lo vemos juntos, sin compromiso.
¿Necesitas acreditar la conformidad de tu servicio cloud para vender a la Administración? Conoce mi servicio de consultoría ENS para empresas que quieren licitar o ser proveedoras del sector público.