ENS en la nube: requisitos y guía CCN-STIC 823

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.

BLOQUE 1 — Qué exigir por contrato a AWS, Azure, Google Cloud o a tu hosting

La medida op.nub.1 y la guía CCN-STIC 823 te dicen qué debe cumplirse; el contrato es donde eso se vuelve exigible. Da igual que el proveedor sea un hiperescalar o un hosting gestionado: si el sistema está dentro del alcance del ENS, estas cláusulas tienen que estar por escrito.

• Conformidad con alcance nominal. No basta «el proveedor está certificado en el ENS»: el certificado debe cubrir el servicio concreto que contratas, en tu categoría o superior. Pide el documento, no el logo.

• Localización y jurisdicción. Región de tratamiento y almacenamiento pactada por contrato. Los tres grandes ya tienen región en España: AWS en Aragón, Azure y Google Cloud en Madrid. Si el pliego exige territorio nacional, nómbrala.

• Evidencias auditables. Derecho a recibir el certificado de conformidad vigente y el informe de auditoría (los tres hiperescalares los publican en sus portales de confianza), más acceso a los registros de actividad de tu servicio, con retención y exportación pactadas.

• Gestión de claves. Si cifras con claves bajo tu control, dilo en el contrato: cambia el reparto de responsabilidades y concentra el riesgo del proveedor en la disponibilidad, como recoge la propia CCN-STIC 823.

• Notificación de incidentes. Plazos y canal de aviso al organismo cuando el incidente afecte a su información, alineados con la obligación de reporte que el organismo tiene frente al CCN-CERT.

• Salida y borrado. Reversibilidad con formato pactado, plazo de devolución de datos y borrado certificado al terminar.

• Cadena de suministro. La cláusula que casi nadie escribe: si eres el proveedor de la Administración y montas tu servicio sobre un tercero (un SaaS sobre AWS, una web sobre un hosting), el pliego te exige la conformidad a ti, y tú debes trasladar contractualmente los requisitos al siguiente eslabón. La exigencia baja en cascada; la responsabilidad ante el organismo no baja contigo. Cómo aparece esto en los pliegos lo desarrollo en ENS para proveedores de la Administración.

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-888

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.
• CCN-STIC 888 — perfil de cumplimiento específico para Google Cloud (servicio de cloud corporativo), con sus guías de configuración segura 888A (Google Workspace) y 888B (GCP).

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.

BLOQUE 2 — Qué certificación ENS tienen los grandes clouds en España (verificado)

Esto es lo que acredita cada proveedor a fecha de esta actualización, contrastado con sus páginas oficiales de cumplimiento:

Dos avisos antes de copiar esta tabla en un pliego o en una oferta. Primero: los alcances cambian con cada renovación, así que comprueba el certificado vigente en el buscador público de certificados de conformidad del CCN el día que lo necesites; explico cómo hacerlo paso a paso en cómo consultar el listado de empresas certificadas en el ENS. Segundo: la última fila es la trampa habitual de las pymes. Un hosting gestionado serio con ISO 27001 y SOC 2 es un buen proveedor para muchas cosas, pero sin conformidad ENS propia no resuelve op.nub.1 por sí solo, aunque su infraestructura sea la de un hiperescalar certificado. La certificación de Google cubre la capa de Google; la capa del hosting es otro eslabón de la cadena.

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.

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.

BLOQUE 3 — «El cloud ya está certificado, yo no tengo que hacer nada»: el error que más proyectos tumba

Lo escucho en casi cada primer contacto con un SaaS que quiere licitar. La frase suena razonable y es falsa por cinco vías distintas:

1. El certificado del hiperescalar no nombra tu servicio. Cubre los servicios de AWS, Azure o Google que aparecen en su alcance; tu producto no está en esa lista y nunca lo estará.
2. Heredar controles no es heredar conformidad. Los perfiles 884-888 te ahorran implantación, pero la declaración o certificación de tu servicio sigue siendo tuya, con tu análisis de riesgos y tu declaración de aplicabilidad.
3. Su categoría no fija la tuya. Que la plataforma esté certificada en ALTA no te da la ALTA: tu categoría sale de valorar tu información y tus servicios, no de la factura del proveedor.
4. La configuración por defecto no es conforme. Los perfiles de cumplimiento existen precisamente porque la misma nube se puede desplegar bien o mal; lo que se audita es cómo la usas tú.
5. La responsabilidad no viaja con el contrato. Como vimos en el modelo de responsabilidad compartida, el organismo responde de su información y tú de tu servicio; el hiperescalar solo responde de su capa.

