NIS2 Article 21: What Your Azure Environment Actually Needs to Show

NIS2 Article 21 requires your Azure environment to produce demonstrable configuration evidence — not policy documents — across ten security measure domains, from PIM-enforced access control to tested backups and active Microsoft Sentinel detection rules. Under the Dutch Cyberbeveiligingswet, a supervisory authority checks the configuration, not the Word file that describes it.

Someone handed you an NIS2 questionnaire. Maybe it came from your CISO. Maybe directly from a consultant who billed 40 hours to produce it. Either way, you’re now looking at ten “security measure domains” written in the language of EU policy documents, and your job is to figure out what that means for the Azure tenant you’re actually responsible for.

Every NIS2 explainer you’ve found so far describes the law. None of them tell you what to configure.

That’s what this is.

Key takeaways

NIS2 Article 21(2) defines ten security measure domains. Each maps to a specific Microsoft Azure service and a configuration that produces audit evidence — not to a paragraph in a policy.
The recurring failure is policy-on-paper: the documentation claims a control exists while the Azure tenant shows permanent Global Administrator roles, an empty Microsoft Sentinel workspace, and backups that have never been restored.
Four gaps appear in nearly every Dutch mid-market environment — PIM licensed but not activated, Sentinel deployed but analytically empty, network segmentation on paper rather than in NSG config, and untested backups.
The artifacts that satisfy supervision are native: the Microsoft Defender for Cloud Regulatory Compliance Report, PIM audit logs, Sentinel incident logs, Key Vault audit logs. Assembling all ten domains by hand takes days.

The problem with policy-first compliance

Here’s what typically happens. The legal team or a compliance consultant maps NIS2 to a framework — ISO 27001, CIS Controls, something — and produces a spreadsheet with 200 rows. Each row says something like “access control policy exists.” Your job is to put a checkmark in the “implemented” column.

But “access control policy exists” and “PIM is activated on all privileged roles” are not the same thing. One is a document. The other is a configuration. Supervisory authorities under the Dutch Cyberbeveiligingswet will eventually want the second one. And if your Azure environment doesn’t actually reflect the controls your policy claims are in place, the gap is your problem — not the compliance consultant’s.

A Dutch healthcare network with around 2,200 staff ran exactly into this in late 2024. Their NIS2 policy documentation was solid. When an external assessor pulled their Azure configuration, they found Global Administrator assigned permanently to six accounts, no PIM activation workflows, Sentinel deployed with zero custom analytic rules, and Azure Backup configured but never tested. Every gap was in the Article 21 domains their policy claimed were covered. The documentation said compliant. The environment said otherwise.

That’s not unusual. It’s the norm.

What Article 21 actually asks for

Article 21(2) of Directive (EU) 2022/2555 defines ten security measure domains. The Directive is intentionally technology-neutral — it doesn’t name Azure or any other platform. But “state of the art” is the standard, and for organisations running workloads on Azure in 2026, that has a direct meaning.

The ten domains:

Policies on risk analysis and information system security
Incident handling
Business continuity, backup management, and disaster recovery
Supply chain security
Security in network and information system acquisition, development, and maintenance
Policies and procedures to assess the effectiveness of cybersecurity risk management measures
Basic cyber hygiene practices and cybersecurity training
Policies and procedures regarding cryptography and encryption
Human resources security, access control policies, and asset management
Multi-factor authentication, secured communications, and emergency communication systems

What follows is the mapping. For each domain: which Azure service owns it, what configuration is required, and what that configuration produces as audit evidence.

The mapping

Domain 1 — Risk analysis and IS security

Microsoft Defender for Cloud is the control here. Secure Score needs to be enabled and actively reviewed, not just lit up. The regulatory compliance dashboard should have a Policy Initiative assigned — NIS2, ISO 27001, or NIST SP 800-53 — at the Management Group level, not per subscription. Without Management Group assignment, you’ll have compliance gaps for subscriptions that nobody remembered to configure.

The artifact this produces: the Defender for Cloud Regulatory Compliance Report. Exportable as PDF or via API. This is the closest thing to a pre-formatted NIS2 compliance artifact that Azure natively generates, and most organisations haven’t pulled it once.

