La medida op.nub.1 del Anexo II del ENS exige que los servicios en la nube de terceros sean conformes con el ENS o cumplan una guía CCN-STIC equivalente sobre pentesting, transparencia, cifrado y gestión de claves, y jurisdicción de los datos. Aplica ya desde categoría básica, sin refuerzo. Y un proveedor certificado no te exime de responsabilidad: el artículo 13.5 del Real Decreto 311/2022 la deja en la entidad que presta el servicio final.
El Esquema Nacional de Seguridad exige una medida específica para cuando un sistema usa servicios en la nube: op.nub.1, protección de servicios en la nube. Y no, contratar un proveedor cloud "certificado" o "compatible con ENS" no te libera de responsabilidad: el propio Real Decreto 311/2022 dice, literalmente, que la responsabilidad última sigue siendo de tu organización.
La medida específica: op.nub.1, «Protección de servicios en la nube»
Si estás valorando migrar o ya trabajas con infraestructura cloud, esto es lo que el ENS exige a ese proveedor. La medida op.nub.1 del Anexo II del Real Decreto 311/2022 es la única de su familia (op.nub) y aplica ya desde categoría básica, sin refuerzo. El texto del requisito [op.nub.1.1] remite el cumplimiento a las guías CCN-STIC que sean de aplicación según el modelo de servicio contratado, y el requisito [op.nub.1.2] añade, para servicios prestados por terceros, la exigencia textual siguiente:
«Cuando se utilicen servicios en la nube suministrados por terceros, los sistemas de información que los soportan deberán ser conformes con el ENS o cumplir con las medidas desarrolladas en una guía CCN-STIC que incluirá, entre otros, requisitos relativos a: a) Auditoría de pruebas de penetración (pentesting). b) Transparencia. c) Cifrado y gestión de claves. d) Jurisdicción de los datos.»
— Real Decreto 311/2022, Anexo II, requisito [op.nub.1.2] (BOE-A-2022-7191)
Esta medida forma parte del mismo Anexo II que desglosamos aquí, y aplica ya en básica: para ver el resto de medidas de tu categoría, consulta el listado completo de básica, o resuelve dudas sobre cualquier otra medida en el ENS navegable del CCN.
Qué exige según el modelo de servicio: SaaS, PaaS e IaaS
El requisito [op.nub.1.1] no trata igual un SaaS que un IaaS: cuanta más responsabilidad de gestión asume el proveedor (SaaS), más recae en él la aplicación de las guías CCN-STIC correspondientes; cuanta más responsabilidad recae en el cliente (IaaS), más control técnico directo tienes tú y más evidencias tendrás que aportar tú mismo. La diferencia entre estos tres modelos ya la explicamos aquí: el ENS exige de forma distinta según cuál contrates, no porque la norma discrimine entre modelos, sino porque el reparto real de responsabilidad técnica cambia.
En un SaaS, el proveedor gestiona toda la pila técnica: sistema operativo, red, aplicación. Ahí, la evidencia que puedes exigir es sobre todo documental —certificaciones, informes de auditoría, cláusulas contractuales— porque no tienes acceso directo a la infraestructura subyacente. En un IaaS, el proveedor solo gestiona la capa de infraestructura física y de virtualización; el sistema operativo, las aplicaciones y buena parte de la configuración de seguridad quedan de tu lado, así que las evidencias que op.nub.1 exige del "servicio en la nube" se reparten entre lo que aporta el proveedor y lo que tienes que documentar tú mismo sobre tu propia capa. Un PaaS queda en un punto intermedio: el proveedor gestiona el entorno de ejecución, pero el código y buena parte de la configuración de la aplicación siguen siendo responsabilidad tuya. Confundir estos tres repartos es la causa más habitual de que una Declaración de Aplicabilidad para op.nub.1 quede incompleta: se documenta lo que aporta el proveedor y se olvida lo que queda del lado del cliente.
Qué debe pedirse a un proveedor cloud de terceros: conformidad ENS o guía CCN-STIC equivalente
El propio Anexo II da dos vías válidas para un proveedor de terceros: que el servicio sea conforme con el ENS, o que cumpla con una guía CCN-STIC equivalente que cubra los cuatro puntos citados en la cita textual anterior. No basta con pedir "una certificación de seguridad" genérica: hay que pedir evidencia concreta de esos cuatro puntos, o de la conformidad ENS del servicio contratado. Tampoco basta con asumir que un proveedor conocido internacionalmente cumple esto de forma automática por su tamaño o su reputación: la exigencia es documental y específica, no una presunción de confianza.
En la práctica, esto se traduce en pedir al proveedor, antes de firmar, la documentación concreta que acredite cada uno de los cuatro puntos —no una declaración genérica de "cumplimos con los estándares del sector"—, y dejar constancia por escrito de qué guía CCN-STIC o qué esquema de conformidad ENS ampara el servicio contratado. Si el proveedor no puede identificar con precisión cuál de las dos vías cubre su servicio, es una señal de que el análisis no se ha hecho todavía, ni por su parte ni por la tuya.
Los cuatro puntos que la guía exige revisar: pentesting, transparencia, cifrado y gestión de claves, jurisdicción de los datos
- Auditoría de pruebas de penetración (pentesting): exigir evidencia de que el servicio se somete a pruebas de intrusión periódicas. La exigencia de pentesting al proveedor cloud conecta directamente con pentesting y red teaming, que explicamos en detalle en esa guía.
- Transparencia: visibilidad real sobre dónde y cómo se procesan los datos, no una declaración genérica de confianza.
- Cifrado y gestión de claves: el cifrado en tránsito que exige esta guía se apoya en los mismos fundamentos de TLS que ya tratamos aquí, además de la gestión del ciclo de vida de las claves.
- Jurisdicción de los datos: a qué ley está sujeto el proveedor, no solo en qué país físico está el centro de datos. Este matiz —un proveedor puede estar sujeto a legislación extranjera aunque aloje los datos en un centro de datos europeo— conviene verificarlo caso por caso en el contrato, no darlo por sentado.
Los refuerzos: certificación reconocida (R1) y guías de configuración específicas (R2)
Sobre la medida base, el Anexo II añade dos refuerzos: R1 exige que el servicio esté certificado bajo una metodología reconocida por el Organismo de Certificación del CCN, y R2 exige que la configuración del servicio siga una guía CCN-STIC de Configuración de Seguridad Específica.
Qué categoría exige qué: básica, media y alta en op.nub.1
- Categoría básica: op.nub.1 sin refuerzo.
- Categoría media: op.nub.1 + R1 (certificación reconocida).
- Categoría alta: op.nub.1 + R1 + R2 (certificación reconocida y guía de configuración específica).
La responsabilidad NO se transfiere al proveedor (aunque esté certificado)
El artículo 13.5 del Real Decreto 311/2022 es explícito sobre este punto. En servicios externalizados, el proveedor designa un punto de contacto de seguridad, pero:
«[...] sin perjuicio de que la responsabilidad última resida en la entidad del sector público destinataria de los citados servicios.»
— Real Decreto 311/2022, art. 13.5 (BOE-A-2022-7191)
Un proveedor cloud certificado ENS reduce el riesgo y facilita la evidencia, pero no traslada la responsabilidad legal. Si tu proveedor cloud falla, la continuidad del servicio sigue dependiendo de un plan de backup y recuperación real, no solo de la promesa del proveedor; y de que esas copias restauren de verdad, no solo de que existan.
Esta distribución de responsabilidad tiene una consecuencia práctica que se pasa por alto con frecuencia: si un incidente de seguridad se origina en la infraestructura del proveedor cloud, la entidad que presta el servicio final sigue siendo la que responde ante el auditor de conformidad del ENS, sigue siendo la que tiene que notificar el incidente conforme a sus propios procedimientos, y sigue siendo la que asume las consecuencias de una eventual sanción o incumplimiento. El contrato con el proveedor puede repartir después esa responsabilidad económica entre las partes, pero eso ocurre en un plano distinto —el civil o mercantil— del que fija el artículo 13.5: frente al ENS, la responsabilidad no se subcontrata.
Cómo se traduce esto en la práctica: cláusulas contractuales y evidencias que pedir
En un contrato o pliego con un proveedor cloud sujeto a op.nub.1, conviene exigir por escrito: evidencia de conformidad ENS o de cumplimiento de la guía CCN-STIC equivalente; informes de pentesting periódicos; documentación de cifrado en tránsito y en reposo con gestión de claves propia o compartida claramente definida; y una cláusula explícita de jurisdicción de los datos. Calcula además el coste real de un backup en la nube que cumpla estas exigencias con esta calculadora.
Un error habitual al preparar la Declaración de Aplicabilidad es documentar op.nub.1 con una única frase genérica del tipo "se usa un proveedor cloud de confianza" y darla por cerrada. El auditor de conformidad —o el propio responsable de seguridad en una autoevaluación de básica— necesita evidencia concreta y fechada: el contrato o anexo técnico donde consta la vía de conformidad elegida, el último informe de pentesting recibido del proveedor (o encargado a un tercero sobre el servicio contratado), y la política de cifrado y gestión de claves aplicada, con indicación de quién custodia las claves y bajo qué condiciones se puede acceder a ellas. Sin esos tres documentos fechados, la medida queda declarada pero no demostrada, que es precisamente la distinción que separa una autoevaluación sólida de una autoevaluación de trámite.
Auditar si tu proveedor cloud actual cumple lo que exige op.nub.1 es parte de nuestro servicio de implantación técnica del ENS.
Preguntas frecuentes
¿Un proveedor cloud certificado ENS me exime de responsabilidad?
No. El artículo 13.5 del Real Decreto 311/2022 establece que la responsabilidad última reside en la entidad que presta el servicio final, aunque el proveedor cloud subcontratado esté certificado y designe su propio punto de contacto de seguridad.
¿Necesito un proveedor con Declaración de Conformidad ENS o basta con una certificación internacional (ISO 27001, SOC 2)?
El requisito [op.nub.1.2] exige conformidad con el ENS o cumplimiento de una guía CCN-STIC equivalente que cubra pentesting, transparencia, cifrado/gestión de claves y jurisdicción de los datos. Una certificación internacional genérica no sustituye automáticamente esa exigencia: hay que pedir evidencia específica de esos cuatro puntos.
¿Esta medida aplica desde qué categoría?
Desde básica, sin refuerzo. En media se añade el refuerzo R1 (certificación reconocida) y en alta se añaden R1 y R2 (además, la guía de configuración específica).
Este contenido tiene carácter divulgativo y orientativo. No constituye asesoramiento legal ni sustituye el análisis de un profesional cualificado para tu caso concreto.