NIS2 se encuentra con la Ley CLOUD: ¿Quién responde por la brecha de terceros países?

8 min. de lectura

NIS2 obliga a los operadores alemanes a realizar una auditoría de la cadena de suministro que, al mismo tiempo, elude el US CLOUD Act. Quien gestione un hiperscalador estadounidense con datos alemanes se enfrenta a dos autoridades que exigen acceso de forma contradictoria. En 2026, la responsabilidad por ello ya no recaerá en el departamento de compras, sino en el director general.

Relacionado:Cumplimiento de NIS2 en la pyme: pasos viables  /  DORA y NIS2: por qué las auditorías bancarias entran en conflicto ahora

Lo que exige realmente la obligación de NIS2 en materia de cadena de suministro

¿Qué es Supply Chain Security según NIS2? Supply Chain Security, en el sentido de la directiva NIS2, obliga a las entidades afectadas a evaluar, documentar y garantizar contractualmente la seguridad de sus proveedores y prestadores de servicios de forma sistemática. Esto incluye proveedores de servicios en la nube, proveedores de servicios gestionados y proveedores de software. La responsabilidad recae en la dirección general y no es delegable.

El artículo 21, apartado 2, letra d, de la directiva NIS2 y su transposición en la NIS2UmsuCG exigen explícitamente que la seguridad de la cadena de suministro se incorpore a la gestión de riesgos. La ley menciona cuatro puntos por su nombre: vulnerabilidades de los proveedores directos, prácticas de seguridad de los proveedores, respuesta a incidentes de seguridad en la cadena y la fiabilidad de esta relación con el proveedor a lo largo de la vigencia del contrato.

Quien pretenda aplicar esto en la práctica no puede evitar una pregunta: qué proveedores de servicios en la nube forman parte de su propia cadena de suministro y qué subproveedores han integrado a su vez. En el contexto de una auditoría, la respuesta «utilizamos Azure» no es suficiente. Se exige una visión dos niveles más abajo.

Dónde el US CLOUD Act anula el protección europeo

El US Clarifying Lawful Overseas Use of Data Act de 2018 permite a las autoridades estadounidenses de investigación criminal solicitar datos a proveedores estadounidenses, independientemente de dónde se almacenen estos datos. AWS, Microsoft y Google son proveedores estadounidenses. Una región alemana no cambia nada en esto. El proveedor está obligado a cooperar, y el cliente alemán en muchos casos no se informa.

Eso no es un secreto. Está escrito en los contratos de procesamiento de datos de los hyperscalers, normalmente bajo «Government Access Requests» o «Law Enforcement Demands». Quien no lo haya leído no ha cumplido con la diligencia debida hacia sus proveedores. Quien lo haya leído y omitido tiene otro problema: sabe que su cláusula estándar conforme a Schrems-II cederá en caso de conflicto, pero igualmente ha firmado.

El TJUE estableció en su decisión Schrems-II de 2020 que las cláusulas contractuales estándar solo serán suficientes si el nivel de protección en el tercer país es realmente equivalente. El CLOUD Act no lo hace equivalente. El Marco de Privacidad EU-US de 2023 lo compensa a nivel de aplicación, pero no resuelve el conflicto estructural. Las autoridades de protección de datos y las supervisoras lo evalúan de forma diferente, lo cual no simplifica el camino de cumplimiento.

Quien utilice un hyperscaler estadounidense acepta contractualmente una cláusula de acceso a autoridades que entra en conflicto con el derecho al privacidad europeo. Eso es una asunción consciente de riesgo, no una debilidad técnica residual.

Países terceros no son solo Estados Unidos

La discusión pública se centra en los proveedores estadounidenses. La realidad de las cadenas de suministro es más amplia. Un SOC gestionado de un MSSP alemán suele trabajar con analistas en India, un proveedor de respaldo en la nube almacena almacenamiento en Polonia y copias de seguridad en Israel, un proveedor SaaS para software de RR.HH. tiene hubs de desarrollo en Vietnam. Cada uno de estos lugares tiene su propia lógica de acceso de autoridades y su propia interpretación del exportación de datos.

Fuente: Evaluación propia NIS2UmsuCG más decisiones de adecuación de la Comisión Europea, fecha mayo 2026.

Un registro de riesgos que no refleje esta perspectiva es vulnerable en el auditorio NIS2. La autoridad de supervisión no pregunta por proveedores favoritos, pregunta por la metodología de evaluación. Quien tenga cinco subproveedores en tres países tercero y no tenga una evaluación escrita del riesgo de acceso de autoridades, no ha cumplido formalmente la atención requerida por NIS2.

Donde realmente se activan las trampas de responsabilidad

