GRCreal // expediente: guía CCN-STIC referencia: CCN-STIC 823
← Volver a Guías CCN-CERT
CCN-STIC · Serie 800 · ENS

CCN-STIC 823
Cloud Computing en el ENS

Nube y ENS: el reparto de responsabilidades que casi nadie documenta.

♙ Miguel Ángel Carriazo
▣ 18 junio 2026
◷ 13 min de lectura
LEE ESTA GUÍA CUANDO...

Necesites trabajar sobre cloud y ens dentro del ENS.

En vez de buscar una frase aislada, sigue el recorrido de la guía y relaciona cada conclusión con el sistema, el responsable y la evidencia que debería existir.

CCN-STIC 823 · Cloud y ENS
Dónde encaja esta guía en una revisión práctica
01Servicio02Responsabilidad03Proveedor04Control PREGUNTA → CRITERIO → IMPLANTACIÓN → EVIDENCIA REVISABLE
Utiliza la guía para orientar la revisión y contrasta siempre la versión vigente en el portal oficial del CCN-CERT.
Qué es

Qué es y para qué vale

La CCN-STIC 823 aborda cómo aplicar el ENS cuando los sistemas están en la nube: el reparto de responsabilidades entre cliente y proveedor, la conformidad del servicio cloud y las medidas que siguen siendo tuyas aunque «todo esté en el proveedor». Incluye cláusulas y acuerdos de nivel de servicio orientados a la seguridad.

Es una guía clave hoy, cuando prácticamente todo es SaaS, PaaS o IaaS. El error más extendido es asumir que la conformidad del proveedor te cubre por completo. No es así: en la nube la responsabilidad es compartida, y hay medidas (configuración, gestión de accesos, protección del dato) que siguen siendo del cliente por mucho que el proveedor esté certificado.

La guía se basa en la definición de cloud computing de ISO/IEC 17788 y establece cinco características esenciales: auto-servicio a demanda, amplio acceso a redes, agregación y compartición de recursos, adaptación inmediata y servicio consumido.

Mi lectura

Mover un sistema al cloud no mueve la responsabilidad fuera del alcance.

La 823 es especialmente útil porque el cloud genera dos extremos igual de peligrosos. El primero: «el proveedor ya está certificado». El segundo: intentar gestionar un servicio cloud exactamente como si fuera infraestructura propia. Entre ambos está el modelo real de responsabilidad compartida.

Necesito entender el servicio concreto: IaaS, PaaS, SaaS, región, identidad, cifrado, registros, operación, soporte y subcontratación. Una certificación del proveedor puede aportar evidencia, pero no demuestra cómo has configurado tu tenant, tus identidades ni tus datos.

En cloud, muchas brechas no están en la plataforma. Están en la frontera entre lo que el proveedor controla y lo que la organización creyó que controlaba.
CCN-STIC 823 · Responsabilidad compartida
Cómo leer el cloud sin perder de vista quién controla cada capa
PROVEEDOR CLOUD plataforma · infraestructura · disponibilidad base RESPONSABILIDAD COMPARTIDA identidad · logging · cifrado · configuración · soporte ORGANIZACIÓN datos · permisos · tenant · operación · salida
Lectura técnica GRCREAL: una manera práctica de conectar la guía con arquitectura, operación y evidencia.
Explicación técnica

Qué me interesa técnicamente de esta guía

La guía 823 obliga a aterrizar el cloud por capas. No es lo mismo revisar IaaS, PaaS o SaaS; ni un tenant administrado que un servicio casi cerrado. Técnicamente, la clave está en separar qué heredas del proveedor, qué configuras tú y qué controles quedan repartidos entre ambos. Identidad, red, cifrado, logging, copia, recuperación, soporte y subcontratación no se gobiernan igual en todos los modelos.

También es importante mirar la dependencia operativa. Un control puede existir gracias a capacidades nativas del proveedor, pero eso no elimina la obligación de entenderlo, supervisarlo y preparar escenarios de degradación, cambio o salida. La responsabilidad compartida no reduce responsabilidad; la redistribuye.

Yo leería esta guía siempre con una arquitectura real delante: servicio concreto, región, tenant, datos, dependencias y contrato. Sin ese contexto, el cloud se convierte en una conversación genérica que aporta poco valor al expediente ENS.

Qué mapearía por servicio cloud

Modelo de servicio, región, tenant, identidades, privilegios, conectividad, datos, cifrado, logging, backup, recuperación, soporte, subprocesadores y salida. Para cada control, marcaría proveedor, cliente o responsabilidad compartida.

La evidencia del proveedor debe revisarse por alcance. Una certificación puede cubrir la plataforma, pero no tu configuración ni tus decisiones de acceso y retención.

Error habitual

