NIS2 Art.21(2)(d) + CLOUD Act: The Supply Chain Compliance Gap Exposing EU Critical Infrastructure Entities (2026 Audit Guide)

NIS2 (Directive 2022/2555) is Europe's most ambitious cybersecurity law to date. It covers approximately 160,000 entities across 18 critical sectors — energy, transport, banking, health, water, digital infrastructure, and more. Article 21(2) mandates 10 specific security measures. Article 21(2)(d) requires supply chain security, including security-related aspects of relationships between entities and their direct suppliers or service providers.

Here is the problem: most NIS2-regulated organisations in the EU run their critical workloads on AWS Frankfurt, Azure West Europe, or GCP Belgium. These data centres sit on European soil. But the companies operating them — Amazon.com Inc., Microsoft Corporation, Alphabet Inc. — are incorporated in the United States. And under 18 U.S.C. § 2713, the Clarifying Lawful Overseas Use of Data (CLOUD) Act, a US court can compel these companies to produce your data regardless of where their servers physically sit.

NIS2 Art.21(3) requires organisations to use state-of-the-art security measures. In 2026, ignoring a well-documented legal mechanism that grants US law enforcement access to EU-hosted data is arguably not state of the art.

The June 2026 NIS2 audit season is here. National competent authorities across the EU are issuing their first formal assessments. Supply chain security is a primary audit focus. This guide explains what auditors are looking for and how to close the gap.

1. NIS2 Art.21: The 10 Mandatory Measures

Article 21(1) requires organisations to implement appropriate and proportionate technical, operational, and organisational measures to manage risks posed to their networks and information systems. Article 21(2) lists 10 mandatory categories:

Art.21(3) anchors all of these to the "state of the art" standard, taking into account the costs of implementation and the risks involved.

Art.21(2)(d) Supply Chain Security — Full Text

"supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers"

The recitals clarify that this includes assessing the overall security practices of suppliers, including their vulnerability handling and disclosure processes, and the security of products and services they deliver.

In the context of cloud hosting, your cloud provider is a service provider under Art.21(2)(d). Their susceptibility to third-country legal demands — including the CLOUD Act — is a security-related aspect of that relationship.

2. What the CLOUD Act Actually Does

The Clarifying Lawful Overseas Use of Data Act (CLOUD Act), 18 U.S.C. § 2713, was enacted in 2018. It amends the Stored Communications Act to explicitly state:

"A provider of electronic communication service or remote computing service shall comply with the obligations of this chapter to preserve, backup, or disclose the contents of a wire or electronic communication and any record or other information pertaining to a customer or subscriber within such provider's possession, custody, or control, regardless of whether such communication, record, or other information is located within or outside of the United States."

Key implications for EU-based workloads:

1. Jurisdiction follows incorporation, not server location. AWS EMEA SARL (Luxembourg) is a subsidiary of Amazon.com Inc. (Seattle, Washington). US courts apply US law to the parent, which controls the subsidiary's data.

2. No notification requirement. The CLOUD Act does not require the provider to inform you that your data has been produced. You may never know.

3. GDPR conflict. GDPR Art.48 prohibits transfers of personal data to third countries unless an adequacy decision, appropriate safeguards, or derogation applies. A CLOUD Act production order is neither. EU supervisory authorities have consistently held that complying with a CLOUD Act order without an Art.48 exception constitutes an unlawful transfer.

4. The EU-US Data Privacy Framework (DPF) does not fix this. The DPF governs commercial data flows. CLOUD Act orders are law enforcement demands — outside the DPF scope entirely.

3. The NIS2 × CLOUD Act Compliance Paradox

Here is the structural problem facing NIS2-regulated entities in 2026:

NIS2 Art.21(2)(d): Assess security of your cloud provider
         ↓
Cloud provider = AWS Frankfurt (Amazon.com Inc., US)
         ↓
Amazon.com Inc. is subject to CLOUD Act 18 U.S.C. § 2713
         ↓
US law enforcement can compel production of your NIS2-regulated data
         ↓
NIS2 Art.21(3): State of the art → this risk is well-documented in 2026
         ↓
Failure to document and mitigate = Art.21(2)(d) non-compliance finding

The NIS2 regulation does not name the CLOUD Act. But Art.21(2)(d) does not need to name it. The requirement is to assess security-related aspects of supplier relationships. A legal mechanism that grants a third-country government access to your data, without your knowledge or consent, is a security-related aspect.

