NIS2 Cloud Shared Responsibility: The Phrase Appears Nowhere in the Directive — Here’s Who Actually Owns IaaS, PaaS, and SaaS

Search Directive (EU) 2022/2555 for the phrase “shared responsibility” and you find nothing. Search Commission Implementing Regulation (EU) 2024/2690 — the Commission’s technical annex written specifically for cloud computing service providers — and you find nothing there either. “Infrastructure as a Service”, “Platform as a Service” and “Software as a Service” appear exactly once each in the entire directive, in Recital 33, and only to define what counts as a cloud service[5]. They appear nowhere in the operative articles, nowhere in the annexes, and nowhere in the implementing regulation[9][10].

That absence is the whole problem. Your provider’s shared-responsibility diagram is a commercial and operational document: it tells you who runs what. NIS2 is a regulatory one: it tells you who answers for what. The two are not the same map, and the second one does not divide anything. It lays two independent sets of obligations over the same infrastructure — one always on you, one sometimes on your provider — and lets them overlap.

Who This Applies To

In plain terms: if your organisation is an essential or important entity and any part of your service runs on someone else’s infrastructure, the obligations below are yours. Nothing you buy moves them.

Your situation	What this article decides for you
Essential or important entity buying IaaS or PaaS (AWS, Azure, GCP, OVH, Hetzner)	Which stack layers you must control yourself, and which you must instead evidence
Essential or important entity running critical processes on SaaS	Whether your vendor carries any NIS2 obligation of its own — and what to do when it does not
Cloud computing service provider (NIS2 Annex I, digital infrastructure)	What your customers are now legally required to ask you for, and why refusing costs you renewals
MSP or MSSP (Annex I, ICT service management)	The same as above, plus your own CIR 2024/2690 annex obligations
Below the size thresholds and not designated by your Member State	You are likely out of scope as an entity — but you are still in your customers’ supply chain

What the Directive Actually Says About IaaS, PaaS and SaaS

Recital 33 is the only place the service models appear: “The service models of cloud computing include, inter alia, Infrastructure as a Service (IaaS), Platform as a Service (PaaS), Software as a Service (SaaS) and Network as a Service (NaaS)”[5]. Read what that sentence is doing. It is drawing a scope boundary — establishing that all four models count as cloud computing services, so a SaaS vendor cannot argue it is something else. Recitals are non-binding interpretive aids; they explain intent and create no obligations. This one allocates nothing, and no operative article picks the models up again.

The operative rule runs in the opposite direction. Article 21(1) requires essential and important entities to take appropriate and proportionate measures to manage the risks to the security of network and information systems “which those entities use for their operations or for the provision of their services”[1]. Article 21(2) then binds those measures to an all-hazards approach covering the systems “and the physical environment of those systems”[1] — language that does not stop at the edge of your own data centre. Recital 83 removes the ambiguity: those measures and the reporting obligations “should apply to the relevant essential and important entities regardless of whether those entities maintain their network and information systems internally or outsource the maintenance thereof”[6]. Germany’s competent authority, the BSI, states the same thing without hedging in its NIS2 FAQ: even when IT is completely outsourced, you as an important or particularly important entity remain responsible yourself[12].

So there is no split. There is your perimeter, which covers every system you use including the ones you do not operate, and there is your provider’s perimeter, which exists only if the provider is itself a regulated entity. Where they overlap, the same control is covered twice — once as your obligation, once as theirs. Where they do not, the uncovered part is always yours.

Is Your Provider Even a NIS2 Entity? Three Questions

Most cloud compliance advice assumes the answer is yes. Often it is not, and the answer changes what evidence you can realistically obtain. Three questions settle it, in order.

