---
title: "NIS2 for Cloud Teams, Part 1: Requirements Checklist for AWS, Azure and Google Cloud"
description: "Part 1 of the NIS2 for Cloud Teams series. Article 21 lists ten minimum security measures and none of them mentions a cloud. This checklist maps each one to concrete controls in AWS, Azure and Google Cloud, separates what your provider covers from what you own, and gives a 30-day plan."
author: Aleksei Aleinikov
date: 2026-10-15
lang: en
tags: [nis2, nis2-compliance, compliance, cloud-security, aws, azure, google-cloud]
canonical: https://www.alekseialeinikov.com/en/blog/topics/security/nis2-compliance-checklist-aws-azure-google-cloud
source: alekseialeinikov.com
---

# 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.

![NIS2 for cloud teams, Part 1: ten Article 21 measures checked against AWS, Azure and Google Cloud.](https://www.alekseialeinikov.com/blog/nis2-cloud-checklist.webp)

> [!NOTE]
> **NIS2 for Cloud Teams, Part 1.** This series goes from the legal text to configuration you can show an auditor. Subscribe at the end of this article to get the next part the day it ships.

## 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:

| Obligation | Where | What it means for a cloud team |
| --- | --- | --- |
| Risk management measures | Art. 21 | Ten minimum measures, (a) to (j). Proportionate to your risk and size, based on an all-hazards approach. |
| Incident reporting | Art. 23 | Early warning within 24 hours, notification within 72 hours, final report one month later. |
| Management accountability | Art. 20 | Management approves and oversees the measures, and its members must be trained. |
| Fines | Art. 34 | Up to at least €10M or 2% of worldwide turnover (essential), or €7M or 1.4% (important). |

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](https://betroffenheitspruefung-nis-2.bsi.de/). 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](https://eur-lex.europa.eu/eli/reg_impl/2024/2690/oj), which spells out the technical requirements and defines when an incident counts as significant. That covers **their** data centres, hypervisors and global network.

> [!TIP]
> If you are a cloud, managed or managed security service provider yourself, the annex of Implementing Regulation 2024/2690 is your real checklist. It breaks each Article 21 measure into detailed technical requirements, far more specific than the directive.

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](https://aws.amazon.com/compliance/bsi-c5/), [Microsoft](https://learn.microsoft.com/en-us/compliance/regulatory/offering-c5-germany) and [Google Cloud](https://cloud.google.com/security/compliance/bsi-c5)). 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.

![NIS2 shared responsibility in the cloud: the provider secures and certifies its infrastructure, you own identity, configuration, data, logging, backups, incident reporting and people.](https://www.alekseialeinikov.com/blog/nis2-cloud-shared-responsibility.webp "The cloud provider's certificate covers its data centre. Everything you configure stays on your side.")

> [!KEY]
> 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.

| # | Measure (Art. 21(2)) | In plain cloud terms | Evidence to have ready |
| --- | --- | --- | --- |
| a | Risk analysis and information system security policies | Know which workloads matter, what threatens them, and write it down | Risk register, cloud security policy, approval by management |
| b | Incident handling | Detect, triage, contain and report incidents | Runbooks, on-call rota, alert routing, incident log |
| c | Business continuity, backups, disaster recovery, crisis management | Backups you can restore and a plan for losing a region or an account | Backup policy, restore test results, DR plan, crisis contacts |
| d | Supply chain security | Assess the providers, SaaS and open source you depend on | Supplier register, provider attestations, contract clauses |
| e | Security in acquisition, development and maintenance, incl. vulnerability handling and disclosure | Secure CI/CD, patching, image scanning and a way to report vulnerabilities | Pipeline controls, patch SLAs, scan reports, disclosure policy |
| f | Assessing the effectiveness of measures | Measure whether all of the above actually works | Compliance dashboards, internal audits, pentest reports |
| g | Basic cyber hygiene and training | Secure baselines and people who know them | CIS benchmark results, training records |
| h | Cryptography and encryption | Encryption at rest and in transit, key management | Key inventory, rotation policy, TLS configuration |
| i | HR security, access control, asset management | Least privilege, joiner-mover-leaver, a complete asset inventory | Access reviews, IAM policy, cloud asset inventory |
| j | MFA, secured communications, emergency communications | MFA everywhere, secure channels, a way to talk when email is down | MFA enforcement reports, out-of-band comms plan |

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 Article 21(2) measures (a) to (j) grouped into four cloud jobs: govern, protect, respond, recover and supply chain.](https://www.alekseialeinikov.com/blog/nis2-article-21-cloud-map.webp "Ten legal measures, four engineering jobs. GOVERN is the one no dashboard can see.")

## 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**.

| # | AWS | Azure | Google Cloud |
| --- | --- | --- | --- |
| a | Security Hub CSPM, AWS Config, Organizations SCPs | Defender for Cloud, Azure Policy | Security Command Center, Organization Policy |
| b | GuardDuty, Security Hub CSPM findings, EventBridge to on-call | Microsoft Sentinel, Defender for Cloud alerts | Security Command Center threat detection, Google SecOps |
| c | AWS Backup with Vault Lock, multi-Region design | Azure Backup immutable vaults, Azure Site Recovery | Backup and DR Service, multi-region design |
| d | AWS Artifact reports, ECR image scanning | Service Trust Portal reports, Defender for Containers | Compliance Reports Manager, Artifact Analysis, Binary Authorization |
| e | Amazon Inspector, Systems Manager Patch Manager | Defender for Servers, Azure Update Manager | Artifact Analysis, VM Manager, GKE auto-upgrades |
| f | Security Hub CSPM standards, Config conformance packs | Defender for Cloud regulatory compliance dashboard | Compliance Manager in Security Command Center |
| g | Security Hub CSPM CIS benchmark | Defender for Cloud secure score | Security Health Analytics (CIS checks) |
| h | AWS KMS, ACM | Key Vault, Managed HSM | Cloud KMS with CMEK, Cloud HSM |
| i | IAM Identity Center, IAM Access Analyzer, Config inventory | Entra ID PIM, Azure Resource Graph | IAM Recommender, Cloud Asset Inventory |
| j | IAM Identity Center MFA | Entra ID Conditional Access | Cloud Identity 2-Step Verification |

[Download the full checklist as CSV](https://www.alekseialeinikov.com/blog/nis2-cloud-checklist.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.

> [!WARNING]
> Measures (a), (d), (f) and (g) are only partly technical. Risk analysis, supplier contracts, training and management approval need documents and people, not services. A dashboard at 100% with no signed policy behind it will not survive an audit.

## 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](https://learn.microsoft.com/en-us/azure/governance/policy/samples/built-in-initiatives) for NIS2, and once assigned they show up in the Defender for Cloud regulatory compliance dashboard. Finding them takes one command:

```bash
# 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:

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

```bash
# 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](https://www.alekseialeinikov.com/en/blog/topics/security/first-24-hours-google-cloud-security-command-center-2026) 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 | Focus | Measures | Done when |
| --- | --- | --- | --- |
| 1 | Scope, owner, inventory | a, i | Registration status is known, one accountable owner is named, every account, subscription and project is listed |
| 2 | Identity | i, j | MFA is enforced for every human, break-glass accounts are tested, long-lived keys have an end date |
| 3 | Logging and detection | b, f | Org-wide audit logs land in one tamper-resistant place, and an alert reaches a human within minutes |
| 4 | Recovery and suppliers | c, d, h | One real restore test is documented, a key inventory exists, the supplier register lists your clouds with their attestations |

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

> [!TIP]
> **All three clouds now force MFA on part of your estate.** Azure requires MFA for every user account that manages resources: in the portal since October 2024, and in the CLI, PowerShell, IaC tools and REST API in a second phase rolling out since October 2025, break-glass accounts included. AWS requires MFA for the root user of every account type. Google Cloud requires 2-step verification for the console, for enterprise Cloud Identity accounts without SSO from 20 October 2026. None of it covers service accounts, CI pipelines or the long-lived keys they use, and federated sign-in depends on your own identity provider. Measure (j) is still yours.

The gap the providers leave is machine identity. On Google Cloud, [killing service account keys with Workload Identity Federation](https://www.alekseialeinikov.com/en/blog/topics/security/kill-service-account-keys-workload-identity-federation-2026) 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](https://www.alekseialeinikov.com/en/blog/topics/security/siem-pricing-wazuh-vs-sentinel-vs-google-secops-2026) 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](https://www.alekseialeinikov.com/en/blog/topics/security/npm-supply-chain-attack-mitigation-2026) 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:

![NIS2 incident reporting timeline under Article 23: early warning within 24 hours, incident notification within 72 hours, final report one month after the notification.](https://www.alekseialeinikov.com/blog/nis2-incident-reporting-timeline.webp "The clock starts at awareness, not at detection. Your logging pipeline decides how early that is.")

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.

> [!NOTE]
> This article is an engineering guide, not legal advice. Sources: [Directive (EU) 2022/2555, Article 21](https://www.nis-2-directive.com/NIS_2_Directive_Article_21.html), [Article 23](https://www.nis-2-directive.com/NIS_2_Directive_Article_23.html) and [Article 34](https://www.nis-2-directive.com/NIS_2_Directive_Article_34.html), the [BSI's NIS2 pages](https://www.bsi.bund.de/DE/Themen/Regulierte-Wirtschaft/NIS-2-regulierte-Unternehmen/nis-2-regulierte-unternehmen_node.html) and Implementing Regulation (EU) 2024/2690. Check your national implementation and your own legal team for your specific case.