What auditors will ask:

• "Have you assessed your cloud provider's susceptibility to third-country legal demands?"
• "Is this risk documented in your supplier risk register?"
• "What mitigations have you implemented or planned?"
• "Do your contracts with cloud providers include Art.28(3)(f) GDPR clauses covering CLOUD Act scenarios?"

4. Sector-Specific Risk: Who Is Most Exposed

Not all NIS2 entities carry the same CLOUD Act risk. The severity depends on the sensitivity of data processed:

*Selected member states have designated public administration entities as Essential.

5. Python: NIS2CloudActRiskAssessor

from dataclasses import dataclass, field
from enum import Enum
from typing import Optional
import json

class CloudActExposure(Enum):
    NONE = "none"          # EU-incorporated, no US parent
    LOW = "low"            # EU legal entity, complex US parent chain
    MEDIUM = "medium"      # US parent, EU DPA agreement + CLOUD Act clauses
    HIGH = "high"          # Direct US entity, no mitigations
    CRITICAL = "critical"  # Direct US entity, personal data of Art.9 categories

class NIS2EntityType(Enum):
    ESSENTIAL = "essential"
    IMPORTANT = "important"

@dataclass
class CloudSupplier:
    name: str
    incorporation_country: str       # ISO 3166-1 alpha-2
    us_parent: bool
    cloud_act_clauses_in_contract: bool
    eu_legal_entity: bool
    data_categories: list[str]       # e.g. ["personal", "health", "financial"]
    documented_in_risk_register: bool
    mitigation_plan: Optional[str] = None

@dataclass
class NIS2Entity:
    name: str
    sector: str
    entity_type: NIS2EntityType
    suppliers: list[CloudSupplier] = field(default_factory=list)

def assess_cloud_act_exposure(supplier: CloudSupplier) -> CloudActExposure:
    """Assess CLOUD Act exposure level for a single supplier."""
    if not supplier.us_parent and supplier.incorporation_country != "US":
        return CloudActExposure.NONE
    
    if "health" in supplier.data_categories or "biometric" in supplier.data_categories:
        return CloudActExposure.CRITICAL
    
    if supplier.us_parent and not supplier.cloud_act_clauses_in_contract:
        return CloudActExposure.HIGH
    
    if supplier.us_parent and supplier.cloud_act_clauses_in_contract:
        return CloudActExposure.MEDIUM
    
    if not supplier.eu_legal_entity:
        return CloudActExposure.HIGH
    
    return CloudActExposure.LOW

@dataclass
class SupplierRiskResult:
    supplier_name: str
    exposure: CloudActExposure
    art21d_findings: list[str]
    recommended_actions: list[str]

