8 min read<\/p>\n
NIS2 forces German operators to audit their supply chains-just as the US CLOUD Act simultaneously undermines that effort. Running German data on a US hyperscaler means two authorities can demand contradictory access. By 2026, liability for any breach will sit not with procurement, but with the CEO.<\/strong><\/p>\n Key Takeaways<\/p>\n Related:<\/span>NIS2 compliance for SMEs: practical steps<\/a> \/<\/span> DORA & NIS2: why bank audits collide in 2026<\/a><\/p>\n What does \u201csupply chain security\u201d mean under NIS2?<\/strong> Within the NIS2 framework, affected entities must systematically assess, document and contractually secure the security posture of every supplier and service provider-cloud vendors, managed-service outfits and software suppliers alike. Responsibility rests with the executive suite and cannot be delegated.<\/p>\n Article 21(2)(d) of the NIS2 Directive and its transposition in the NIS2UmsuCG explicitly require supply-chain security to be folded into risk management. The law names four concrete points: vulnerabilities of direct providers, supplier security practices, incident response within the chain, and the ongoing reliability of each supplier relationship throughout the contract term.<\/p>\n In practice, that means answering a question you can no longer dodge: which cloud providers sit inside your supply chain, and which subcontractors have they brought in? During an audit, the answer \u201cwe use Azure\u201d is no longer enough. NIS2 wants visibility two layers deep.<\/p>\n The US Clarifying Lawful Overseas Use of Data Act of 2018 allows US law enforcement agencies to demand data from US providers, regardless of where that data is stored. AWS, Microsoft, and Google are US providers. A German region changes nothing. The provider is obligated to cooperate, and in many cases the German client is not informed.<\/p>\n This is no secret. It\u2019s spelled out in the data-processing contracts of the hyperscalers, typically under \u201cGovernment Access Requests\u201d or \u201cLaw Enforcement Demands.\u201d Anyone who hasn\u2019t read it hasn\u2019t met their supplier-diligence obligations. Anyone who has read it and ignored it faces a different problem: they know their Schrems-II-compliant standard contractual clauses will buckle in a conflict and have signed anyway.<\/p>\n The European Court of Justice ruled in the 2020 Schrems-II decision that standard contractual clauses are only sufficient if the level of protection in the third country is in fact equivalent. The CLOUD Act makes it anything but equivalent. The 2023 EU-US Data Privacy Framework softens the impact at the application level, but it doesn\u2019t resolve the structural conflict. Data-protection and supervisory authorities assess the situation differently, leaving the compliance path anything but straightforward.<\/p>\n \nUsing a US hyperscaler means you contractually accept a clause that grants authorities access-one that clashes with European data-protection law. That\u2019s a deliberate risk transfer, not a technical shortcoming.<\/p><\/blockquote>\n The public debate often centers on US providers. Yet supply-chain reality is far broader. A managed SOC operated by a German MSSP frequently employs analysts in India, a cloud-backup vendor stores data in Poland and backups in Israel, and a SaaS HR-software provider runs development hubs in Vietnam. Each of these locations has its own government-access logic and its own interpretation of data export.<\/p>\n Source: Internal NIS2UmsuCG analysis plus EU Commission adequacy decisions, status May 2026.<\/p>\n A risk register that omits this view is exposed in a NIS2 audit. The regulator does not ask about favorite vendors; it asks for the evaluation methodology. If you have five sub-contractors in three third countries and no written assessment of government-access risk, you have formally failed NIS2 due-diligence.<\/p>\n Three situations make personal liability for senior management tangible in practice. First, after a security incident with data exfiltration: if the investigation reveals the supply chain was never evaluated, that\u2019s a breach of the duty of care. Second, during an audit without an incident: a regulator can sanction missing documentation even absent harm. Third, in civil litigation: when customer data is compromised through a third-country transfer, damage claims scale directly with the volume of data exposed.<\/p>\n Hyperscalers won\u2019t be the main defendants in these cases. Their contracts clearly delineate what they deliver and what they don\u2019t. The primary defendants are the customers who signed without contractually closing the gaps. That\u2019s the construction NIS2 now explicitly targets.<\/p>\n Step one: supplier inventory with third-country connections. Which vendor, which contract, which actual processing location, which sub-processors. If you can reduce this to an Excel sheet, you must be able to present it to a supervisory authority.<\/p>\n Step two: written risk assessment per supplier. Not \u201cwe trust AWS,\u201d but: what government access rights exist, which data categories are affected, what measures mitigate the risk. Customer-key encryption is one measure, geographic restriction another. Both must be documented.<\/p>\n Step three: contractual tightening. Standard contractual clauses plus additional safeguards are mandatory, not optional. Specifically: encryption controls, audit rights, mandatory reporting of government access, exit clauses with data-transfer paths.<\/p>\n Step four: executive-board resolution. The choice of supplier and the residual-risk assessment must be recorded in a formal board decision. Not in a cloud-strategy slide deck. In minutes that a regulator can follow.<\/p>\n The honest answer: not for every workload, not right away. The European Open Cloud Initiative and sovereign offerings such as OVHcloud, Open Telekom Cloud or Stackit cover a growing range, yet they do not replicate every technical feature of a hyperscaler. If you need Bedrock-equivalent inference, Aurora Serverless or specific Microsoft-Identity functions, there is no one-to-one replacement today.<\/p>\n That is no reason to keep the status quo. It is a reason for a differentiated architecture. Sensitive data categories move to European providers or stay on-premises. Generic workloads remain on the hyperscaler, with documented safeguards. The 2026 platform architecture is polyglot, not either-or.<\/p>\n The 2023 framework restored the adequacy decision and is the current legal basis. Several data-protection authorities and legal opinions, however, anticipate a new CJEU proceeding that will reassess its validity. Relying on the framework alone means accepting the risk of a Schrems-III ruling. A more robust approach combines the framework with additional technical measures-especially customer-key encryption.<\/p>\n Provider-managed encryption is insufficient because the provider holds the keys and can be compelled to surrender them under US law. Bring-Your-Own-Key or Hold-Your-Own-Key solutions with external key management close the gap technically, provided the key custodian itself is not subject to US jurisdiction. Note that not every provider offers HYOK for all services.<\/p>\n The provider is legally required to hand over the requested data. It may file an objection, but in practice this rarely succeeds. Customers are often not notified because the order can include a gagging clause. The data subject may only learn of the disclosure later, during subsequent legal proceedings.<\/p>\n NIS2 obligations apply above a certain size threshold or in regulated sectors. Smaller firms are generally not directly bound, yet they are contractually pulled into the checks by NIS2-bound customers. The duty effectively shifts into the supply chain. If your SME serves a NIS2-bound client, you must be able to provide the required information.<\/p>\n\n
What NIS2\u2019s supply-chain duty really demands<\/h2>\n
Where the US CLOUD Act Overrides European Data Protection<\/h2>\n
Third countries aren\u2019t just the USA<\/h2>\n
\n\n
\n \nRegion<\/th>\n Government Access (short)<\/th>\n NIS2 Assessment in the Data Room<\/th>\n<\/tr>\n<\/thead>\n \n USA<\/strong><\/td>\n CLOUD Act, FISA 702<\/td>\n High, residual conflict with Schrems II<\/td>\n<\/tr>\n \n UK<\/strong><\/td>\n Investigatory Powers Act, EU adequacy decision<\/td>\n Medium, adequacy under review<\/td>\n<\/tr>\n \n India<\/strong><\/td>\n IT Act Section 69, DPDP Act 2023<\/td>\n High, no adequacy decision<\/td>\n<\/tr>\n \n Israel<\/strong><\/td>\n Privacy Protection Law, EU adequacy decision<\/td>\n Medium, sector-specific residual risks<\/td>\n<\/tr>\n \n Philippines<\/strong><\/td>\n Data Privacy Act, government access via AML framework<\/td>\n High, frequent sub-contractor without contract<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n Where personal liability for executives really kicks in<\/h2>\n
Four concrete steps that must now appear in your risk register<\/h2>\n
When switching to European providers becomes realistic<\/h2>\n
Frequently Asked Questions<\/h2>\n
Is the EU-US Data Privacy Framework a sufficient basis for using US clouds?<\/h3>\n
Does server-side encryption on the hyperscaler protect against the CLOUD Act?<\/h3>\n
What happens if a hyperscaler receives a CLOUD Act demand?<\/h3>\n
Do small companies have to perform NIS2 supply-chain checks?<\/h3>\n
Editor\u2019s Reading Picks<\/h3>\n