Dónde suele torcerse en proyectos reales

DONDE SUELE TORCERSE
Suponer que la certificación o madurez del proveedor cubre automáticamente la configuración del cliente. Este error es habitual porque el cloud empaqueta mucha seguridad nativa y da sensación de control. Pero los problemas más comunes siguen apareciendo en identidades, permisos, almacenamiento expuesto, logging insuficiente, claves mal gobernadas o dependencias no comprendidas.

El otro extremo es intentar tratar el cloud exactamente como si fuera CPD propio, desperdiciando las particularidades del servicio y complicando la operación sin ganar control real.
Ejemplo práctico

Cómo lo aterrizaría en un caso real

CASO
Piensa en una aplicación desplegada en un PaaS con autenticación federada, almacenamiento gestionado y copias automáticas. El proveedor puede demostrar disponibilidad de plataforma, cifrado base o determinadas certificaciones. Pero la organización sigue necesitando responder por configuración de identidades, privilegios, exposición de datos, retención de logs, revisión de alertas y capacidad de recuperar o portar información si cambia la relación contractual.

Mi forma de aterrizarlo es dibujar la cadena completa de responsabilidad control por control. En cuanto haces ese ejercicio, la conversación deja de ser “¿está el proveedor certificado?” y pasa a ser “¿qué parte de este control depende de nosotros y cómo lo demostramos?”.
Ejemplo técnico de infraestructura

Aplicación PaaS con identidad federada y logs incompletos

EJEMPLO TÉCNICO · INFRAESTRUCTURA
Componentes implicados en el caso
IdPPaaSDBaaSSIEMBackup SERVICIO → DEPENDENCIA → CONTROL → EVIDENCIA
INFRA
Una aplicación en PaaS utiliza identidad corporativa y base de datos gestionada. El proveedor cubre plataforma y disponibilidad, pero los logs de aplicación no se exportan al SIEM y las copias dependen de una configuración que nadie ha probado.

Arquitectura técnica: IdP, PaaS, base de datos gestionada, storage, SIEM y backup cloud.
Responsabilidad del proveedor: infraestructura y servicio base.
Responsabilidad propia: identidades, permisos, logging, retención, datos y recuperación.
Qué haría: matriz control por control, exportación de logs, prueba de restore y estrategia de salida documentada.
Pregunta incómoda

¿Qué control dejaría de existir si mañana cambias de proveedor cloud?

NO RESPONDAS CON LA POLÍTICA
La respuesta ayuda a distinguir capacidad propia de capacidad heredada. También muestra concentración y dependencia. Si monitorización, identidad, copias y recuperación están completamente acopladas a un proveedor, la estrategia de salida necesita ser mucho más que una cláusula contractual.

Revisaría además quién puede cambiar configuraciones críticas y cómo se detectan cambios fuera de patrón.
Ref.Qué pediríaQué necesito ver
GR-01Modelo de responsabilidadControl por control, proveedor y cliente claramente asignados.
GR-02ConfiguraciónBaseline, desviaciones y monitorización del tenant.
GR-03ProveedorCertificaciones, alcance, contratos y subcontratación.
GR-04Salida y recuperaciónPortabilidad, copias, dependencias y pruebas.
Mi enfoque

Cómo la aterrizaría yo en un entorno real

GRCREAL
Elegiría un servicio cloud que soporte una función importante y dibujaría la cadena completa: usuario, identidad, red, servicio, datos, logs, backup y soporte. Después pondría un propietario sobre cada control.

La nube simplifica mucha infraestructura. No simplifica la obligación de saber quién hace qué y cómo lo demuestras.
Contenido

Qué contiene la guía

  • El modelo de responsabilidad compartida entre cliente y proveedor cloud.
  • Cómo se acredita la conformidad ENS de un servicio en la nube.
  • Las medidas que permanecen bajo responsabilidad del cliente.
  • Cláusulas de seguridad y Acuerdos de Nivel de Servicio (ANS/SLA) recomendados.
  • Consideraciones para IaaS, PaaS y SaaS.
  • Los modelos de despliegue: nube pública, privada, comunitaria e híbrida.
  • Un decálogo de recomendaciones y un anexo con clausulado tipo para contratación.
Conceptos

Conceptos clave que debes manejar

Responsabilidad compartida
Reparto de medidas entre cliente y proveedor según el modelo de servicio. El cliente siempre es responsable de la información y los servicios, aunque estén externalizados.
Conformidad del servicio
Acreditación de que el servicio cloud cumple el ENS para una categoría dada. Es obligación del contratante exigir la conformidad del CSP.
IaaS/PaaS/SaaS
Modelos de servicio que determinan qué controla el cliente y qué el proveedor. IaaS: infraestructura (servidores, almacenamiento); PaaS: plataforma (entornos de desarrollo); SaaS: software (aplicaciones).
ANS/SLA de seguridad
Compromisos contractuales de seguridad y nivel de servicio con el proveedor. Incluyen disponibilidad, capacidad, tiempos de respuesta, penalizaciones, etc.
POC (Punto de Contacto)
Figura designada por el CSP para canalizar comunicaciones de seguridad e incidentes con el cliente. El Responsable de Seguridad del cliente actúa como POC por su parte.
Alcance