def assess_nis2_supply_chain(entity: NIS2Entity) -> dict:
    """
    Assess NIS2 Art.21(2)(d) compliance for cloud suppliers.
    Returns a structured audit report.
    """
    results = []
    critical_gaps = []
    
    for supplier in entity.suppliers:
        exposure = assess_cloud_act_exposure(supplier)
        findings = []
        actions = []
        
        # Finding 1: Risk register documentation
        if not supplier.documented_in_risk_register:
            findings.append(
                f"Art.21(2)(d) gap: {supplier.name} not documented in supplier risk register"
            )
            actions.append(
                f"Add {supplier.name} to supplier risk register with CLOUD Act exposure assessment"
            )
        
        # Finding 2: Contract clauses
        if supplier.us_parent and not supplier.cloud_act_clauses_in_contract:
            findings.append(
                f"Contract with {supplier.name} lacks CLOUD Act disclosure clauses "
                f"(Art.28(3)(f) GDPR + NIS2 Art.21(2)(d) supply chain requirement)"
            )
            actions.append(
                f"Negotiate CLOUD Act addendum with {supplier.name}: "
                f"notification obligation (where legally permitted), "
                f"challenge obligation, GDPR Art.48 conflict documentation"
            )
        
        # Finding 3: Exposure level actions
        if exposure in (CloudActExposure.HIGH, CloudActExposure.CRITICAL):
            findings.append(
                f"CLOUD Act exposure: {exposure.value.upper()}. "
                f"US law enforcement can compel {supplier.name} to produce your data "
                f"without prior notice under 18 U.S.C. § 2713."
            )
            actions.append(
                f"Initiate migration assessment for {supplier.name} workloads "
                f"to EU-sovereign alternative (NIS2 Art.21(3) state-of-the-art)"
            )
            critical_gaps.append(supplier.name)
        
        # Finding 4: Art.9 special category data
        if exposure == CloudActExposure.CRITICAL:
            findings.append(
                f"Art.9 GDPR special category data + CLOUD Act = double-exposure. "
                f"EDPB Opinion 1/2021: transfers under law enforcement demands "
                f"cannot be legitimised under GDPR Art.46 SCCs."
            )
            actions.append(
                f"PRIORITY: Replace {supplier.name} with EU-sovereign provider "
                f"for all Art.9 data processing within 90 days."
            )
        
        results.append(SupplierRiskResult(
            supplier_name=supplier.name,
            exposure=exposure,
            art21d_findings=findings,
            recommended_actions=actions
        ))
    
    # Overall Art.21(2)(d) compliance assessment
    max_exposure = max(
        (assess_cloud_act_exposure(s) for s in entity.suppliers),
        key=lambda e: list(CloudActExposure).index(e),
        default=CloudActExposure.NONE
    )
    
    return {
        "entity": entity.name,
        "sector": entity.sector,
        "entity_type": entity.entity_type.value,
        "art21d_compliance_status": (
            "NON-COMPLIANT" if critical_gaps else
            "PARTIAL" if any(r.art21d_findings for r in results) else
            "COMPLIANT"
        ),
        "max_cloud_act_exposure": max_exposure.value,
        "critical_suppliers": critical_gaps,
        "supplier_results": [
            {
                "supplier": r.supplier_name,
                "exposure": r.exposure.value,
                "findings": r.art21d_findings,
                "actions": r.recommended_actions
            }
            for r in results
        ],
        "audit_recommendation": (
            "Immediate remediation required before NIS2 audit" if critical_gaps
            else "Document existing mitigations and include in Art.21 security policy"
        )
    }


# Example usage: German energy provider
def example_assessment():
    aws_frankfurt = CloudSupplier(
        name="AWS Frankfurt (Amazon Web Services EMEA SARL)",
        incorporation_country="LU",  # Luxembourg entity
        us_parent=True,              # Parent: Amazon.com Inc.
        cloud_act_clauses_in_contract=False,
        eu_legal_entity=True,
        data_categories=["operational", "personal"],
        documented_in_risk_register=False
    )
    
    azure_west_eu = CloudSupplier(
        name="Azure West Europe (Microsoft Ireland Operations Ltd.)",
        incorporation_country="IE",
        us_parent=True,              # Parent: Microsoft Corporation
        cloud_act_clauses_in_contract=True,  # Microsoft has CLOUD Act addendum
        eu_legal_entity=True,
        data_categories=["personal", "financial"],
        documented_in_risk_register=True
    )
    
    sota_eu = CloudSupplier(
        name="sota.io (EU-sovereign PaaS)",
        incorporation_country="DE",
        us_parent=False,
        cloud_act_clauses_in_contract=False,  # Not needed — no US parent
        eu_legal_entity=True,
        data_categories=["operational"],
        documented_in_risk_register=True
    )
    
    entity = NIS2Entity(
        name="Example Energy GmbH",
        sector="Energy",
        entity_type=NIS2EntityType.ESSENTIAL,
        suppliers=[aws_frankfurt, azure_west_eu, sota_eu]
    )
    
    report = assess_nis2_supply_chain(entity)
    print(json.dumps(report, indent=2))


if __name__ == "__main__":
    example_assessment()

Example output:

{
  "entity": "Example Energy GmbH",
  "sector": "Energy",
  "entity_type": "essential",
  "art21d_compliance_status": "NON-COMPLIANT",
  "max_cloud_act_exposure": "high",
  "critical_suppliers": ["AWS Frankfurt (Amazon Web Services EMEA SARL)"],
  "audit_recommendation": "Immediate remediation required before NIS2 audit"
}

6. NIS2 × CLOUD Act: The Three Legal Gaps You Need to Close

Gap 1: Supplier Risk Register Does Not Document CLOUD Act Exposure

