How to Prepare for an NIS2 Audit on Azure in 12 Weeks

In this article

• Why twelve weeks
• Phase 1: Discover and scope (weeks 1–3)
• Week 1: Inventory the environment
• Week 2: Identity baseline
• Week 3: Article 21 map
• Phase 2: Close high-impact gaps (weeks 4–6)
• Week 4: Public exposure
• Week 5: RBAC cleanup
• Week 6: Logging and detection
• Phase 3: Build evidence (weeks 7–9)
• Week 7: Policy and compliance state
• Week 8: Backup and DR
• Week 9: Cryptography and key management
• Phase 4: Audit readiness (weeks 10–12)
• Week 10: Per-control narratives
• Week 11: Attestations and exemptions
• Week 12: Pre-audit dry run
• Who runs this
• What we have seen go wrong
• After week twelve

NIS2 enforcement in Belgium passed its first big milestone on 18 April 2026: the deadline for the CyFun self-assessment that the CCB has aligned with NIS2 supervision. Most organisations we encounter are not at zero, but they are not at evidence-ready either. They have Defender for Cloud running, RBAC defined, some Azure Policy in place. They cannot answer “show us how you handle Article 21(2)(d) on supply chain security” in five minutes with dated artefacts and named owners.

This post is the 12-week plan we run with clients to close that gap on Microsoft Azure. It stays Azure-specific throughout and assumes you are starting from “we have an Azure tenant, some controls in place, and a deadline coming.” The plan gets an organisation from “we have controls but no evidence trail” to “we can produce an audit pack on demand.” If your timeline is tighter than 12 weeks, the phases stay the same and the work compresses. If your timeline is longer, the work spreads but the structure does not change.

Why twelve weeks

Six weeks is too short to gather evidence with discipline. Twenty-four weeks turns into a permanent project that nobody owns. Twelve weeks is the realistic window for an organisation with one or two Azure subscriptions and a part-time security owner who is also doing other things.

The plan is four phases, three weeks each. Each phase has a single clear output. Skipping a phase is the most common reason audit preparation stalls.

Phase 1: Discover and scope (weeks 1–3)

The output of phase 1 is a written scope document. What Azure subscriptions are in scope, who owns each one, which Article 21 measures apply to which workloads, and where the obvious gaps are. No fixes yet. Just the map.

Week 1: Inventory the environment

Run Azure Resource Graph against every subscription and produce a single resource inventory: subscription IDs, resource counts by type, region distribution, tag coverage, and management group placement. Mark each subscription as in-scope or out-of-scope for NIS2 with a one-line reason. If you cannot draw the boundary, you cannot evidence the boundary.

Enable Defender for Cloud free tier on every in-scope subscription if it is not already on. Free CSPM costs nothing and gives you the recommendation engine output you will need from week 2 onward. The deeper Defender plans (Servers Plan 2, Storage, Key Vault, App Service) are a phase-2 decision, not a phase-1 prerequisite.

Capture for evidence: Resource inventory snapshot (CSV from Resource Graph), subscription owners list with named individuals, Defender enablement screenshot per subscription.

Week 2: Identity baseline

Pull the Conditional Access policy set, MFA registration coverage, and Privileged Identity Management activation history from Entra. Inventory every service principal: name, owner, last sign-in, secret/certificate expiry, and assigned roles at every scope. Flag the ones with no human owner, no sign-in in 90 days, or secrets expiring inside the audit window.

The service principal inventory is the most under-examined identity surface in most Azure environments. Auditors ask about it. Microsoft does not give you a single pane for it. Build the spreadsheet (or skip ahead to Governator’s automated version) before week 3.

Week 3: Article 21 map

Pull the ten measures from NIS2 Article 21(2). For each one, write a short paragraph: what Azure controls exist, where they are configured, who owns them, and what is missing. This becomes your gap register and the spine of every later phase.

The deliverable from week 3 is two pages: scope plus mapping. If it is twenty pages, you have written your remediation plan instead of your gap register, which is a different document and a phase-3 task.

