The 10 NIS2 Risk-Management Measures on Azure
Map all 10 NIS2 Article 21 risk-management measures to concrete Azure controls — with an implementation checklist for German entities.
The NIS2 Directive is no longer a roadmap item. In Germany the implementing law — the NIS2UmsG — applied from 6 December 2025 with no transition period, the BSI registration portal opened on 6 January 2026, and the registration deadline of 6 March 2026 has already passed (late registration remains mandatory and advisable). What boards now need is not another explainer on the directive's intent, but a precise mapping from legal text to working technical controls.
This article does exactly that for Microsoft Azure. We take the ten risk-management measures of NIS2 Article 21(2) and show, measure by measure, which Azure capabilities implement them — and where the platform stops and your accountability begins.
TL;DR / Key takeaways
- NIS2 Article 21(2) defines ten minimum risk-management measures; the German NIS2UmsG transposes them with personal liability for the Geschäftsleitung (management body).
- Azure provides the building blocks, but compliance is a shared-responsibility outcome — tooling alone never satisfies an Article 21 measure.
- A core stack of Defender for Cloud, Sentinel, Entra ID (Conditional Access + PIM), Azure Policy and Azure Backup covers most of the technical surface.
- The measures are organisational and procedural as much as technical: evidence, ownership, and review cadence are what auditors and the BSI will examine.
- Start with governance and an identity baseline, then layer detection, encryption, and continuous policy enforcement.
How to read Article 21 on Azure
NIS2 demands an "all-hazards" approach that is "proportionate" to the entity's risk exposure. That word — proportionate — matters. A particularly important entity (>=250 staff or >EUR 50M turnover and >EUR 43M balance sheet) will be held to a higher bar than an important entity (>=50 staff or >EUR 10M turnover). Azure lets you scale the same control set up or down, which is why a cloud-native control model maps so cleanly to the directive.
The table below summarises the mapping. The sections that follow add the practitioner detail.
| # | Article 21(2) measure | Primary Azure controls | Your accountability |
|---|---|---|---|
| a | Risk analysis & security policies | Defender for Cloud secure score, Azure Policy | Documented risk framework, named owners |
| b | Incident handling | Sentinel, Defender for Cloud, Logic Apps playbooks | 24h/72h/1-month reporting decisions |
| c | Business continuity & crisis mgmt | Azure Backup, Azure Site Recovery, immutable vaults | RPO/RTO definitions, tested restores |
| d | Supply chain security | Entra B2B, PIM, Conditional Access, GitHub Advanced Security | Supplier assessment & contracts |
| e | Security in acquisition/development | Defender for DevOps, IaC scanning, private endpoints | Secure SDLC, change control |
| f | Effectiveness assessment | Defender compliance dashboard, Azure Policy compliance | Audit cadence, evidence retention |
| g | Cyber hygiene & training | Update Manager, secure score, Defender XDR training | Awareness programme, patching SLAs |
| h | Cryptography & encryption | Azure Key Vault/Managed HSM, encryption at rest & in transit | Key governance, customer-managed keys |
| i | HR security, access control, asset mgmt | Entra ID, Intune, Defender for Cloud inventory | Joiner/mover/leaver process |
| j | MFA & secured communications | Entra Conditional Access, FIDO2/passkeys, Private Link | Enforcement scope, exception governance |
a. Risk analysis and information system security policies
Start with a living risk framework (ISO 27005 or NIST RMF) and a complete asset inventory. On Azure, Defender for Cloud auto-discovers resources and produces a quantified secure score you can track over time, while Azure Policy encodes your security baseline as enforceable rules. The platform inventories assets; you own the risk-acceptance decisions, the owners, and the review dates. Map your scope first — our NIS2 scope test for the NIS2UmsG walks through the thresholds.
b. Incident handling
NIS2 imposes a strict cadence: early warning within 24 hours, a detailed report within 72 hours, and a final report within one month. A manual ticket queue will not meet a 24-hour clock. Stream Defender for Cloud, Entra ID, and resource logs into Microsoft Sentinel, then build Logic Apps playbooks that classify severity and pre-populate the regulator notification. We document the operational side of this in our 24/72-hour incident-reporting runbook.
c. Business continuity and crisis management
Define RPO and RTO for every critical workload and prove them with tested restores — not documented intentions. Azure Backup with immutable vaults and soft delete protects against ransomware-driven deletion, and Azure Site Recovery handles regional failover. Run restore drills quarterly and keep the evidence; "we have backups" is not a control until you have restored from them.
d. Supply chain security
This is where NIS2 has teeth. Article 21(2)(d) makes you responsible for security in your direct suppliers. On Azure, govern third-party access with Entra ID B2B, time-bound Privileged Identity Management (PIM) roles, and Conditional Access. Validate your software supply chain with GitHub Advanced Security and SBOM generation in CI/CD. And remember: Microsoft is itself a critical supplier you must assess, not exempt.
e. Security in acquisition, development and maintenance
Bake security into the SDLC. Defender for DevOps and infrastructure-as-code scanning catch misconfigurations before deployment, private endpoints keep data-plane traffic off the public internet, and change control ties every production change to an approved request. This is DevSecOps in service of compliance, not as a separate exercise.
f. Policies to assess effectiveness
Article 21(2)(f) is the measure organisations most often skip — and the one the BSI will probe. You must assess whether your controls actually work. Defender for Cloud's regulatory compliance dashboard and Azure Policy compliance states give you continuous, evidence-grade reporting rather than an annual snapshot. Set an audit cadence and retain the evidence.
g. Basic cyber hygiene and training
Patching, hardening, and awareness. Azure Update Manager governs OS and workload patching with SLAs, secure score nudges configuration hygiene, and Defender XDR provides attack-simulation training. Cyber hygiene is unglamorous and disproportionately effective; most incidents we triage trace back to an unpatched system or a missing baseline, not an exotic zero-day.
h. Cryptography and encryption
Azure encrypts data at rest and in transit by default, but NIS2 expects a deliberate cryptography policy. Use Azure Key Vault or Managed HSM for key governance, adopt customer-managed keys (CMK) where data sensitivity or sovereignty requires it, and enforce TLS 1.2+ everywhere. The control is not "encryption exists" — it is "we govern our keys and can prove it."
i. Human resources security, access control and asset management
Tie identity lifecycle to HR. Entra ID governs joiner/mover/leaver flows, Intune enforces device compliance, and Defender for Cloud maintains the asset inventory. Least-privilege access and a clean leaver process close two of the most common audit findings. For Zero Trust as the connective architecture across these controls, see our Zero Trust service.
j. Multi-factor authentication and secured communications
MFA is named explicitly in Article 21(2)(j) and is effectively mandatory. Enforce it with Entra ID Conditional Access, using phishing-resistant FIDO2 keys or passkeys for privileged accounts, and block legacy authentication that bypasses MFA. Secure machine-to-machine and service traffic with Private Link and managed identities rather than shared secrets.
A practitioner's implementation sequence
Order matters. Implementing the measures in the wrong sequence wastes effort and leaves gaps. The sequence we use on delivery:
- Governance and scope. Confirm your entity classification, name owners, and obtain management-body sign-off. Liability sits with the Geschäftsleitung, so this step is non-negotiable.
- Baseline. Turn on Defender for Cloud and the compliance dashboard, build the asset inventory, and measure your starting secure score.
- Identity. Enforce phishing-resistant MFA, deploy PIM for just-in-time admin, and kill legacy auth. Identity is the highest-leverage control in the directive.
- Detection and reporting. Wire everything into Sentinel and build playbooks aligned to the 24h/72h/1-month timeline.
- Resilience and crypto. Immutable backups, tested restores, key governance.
- Continuous governance. Codify controls as Azure Policy, alert on drift, and run effectiveness reviews and tabletop exercises.
When you are ready to register, our BSI registration walkthrough covers the portal step by step.
Where Azure stops and you begin
The recurring mistake we see is treating NIS2 as a procurement problem — buy the licences, switch on the features, declare victory. Article 21 is organisational and procedural as much as technical. Sentinel does not decide whether an incident is reportable; your playbook and your people do. Defender for Cloud measures your posture; your management body owns the risk. The platform gives you leverage, but accountability is not a SKU.
At CC Conceptualise we have implemented these controls for European enterprises operating under NIS2, DORA, and BSI C5 in parallel, and the pattern holds: organisations that treat the ten measures as a continuous operating model — not a one-off project — pass audits and, more importantly, withstand incidents.
FAQ
What are the 10 NIS2 risk-management measures? Article 21(2) of NIS2 lists ten minimum measures: risk analysis and information system security policies; incident handling; business continuity and crisis management; supply chain security; security in acquisition, development and maintenance; policies to assess the effectiveness of measures; basic cyber hygiene and training; cryptography and encryption; human resources security, access control and asset management; and multi-factor authentication and secured communications. German law transposes these via the NIS2UmsG.
Does using Azure make us NIS2 compliant automatically? No. Azure provides the technical building blocks, but NIS2 compliance is a shared-responsibility outcome. Microsoft secures the platform; you remain accountable for configuring identity, logging, encryption, supplier oversight, and governance correctly. The measures in Article 21 are organisational and procedural as much as technical, so tooling alone never satisfies them.
Which Azure services cover the most NIS2 measures? Microsoft Defender for Cloud, Microsoft Sentinel, Entra ID (Conditional Access and PIM), Azure Policy, and Azure Backup together cover the majority of the technical requirements. Defender for Cloud's regulatory compliance dashboard can map your environment against frameworks that overlap heavily with NIS2, giving you a continuous control posture rather than a point-in-time snapshot.
How does NIS2 treat multi-factor authentication? MFA is named explicitly in Article 21(2)(j) and is effectively mandatory. On Azure, you enforce it through Entra ID Conditional Access, ideally with phishing-resistant methods such as FIDO2 security keys or passkeys for privileged accounts. Legacy authentication protocols that bypass MFA must be blocked.
What does NIS2 require for supply chain security on Azure? Article 21(2)(d) requires you to manage security risks in your direct suppliers and service providers. On Azure this means controlling third-party access with Entra ID B2B, time-bound PIM roles and Conditional Access, validating your software supply chain in CI/CD, and tracking the security posture of SaaS and managed-service dependencies. Microsoft is itself a critical supplier you must assess.
Is management personally liable for these measures under German NIS2 law? Yes. Under the NIS2UmsG, the management body (Geschäftsleitung) must approve and oversee the risk-management measures and can be held personally liable for failures of oversight. This is not delegable to IT. Boards should require documented evidence that each Article 21 measure is implemented, tested, and reviewed.
Bringing it together
The ten Article 21 measures are demanding but tractable on Azure once you sequence them correctly and treat them as an operating model rather than a checklist. If you want a senior architect to map your environment against NIS2 and build the implementation plan, explore our Zero Trust and security advisory — we work as a strategic engineering partner, not a body shop.
Topics