NIS2 Art.21(2)(a) requires a risk analysis and information security policies. Art.21(2)(d) requires supply chain security assessment. Most supplier risk registers document availability, SLA, and data residency. Very few document legal jurisdiction of the operating entity.

Fix: Add a "US Parent / CLOUD Act Exposure" column to every supplier in your risk register. Classify: EU-sovereign, EU entity with US parent (LOW), US entity with EU operations (HIGH).

Gap 2: Cloud Service Agreements Lack CLOUD Act Clauses

GDPR Art.28(3) Data Processing Agreements require processors to notify controllers of legal obligations that prevent them from fulfilling DPA obligations. CLOUD Act orders are exactly such an obligation — but most standard cloud DPAs written before 2018 do not address them.

Fix: Request a CLOUD Act addendum from each major cloud provider. Microsoft, Google, and (selectively) AWS have published their positions and offer addenda. Require: (1) obligation to notify you of any CLOUD Act order received, to the extent legally permitted; (2) obligation to challenge overbroad orders; (3) documentation of the GDPR Art.48 conflict.

Gap 3: Incident Response Plan Does Not Cover Covert CLOUD Act Productions

NIS2 Art.21(2)(b) requires incident handling. Art.23 requires 24h early warning and 72h incident report. But a CLOUD Act production order may never trigger your incident detection systems — the data leaves silently.

Fix: Add a "covert legal demand" scenario to your incident response playbook. Document the detection pathway: provider transparency report → annual review → no real-time detection. Classify this as a residual risk. Escalate if you are in a sector where covert data access would qualify as a significant incident.

7. NIS2 Art.23 Incident Reporting + CLOUD Act

Article 23 of NIS2 establishes the incident reporting chain:

• 24 hours: Early warning to CSIRT or competent authority
• 72 hours: Incident notification with initial assessment
• 1 month: Final report

A CLOUD Act production order that results in exfiltration of EU citizen data may qualify as a "significant incident" under Art.23(3) if it has a significant impact on service delivery. However, since the cloud provider may not notify you, the 24h clock never starts.

This is a structural gap in NIS2 that has not yet been resolved by the Commission. Pending guidance from ENISA, the prudent approach is:

1. Document in your incident classification matrix: "Covert legal demand by third-country authority to cloud provider — undetectable via normal monitoring"
2. Set an annual review of provider transparency reports as a compensating control
3. Flag this gap explicitly in your Art.21(2)(a) risk analysis

8. CLOUD Act Risk Tiers for NIS2 Compliance

Key: "EU region" does not determine CLOUD Act exposure. Legal incorporation of the operating entity and its parent does.

9. What NIS2 Auditors Will Check in June 2026

Based on published audit frameworks from BSI (Germany), ANSSI (France), and ENISA's NIS2 Implementation Guide, auditors assessing Art.21(2)(d) will review:

1. Supplier inventory: Is every cloud provider listed with full legal entity details?
2. Risk classification: Has each supplier's legal jurisdiction been assessed for third-country law exposure?
3. Contract review: Do DPAs/cloud service agreements address legal demand disclosure?
4. Risk register documentation: Is CLOUD Act exposure explicitly documented as a risk?
5. Mitigation plans: For HIGH/CRITICAL exposure suppliers, is there a migration roadmap?
6. Board-level awareness: Has the CLOUD Act risk been reported to management (Art.20 NIS2)?

Art.20 NIS2 requires management bodies to approve cybersecurity risk management measures and oversee their implementation. Board members can be held personally liable for non-compliance. This means the CLOUD Act supply chain gap is not just a technical issue — it is a governance issue.

10. NIS2 + CLOUD Act: 25-Item Compliance Checklist

Part A: NIS2 Art.21 Baseline (5 items)

• A-01: Risk analysis (Art.21(2)(a)) documents all cloud providers as third-party suppliers
• A-02: Incident response plan (Art.21(2)(b)) includes covert legal demand scenario
• A-03: Business continuity (Art.21(2)(c)) covers loss of access to cloud-hosted data
• A-04: All cloud DPAs include GDPR Art.28(3)(f) legal obligation notification clauses
• A-05: Board has reviewed and approved supply chain security measures (Art.20 NIS2)

Part B: Art.21(2)(d) Supply Chain Security (7 items)