Domain 2 — Incident handling

Microsoft Sentinel. But not just deployed — operational. There’s a meaningful difference.

A Sentinel workspace with the default Microsoft Security Incidents connector enabled is not a detection capability. It’s an expensive log sink. Article 21(2)(b) requires incident handling. That means analytic rules that fire on your actual threat scenarios — at minimum: impossible travel, new Global Admin assignment, large-scale data exfiltration indicators, service principal credential additions. Default rules catch some of this. They don’t catch all of it. Log retention needs to hit 12 months minimum. Incident response playbooks (Logic Apps) should be configured and tested, not sitting as drafts.

The artifact: Sentinel incident log, filterable by severity and MITRE ATT&CK tactic, exportable as CSV.

Domain 3 — Business continuity, backup, DR

Azure Backup and Azure Site Recovery. The configuration requirements are specific: backup policies defined per workload (not a single policy applied globally), RTO and RPO documented per workload, ASR replication active for critical VMs, geo-redundant storage enabled on storage accounts containing material data.

The part most teams skip: restore testing. Untested backups satisfy zero Article 21(2)(c) requirements. They’re just storage costs. A quarterly restore test, documented, is what the domain actually requires. If you’ve never run one, schedule it this week before anything else in this list.

Domain 4 — Supply chain security

This is the domain that catches people off guard, because it sounds like a procurement problem. It’s partly that, but it also means: are third-party resources in your Azure environment being evaluated for compliance? Defender for Cloud covers this — it flags non-compliant resources regardless of how they were deployed. Container image scanning via Defender for Containers needs to be enabled if you’re running containerised workloads. Azure Marketplace sourcing policies should be documented, even if the documentation is brief.

Domain 5 — Secure acquisition, development, maintenance

Azure DevOps or GitHub Advanced Security with Defender for DevOps. The specific requirements: branch protection rules enforced (no direct commits to main), dependency scanning enabled, secrets scanning active, IaC scanning via Defender for DevOps. If your pipelines can push infrastructure changes without any of these gates, Domain 5 is uncovered.

Domain 6 — Effectiveness assessment

This is the domain that converts NIS2 from a point-in-time project into an ongoing operational requirement. Article 21(2)(f) requires a demonstrable process for periodically evaluating whether your measures are working. Defender for Cloud provides continuous compliance assessment. Monthly export of Secure Score and compliance posture to Log Analytics, with change tracking enabled, gives you a time-series record of your posture — which is what “demonstrable process” means in practice.

Domain 7 — Cyber hygiene and training

MFA enforced via Conditional Access — non-negotiable. Entra ID Protection risk policies configured for sign-in and user risk. Phishing-resistant authentication methods (FIDO2 or certificate-based auth) enforced for privileged roles. If your Conditional Access policies still allow legacy authentication protocols anywhere, that’s a Domain 7 finding.

Domain 8 — Cryptography and encryption

Customer-managed keys in Azure Key Vault for data at rest on workloads that handle sensitive data. TLS 1.2 minimum enforced on App Service, API Management, and Storage Account endpoints — and checked, not assumed. Key Vault soft-delete and purge protection enabled. Key rotation documented and tested.

The artifact: Key Vault audit logs showing access events, rotation history, and access policy changes. This maps directly to Article 21(2)(h).

Domain 9 — HR security, access control, asset management

Privileged Identity Management. Full stop.

If your environment has permanent Global Administrator or Subscription Owner assignments — roles held continuously, not activated on demand — you have a Domain 9 finding. PIM requires just-in-time activation, approval workflows, and access reviews. Entra ID Governance handles the access review scheduling. Azure Resource Graph provides the asset inventory. JIT access for VM management ports via Defender for Cloud closes the VM-level exposure.

The artifact: PIM audit logs, available in Entra admin portal and exportable to Log Analytics, showing every privileged role activation, who approved it, duration. This is direct evidence for Article 21(2)(i).

Domain 10 — MFA and secure communications