Question	Legal test	If the answer is no
1. Is it a cloud computing service?	Article 6(30): “a digital service that enables on-demand administration and broad remote access to a scalable and elastic pool of shareable computing resources”[4]. Recital 33 confirms IaaS, PaaS, SaaS and NaaS all qualify[5].	It may still be an MSP under Annex I sector 9, or simply an unregulated software vendor
2. Is it large enough?	Article 2(1): NIS2 applies to Annex I and II entity types that are medium-sized or larger[7]. Cloud providers are not in the Article 2(2)(a) size-independent list, which covers only public electronic communications, trust services, TLD registries and DNS providers[7].	The provider is outside NIS2 unless a Member State designates it under Article 2(2)(b) to (e)
3. Where is it established?	Article 26(1)(b) puts cloud providers under the jurisdiction of the Member State of their main establishment in the Union; Article 26(2) defines that as, first, where cybersecurity risk-management decisions are predominantly taken[3]. Under Article 26(3) a provider not established in the Union but offering services within it “shall designate a representative” in a Member State[3].	Enforcement against it is uncertain; treat its assurances as contractual promises, not regulated obligations

The practical consequence is uncomfortable and rarely stated: a 30-person European SaaS vendor holding your production data is, in most cases, not a NIS2 entity at all. Article 3(1)(a) makes an Annex I provider that exceeds the medium-sized ceilings an essential entity, subject to proactive supervision; anything smaller is at most important, or out of scope entirely[8]. Your Article 21 obligations over that data do not shrink to match. If you want to know whether your own organisation clears these thresholds, the NIS2 scope test works through the same logic from the customer side.

The Responsibility Matrix, Layer by Layer

This is the translation the provider diagram never gives you: each stack layer, who operates it under each service model, and the Article 21(2) measure it engages. “Operates” is the honest word — not “is responsible for”.

Stack layer	IaaS	PaaS	SaaS	Art. 21(2)
Physical facility, hardware, hypervisor	Provider	Provider	Provider	21(2) chapeau: physical environment
Network fabric and tenant isolation	Provider	Provider	Provider	(e) acquisition, development, maintenance
Guest OS and patching	You	Provider	Provider	(e) vulnerability handling
Runtime, middleware, managed database engine	You	Provider	Provider	(e) secure maintenance
Application code and dependencies	You	You	Provider	(e) secure development
Service configuration (buckets, roles, network rules, tenant settings)	You	You	You	(a) risk analysis + (e) maintenance
Identity, access rights, MFA	You	You	You	(i) access control, (j) MFA
Data, classification, retention	You	You	You	(i) asset management
Backup completeness and restore testing	You	Shared	Shared	(c) business continuity
Log generation, export and retention	You	Shared	Provider-gated	(b) incident handling
Assessment of the provider itself	You	You	You	(d) supply chain

Two rows deserve a second reading. The configuration row never moves — on every model, in every deployment pattern, misconfiguration of a provider-managed service is yours. And the bottom row is the one the diagrams omit entirely, because it is not a technical layer at all: Article 21(3) requires you to take into account “the vulnerabilities specific to each direct supplier and service provider and the overall quality of products and cybersecurity practices of their suppliers and service providers”[1]. The provider is the direct supplier being assessed. No service model removes that.

The Column the Provider’s Diagram Doesn’t Have

Once you accept that the two perimeters overlap rather than divide, every layer in the table above falls into one of four zones — and the zone, not the operator, tells you what you actually have to produce.

Zone	Situation	What you owe
A — Double-covered	Provider operates the layer and is itself a NIS2 entity bound by CIR 2024/2690	Evidence, not controls. CIR Annex 5.1.4(e) sets “the right to audit or right to receive audit reports”[9] as standard contract content for regulated providers — negotiate the same clause, then obtain and file the reports
B — Operated but unregulated	Provider operates the layer but is below threshold, non-EU without a representative, or not a cloud service at all	Evidence and compensating controls. Most niche SaaS lands here. Your Article 21 duty is unchanged; your assurance route is contractual only
C — Yours outright	You operate the layer	Controls, documentation and testing, exactly as on-premises
D — Unallocated	Neither the diagram nor the contract assigns it: log retention beyond the provider’s default, identity federation, sub-processor changes, exit and data portability	Yours by default, because Article 21 attaches to the entity, not the operator

