Public cloud LLMs and NIS2: a quick read of Article 21(1)(d)

A technical note about one article and one scenario. A mid-sized manufacturer — an essential entity under NIS2 — wants to use ChatGPT Enterprise or Claude to generate work instructions. The compliance question that lands on the CISO's desk: does a contract with a public-cloud LLM provider meet the supply-chain security requirements of Article 21(1)(d) of the NIS2 Directive?

Short answer: not always "no," but more often "you need to document why yes" than "it's obviously fine."

What Article 21(1)(d) actually says

Directive (EU) 2022/2555 (NIS2) requires, in Article 21(1), that essential and important entities implement appropriate and proportionate cybersecurity risk-management measures. Point (d) covers, in short: supply-chain security, including security-related aspects of the relationships between an entity and its direct suppliers or service providers.

Crucially, Article 21(3) specifies that the assessment of these relationships must take into account:

• the specific vulnerabilities of each direct supplier,
• the overall quality of the supplier's products and cyber practices,
• the supplier's secure development practices.

ENISA's 2024 and 2025 guidance says it plainly: this is not only about classic IT vendor management. It concerns any supplier that touches systems or data within NIS2 scope. A generative-AI provider that receives an essential entity's technical content falls squarely within that scope.

Anatomy of a public-cloud LLM relationship

When an essential entity uses ChatGPT Enterprise, Claude for Work, or Gemini Enterprise, the supply chain doesn't end at the vendor. Each major LLM provider runs on hyperscaler infrastructure:

• OpenAI: a significant share of production infrastructure on Microsoft Azure.
• Anthropic: AWS and GCP as compute platforms.
• Google: its own infrastructure, but with numerous sub-processors.

From the perspective of Article 21(1)(d), this means the supply-chain risk assessment covers not one but at least two suppliers (the LLM vendor plus its hyperscaler), and often more (CDN, observability, billing, support).

Three areas where the standard relationship struggles

Reviewing publicly available contracts (DPAs, master service agreements, sub-processor lists) surfaces three areas where a standard public-cloud LLM relationship rarely meets Article 21(1)(d) without extra negotiation.

1. Sub-processors and supply-chain transparency

A standard DPA lets the LLM vendor add and change sub-processors with limited notice (typically 30 days). For an essential entity that must document the full supplier list in its Article 21 mapping, that means an ongoing obligation to monitor the vendor's changes. In practice: someone in the organisation verifies the sub-processor list every month and updates the risk register.

2. Audit rights and the right to verify

Classic enterprise SaaS allows audits, but within narrow limits: annual frequency, a contracted auditor, scope limited to certifications (SOC 2, ISO 27001). Article 21(3) requires assessing the supplier's "secure development practices." How many LLM vendors will agree to an audit of the MLOps pipeline, training-data governance, model lifecycle management? In practice: very few — and if they do, the audit itself costs EUR 50,000–150,000 in auditor and legal hours.

3. Incident notification and response time

NIS2 requires an essential entity to report a significant incident to the CSIRT within 24 hours of detection. If the incident happens on the LLM provider's side (e.g. a data breach at the hyperscaler), the essential entity must learn of it faster than a standard "99.9% uptime" SLA provides. A typical public-cloud LLM contract doesn't guarantee notification within hours (usually a "without undue delay" formula). Meaning: you have to monitor actively, not rely on vendor notification.

What this means in practice

It doesn't mean "you may not use public-cloud LLMs." It means: if you use them, your Article 21 mapping should document:

• a sub-processor list updated monthly,
• a risk analysis for each sub-processor,
• a mechanism to monitor changes to the sub-processor list,
• alternative audit mechanisms (SOC 2 Type II report, security questionnaire, third-party attestation),
• an incident-response runbook for a breach on the vendor's side,
• data-residency mapping for each type of content processed,
• a compliance decision: which document categories may be sent to the vendor, and which may not.

That's real work. For a mid-sized firm of 200–500 FTE with one compliance lead and a half-time CISO, documenting it alone is often 4–6 weeks, plus ongoing maintenance. For comparison, the same team in the same window could plan an on-prem pilot, where data residency resolves by definition.

Red flags in the vendor contract

A short checklist to review before signing an MSA with a public-cloud LLM. If any point can't be resolved contractually, it's worth pausing to cost the alternative.

• No concrete sub-processor list (only "the list is available online") plus no SLA for change notification.
• Audit rights limited to certifications, with no right to an operational audit.
• Incident notification limited to incidents "affecting the customer" (who defines impact?).
• Data residency specified only at region level (e.g. EU), with no guarantee of a specific data centre.
• No data-deletion mechanism after contract end with a confirming SLA.
• Vendor liability capped at 12 months of fees. Against a potential penalty of EUR 10 million or 2% of global turnover on the essential entity's side, that's an asymmetry the board should examine separately.

// disclosure & biasesDisclosure and biases

The author works on an on-prem AI platform for European manufacturers. The analysis here may be biased toward alternatives to public-cloud LLMs. Where that bias could shape the conclusions, I've tried to flag it inline. The estimates of compliance-team effort for public cloud are my own judgement based on a handful of conversations with compliance leads, not public data.

What I don't cover here

This note shouldn't be read as an exhaustive analysis of Article 21. I've left out:

• the remaining points of Article 21(1) (a–j); some, e.g. point (f) (policies to assess the effectiveness of measures), also have concrete implications for AI vendor selection,
• the relationship between Article 21 and Article 23 (notification obligations) in a vendor-breach scenario,
• member-state specifics in NIS2 transposition (Poland's amended UKSC, Germany's NIS2UmsG, France's LPM),
• the EU AI Act and its high-risk classification, which may further influence the vendor decision,
• the build-vs-buy economics with concrete numbers for a mid-sized 500-FTE firm,
• the technical options for private deployment in hyperscaler offerings (Azure OpenAI Dedicated, Google Distributed Cloud), which deserve a separate calibration analysis.

Those topics will come in later notes.

---

Related notes

• AI vendor lock-in: three layers and two contractual traps
• On-prem AI in European manufacturing 2026: a complete architecture guide
• DIY, productized, or managed: three on-prem AI models and who maintains them

Next step

This site doesn't sell — it takes notes. In the meantime, follow us on LinkedIn: linkedin.com/in/fryderykpryjma