Phase 2: Close high-impact gaps (weeks 4–6)

Phase 2 closes the three high-impact gap categories: public exposure that should not exist, over-privileged accounts at privileged scope, and missing detection coverage. Three weeks is enough for a well-scoped Azure environment. If it is not, your scope is too broad and you should narrow phase 1.

Week 4: Public exposure

Enumerate every public IP, every storage account with public blob access, every App Service without access restrictions, every database firewall rule with 0.0.0.0. The Resource Graph queries are well known. The hard part is the decision per resource: is the exposure intentional, mitigated by another control, or a finding that needs closure.

Move the easy ones (orphaned public IPs, forgotten dev/test exposure) immediately. For the rest, file each one as either “remediate by week N” or “exempt with justification.” The exemption with a written justification and a review date is acceptable evidence. The exemption without one is not.

Week 5: RBAC cleanup

For every privileged role assignment (Owner, Contributor, User Access Administrator) at the subscription scope or above, the question is the same: is the principal still active, still in role, still needed at this scope. The default answer in most environments is “no for at least one third of them.”

The mechanical task: pull every assignment with az role assignment list --all, join against Entra users (active vs disabled vs left the organisation), and produce the cleanup list. The political task is harder and is the reason this is a one-week effort, not a one-day effort.

Week 6: Logging and detection

Confirm Azure Activity Log diagnostic settings are sending to Sentinel or a central Log Analytics workspace for every in-scope subscription. Confirm Defender for Cloud is connected to Sentinel if you have a workspace running. Confirm at least the Microsoft incident-creation analytics rule is enabled in Sentinel.

Sentinel ingestion is a cost lever and a compliance lever at the same time. The phase-2 question is “is the data flowing for the in-scope set”, not “have we built the perfect detection library.” That is a phase-3 conversation.

Capture for evidence: Public-exposure register with disposition per resource, RBAC cleanup change log, Activity Log routing diagram, Sentinel rule enablement export.

Phase 3: Build evidence (weeks 7–9)

Phase 1 found the gaps. Phase 2 closed the urgent ones. Phase 3 builds the evidence trail that demonstrates a managed compliance programme to an auditor: dates, snapshots, attestations, exemptions, ownership. This is the phase most programmes underweight, and it is the phase auditors actually grade.

Week 7: Policy and compliance state

Take a snapshot of every Azure Policy assignment, its compliance state, and its exemption set. The auditor’s question is rarely “are you 100% compliant” (you will not be) but “do you know your non-compliance, why it exists, and what you are doing about it.” A snapshot per quarter with delta is better evidence than a single live dashboard.

If you do not have an exemption process, build one this week. A policy exemption requires a business justification, an owner, and a review date. Without those three fields, an exemption is just an unmonitored gap.

Week 8: Backup and DR

Inventory backup policies by workload, recovery objectives by workload, and the date of the last successful restore test per workload. Article 21(2)(c) on business continuity is one of the measures most often evidenced badly: organisations have backup configured but cannot show the runbook test. A single attestation per critical workload, with a date and an owner, is worth more than a backup policy summary.

Week 9: Cryptography and key management

Inventory Key Vault instances, customer-managed key (CMK) coverage on storage and disks, TLS minimum-version policy on App Services and APIM, and certificate expiry across the environment. Article 21(2)(h) is a control where Azure has all the primitives but most organisations have not built the inventory view.

Decide your CMK posture. Either you encrypt everything in scope with CMK, or you have an exemption per workload explaining why platform-managed keys are sufficient. Both are defensible. “We will get to it” is not.

Capture for evidence: Policy compliance snapshot (XLSX), exemption register with reviews, backup attestation register, Key Vault inventory, CMK coverage report.

Phase 4: Audit readiness (weeks 10–12)

The output of phase 4 is the audit pack. Per-control narratives, attestation register, exemption register, executive summary, and a tested dry-run.

Week 10: Per-control narratives