One caveat governs every CIR reference in this article. Commission Implementing Regulation (EU) 2024/2690 legally binds only the entity types listed in its Article 1 — DNS and TLD operators, cloud computing and data centre service providers, CDNs, MSPs and MSSPs, online marketplaces, search engines, social platforms and trust service providers[9]. If your organisation is a hospital, a utility or a manufacturer, the CIR annex does not bind you; it is the most detailed interpretive reference available for what “appropriate and proportionate” looks like under Article 21, and the standard your cloud provider is measured against. Use it that way, not as a citation for your own obligations.

Zone D is where audits go wrong, and there is a specific mechanism worth knowing. CIR 2024/2690 marks many requirements “where appropriate”, “where applicable” or “to the extent feasible”. Article 2(2) of that regulation closes the loophole: where an entity considers such a requirement not appropriate, applicable or feasible, “the relevant entity shall in a comprehensible manner document its reasoning to that effect”[9]. That obligation binds the regulated cloud providers directly. Adopt the same discipline for your own boundary decisions and the argument you will have to make in an audit is already written down — which is the whole point of ENISA’s technical implementation guidance, built around examples of the evidence that shows a requirement has been met[11].

Three Places the Diagram Says “Provider” and NIS2 Says “You”

Backups. The CIR annex mentions cloud exactly once in its technical requirements, and it is here: backup plans must include “assurance that backup copies are complete and accurate, including configuration data and data stored in cloud computing service environment” (point 4.2.2(b))[9]. Assurance is an act someone performs. A provider’s managed backup service produces copies; it does not produce your assurance that they are complete, that they include your configuration state, or that a restore works. That test is yours on every service model.

Incident reporting. Article 23(1) requires an entity to notify “the recipients of their services of significant incidents that are likely to adversely affect the provision of those services”, where appropriate[10]. That is your provider’s duty towards you. It is not your discharge. Your own early warning is due “within 24 hours of becoming aware of the significant incident” under Article 23(4)(a)[10], and awareness starts when you learn of it — which, in practice, is often from a status page rather than a contractual notice. Our detailed walk-through of that timing sits in NIS2 cloud outage reporting.

Governance. Article 20(1) makes management bodies approve the risk-management measures, oversee their implementation, and be liable for infringements of Article 21[2]. There is no outsourced-IT exception. The BSI puts it directly: management remains obliged to steer and implement risk management, and must ensure its service providers implement the necessary NIS2 requirements and that incidents are reported properly[12]. The same reasoning applies to security operations generally — see the Article 20 liability you cannot delegate to an MSSP.

The Boundary Register: What to File Before the Auditor Asks

The artefact that answers all of this is not a policy. It is a register: one row per cloud service, recording where the boundary sits, which zone each contested layer falls into, and what evidence supports it. CIR Annex 5.1.1 already requires regulated entities to “identify their role in the supply chain and communicate it to their direct suppliers and service providers”[9]. Do the same in the other direction.

Role	Owns	Evidence produced
CISO / IT security	Layer-by-layer boundary mapping per service; configuration baselines; restore testing	Boundary register, restore test records, configuration review logs
Procurement	Selection criteria and contract content, modelled on CIR Annex 5.1.2 and 5.1.4[9]	Signed clauses on incident notification, audit rights, subcontracting, termination
Compliance / legal	The three-question provider status test; documented reasoning for every “where appropriate” call	Provider status assessment, reasoning notes, retained audit reports
Management body	Approval and oversight under Article 20(1)[2]	Minuted approval of the boundary register and of accepted residual risk

Review it on a cadence, not on incident. CIR Annex 5.1.6 requires regulated entities to monitor and act on changes in their suppliers’ cybersecurity practices “at planned intervals”[9] — a reasonable standard to hold yourself to when your supplier is the one running your production stack. For the control-by-control mapping underneath this register, see our Article 21 controls mapped to CIR 2024/2690 for AWS, Azure and GCP and, for the sub-provider layer, the one-level-down obligation in CIR Annex 5.