Hay tres puntos donde la responsabilidad personal de la dirección en la práctica se manifiesta. Primero, en el incidente de seguridad con fuga de datos: si la investigación muestra que la cadena de suministro no fue evaluada, se trata de una violación de la obligación de cuidado. Segundo, en el auditorio sin incidente: una autoridad de supervisión puede sancionar incluso sin haber ocurrido daños. Tercero, en el procedimiento civil: si los datos de los clientes se comprometen mediante una transmisión a un país tercero, surgen demandas por daños y perjuicios cuyo valor depende directamente del volumen de datos.

Los hyperscalers no serán los principales demandantes en estos procedimientos. Han definido claramente en sus condiciones generales de contratación lo que entregan y lo que no. Los principales demandantes son los encargados que firmaron sin capturar las implicaciones contractualmente. Esta es la construcción que NIS2 aborda ahora expresamente.

Cuatro pasos concretos que deben estar ahora en el registro de riesgos

Paso uno: Inventario de proveedores con vínculo a terceros países. ¿Qué proveedor, qué contrato, qué lugar real de procesamiento, qué subcontratistas? Quien pueda reducir esto a una tabla de Excel debe poder presentarlo a una autoridad de supervisión.

Paso dos: Evaluación escrita de riesgos por proveedor. No «confiamos en AWS», sino: ¿qué derechos de acceso de las autoridades existen, qué categorías de datos están afectadas, qué medidas reducen el riesgo? El cifrado con claves del cliente es una medida, la restricción geográfica otra. Ambas deben documentarse.

Paso tres: Refuerzo contractual. Las cláusulas contractuales estándar más medidas de protección adicionales son obligatorias, no recomendaciones. Esto significa concretamente: control de cifrado, derechos de auditoría, obligaciones de notificación ante accesos de autoridades, cláusulas de salida con ruta de transferencia de datos.

Paso cuatro: Aprobación por la dirección. La selección del proveedor y la evaluación del riesgo residual deben documentarse en una resolución de la dirección. No en una diapositiva de estrategia en la nube. En un acta que la autoridad de supervisión pueda seguir.

Cuándo es realista cambiar a proveedores europeos

La respuesta sincera es: no para todas las cargas de trabajo, no de inmediato. La Iniciativa Europea de Nube Abierta y ofertas soberanas como OVHcloud, Open Telekom Cloud o Stackit cubren un espectro creciente, pero no abarcan cada función técnica de un hyperscaler. Quien necesite inferencia equivalente a Bedrock, Aurora Serverless o funciones específicas de identidad de Microsoft, no tiene hoy un sustituto 1:1.

Esto no es un motivo para mantener el statu quo. Es un motivo para una arquitectura diferenciada. Las categorías de datos sensibles migrarán a proveedores europeos o permanecerán on-premises. Las cargas de trabajo genéricas permanecerán en el hyperscaler, con medidas de protección documentadas. La arquitectura de plataforma en 2026 será políglota, no todo o nada.

Preguntas frecuentes

¿Es el EU-US Data Privacy Framework una base suficiente para el uso de nube estadounidense?

El marco de 2023 ha restablecido la decisión de adecuación y es la base jurídica actual. Varios organismos de protección de datos y dictámenes jurídicos esperan un nuevo procedimiento del TJUE que vuelva a examinar su viabilidad. Quien se base únicamente en el marco asume el riesgo de una decisión Schrems-III. Es sólido el marco junto con medidas técnicas adicionales, especialmente el cifrado con claves del cliente.

¿Basta un cifrado en el hyperscaler como protección contra la CLOUD Act?

Un cifrado del lado del servidor del proveedor no es suficiente, porque el proveedor gestiona las claves y puede ser obligado a entregarlas en un procedimiento de autoridades. Soluciones Bring-Your-Own-Key o Hold-Your-Own-Key con gestión externa de claves cierran la brecha técnicamente, siempre que el gestor de claves no esté sujeto a la legislación estadounidense. Además, no todos los proveedores ofrecen HYOK para todos los servicios.

¿Qué ocurre si un hyperscaler recibe una notificación de la CLOUD Act?

El proveedor está obligado a entregar los datos solicitados. Puede presentar un recurso, aunque en la práctica rara vez tiene éxito. A menudo no se notifica al cliente, porque la notificación puede incluir una obligación de secreto. El cliente, en caso de duda, solo se entera en el procedimiento posterior de que los datos fueron transmitidos.

¿Deben las pequeñas empresas realizar revisiones de la cadena de suministro NIS2?

Las obligaciones NIS2 entran en vigor a partir de un tamaño determinado o en sectores regulados. Las pequeñas empresas no están generalmente obligadas directamente, pero son incluidas contractualmente en la revisión por parte de sus clientes obligados a cumplir con NIS2. Esto desplaza la obligación, de hecho, a la cadena de suministro. Quien, como PYME, tenga un cliente obligado a cumplir con NIS2, debe poder proporcionar información.

Fuente de imagen: Generada por IA (mayo 2026), certificado C2PA incluido en la imagen