For each Article 21 measure (and each CyFun control if you are demonstrating compliance through CyFun), write a short narrative: what the measure requires, what we have configured on Azure, what evidence we hold, who owns it, when it was last reviewed. Two paragraphs each. Tighter is better.

The narrative is the layer that turns “Defender Secure Score is 78%” into “for Article 21(2)(a) on risk analysis, we run quarterly Defender for Cloud reviews against the NIS2 initiative, exempt findings with named owners and review dates, and attach the exemption register from week 7.” Auditors read narratives, not dashboards.

Week 11: Attestations and exemptions

Reconcile the exemption register from week 7 with the attestation register from weeks 4 and 8. Every exemption has a review date that has not passed. Every attestation has a named owner and a date. Every gap has either an exemption, an attestation, or a remediation in flight.

If anything in the register is past its review date, this week is when you renew it or close the exemption. Bringing an audit a register full of expired reviews is worse than bringing one with no register at all.

Week 12: Pre-audit dry run

Run the audit yourself. Pick three Article 21 measures at random and have someone outside the project ask the standard auditor questions: what does this require, how have you implemented it on Azure, where is the evidence, who owns it, when was it last reviewed. The five-minute target is a useful one. If a measure takes thirty minutes to evidence in the dry run, it will take thirty minutes (or fail) in the real audit.

The pre-audit pack (executive summary, control evidence matrix, attestations, exemptions) is the artefact you carry into the engagement. If it is more than fifty pages, it is a remediation plan dressed up as an audit pack. Aim for the executive summary to fit on one page.

Who runs this

Twelve weeks at this level of detail needs roughly half to four-fifths of a full-time security or compliance owner, plus a third to a half of a platform engineering FTE for the Azure-specific work. If you do not have either, the realistic options are to extend to sixteen or twenty weeks with a smaller team, or to run the first cycle as an external assessment with internal handover.

The handover point matters. Phase 2 (gap closure) is engineering work. Phase 3 (evidence) is compliance work. Phase 4 (narrative) is communication work. Programmes that put one person across all four phases tend to underdeliver on the last two, because by week 9 they are tired and the deadline pressure is on phase 4.

What we have seen go wrong

A few patterns repeat across NIS2 readiness programmes on Azure.

Treating CyFun like a yes-no checklist. A control marked “yes” without dated evidence is worse than a control marked “no” with a remediation plan.

Skipping evidence capture in weeks 1–3 because it feels like discovery work. By week 12 the audit trail starts at week 4, which means three weeks of baseline state are missing from the record.

Trying to fix the long tail in phase 2. The point of phase 2 is the high-impact set: public exposure, RBAC at privileged scope, missing detection. The long-tail Defender recommendations belong in a continuous improvement backlog, not in a 12-week sprint.

Letting one person own every phase. The handover discipline is what makes the deadline.

Confusing Defender Secure Score with audit readiness. Score is a useful trend metric. It is not an answer to any of the ten questions an Article 21 auditor will ask. The score going from 65% to 80% during phase 2 is a good signal, but the audit pack still has to be built in phase 3 and 4 either way.

After week twelve

Audit readiness is not a destination. The CyFun progress report is due 18 April 2027. The maintenance burden between an audit-ready state and the next regulatory checkpoint is not zero. The realistic options are an annual repeat of the 12-week cycle, or moving to continuous assurance where the evidence pack regenerates against live Azure data and the team is alerted on drift instead of working from a snapshot.

If the pressure point on the calendar is the 17 July 2026 reclassification or the 18 April 2027 progress report, the 12-week cycle above is the right shape. If the pressure point is “we want to stop running this every year,” continuous assurance is the move. Either way, the structure of the four phases is what gets you to a defensible posture. The tooling decision is downstream of that.

Related: Your Board Is Asking About NIS2 covers the regulatory and board-level framing. Defender for Cloud in 2026 covers what to enable, tune, and skip on the data-source layer. CyberFundamentals on Azure covers the CyFun assurance levels and how Governator handles them. Azure NIS2 compliance covers the Article 21 mapping in detail.