Frequently Asked Questions

Does NIS2 recognise the shared responsibility model?
No. The phrase appears nowhere in Directive (EU) 2022/2555 or in Commission Implementing Regulation (EU) 2024/2690[9][10]. The model remains useful for deciding who operates what, but it carries no legal weight in allocating obligations. Article 21 attaches to the entity, and Recital 83 confirms it applies whether systems are maintained internally or outsourced[6].

If my cloud provider is NIS2-compliant, am I compliant for those layers?
No. The provider’s compliance is evidence you can use, not a transfer of duty. Where the provider is a regulated entity, your remaining obligation for those layers is to obtain and retain that evidence under Article 21(3)[1], using the audit-report clause that CIR Annex 5.1.4(e) makes standard contract content for regulated providers[9]. Where it is not regulated, you need contractual assurance and, usually, compensating controls.

Is a small EU SaaS vendor covered by NIS2?
Usually not as an entity. Article 2(1) limits scope to Annex I and II entity types that are medium-sized or larger, and cloud providers do not appear in the size-independent list at Article 2(2)(a)[7]. A Member State can still bring one into scope under Article 2(2)(b) to (e). Either way, it remains your direct supplier under Article 21(2)(d).

Does using a non-EU cloud provider change my obligations?
Not yours. It changes theirs. Under Article 26(3) a provider not established in the Union but offering services within it must designate a representative in a Member State, and that Member State takes jurisdiction[3]. If no representative exists, enforcement is uncertain — which is a supply-chain risk factor to record, not a reason to lower your own standard.

Which service model carries the least compliance work?
SaaS shifts the most operational work to the provider, but it does not reduce the obligations that never move: configuration, identity and access, data classification, restore assurance, and the supplier assessment itself. It also concentrates the layers you cannot inspect, which increases the evidence you must obtain rather than the controls you must run.

Key Takeaways

• NIS2 and its implementing regulation never use the phrase “shared responsibility”, and name IaaS, PaaS and SaaS only once, in Recital 33, to define scope[5][9][10].
• Obligations do not split between provider and customer. Two perimeters overlap; the uncovered remainder is always yours.
• Before relying on a provider’s compliance, test whether it is a NIS2 entity at all: Article 6(30) service definition, Article 2(1) size, Article 26 jurisdiction[3][4][7].
• Configuration, identity, data classification and supplier assessment stay with you on every service model.
• For provider-operated layers you owe evidence rather than controls — and CIR Annex 5.1.4(e) gives you the contractual hook to obtain it[9].
• Document the reasoning behind every boundary decision, the way CIR Article 2(2) requires regulated entities to document their “where appropriate” calls[9].

Sources

1. Directive (EU) 2022/2555, Article 21 — cybersecurity risk-management measures, nis2resources.eu
2. Directive (EU) 2022/2555, Article 20 — governance, nis2resources.eu
3. Directive (EU) 2022/2555, Article 26 — jurisdiction and territoriality, nis-2-directive.com
4. Directive (EU) 2022/2555, Article 6 — definitions, nis-2-directive.com
5. Directive (EU) 2022/2555, Recital 33 — cloud computing service models, nis-2-directive.com
6. Directive (EU) 2022/2555, Recital 83 — outsourced network and information systems, nis-2-directive.com
7. Directive (EU) 2022/2555, Article 2 — scope, nis2resources.eu
8. Directive (EU) 2022/2555, Article 3 — essential and important entities, nis2resources.eu
9. Commission Implementing Regulation (EU) 2024/2690, EUR-Lex
10. Directive (EU) 2022/2555, full text (Article 23, Annex I), EUR-Lex
11. NIS2 Technical Implementation Guidance, v1.0, June 2025, ENISA
12. NIS-2-FAQ, Bundesamt für Sicherheit in der Informationstechnik (BSI), Germany

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.