• B-01: Supplier risk register includes legal incorporation country for all cloud providers
• B-02: Supplier risk register documents US-parent status for all cloud providers
• B-03: CLOUD Act exposure classified (NONE / LOW / MEDIUM / HIGH / CRITICAL) per supplier
• B-04: Art.21(3) state-of-the-art assessment documents CLOUD Act as foreseeable risk
• B-05: Annual supplier security assessment includes third-country legal demand review
• B-06: Migration assessment completed for HIGH/CRITICAL exposure suppliers
• B-07: Compensating controls documented for suppliers where migration is not yet feasible

Part C: CLOUD Act Exposure Mitigation (5 items)

• C-01: CLOUD Act addendum requested/obtained from each US-parent cloud provider
• C-02: Provider transparency reports reviewed annually for each major cloud supplier
• C-03: Art.9 GDPR special category data hosted exclusively on non-CLOUD-Act platforms
• C-04: Transfer Impact Assessment (TIA) completed for each US-parent cloud processor
• C-05: Legal team briefed on GDPR Art.48 conflict with CLOUD Act production orders

Part D: Incident Response (4 items)

• D-01: Incident classification matrix includes "covert third-country legal demand" category
• D-02: CSIRT escalation path defined for CLOUD Act-related incidents
• D-03: Art.23 24h early warning checklist covers covert data access scenarios
• D-04: Post-incident review process includes transparency report comparison

Part E: Audit Preparation (4 items)

• E-01: All Art.21(2)(d) supplier assessments documented with date and assessor
• E-02: CLOUD Act risk documented in Art.21(2)(a) risk register with residual risk rating
• E-03: Management sign-off on CLOUD Act risk acceptance or mitigation plan obtained
• E-04: Evidence package prepared: supplier list + risk ratings + contract addenda + TIAs

11. The Sovereign Hosting Solution

The cleanest way to close the NIS2 Art.21(2)(d) CLOUD Act gap is to eliminate it from your supply chain entirely. This means hosting NIS2-regulated workloads on providers where there is no US parent, no US subsidiary relationship, and no CLOUD Act exposure.

What EU-sovereign hosting requires:

1. EU legal entity as the operating entity (not just a subsidiary)
2. No US parent company in the corporate ownership chain
3. EU-resident infrastructure (servers, storage, networking)
4. EU-jurisdiction contracts with no US governing law clauses
5. GDPR Art.28 DPAs that explicitly document the absence of third-country legal exposure

sota.io is a European PaaS that meets all five criteria. No CLOUD Act exposure. No US parent. No surprise legal demands. Your NIS2 Art.21(2)(d) supplier risk assessment for sota.io ends at: CLOUD Act exposure: NONE.

12. Common Mistakes

Mistake 1: Treating "EU region" as equivalent to "EU jurisdiction"

Frankfurt, Amsterdam, and Dublin data centres operated by AWS, Azure, and GCP are in the EU. But CLOUD Act jurisdiction follows the incorporating country of the operating entity — not the server location. See EU Region vs. EU Jurisdiction.

Mistake 2: Assuming the EU-US Data Privacy Framework covers CLOUD Act

The DPF governs commercial data transfers under GDPR Chapter V. CLOUD Act orders are law enforcement demands — they fall entirely outside the DPF framework. The DPF does not provide any protection against CLOUD Act production orders.

Mistake 3: Thinking Standard Contractual Clauses prevent CLOUD Act production

SCCs create obligations between the controller and processor. CLOUD Act creates obligations between the US government and the provider. The provider cannot lawfully breach a US court order because you have SCCs. Your SCC clause is simply overridden — this is documented in the GDPR Art.48 conflict analysis.

Mistake 4: Waiting for ENISA guidance before acting

ENISA is expected to publish NIS2 supply chain security guidelines in late 2026. But NIS2 audits are happening now, in June 2026. Art.21(3) "state of the art" is assessed at the time of the audit, not at the time of future guidance. Auditors will not wait for ENISA guidance before flagging CLOUD Act as a known risk.

Summary

NIS2 Art.21(2)(d) does not name the CLOUD Act. It does not need to. It requires you to assess security-related aspects of your supplier relationships. A US statute that grants law enforcement access to your EU-hosted data without your knowledge is a security-related aspect. Document it, mitigate it, and be ready to show your work to the auditor.

For EU-sovereign PaaS with no CLOUD Act exposure — meeting NIS2 Art.21(2)(d) supply chain requirements — see sota.io.