Microsoft anunció recientemente que Azure supera los 300 servicios certificados con ENS (Esquema Nacional de Seguridad) en Categoría Alta en España. Es una noticia relevante para cualquier organización del sector público o regulado que opera en España, y el anuncio ha generado conversaciones sobre si esto resuelve de una vez el debate sobre soberanía digital en cloud. La respuesta corta es: depende de qué problema estás intentando resolver.
La certificación ENS en Categoría Alta significa algo concreto y valioso. Pero también hay cosas que no significa, y confundirlas puede llevar a decisiones de arquitectura con consecuencias jurídicas y regulatorias que son difíciles de deshacer una vez que tienes cargas de trabajo críticas en producción.
Lo que ENS Categoría Alta sí garantiza
El ENS es el marco de seguridad que el Real Decreto 311/2022 hace obligatorio para las Administraciones Públicas españolas y recomendado para infraestructuras críticas. La Categoría Alta es el nivel máximo y aplica a sistemas cuyo compromiso puede tener consecuencias graves para las funciones esenciales del Estado, la defensa nacional, la seguridad pública o los derechos fundamentales.
Cuando Azure obtiene la certificación ENS Categoría Alta para un servicio concreto, eso significa que ese servicio ha sido auditado por un organismo de certificación independiente acreditado por el CCN (Centro Criptológico Nacional) y cumple los controles técnicos, operativos y de gobierno que el esquema define. Es una certificación real, auditada por terceros y renovada periódicamente, no una autodeclaración.
Para una organización que necesita desplegar en cloud cargas de trabajo con datos clasificados o procesos críticos bajo supervisión del CCN, tener 300 servicios certificados significa en la práctica que puede diseñar arquitecturas modernas — Kubernetes, bases de datos PaaS, análisis en streaming, IA — sin tener que recurrir a servicios no certificados o a alternativas on-premise significativamente más costosas y menos capaces.
Eso es valioso. Pero no es soberanía operativa completa.
Lo que ENS no resuelve por sí solo
Residencia de datos no es lo mismo que soberanía operativa
El primer malentendido frecuente es asumir que si los datos están en regiones de Azure ubicadas en España o Europa (Spain Central en Madrid, West Europe en Países Bajos), la organización tiene control soberano sobre esos datos. La residencia de datos — la garantía contractual de que los datos no salen de una geografía definida — es una condición necesaria pero no suficiente para la soberanía operativa.
La soberanía operativa implica también que el personal que puede acceder a esos datos con privilegios elevados (los ingenieros de soporte de Microsoft que pueden resolver un incidente grave en un sistema de cliente, por ejemplo) sea personal bajo jurisdicción europea. Este es uno de los controles que las ofertas de cloud soberana de Microsoft — las que van más allá de la certificación estándar — abordan específicamente, pero que la certificación ENS estándar no requiere ni verifica.
Para organizaciones con datos en el nivel más alto de sensibilidad — sistemas de defensa, fuerzas de seguridad del Estado, infraestructuras críticas bajo supervisión directa del CNI — la pregunta correcta no es "¿está certificado ENS?" sino "¿quién tiene acceso privilegiado a la infraestructura que gestiona mis datos?".
La CLOUD Act americana aplica aunque los datos estén en Europa
Este es el punto que genera más debate y que más organizaciones del sector público español han tenido que afrontar al analizar sus opciones cloud. La CLOUD Act (Clarifying Lawful Overseas Use of Data Act) de 2018 otorga a los tribunales y agencias de investigación estadounidenses la autoridad de requerir a empresas americanas que entreguen datos almacenados en servidores en el extranjero, incluidos servidores en Europa.
Microsoft, como empresa americana, está sujeta a la CLOUD Act. Esto no significa que los datos de cualquier cliente europeo sean accesibles libremente para el gobierno americano — existen salvaguardas procesales importantes — pero sí significa que en determinados supuestos legales existe un mecanismo por el cual datos en Azure Europa podrían ser requeridos sin que el cliente europeo tenga control sobre la respuesta de Microsoft a ese requerimiento.
La implicación práctica para organizaciones con datos sujetos a soberanía jurisdiccional (administración pública, defensa, justicia, datos clasificados) es que la evaluación jurídica de los riesgos de la CLOUD Act debe ser independiente y realizada por asesores legales especializados en derecho internacional de datos, no delegada en el asesor legal de Microsoft ni asumida a partir de la certificación ENS.
Para la mayoría de organizaciones del sector privado regulado — banca, seguros, telecomunicaciones — la CLOUD Act no representa un riesgo operativo materialmente diferente al que ya asumen con cualquier otro proveedor tecnológico americano que utilizan. Pero para organizaciones con datos clasificados o bajo regímenes jurídicos especiales, es una variable que debe evaluarse explícitamente.
Las 6 decisiones que determinan la soberanía operativa real
1. Mapear los sistemas críticos antes de diseñar la arquitectura
NIS2 y DORA establecen multas de hasta el 2% del volumen de negocio global para incumplimientos relacionados con la resiliencia de infraestructuras críticas. Pero para muchas organizaciones, el mapa de qué sistemas son "críticos" en el sentido regulatorio no está actualizado ni documentado de forma que sea defendible ante un supervisor.
La decisión arquitectónica correcta antes de cualquier diseño cloud soberano es producir un inventario clasificado de sistemas, con los criterios de criticidad explicitados y validados por la dirección. Esto determina qué cargas necesitan controles de soberanía reforzados, qué cargas pueden ir a cloud estándar certificado ENS, y cuáles pueden ir a entornos cloud sin restricciones especiales. Sin ese mapa, el diseño cloud es arbitrario desde la perspectiva regulatoria.
2. Verificar que el personal privilegiado es europeo para los datos más sensibles
Si los datos requieren soberanía operativa completa, la arquitectura debe incluir controles sobre quién puede acceder con privilegios elevados a la infraestructura que los gestiona. En la práctica, esto puede requerir opciones de cloud soberana de los grandes proveedores (Azure Sovereign, o las arquitecturas de Microsoft for Sovereignty) en las que el soporte operativo está restringido a personal con residencia y ciudadanía en jurisdicciones europeas.
Este es un control que tiene un coste adicional sobre el cloud estándar y que no todas las organizaciones necesitan. La decisión de qué datos lo requieren debe basarse en el mapa de sistemas críticos del punto anterior, no en una posición de principio genérica sobre soberanía.
3. Realizar una evaluación jurídica independiente de la CLOUD Act
Para organizaciones con datos bajo regímenes jurídicos especiales, la evaluación del riesgo CLOUD Act debe documentarse y actualizarse periódicamente. Esta evaluación no puede ser delegada en el proveedor cloud — que tiene un conflicto de interés evidente — ni en el asesor legal corporativo sin especialización específica en derecho internacional de datos.
El resultado de esa evaluación debe incluir una posición sobre si los datos específicos de la organización están dentro del ámbito de aplicación material de la CLOUD Act, qué mecanismos de protección existen (incluyendo el régimen de transferencias de datos UE-EEUU vigente en cada momento), y qué medidas técnicas adicionales — cifrado con gestión de claves exclusivamente en la organización, por ejemplo — pueden reducir el riesgo residual.
4. Usar certificaciones BSI C5 o ENS Alto como evidencia ante reguladores, no como punto de llegada
La certificación ENS es evidencia válida ante el CCN, la AEPD y los organismos de supervisión sectorial. Pero debe presentarse como evidencia de que el proveedor cloud cumple determinados controles técnicos y operativos, no como una garantía total de seguridad de los sistemas del cliente.
Un auditor experimentado va a complementar la revisión de certificaciones con preguntas sobre cómo el cliente ha configurado los servicios certificados. Un servicio Azure con ENS Categoría Alta mal configurado — con acceso público habilitado, sin Private Endpoints, sin políticas de retención de logs — no cumple ENS desde la perspectiva del sistema del cliente, aunque el servicio en sí esté certificado.
5. Probar la autonomía operativa periódicamente
La soberanía operativa no es solo una propiedad de diseño: debe ser verificable en la práctica. Una organización que depende de servicios cloud soberanos debe tener la capacidad de operar sus sistemas críticos durante un período prolongado si el acceso al proveedor principal se interrumpe por un incidente regulatorio, técnico o geopolítico.
Esto implica tener estrategias de continuidad que no dependan de un único proveedor cloud para los sistemas más críticos, y probar activamente esa capacidad con ejercicios de continuidad que incluyan escenarios de no disponibilidad del proveedor principal. DORA ya exige este tipo de pruebas de resiliencia para entidades financieras; NIS2 las extenderá progresivamente a otros sectores.
6. Facturación separada del cloud estándar: la señal de la arquitectura soberana
Las ofertas de cloud soberana o cloud gubernamental tienen estructuras de precios diferenciadas del cloud estándar. Si en el modelo de costes del proyecto no existe una línea separada para los servicios con controles de soberanía reforzados, es probable que en la práctica no existan esos controles — o que no estén correctamente habilitados.
La factura es la evidencia más inmediata de que la arquitectura soberana que se diseñó realmente se implementó. En revisiones de arquitectura, cuando veo que los costes de un proyecto de cloud soberana son idénticos a los de un proyecto de cloud estándar equivalente, la primera pregunta es siempre si los controles adicionales están activos o solo documentados.
La lectura correcta del hito de los 300 servicios ENS
Que Azure supere los 300 servicios con ENS Categoría Alta es una buena noticia para el ecosistema cloud español. Significa que las organizaciones que necesitan cumplir el ENS tienen acceso a un catálogo amplio de servicios modernos certificados, lo que elimina la tensión histórica entre cumplimiento normativo e innovación tecnológica.
Lo que no significa es que esas organizaciones puedan desplegar en Azure sin análisis adicional sobre soberanía, CLOUD Act, configuración correcta de los servicios certificados o continuidad operativa frente a indisponibilidad del proveedor.
La certificación del proveedor y la soberanía operativa del sistema son dos dimensiones diferentes. La primera es condición necesaria para la segunda; no es condición suficiente.
¿Evaluando cloud soberana para tu organización?
Si estás diseñando una estrategia cloud para una organización con requisitos de soberanía o datos bajo regímenes jurídicos especiales, puedo ayudarte a distinguir qué controles son obligatorios, cuáles son recomendables y cuáles son marketing. La diferencia entre los tres puede marcar un gap importante en el presupuesto y en la postura de riesgo real.
Hablemos