NIS2 Cloud Security: 5 Article 21 Controls Mapped to CIR 2024/2690 for AWS, Azure, and GCP

NIS2 does not have a separate cloud security article. There is no “Article 21a — cloud computing” anywhere in the directive. Every obligation that applies to a server in your own data centre applies identically to a workload running in AWS, Azure, or Google Cloud — the same ten measures in Article 21(2), the same Commission Implementing Regulation (CIR) 2024/2690 technical annex, the same auditors. What changes in the cloud is not what you must have, but who builds it and what you can point to as proof — and that distinction is exactly where most cloud-hosted entities get caught out. This guide maps the five Article 21 measures that shift hardest when infrastructure moves off-premises — identity and access, network segmentation, logging, patch management, and supply chain — to their exact CIR 2024/2690 subsection, with the shared-responsibility line drawn explicitly for each one.

Who This Applies To

CIR 2024/2690’s technical annex is not automatically binding on your organisation just because you use cloud services. Read it as two separate tracks.

Your position	Does CIR 2024/2690 bind you directly?
You are the cloud provider — IaaS, PaaS, SaaS, CDN, DNS, or MSP/MSSP operating in the EU	Yes. CIR 2024/2690 lists cloud computing service providers as one of the digital-infrastructure entity types the regulation binds directly. The full annex applies to your own operations.
You use cloud services as an essential or important entity in another sector (manufacturing, healthcare, energy, finance, etc.)	Not directly — you follow Article 21(2) generally, as implemented by your national competent authority. But CIR 2024/2690 is the closest thing the EU has published to a technical answer for “what does state-of-the-art actually mean under Article 21(1),” and auditors in several member states reference it as a benchmark even for entities it doesn’t formally bind.

In practice, both groups end up building the same evidence. If you’re the second group, treat the CIR subsections in this guide as the specification your auditor will implicitly grade you against, not as text you can skip because it “doesn’t apply.” Infringing Article 21 or 23 carries a fine of up to EUR 10,000,000 or 2% of total worldwide annual turnover for essential entities (whichever is higher), and up to EUR 7,000,000 or 1.4% for important entities[1] — the exposure is identical whether the infringing system sits in your server room or in someone else’s data centre.

The Shared Responsibility Boundary, Mapped to Article 21

Cloud providers publish shared-responsibility diagrams that split “security of the cloud” from “security in the cloud.” Those diagrams are useful for billing conversations; they are useless for an NIS2 audit, because they aren’t written against Article 21(2)’s ten measures. The table below is that translation — who is expected to hold the evidence for each measure, by deployment model.

Art.21(2) measure	IaaS	PaaS	SaaS
(b) Incident handling / logging	You — full stack visibility is yours to build	Shared — platform logs plus your application logs	Mostly provider — you depend on their audit-log export
(c) Backup / business continuity	You configure and validate	Shared — provider backs up the managed service, you back up your data/config	Provider-managed, but you must still prove you verified it
(d) Supply chain	Provider is your direct supplier either way	Provider is your direct supplier either way	Provider is your direct supplier either way
(e) Network security / patching	You — OS and network layer are yours	Provider patches the runtime; you patch your code and configuration	Provider — but you own access configuration
(i)/(j) Access control, MFA	You	You	You — this line almost never moves

Two rows are worth reading twice. First, supply-chain obligations under Article 21(2)(d) never transfer to the provider — no deployment model removes your duty to assess your provider’s cybersecurity practices, because the provider is the direct supplier being assessed. Second, identity and access management barely moves across IaaS, PaaS, and SaaS. Whatever else the provider manages, you almost always still own who can log in and what they can do once they’re in.

Identity and Access Management in the Cloud

Article 21(2)(i) requires access control policies and asset management; Article 21(2)(j) adds multi-factor or continuous authentication “where appropriate”[1]. CIR 2024/2690’s Section 11 (access control) sets the technical floor: a documented access-control policy, periodic review of access rights, dedicated controls for privileged accounts, unique identification for every user, and MFA or continuous authentication for critical systems and remote access[2].

Cloud identity providers (Entra ID, AWS IAM Identity Center, Google Cloud Identity, Okta) make the mechanics easier than on-premises Active Directory ever was — conditional access policies, just-in-time privileged access, and MFA enforcement are configuration toggles, not infrastructure projects. The part cloud tooling doesn’t do for you is the policy and the periodic review. A CIR-compliant access review means someone signs off, on a defined cadence, that the list of humans and service accounts with standing privileged access is still correct — cloud IAM logs who has access; they don’t attest that access is still justified. That attestation step is the evidence gap that shows up most often when auditors examine cloud-native environments: the technical control exists, but nobody can produce a dated record of the last review. Our own access control and asset management guide walks through the full CIR Section 10–12 requirement set if you need the human-resources and asset-inventory side as well.

