NIS2 meets CLOUD Act: Who is liable for the third-country gap?

8 min read

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.

Related:NIS2 compliance for SMEs: practical steps  /  DORA & NIS2: why bank audits collide in 2026

What NIS2’s supply-chain duty really demands

What does “supply chain security” mean under NIS2? 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.

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.

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 “we use Azure” is no longer enough. NIS2 wants visibility two layers deep.

Where the US CLOUD Act Overrides European Data Protection

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.

This is no secret. It’s spelled out in the data-processing contracts of the hyperscalers, typically under “Government Access Requests” or “Law Enforcement Demands.” Anyone who hasn’t read it hasn’t 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.

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’t resolve the structural conflict. Data-protection and supervisory authorities assess the situation differently, leaving the compliance path anything but straightforward.

Using a US hyperscaler means you contractually accept a clause that grants authorities access-one that clashes with European data-protection law. That’s a deliberate risk transfer, not a technical shortcoming.

Third countries aren’t just the USA

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.

Source: Internal NIS2UmsuCG analysis plus EU Commission adequacy decisions, status May 2026.

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.

Where personal liability for executives really kicks in

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’s 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.

Hyperscalers won’t be the main defendants in these cases. Their contracts clearly delineate what they deliver and what they don’t. The primary defendants are the customers who signed without contractually closing the gaps. That’s the construction NIS2 now explicitly targets.

Four concrete steps that must now appear in your risk register

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.

Step two: written risk assessment per supplier. Not “we trust AWS,” 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.

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.

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.

When switching to European providers becomes realistic

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.

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.

Frequently Asked Questions

Is the EU-US Data Privacy Framework a sufficient basis for using US clouds?

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.

Does server-side encryption on the hyperscaler protect against the CLOUD Act?

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.

What happens if a hyperscaler receives a CLOUD Act demand?

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.

Do small companies have to perform NIS2 supply-chain checks?

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.

Editor’s Reading Picks

• NIS2 compliance for SMEs: practical steps
• DORA and NIS2: why bank audits are now colliding
• 72 % of cyber-defence capabilities originate abroad