Phishing-resistant MFA for all users — FIDO2 security keys or certificate-based authentication. Not SMS. Not authenticator app alone for privileged accounts. Conditional Access policies enforce compliant device requirement. Legacy authentication protocols blocked. Microsoft Teams meeting policies configured appropriately for the sensitivity of communications conducted on the platform.

The four gaps that appear everywhere

After looking at a lot of Dutch mid-market Azure environments, the same four problems show up regardless of sector.

PIM licensed but not activated. Entra ID P2 covers PIM. Most organisations bought P2 for Conditional Access and never touched PIM. Permanent role assignments are the single most common Domain 9 gap — and the most visible one in any Defender for Cloud assessment.

Sentinel deployed but analytically empty. A workspace exists. Maybe it’s ingesting logs. But the analytic rules are defaults, and the defaults don’t cover the scenarios that actually matter for the organisation. The Gartner SIEM Market Guide (2024) found that 61% of organisations with a deployed SIEM reported less than 30% of use cases were actively monitored. Sentinel is not immune to this pattern.

Network segmentation on paper, not in config. Hub-and-Spoke architecture in the documentation. NSG rules in practice: allow-all rules added during development, never removed. East-west traffic between workload subnets unrestricted. Azure Firewall in Alert mode instead of Deny mode. NSG flow logs tell the auditor exactly what the architecture diagram hides.

Backups that have never been restored. The vault exists. The policy exists. No one has run a restore since initial deployment. That’s not disaster recovery. That’s a false sense of it.

What “producing evidence” actually means

The organisations that will find NIS2 supervision manageable are the ones treating their Azure configuration as the compliance record. Not as an input to a compliance process happening somewhere else in a Word document.

A correctly configured Azure environment produces artifacts that map directly to Article 21 domains. The Defender for Cloud Regulatory Compliance Report for Domain 1. PIM audit logs for Domain 9. Sentinel incident log for Domain 2. Azure Policy compliance state — queryable via Resource Graph using policyStates — for Domain 6. Key Vault audit logs for Domain 8.

Producing this package manually, covering all ten domains, takes days. Keeping it current takes continuous effort, because configuration drifts and posture changes.

Platforms like PAA (Platform Architecture Authority, by Crimson Owl Technologies) run a full WAF and CAF assessment including NIS2 compliance mapping across all ten domains in hours, using Azure Resource Graph, and sync findings to GitHub or Confluence. Built by a former Microsoft engineer, active Microsoft ISV and CSP partner. It won’t configure your environment for you — but it will tell you exactly what’s wrong, mapped to the Article 21 domain it violates, before an auditor does.

FAQ

Does NIS2 Article 21 specifically require Microsoft Azure controls? No. Article 21(2) of Directive (EU) 2022/2555 is technology-neutral and names no platform. But “state of the art” is the standard, and for an Azure tenant in 2026 that translates to concrete services — Microsoft Defender for Cloud, Microsoft Sentinel, Privileged Identity Management — and the configuration evidence each produces.

What is the single most common Article 21 finding in Azure? Permanent privileged role assignments. Most organisations hold Microsoft Entra ID P2 licensing yet never activate Privileged Identity Management, leaving Global Administrator or Subscription Owner roles assigned continuously. That is a direct Domain 9 finding and the most visible gap in any Microsoft Defender for Cloud assessment.

Is an NIS2 policy document enough to pass supervision? No. A policy states intent; supervisory authorities under the Dutch Cyberbeveiligingswet check the live Azure configuration. If your documentation claims a control the tenant does not enforce — untested backups, empty Sentinel rules — the gap is yours, not the consultant’s who wrote the policy. Incident detection in particular has to be demonstrated, not asserted; see NIS2 incident reporting on Azure.

How long does it take to produce Article 21 evidence manually? Assembling the full package across all ten domains — Defender for Cloud reports, PIM audit logs, Sentinel incident logs, Key Vault audit logs, and Azure Policy state versus a real architecture assessment — takes days, and keeping it current takes continuous effort because configuration drifts between reviews.

The alternative is continuing to produce Word documents about what your Azure environment is supposed to look like. That strategy has a known failure mode.