Network Segmentation Beyond the VPC

CIR Section 6.8 requires entities to “segment systems into networks or zones” based on the risk assessment, to separate the administration network from the operational network, and to segregate administration channels from other traffic[2]. In a cloud environment, that requirement doesn’t stop at “we created a VPC.” A single flat VPC with every workload in one subnet and one security group satisfies none of Section 6.8’s three sub-points — it isn’t zoned by risk, it doesn’t separate admin from operational traffic, and it gives no evidence of segregated administration channels.

What auditable cloud segmentation looks like: separate VPCs or subnets by risk tier (public-facing, application, data), a dedicated management subnet reached only through a bastion host or cloud-native session manager (AWS Systems Manager Session Manager, Azure Bastion) rather than direct SSH/RDP exposure, and security groups or NSGs that default-deny lateral movement between tiers. Section 6.7 additionally expects a documented plan to move toward current, secure network protocols — in cloud terms, that’s TLS 1.2 minimum (1.3 where supported) on load balancers and API gateways, not legacy cipher suites left on by default[2]. Section 6.8.3 requires the segmentation model to be reviewed and updated at planned intervals — worth calendaring explicitly, because cloud environments drift fast: a new microservice or a temporary debugging rule added to a security group six months ago is exactly the kind of undocumented exception an audit finds. For the full on-premises and OT segmentation model this same CIR section covers, see the site’s network security and segmentation guide.

Logging and Monitoring: CIR Section 3.2 in a Cloud-Native Stack

Section 3.2 sets seven sub-requirements for logging, sitting under Article 21(2)(b)’s incident-handling measure: log and monitor activity to detect potential incidents; automate monitoring where feasible, continuously or at regular intervals; maintain, document, and review the logs; review logs regularly for unusual trends and set alarm thresholds where appropriate; retain and back up logs for a defined period and protect them from unauthorised access or change; synchronise time sources across systems so logs can be correlated; and review and update both the logging procedures and the list of logged assets at regular intervals and after significant incidents[2].

AWS CloudTrail, Azure Monitor, and Google Cloud Audit Logs each satisfy the automation and continuity sub-points almost by default — that part of Section 3.2 is genuinely easier in the cloud than it ever was on-premises. The sub-points cloud-native teams miss are 3.2.5 (defined retention with protection from unauthorised change — CloudTrail’s default retention is 90 days in the console event history, which is not the same as a protected, exportable archive you control) and 3.2.7 (the asset list under monitoring has to be reviewed and updated, not just “logging is on for everything we remembered to tag”). A log bucket with default lifecycle rules quietly deleting data at 30 or 90 days is one of the most common gaps we see cited: the logging exists, but nobody configured retention against a documented policy, so there’s nothing to show an auditor who asks for six-month-old evidence. This site’s logging and monitoring guide covers retention-period benchmarking and the in-house-versus-MSSP decision in more depth.

Patch Management When You Don’t Own the Patch

CIR 6.6.1 requires security patches to be applied “within a reasonable time after they become available” and tested before production deployment; 6.6.2 permits a documented exception when the disadvantages of patching outweigh the cybersecurity benefit[2]. In the cloud, “reasonable time” splits by who is holding the patch.

• IaaS (EC2, Azure VMs, Compute Engine): the guest OS and everything above it is yours. Cloud workload protection platforms (Defender for Cloud, GuardDuty, or an equivalent CWPP) can automate detection, but the patch-testing and deployment obligation under 6.6.1 is still your process to document.
• PaaS (managed databases, App Service, Cloud Run): the provider patches the runtime and underlying OS on a schedule you don’t control. Your CIR evidence here isn’t a patch log — it’s the provider’s published patching SLA or maintenance-window notice, kept as your audit record that the obligation was met on your behalf.
• SaaS: patching is entirely the vendor’s responsibility. Your remaining Article 21(2)(e) exposure is application-layer: API integrations, custom scripts, and third-party plugins you added on top of the SaaS platform, which nobody but you is patching.

The gap that surfaces most often in PaaS environments specifically: teams assume “the provider patches it” fully discharges the obligation and keep no record at all. CIR doesn’t require you to run the patch yourself — it requires you to be able to show, when asked, that the patch was applied within a reasonable time and that any non-patched exception was a documented decision, not an oversight. A saved copy of the provider’s patch-notes feed, dated, is a five-minute habit that closes that gap.