A quién aplica y cuándo entra en juego

Aplica a cualquier entidad bajo ENS que use nube pública o híbrida, que hoy son casi todas. Es especialmente relevante al contratar o renovar servicios cloud y al definir la Declaración de Aplicabilidad de sistemas que residen en la nube. También aplica a entidades privadas que presten servicios cloud al sector público, que deben cumplir el ENS.
Implantación

Cómo lo implanta una empresa, paso a paso

  1. Identifica el modelo y el repartoDetermina si es IaaS, PaaS o SaaS y qué medidas asume cada parte. Sin este reparto claro, nadie responde de nada. La responsabilidad última siempre es del cliente.
  2. Exige conformidad al proveedorPide evidencia de conformidad ENS del servicio concreto que usas, para tu categoría. «Está en la nube» no es conformidad. La ITS de conformidad del ENS obliga a exigirlo.
  3. Implanta tus propias medidasConfigura, gestiona accesos y protege el dato: esas medidas son tuyas aunque el proveedor esté certificado. La guía 807 aplica para criptografía en la nube.
  4. Lleva todo al contratoRefleja cláusulas de seguridad y ANS/SLA en el contrato. Lo que no está escrito, no es exigible. Incluye: conformidad ENS, ubicación de datos, confidencialidad, gestión de incidentes, copias de seguridad y finalización del contrato.
  5. Documéntalo en tu expedienteIncluye el reparto de responsabilidades y la conformidad del proveedor en tu Declaración de Aplicabilidad. La guía 823 se integra con la 804 y 808.
Auditoría

Para qué sirve en una auditoría

  • El auditor revisa el reparto de responsabilidades y la conformidad del proveedor.
  • Comprueba que las medidas «del cliente» están implantadas por ti.
  • Verifica las cláusulas de seguridad y los ANS/SLA del contrato.
  • «Está en cloud certificado» no exime de tus propias medidas.
  • La falta de documentación del reparto es un hallazgo habitual.
  • El auditor verificará la ubicación geográfica de los datos (UE/España según normativa).
Serie 800

Relación con otras guías de la serie

  • CCN-STIC 804804 — Las medidas de protección se reparten entre cliente y proveedor.
  • CCN-STIC 807807 — El cifrado y la gestión de claves en cloud requieren atención específica.
  • CCN-STIC 817817 — La detección y respuesta a incidentes implica también al proveedor.
  • CCN-STIC 808808 — La verificación del cumplimiento en cloud se basa en esta guía.
Mapeo

Equivalencia con otros marcos

Cómo se conecta esta guía con los marcos que probablemente ya manejas:
Aspecto en el ENSISO 27001NIS2 / DORA
Responsabilidad compartida cloudISO 27001: A.5.19–A.5.23 (proveedores) + ISO 27017DORA: gestión de riesgo de terceros TIC (art. 28-30)
Conformidad del servicioConformidad ENS del proveedorNIS2: seguridad de la cadena de suministro
ANS/SLA de seguridadISO 27001: acuerdos de servicio (A.5.20)DORA: cláusulas contractuales mínimas
Ubicación geográfica de datosISO 27001: A.5.34 (privacidad)RGPD: transferencias internacionales
Gestión de incidentes en cloudISO 27001: A.5.24–A.5.28DORA: respuesta a incidentes
Sin humo

Errores típicos

  • Asumir que la conformidad del proveedor te cubre al 100%.
  • No documentar qué medidas son tuyas y cuáles del proveedor.
  • Contratos sin cláusulas de seguridad ni ANS/SLA.
  • No verificar la conformidad ENS del servicio concreto contratado.
  • No considerar la ubicación geográfica de los datos (UE/España).
  • No designar un POC (Punto de Contacto) en el proveedor.
Checklist

Checklist práctico

  • Modelo de servicio y reparto de responsabilidades identificados.
  • Conformidad ENS del proveedor verificada para tu categoría.
  • Medidas del cliente implantadas y documentadas.
  • Cláusulas de seguridad y ANS/SLA en el contrato.
  • Reparto reflejado en la Declaración de Aplicabilidad.
  • POC designado por el proveedor.
  • Ubicación geográfica de los datos conforme a la normativa.
Ficha

Ficha y enlace oficial

