8 min. de lectura<\/p>\n
NIS2 obliga a los operadores alemanes a realizar una auditor\u00eda 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\u00e1 en el departamento de compras, sino en el director general.<\/strong><\/p>\n Lo m\u00e1s importante en resumen<\/p>\n Relacionado:<\/span>Cumplimiento de NIS2 en la pyme: pasos viables<\/a> \/<\/span> DORA y NIS2: por qu\u00e9 las auditor\u00edas bancarias entran en conflicto ahora<\/a><\/p>\n \u00bfQu\u00e9 es Supply Chain Security seg\u00fan NIS2?<\/strong> 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\u00e1tica. Esto incluye proveedores de servicios en la nube, proveedores de servicios gestionados y proveedores de software. La responsabilidad recae en la direcci\u00f3n general y no es delegable.<\/p>\n El art\u00edculo 21, apartado 2, letra d, de la directiva NIS2 y su transposici\u00f3n en la NIS2UmsuCG exigen expl\u00edcitamente que la seguridad de la cadena de suministro se incorpore a la gesti\u00f3n de riesgos. La ley menciona cuatro puntos por su nombre: vulnerabilidades de los proveedores directos, pr\u00e1cticas de seguridad de los proveedores, respuesta a incidentes de seguridad en la cadena y la fiabilidad de esta relaci\u00f3n con el proveedor a lo largo de la vigencia del contrato.<\/p>\n Quien pretenda aplicar esto en la pr\u00e1ctica no puede evitar una pregunta: qu\u00e9 proveedores de servicios en la nube forman parte de su propia cadena de suministro y qu\u00e9 subproveedores han integrado a su vez. En el contexto de una auditor\u00eda, la respuesta \u00abutilizamos Azure\u00bb no es suficiente. Se exige una visi\u00f3n dos niveles m\u00e1s abajo.<\/p>\n El US Clarifying Lawful Overseas Use of Data Act de 2018 permite a las autoridades estadounidenses de investigaci\u00f3n criminal solicitar datos a proveedores estadounidenses, independientemente de d\u00f3nde se almacenen estos datos. AWS, Microsoft y Google son proveedores estadounidenses. Una regi\u00f3n alemana no cambia nada en esto. El proveedor est\u00e1 obligado a cooperar, y el cliente alem\u00e1n en muchos casos no se informa.<\/p>\n Eso no es un secreto. Est\u00e1 escrito en los contratos de procesamiento de datos de los hyperscalers, normalmente bajo \u00abGovernment Access Requests\u00bb o \u00abLaw Enforcement Demands\u00bb. Quien no lo haya le\u00eddo no ha cumplido con la diligencia debida hacia sus proveedores. Quien lo haya le\u00eddo y omitido tiene otro problema: sabe que su cl\u00e1usula est\u00e1ndar conforme a Schrems-II ceder\u00e1 en caso de conflicto, pero igualmente ha firmado.<\/p>\n El TJUE estableci\u00f3 en su decisi\u00f3n Schrems-II de 2020 que las cl\u00e1usulas contractuales est\u00e1ndar solo ser\u00e1n suficientes si el nivel de protecci\u00f3n en el tercer pa\u00eds es realmente equivalente. El CLOUD Act no lo hace equivalente. El Marco de Privacidad EU-US de 2023 lo compensa a nivel de aplicaci\u00f3n, pero no resuelve el conflicto estructural. Las autoridades de protecci\u00f3n de datos y las supervisoras lo eval\u00faan de forma diferente, lo cual no simplifica el camino de cumplimiento.<\/p>\n \nQuien utilice un hyperscaler estadounidense acepta contractualmente una cl\u00e1usula de acceso a autoridades que entra en conflicto con el derecho al privacidad europeo. Eso es una asunci\u00f3n consciente de riesgo, no una debilidad t\u00e9cnica residual.\n<\/p><\/blockquote>\n La discusi\u00f3n p\u00fablica se centra en los proveedores estadounidenses. La realidad de las cadenas de suministro es m\u00e1s amplia. Un SOC gestionado de un MSSP alem\u00e1n 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\u00f3gica de acceso de autoridades y su propia interpretaci\u00f3n del exportaci\u00f3n de datos.<\/p>\n Fuente: Evaluaci\u00f3n propia NIS2UmsuCG m\u00e1s decisiones de adecuaci\u00f3n de la Comisi\u00f3n Europea, fecha mayo 2026.<\/p>\n Un registro de riesgos que no refleje esta perspectiva es vulnerable en el auditorio NIS2. La autoridad de supervisi\u00f3n no pregunta por proveedores favoritos, pregunta por la metodolog\u00eda de evaluaci\u00f3n. Quien tenga cinco subproveedores en tres pa\u00edses tercero y no tenga una evaluaci\u00f3n escrita del riesgo de acceso de autoridades, no ha cumplido formalmente la atenci\u00f3n requerida por NIS2.<\/p>\n Hay tres puntos donde la responsabilidad personal de la direcci\u00f3n en la pr\u00e1ctica se manifiesta. Primero, en el incidente de seguridad con fuga de datos: si la investigaci\u00f3n muestra que la cadena de suministro no fue evaluada, se trata de una violaci\u00f3n de la obligaci\u00f3n de cuidado. Segundo, en el auditorio sin incidente: una autoridad de supervisi\u00f3n puede sancionar incluso sin haber ocurrido da\u00f1os. Tercero, en el procedimiento civil: si los datos de los clientes se comprometen mediante una transmisi\u00f3n a un pa\u00eds tercero, surgen demandas por da\u00f1os y perjuicios cuyo valor depende directamente del volumen de datos.<\/p>\n Los hyperscalers no ser\u00e1n los principales demandantes en estos procedimientos. Han definido claramente en sus condiciones generales de contrataci\u00f3n lo que entregan y lo que no. Los principales demandantes son los encargados que firmaron sin capturar las implicaciones contractualmente. Esta es la construcci\u00f3n que NIS2 aborda ahora expresamente.<\/p>\n Paso uno: Inventario de proveedores con v\u00ednculo a terceros pa\u00edses. \u00bfQu\u00e9 proveedor, qu\u00e9 contrato, qu\u00e9 lugar real de procesamiento, qu\u00e9 subcontratistas? Quien pueda reducir esto a una tabla de Excel debe poder presentarlo a una autoridad de supervisi\u00f3n.<\/p>\n Paso dos: Evaluaci\u00f3n escrita de riesgos por proveedor. No \u00abconfiamos en AWS\u00bb, sino: \u00bfqu\u00e9 derechos de acceso de las autoridades existen, qu\u00e9 categor\u00edas de datos est\u00e1n afectadas, qu\u00e9 medidas reducen el riesgo? El cifrado con claves del cliente es una medida, la restricci\u00f3n geogr\u00e1fica otra. Ambas deben documentarse.<\/p>\n Paso tres: Refuerzo contractual. Las cl\u00e1usulas contractuales est\u00e1ndar m\u00e1s medidas de protecci\u00f3n adicionales son obligatorias, no recomendaciones. Esto significa concretamente: control de cifrado, derechos de auditor\u00eda, obligaciones de notificaci\u00f3n ante accesos de autoridades, cl\u00e1usulas de salida con ruta de transferencia de datos.<\/p>\n Paso cuatro: Aprobaci\u00f3n por la direcci\u00f3n. La selecci\u00f3n del proveedor y la evaluaci\u00f3n del riesgo residual deben documentarse en una resoluci\u00f3n de la direcci\u00f3n. No en una diapositiva de estrategia en la nube. En un acta que la autoridad de supervisi\u00f3n pueda seguir.<\/p>\n 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\u00f3n t\u00e9cnica de un hyperscaler. Quien necesite inferencia equivalente a Bedrock, Aurora Serverless o funciones espec\u00edficas de identidad de Microsoft, no tiene hoy un sustituto 1:1.<\/p>\n Esto no es un motivo para mantener el statu quo. Es un motivo para una arquitectura diferenciada. Las categor\u00edas de datos sensibles migrar\u00e1n a proveedores europeos o permanecer\u00e1n on-premises. Las cargas de trabajo gen\u00e9ricas permanecer\u00e1n en el hyperscaler, con medidas de protecci\u00f3n documentadas. La arquitectura de plataforma en 2026 ser\u00e1 pol\u00edglota, no todo o nada.<\/p>\n El marco de 2023 ha restablecido la decisi\u00f3n de adecuaci\u00f3n y es la base jur\u00eddica actual. Varios organismos de protecci\u00f3n de datos y dict\u00e1menes jur\u00eddicos esperan un nuevo procedimiento del TJUE que vuelva a examinar su viabilidad. Quien se base \u00fanicamente en el marco asume el riesgo de una decisi\u00f3n Schrems-III. Es s\u00f3lido el marco junto con medidas t\u00e9cnicas adicionales, especialmente el cifrado con claves del cliente.<\/p>\n 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\u00f3n externa de claves cierran la brecha t\u00e9cnicamente, siempre que el gestor de claves no est\u00e9 sujeto a la legislaci\u00f3n estadounidense. Adem\u00e1s, no todos los proveedores ofrecen HYOK para todos los servicios.<\/p>\n El proveedor est\u00e1 obligado a entregar los datos solicitados. Puede presentar un recurso, aunque en la pr\u00e1ctica rara vez tiene \u00e9xito. A menudo no se notifica al cliente, porque la notificaci\u00f3n puede incluir una obligaci\u00f3n de secreto. El cliente, en caso de duda, solo se entera en el procedimiento posterior de que los datos fueron transmitidos.<\/p>\n Las obligaciones NIS2 entran en vigor a partir de un tama\u00f1o determinado o en sectores regulados. Las peque\u00f1as empresas no est\u00e1n generalmente obligadas directamente, pero son incluidas contractualmente en la revisi\u00f3n por parte de sus clientes obligados a cumplir con NIS2. Esto desplaza la obligaci\u00f3n, de hecho, a la cadena de suministro. Quien, como PYME, tenga un cliente obligado a cumplir con NIS2, debe poder proporcionar informaci\u00f3n.<\/p>\n\n
Lo que exige realmente la obligaci\u00f3n de NIS2 en materia de cadena de suministro<\/h2>\n
D\u00f3nde el US CLOUD Act anula el protecci\u00f3n europeo<\/h2>\n
Pa\u00edses terceros no son solo Estados Unidos<\/h2>\n
\n\n
\n \nRegi\u00f3n<\/th>\n Acceso de autoridades (breve)<\/th>\n Evaluaci\u00f3n NIS2 en el espacio de datos<\/th>\n<\/tr>\n<\/thead>\n \n Estados Unidos<\/strong><\/td>\n CLOUD Act, FISA 702<\/td>\n Alto, con conflicto residual respecto a Schrems II<\/td>\n<\/tr>\n \n Reino Unido<\/strong><\/td>\n Acta de Potestades Investigativas, Decisi\u00f3n de Adecuaci\u00f3n UE<\/td>\n Medio, adecuaci\u00f3n bajo observaci\u00f3n<\/td>\n<\/tr>\n \n India<\/strong><\/td>\n Secci\u00f3n 69 del Acto de Tecnolog\u00eda de la Informaci\u00f3n, Acto DPDP 2023<\/td>\n Alto, sin decisi\u00f3n de adecuaci\u00f3n<\/td>\n<\/tr>\n \n Israel<\/strong><\/td>\n Ley de Protecci\u00f3n de la Privacidad, Decisi\u00f3n de Adecuaci\u00f3n UE<\/td>\n Medio, riesgos residuales sectoriales<\/td>\n<\/tr>\n \n Filipinas<\/strong><\/td>\n Acto de Protecci\u00f3n de Datos, Acceso de autoridades mediante marco AML<\/td>\n Alto, frecuentemente subproveedores sin contrato<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n Donde realmente se activan las trampas de responsabilidad<\/h2>\n
Cuatro pasos concretos que deben estar ahora en el registro de riesgos<\/h2>\n
Cu\u00e1ndo es realista cambiar a proveedores europeos<\/h2>\n
Preguntas frecuentes<\/h2>\n
\u00bfEs el EU-US Data Privacy Framework una base suficiente para el uso de nube estadounidense?<\/h3>\n
\u00bfBasta un cifrado en el hyperscaler como protecci\u00f3n contra la CLOUD Act?<\/h3>\n
\u00bfQu\u00e9 ocurre si un hyperscaler recibe una notificaci\u00f3n de la CLOUD Act?<\/h3>\n
\u00bfDeben las peque\u00f1as empresas realizar revisiones de la cadena de suministro NIS2?<\/h3>\n
Sugerencias de lectura de la redacci\u00f3n<\/h3>\n