NIS2 for Cloud Teams, Part 1: Requirements Checklist for AWS, Azure and Google Cloud

Open the NIS2 Directive at Article 21 and you will find ten security measures, labelled (a) to (j). Not one of them says AWS, Azure, Google Cloud, Kubernetes or Terraform. Then the ticket lands in your backlog anyway: “Make our cloud NIS2 compliant.” No definition of done, no owner on the business side, and an auditor somewhere in the future.

I work on cloud security in a large, regulated German company, and this is the translation I wish someone had handed me on day one: what NIS2 actually asks for, what your cloud provider already covers, what stays on your plate, and how each of the ten measures maps to real services in AWS, Azure and Google Cloud. You get a table you can paste into a ticket, a CSV you can open in Excel, and a 30-day plan.

This is Part 1 of the NIS2 for Cloud Teams series. It covers what NIS2 asks of a cloud team. The rest of the series goes into how, with real configuration.

What Does NIS2 Require? The 60-Second Summary

NIS2 (Directive (EU) 2022/2555) replaces the original NIS Directive and is implemented through national law in every EU member state. In Germany that is the NIS2 Implementation Act (NIS2UmsuCG), which rewrote the BSI Act (BSIG) and has applied since December 2025. For a cloud team, four parts of it matter:

Everything below is about Article 21, because that is where your cloud configuration lives.

Who Does NIS2 Apply To?

Using a cloud does not put you in scope. Your sector and size do. NIS2 applies to entities in the sectors listed in Annex I (energy, transport, banking, health, digital infrastructure, ICT service management, and more) and Annex II (postal, waste, chemicals, food, manufacturing, digital providers, and more) that are at least medium-sized. In practice that means 50 or more employees, or more than €10 million in both annual turnover and balance sheet.

Some entities are covered regardless of size: providers of public electronic communications networks or services, trust service providers, TLD registries and DNS service providers, plus entities a member state designates as critical.

In scope, entities are either essential or important. The duties in Article 21 are the same; the difference is supervision. Essential entities can be audited proactively, important entities mainly after there is evidence of a problem, and the fines differ (see the table above).

Four details catch cloud teams off guard:

• If you sell cloud, managed or security services, you are probably in scope in your own right. Cloud computing service providers, data centre service providers, managed service providers and managed security service providers are listed in Annex I.
• Being outside the EU does not take you out. NIS2 follows the services you provide in the EU. Cloud, data centre, managed and managed security service providers without an EU establishment must designate a representative in a member state where they offer services (Article 26).
• Banks and insurers mostly follow DORA instead. Where a sector-specific EU act sets at least equivalent security and reporting rules, those take precedence (Article 4). For financial entities that act is DORA.
• In Germany, registration is your job. Entities register with the BSI themselves; nobody sends you a letter. If you are not sure whether you are affected, the BSI runs a NIS2 self-check. If you are affected and not registered yet, you are already late.

“Is AWS NIS2 Compliant?” Is the Wrong Question

It is one of the most searched questions about NIS2 and the cloud, and it rests on a misunderstanding. NIS2 obligations land on entities, not on products. A cloud cannot be compliant on your behalf, just as a gym cannot be fit on your behalf.

Here is what actually happens. AWS, Microsoft and Google are themselves in scope as cloud computing service providers. For them, the Commission adopted Implementing Regulation (EU) 2024/2690, which spells out the technical requirements and defines when an incident counts as significant. That covers their data centres, hypervisors and global network.

What you get from them is evidence and tooling. All three publish independent attestations, including ISO 27001 and the BSI’s cloud catalogue C5 (see the C5 pages of AWS, Microsoft and Google Cloud). You download the reports from AWS Artifact, the Microsoft Service Trust Portal or the Google Compliance Reports Manager. Those reports are exactly what measure (d), supply chain security, asks you to collect. They prove the supplier is sound. They prove nothing about your IAM policy.

Your provider’s NIS2 compliance covers their data centre, not your IAM policy. The attestation goes into your supplier file; the misconfiguration stays in your backlog.

NIS2 Article 21 Requirements: The Ten Measures in Plain English

Article 21(2) is short. Here is each measure, what it means for a cloud team, and the evidence an auditor will reasonably expect to see. “Proportionate” (Art. 21(1)) means the depth scales with your risk and size, not that you may skip a letter.

The ten letters read like a random list, but they cluster into four jobs your cloud platform already does: govern, protect, respond and recover.

NIS2 Compliance Checklist: Article 21 Mapped to AWS, Azure and Google Cloud

This is the table to paste into your ticket. Each row lists the native services that produce the control or the evidence. None of them makes you compliant by being switched on; they make the measure implementable and provable.