Esta es una lectura práctica de GRCreal, no la guía oficial. Consulta siempre la versión vigente en el portal del CCN-CERT, ya que estas guías se actualizan periódicamente (esta ficha: publicada Oct 2012, actualizada Sep 2020).
⬇ CCN-STIC 823 en el portal CCN-CERT
Modelos

Modelos de despliegue y categorías de servicio

La guía describe los modelos de despliegue y categorías de servicio en la nube:

  • Modelos de despliegue:
    • Nube pública: Infraestructura gestionada por terceros, recursos compartidos con múltiples clientes.
    • Nube privada: Dedicada a un solo cliente. Puede ser on-premise o gestionada por un tercero.
    • Nube híbrida: Combinación de pública y privada.
    • Nube comunitaria: Compartida por organizaciones con requisitos comunes (ej. sector público).
  • Categorías de servicio:
    • IaaS (Infrastructure as a Service): Recursos de procesamiento y almacenamiento. El cliente controla SO, aplicaciones y componentes de red.
    • PaaS (Platform as a Service): Plataforma para desarrollar aplicaciones. El cliente controla aplicaciones y configuración.
    • SaaS (Software as a Service): Aplicaciones alojadas por el proveedor. El cliente no administra la infraestructura.
Riesgos y contratos

Riesgos y clausulado contractual

La adopción de servicios en la nube introduce riesgos que deben controlarse mediante cláusulas contractuales adecuadas:

  • Riesgos principales:
    • Pérdida de control: el cliente transfiere control al proveedor.
    • Ubicación de datos: debe acordarse que el procesamiento esté sujeto al marco legal del país.
    • Cumplimiento normativo: seguridad e integridad de los datos.
    • Aislamiento de datos: separación de datos entre clientes (multi-tenancy).
    • Portabilidad: capacidad de migrar datos entre proveedores.
    • Acceso de usuarios con privilegios: acordar con el proveedor.
  • Cláusulas contractuales mínimas (Anexo I):
    • Descripción del servicio y dimensionado.
    • Acuerdos de nivel de servicio (SLA) con indicadores: disponibilidad, capacidad, resolución de incidencias.
    • Responsabilidades y obligaciones (clientes vs proveedor).
    • Gestión de incidentes y registros de actividad.
    • Copias de seguridad y recuperación de datos.
    • Finalización del contrato: devolución y destrucción de datos.
    • Confidencialidad y ubicación geográfica de los datos.
    • Conformidad con el ENS del servicio contratado.
Decálogo

Decálogo de recomendaciones para la nube

La guía incluye un decálogo de recomendaciones para la utilización de servicios en la nube:

  • 1 — Determinar la categoría del sistema (BÁSICA, MEDIA o ALTA).
  • 2 — Elaborar la declaración de aplicabilidad (Anexo II del ENS).
  • 3 — Realizar un análisis de riesgos para identificar requisitos adicionales.
  • 4 — Acogerse a un Perfil de Cumplimiento Específico (si aplica).
  • 5 — Establecer las condiciones contractuales previas a la contratación.
  • 6 — Detallar en el contrato servicio, infraestructura, dimensionado, registros, incidentes, copias de seguridad y finalización.
  • 7 — Supervisar el cumplimiento de los requisitos legales por parte del CSP.
  • 8 — Realizar seguimiento periódico de los SLA establecidos.
  • 9 — Planificar revisiones periódicas de la información proporcionada por el CSP (logs, capacidad, almacenamiento).
  • 10 — Elaborar una normativa de seguridad específica para los usuarios de la nube.
Ficha y enlace oficial

Contrasta esta lectura con la publicación del CCN-CERT

La guía oficial sigue mandando. Aquí queda la ficha documental y el acceso directo a la fuente para cerrar la lectura con el contraste adecuado.
ℹ️ Resumen práctico de GRCreal. Consulta siempre la versión oficial vigente en el portal del CCN-CERT.

Resumen realizado a fecha 29/06/2026 con la información disponible en https://www.ccn-cert.cni.es/es/guias.html. Las fechas de publicación y actualización proceden del portal oficial.

DocumentoCategoríaPublicadoActualizado
⬇ PDF CCN-STIC-823 Cloud Computing en el ENS800 Guías Esquema Nacional de SeguridadOct 2012Sep 2020

Abrir documento oficial del CCN-CERT

Sigue en la serie 800
Otras guías CCN-STIC
CCN-STIC 817

ENS. Gestión de Ciberincidentes

Cuando algo pasa: clasificar, notificar y responder. Y LUCÍA.

Serie 800 · ENS
 CCN-STIC 800

Glosario de Términos y Abreviaturas del ENS

El diccionario del ENS. Aburrida, sí; imprescindible, también.

Serie 800 · ENS