Supply Chain: Your Cloud Provider Is a Direct Supplier

Article 21(2)(d) requires supply chain security covering the relationship with each direct supplier and service provider; Article 21(3) specifically requires assessing “the vulnerabilities specific to each direct supplier and service provider and the overall quality of products and cybersecurity practices,” including their secure development procedures[1]. Your cloud provider is, without exception, a direct supplier under this definition — moving a workload to the cloud does not remove it from your supply-chain risk register, it adds an entry to it.

The specific gap CIR 2024/2690 5.1.4(g) exposes: contract clauses must extend to subcontracting, requiring the same cybersecurity standard from any subcontractor the supplier uses[2]. Large cloud providers subcontract constantly — regional data centre operators, DDoS-mitigation partners, CDN edge nodes. Most standard cloud service agreements don’t give you visibility into that chain, and the one-level-down cascade obligation is easy to miss because it reads like boilerplate rather than a control you have to evidence. This is a deep, contract-law-adjacent topic on its own; the site’s cloud supply chain security guide covers the full subcontractor flow-down requirement and what to actually ask your provider for.

Backups in the Cloud: the Annex’s One Explicit “Cloud Computing” Clause

CIR 2024/2690’s technical annex names “cloud computing” directly exactly once, and it’s easy to miss: under Article 21(2)(c) business continuity, section 4.2.2(b) requires assurance “that backup copies are complete and accurate, including configuration data and data stored in cloud computing service environment”[2]. Two words matter here: configuration data. A backup policy that captures application data but not infrastructure-as-code templates, security group rules, and IAM policy definitions doesn’t satisfy 4.2.2(b) — if your cloud environment burned down and you rebuilt from your backups, could you reconstruct the access controls and network configuration exactly as they were, or only the data? Most disaster-recovery tests check the first question and skip the second.

Cloud Security Compliance Checklist by Deployment Model

Effort estimates below are original synthesis based on typical SME compliance projects we’ve reviewed, not a cited statistic — treat them as planning guidance, not a benchmark from any published study.

Control	Current state gap (typical)	Effort to close	Owner
Access review cadence documented	MFA enforced but no dated periodic review record	Low	IT Security
Segmentation reviewed on a schedule	Zones exist but drift undocumented since setup	Medium	Cloud/Infra team
Log retention matches a written policy	Default retention (30–90d), no documented rationale	Low	IT Security
PaaS/SaaS patch evidence on file	Assumed provider handles it; nothing saved	Low	Compliance Officer
Subcontractor flow-down confirmed with provider	Standard contract, clause not verified	Medium–High	Legal/Procurement
Config-data included in backup/DR test	Data backed up; IaC/IAM config untested	Medium	Cloud/Infra team

The role split above matters for board reporting: technical teams own the segmentation, logging, and backup gaps; compliance and legal own the evidence-documentation and contractual gaps. Both categories show up in the same audit, and neither team can close the other’s half.

Frequently Asked Questions

Does using a “NIS2-compliant” cloud provider make my organisation compliant?
No. A provider’s own certifications (ISO 27001, BSI’s C5 catalogue, SOC 2) demonstrate the provider secured their side of the shared-responsibility line[3]. Your Article 21 obligations for configuration, access control, and monitoring on your side of that line remain yours regardless of what the provider holds.

Which cloud security certification should I ask my provider for?
For EU-based or EU-serving providers, Germany’s BSI publishes the C5 (Cloud Computing Compliance Criteria Catalogue), a widely referenced baseline that BSI itself states customers should request and review annually as part of ongoing risk management[3]. ISO 27001 and SOC 2 Type II are the more globally recognised alternatives if a provider doesn’t publish a C5 report.

Does multi-cloud change any of this?
Not the requirements — the same five measures apply to each provider independently. What multi-cloud adds is a documentation burden: your access-review, segmentation, and log-retention evidence has to be maintained per provider, because auditors can ask for any of them individually.

We’re a small team using mostly SaaS — do we still need all of this?
Article 21(1)’s proportionality principle means the depth of implementation can scale to your size and risk exposure[1]. A SaaS-heavy SME’s evidence set will be thinner than an IaaS-heavy enterprise’s, but “we use SaaS so none of this applies” is not a defensible position — access control, MFA, and supply-chain assessment of the SaaS vendor still apply in full.

Sources

1. NIS2 Directive — Article 21 and Article 34, nis-2-directive.com
2. Commission Implementing Regulation (EU) 2024/2690, EUR-Lex
3. Cloud Computing Compliance Criteria Catalogue (C5), BSI (Federal Office for Information Security, 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.