Short answer: NIS2 Article 21 requires essential and important entities to run an all-hazards set of cybersecurity risk-management measures. For organisations that run on AWS, Azure or Google Cloud, supervisors and auditors increasingly ask for configuration and operational evidence against each of the ten areas in Article 21(2)(a) to (j), not a policy PDF alone. This checklist maps those measures to the artefacts cloud teams can produce from read-only settings, logs and identity records.
If you are in scope as an essential or important entity, or you supply one, use this as a practical evidence list for your cloud estate. It sits alongside our other framework guides for SOC 2 on AWS, ISO 27001 on Azure and Cyber Essentials on Google Cloud.
What Article 21 actually asks for
Article 21 of Directive (EU) 2022/2555 (NIS2) requires appropriate and proportionate technical, operational and organisational measures to manage risks to the network and information systems you use, and to limit the impact of incidents. Paragraph 2 lists ten minimum areas (a) to (j). For several digital-infrastructure and ICT service entity types, Commission Implementing Regulation (EU) 2024/2690 sets out more detailed technical and methodological requirements, and ENISA's technical implementation guidance gives non-binding examples of evidence.
Cloud does not remove those duties. Under the shared responsibility model you still own how identities, networks, storage, logging and recovery are configured. The NCSC's guidance on using a cloud platform securely stresses guardrails and periodic tests that configuration remains correct. That is the same evidence habit NIS2 supervision expects.
How to use this checklist
For each Article 21(2) letter below you will find: what auditors and competent authorities typically ask to see in a cloud context; and concrete AWS, Azure and Google Cloud artefacts that support an answer. Prefer organisation-wide, dated exports over a single console screenshot. Record exceptions with an owner and a review date.
Article 21(2) cloud evidence checklist
(a) Policies on risk analysis and information system security
Auditors ask for: an approved information security / cloud security policy, a documented risk assessment that covers cloud services in scope, and proof that management reviewed both within the period.
Cloud artefacts: account, subscription and project inventories; tagged ownership of production resources; organisation policy / management group / SCP summaries showing which security baselines apply; dated risk register entries that name cloud threats (misconfiguration, credential theft, region outage). Policies live in your ISMS; the cloud side proves the scope they claim.
(b) Incident handling
Auditors ask for: an incident response plan that covers cloud, detection and escalation routes, and records of recent exercises or real incidents.
Cloud artefacts: AWS CloudTrail, GuardDuty and Security Hub finding history (or equivalent exports); Azure Monitor / Microsoft Defender for Cloud alerts and activity log retention; Google Cloud Security Command Center findings and Cloud Audit Logs. Show where alerts land (ticket system), who is on-call, and that trails cover every region and account in scope.
(c) Business continuity, backup, disaster recovery and crisis management
Auditors ask for: recovery objectives, backup schedules, restore tests and a crisis playbook that includes cloud control-plane failure.
Cloud artefacts: AWS Backup plans and restore-job history; RDS / EBS snapshot policies; Azure Backup vault policies and restore logs; Google Cloud Backup and DR or persistent disk snapshot schedules. Also: multi-AZ / multi-region design notes, Route 53 / Traffic Manager / Cloud DNS failover records, and a dated restore-test report.
(d) Supply chain security (direct suppliers and service providers)
Auditors ask for: how you assess cloud providers and critical SaaS, contractual security clauses, and how you monitor concentration and change.
Cloud artefacts: list of cloud accounts tied to each supplier; AWS Organizations / Azure management groups / Google Cloud organisation hierarchy showing who can create resources; marketplace and third-party role trusts (IAM roles, Entra enterprise apps, service account impersonation); vendor review dates. Provider SOC reports support the supplier side; your configuration shows how you consume them.
(e) Security in acquisition, development and maintenance, including vulnerability handling
Auditors ask for: secure change for infrastructure-as-code, vulnerability handling for cloud images and services, and disclosure routes.
Cloud artefacts: pipeline records for Terraform / Bicep / Deployment Manager changes; AWS Systems Manager patch baselines and Inspector findings history; Azure Update Manager and Defender vulnerability assessments; Google OS Config and artefact registry scan results; ticket links from finding to fix. Keep before/after configuration for material changes.
(f) Policies and procedures to assess the effectiveness of measures
Auditors ask for: how you know the measures work: internal reviews, metrics, independent tests and management reporting.
Cloud artefacts: scheduled read-only configuration checks across accounts; monthly posture trends (open findings, mean time to remediate, MFA coverage); internal audit samples of cloud controls; board or risk-committee packs that include cloud metrics. Point-in-time screenshots rarely satisfy this letter on their own.
(g) Basic cyber hygiene practices and cybersecurity training
Auditors ask for: hygiene baselines (patching, hardening, least privilege) and evidence that staff who administer cloud completed relevant training.
Cloud artefacts: CIS / foundational benchmark results per account; default-deny public storage settings (S3 Block Public Access, Azure "allow blob anonymous access" disabled, Google public access prevention); removal of long-lived user keys; training completion records for cloud admins. Hygiene is easier to evidence when the same checks run every month.
(h) Cryptography and, where appropriate, encryption
Auditors ask for: encryption at rest and in transit policy, key management, and exceptions.
Cloud artefacts: S3 default encryption and bucket policies denying aws:SecureTransport false; EBS / RDS encryption flags; Azure Storage encryption and "secure transfer required"; Google CMEK / Google-managed encryption settings; KMS / Key Vault / Cloud KMS key inventories, rotation and access policies; TLS minimum versions on load balancers and storage.
(i) Human resources security, access control and asset management
Auditors ask for: joiner-mover-leaver for cloud access, least-privilege roles, privileged access reviews and an asset inventory.
Cloud artefacts: IAM / Entra ID / Cloud Identity user and role inventories; unused access key reports; privilege review exports; AWS IAM Access Analyzer / Azure PIM assignments / Google Cloud IAM recommender outputs; resource inventories with owner tags; SCPs, Azure Policy and organisation policy constraints that block risky grants. Asset lists should match billing accounts in scope.
(j) Multi-factor authentication and secured communications (where appropriate)
Auditors ask for: MFA (or continuous authentication) for human access to cloud consoles and privileged roles, plus secured channels for incident and emergency communications.
Cloud artefacts: AWS IAM account summary MFA on root, SSO / IAM Identity Center MFA enforcement; Entra ID Conditional Access requiring MFA for administrators; Google Cloud 2-Step Verification enforcement and security key policies for Owners/Editors; break-glass account procedures with alerting. Console password-only admin access is a common fail point.
What "good" cloud evidence looks like under NIS2
ENISA's guidance stresses examples of evidence, not a single certificate. For cloud, a defensible pack usually has five properties:
- Scope-complete: every account, subscription, project and region in the NIS2 scope, not a sample of convenience.
- Dated: each export or scan carries a collection timestamp.
- Mapped: each artefact is labelled to Article 21(2)(a)–(j) (and to the Implementing Regulation annex item if you are in that entity class).
- Attributable: you can show who collected it and from which tenant.
- Repeatable: the same checks next month produce a comparable record, so drift and remediation show up.
That pattern also helps if you reuse the same telemetry for ISO 27001, SOC 2 or Cyber Essentials. Our guide to multi-cloud compliance audit evidence explains how to collect once and map many times. Practical misconfiguration fixes that often appear in NIS2 reviews are covered in common cloud misconfigurations: fix and prove.
A monthly routine that matches supervision expectations
- Refresh the inventory of accounts and projects in NIS2 scope.
- Re-run the same read-only configuration and identity checks.
- Diff against last month: new failures, fixed items, reopened exceptions.
- File incident, backup-test and access-review records into the same month folder.
- Update the Article 21(2) mapping table so each letter still has a current artefact.
Organisations that only gather evidence when a questionnaire arrives tend to miss letter (f) (effectiveness) and struggle with supply-chain and continuity proofs that need history.
Where PyraLink Prove fits
PyraLink™ Prove connects to AWS, Azure and Google Cloud with read-only access, runs configuration checks on a schedule, and maps results to frameworks including NIS2, DORA, ISO 27001, SOC 2 and Cyber Essentials. Each run is kept as digitally signed, dated evidence records that you can verify independently, which helps when a competent authority or customer asks what was true on a given date across every cloud account in scope.
Frequently asked questions
Does NIS2 apply if we only use AWS, Azure or Google Cloud?
Using a major cloud provider does not decide whether you are an essential or important entity. That depends on your sector, size and the services you provide under the Directive and national transposition. If you are in scope, cloud configuration is still your responsibility under shared responsibility, and Article 21 measures still apply to the systems you use.
Is a cloud provider's SOC 2 or ISO 27001 report enough for Article 21?
No. Provider reports support supply-chain due diligence (letter (d)) and shared controls, but supervisors still expect evidence of how you configure identity, logging, backups, encryption and incident handling in your own tenants.
What is the difference between Article 21 and Implementing Regulation 2024/2690?
Article 21 sets the ten measure areas for essential and important entities. Regulation 2024/2690 spells out detailed technical and methodological requirements for certain digital-infrastructure and ICT service entity types. Even if the Regulation does not name your entity class, its annex is a useful evidence checklist.
How often should we collect cloud evidence for NIS2?
Continuously where tooling allows, and at least on a fixed monthly cycle plus after material changes. Effectiveness assessments (letter (f)) and continuity tests (letter (c)) need a history, not a single export.
Can the same evidence pack support NIS2 and other frameworks?
Yes for much of the technical layer. MFA, encryption, logging, least privilege and backup tests map cleanly to ISO 27001, SOC 2 and Cyber Essentials. Keep one dated collection and maintain separate mapping tables per framework.