Download the full checklist as CSV: all ten measures with plain-English meaning, evidence, the three providers and empty owner and status columns. It opens in Excel, Numbers and Google Sheets.

Azure NIS2 Policy Initiative, and What AWS and Google Cloud Offer Instead

Azure is the only one of the three that ships NIS2 as a ready-made policy set. Azure Policy contains built-in regulatory compliance initiatives for NIS2, and once assigned they show up in the Defender for Cloud regulatory compliance dashboard. Finding them takes one command:

# List the built-in NIS2 initiatives in your tenant
az policy set-definition list \
  --query "[?contains(displayName, 'NIS2')].{id:name, name:displayName}" \
  --output table

Assign one at the management group level in audit mode first. Turning on deny effects across a live estate on day one is how you break production and lose the team’s goodwill in the same afternoon.

AWS and Google Cloud have no NIS2 framework at the time of writing. Their built-in lists stop at CIS, ISO 27001, NIST, PCI DSS and SOC 2:

• AWS Security Hub CSPM (the posture-management part of Security Hub, now under its own name) evaluates AWS Foundational Security Best Practices, CIS, NIST and PCI DSS. AWS Audit Manager is no longer open to new customers, so do not build a new NIS2 evidence process on it.
• Compliance Manager in Security Command Center ships frameworks such as CIS, ISO 27001:2022, NIST SP 800-53 and SOC 2, and lets you create custom frameworks. Copying the ISO 27001 framework and re-labelling its controls by Article 21 letter is a fast start.

That is less of a problem than it sounds. Most technical NIS2 checks are the same checks those frameworks already run, so you start from them and add the mapping yourself:

# AWS: which standards Security Hub CSPM can evaluate for you
aws securityhub describe-standards \
  --query 'Standards[].Name' --output table

# Google Cloud: which organization policies are set at the org level
gcloud org-policies list --organization=ORG_ID

On Google Cloud, Security Command Center already groups findings by compliance standard. If you are opening it for the first time, read what the first 24 hours with Security Command Center look like before the red numbers scare anyone.

Your First 30 Days

Do not start with a 200-row gap analysis. Start with the measures that are cheap to fix, easy to prove and painful to miss:

Week 2 is where cloud teams win the most for the least, and the providers have already done part of it for you:

The gap the providers leave is machine identity. On Google Cloud, killing service account keys with Workload Identity Federation removes a whole class of long-lived credentials. Week 3 decides whether you can report on time at all; if a SIEM is part of the plan, check what Wazuh, Sentinel and Google SecOps really cost before you commit.

Five Mistakes Cloud Teams Make with NIS2

1. Treating the provider’s certificate as your compliance. C5 and ISO 27001 cover the provider. They belong in your supplier file for measure (d), not in your answer to measure (i).
2. Buying a dashboard and calling it done. A green compliance score measures configurable controls. It cannot see whether management approved the policy or whether anyone was trained.
3. Logging without a human at the end. The 24-hour clock starts when you become aware of a significant incident. Logs nobody reads will not help you report on time, and they make an awkward exhibit later.
4. Backups that were never restored. Measure (c) is about continuity, and continuity means a restore you have timed. An untested backup is a hypothesis.
5. Forgetting the software supply chain. Measure (d) covers more than your cloud contract. Every package registry and base image is a supplier too, which is why npm supply chain attack mitigation belongs in the same backlog.

NIS2 Incident Reporting: The 24-Hour Clock

Article 23 is where NIS2 stops being a document exercise. Once you become aware of a significant incident, the deadlines run regardless of weekends:

In Germany these reports go to the BSI, and the BSI’s own guidance is blunt: speed before completeness. A report can be corrected later, but it cannot be withdrawn.

Here is the uncomfortable part: on all three clouds, some of the logs you need for that report are not collected by default. Google Cloud leaves most Data Access audit logs off. AWS CloudTrail does not record S3 object-level data events unless you ask for them. Azure keeps resource logs only if you configure diagnostic settings. Many teams discover these gaps during their first incident, when the 24-hour clock is already running.

That gap is exactly where the next part of this series starts. Subscribe below and it lands in your inbox the day it ships.

The Bottom Line

NIS2 does not care which cloud you run on. It cares whether you can show, for each of the ten measures in Article 21, that someone owns it, that a control exists, and that the control works. AWS, Azure and Google Cloud give you most of the controls and a pile of evidence about themselves. The configuration, the logs, the restore tests, the reporting and the signatures are still yours.

Start with the table, assign an owner per letter, and fix identity and logging first. That alone moves you further than most organisations that are still waiting for a consultant’s gap analysis.

Then comes the moment a checklist stops being enough: the first significant incident. That is where this series goes next.