Si te reconoces en la frase del título, el primer paso no es contratar nada: es medir dónde estás. Puedes hacerlo en diez minutos con mi autodiagnóstico ENS gratuito y ver el mapa completo de obligaciones en la guía de cumplimiento del ENS.

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.

Preguntas frecuentes

¿Un SaaS necesita certificarse en el ENS para vender a la Administración?

Si el servicio trata información o presta funciones para una entidad pública, cada vez más pliegos lo exigen. La vía es acreditar la conformidad ENS del servicio en la categoría que pida el cliente público: por declaración de conformidad en categoría BÁSICA, o por certificación de una entidad acreditada en MEDIA y ALTA. El alcance del certificado debe cubrir de verdad el servicio y la plataforma desde la que se presta.

¿Qué es la guía CCN-STIC 823?

Es la guía del Centro Criptológico Nacional que orienta el uso de servicios en la nube dentro del ámbito del ENS. Distingue los modelos de servicio (IaaS, PaaS, SaaS) y de despliegue (pública, privada, comunitaria e híbrida), valora el servicio en las cinco dimensiones de seguridad del ENS y detalla qué debe exigir por contrato el organismo que consume nube, desde la localización de los datos hasta el borrado seguro.

¿Qué obliga la medida op.nub del ENS?

La medida op.nub.1, «Protección de los servicios en la nube» del Anexo II del Real Decreto 311/2022, aplica desde la categoría BÁSICA y exige que el servicio cloud cumpla el ENS o las medidas de la guía CCN-STIC aplicable según su modelo de servicio (SaaS, PaaS, IaaS), incluidos requisitos de pruebas de auditoría.

¿Puedo usar AWS, Azure o Google Cloud y cumplir el ENS?

Sí, con matices. Azure, Microsoft 365, AWS y Google Cloud cuentan con perfiles de cumplimiento específicos CCN-STIC (884, 885, 887 y 888) que explican cómo desplegarlos de forma conforme al ENS. Ese perfil cubre la parte del proveedor: verifica siempre el alcance y la región exactos, y recuerda que la identidad, la configuración y los datos siguen siendo responsabilidad tuya.

¿El certificado ENS de mi proveedor cloud me exime de certificarme?

No. Cubre la parte del proveedor dentro del modelo de responsabilidad compartida. El organismo o el SaaS que construye encima sigue siendo responsable de sus propias medidas —identidad, cifrado, configuración, registro y operación— y debe acreditar su propia conformidad cuando el pliego se la exige.

¿Dónde deben estar ubicados los datos bajo el ENS en la nube?

Depende de la categoría del sistema y del tipo de información. La tendencia de los pliegos es exigir tratamiento en la Unión Europea y, en ciertos casos, en territorio nacional, con la jurisdicción aclarada por contrato. Conviene fijarlo de forma expresa y no darlo por supuesto por el hecho de contratar una región europea.

¿Un SaaS alojado en AWS o Azure hereda su certificación ENS?

No. La certificación del hiperescalar cubre su capa de infraestructura. El SaaS debe acreditar su propia conformidad —declaración en BÁSICA, certificación en MEDIA y ALTA— aunque herede controles documentados del perfil CCN-STIC de su plataforma.

¿Puedo usar Kinsta u otro hosting gestionado en un sistema bajo el ENS?

Como pieza de un sistema, solo si la conformidad del conjunto queda acreditada por otra vía: estos hostings publican ISO 27001 o SOC 2, pero no conformidad ENS, así que no satisfacen op.nub.1 por sí solos. Para servicios que un organismo consuma directamente, busca proveedores con certificado ENS vigente.

¿Dónde compruebo si un proveedor está certificado de verdad?

En el buscador público de certificados de conformidad del CCN (gobernanza.ccn-cert.cni.es) y pidiendo el certificado con su alcance. Un sello en la web no prueba nada: el documento debe nombrar el servicio y la categoría.

¿Qué categoría ENS debo exigir a mi proveedor cloud?

La de tu sistema, que sale de categorizar tu información y servicios en las cinco dimensiones. Exigir de más encarece la oferta sin motivo; exigir de menos invalida el cumplimiento. La categoría se fija antes de redactar el pliego, nunca después.