The Azure Architecture Governance Checklist: What Every Dutch Organisation Should Have Documented Before the End of 2026

This is a 35-item Azure governance checklist for Dutch organisations: architecture documentation, NIS2/DORA/SOC2 compliance mapping, and operational governance. Every item is written to be auditable — you either have the artifact or you don’t. Most organisations going through it honestly find eight to fifteen items they can’t check off.

You’re not in crisis. The systems are running, the team is shipping, nothing is on fire. But you’re doing a mid-year review and you’re realising — slowly, then all at once — that you don’t actually know the state of your Azure governance documentation.

NIS2 enforcement is live. DORA examinations have started. Your SOC2 auditor is asking questions you can’t answer cleanly. And every governance resource you’ve found is either a 200-page Microsoft whitepaper or a checklist so generic it might as well say “be more secure.”

“Document your resources.” Great. Which resources? In what format? To what level of detail?

Here’s the specific version. Items are written to be auditable — meaning you either have the thing or you don’t. No partial credit, no “we’re working on it.” Each item is a concrete artifact or configuration state, not a process or an intention.

Most organisations going through this honestly will find eight to fifteen items they can’t check off. That’s not a disaster. It’s a work list. The goal of this exercise is the specific gap list, not the score.

Key takeaways

The checklist has 35 auditable items across three areas: architecture documentation, compliance mapping (NIS2, DORA, SOC2), and operational governance.
Each item is a concrete artifact or configuration state — you either have it or you don’t, with no partial credit.
Three regulatory pressures land simultaneously in 2026: DORA examinations (binding since January 2025), NIS2 under the Cyberbeveiligingswet, and SOC2 Type II as a commercial procurement requirement.
A Dutch fintech that ran a version of this checklist found 14 gaps — none catastrophic — and closed all of them within six weeks for a clean audit cycle.
The useful output is the specific list of items you can’t check off, not the score: each gap is work with an owner and a deadline.

Why the regulatory pressure landed all at once

DORA has been binding since January 2025. DNB supervisory examinations under it are underway now. Article 8 wants a classified ICT asset register. Article 28 wants documented critical third-party dependency assessment. Article 11 wants tested business continuity architecture with configuration evidence attached. Financial institutions that deferred past January 2025 are now in the examination window with incomplete documentation.

NIS2 transposition is in force in the Netherlands under the Cyberbeveiligingswet. For organisations in scope — cloud and managed service providers, digital infrastructure operators, essential service sectors — Article 21 requires documented risk management measures covering access control, asset management, and business continuity. Enforcement by the Rijksinspectie Digitale Infrastructuur is active.

And SOC2 Type II has become, in practice, a commercial compliance requirement for Dutch B2B SaaS. Enterprise procurement teams require it as a supplier onboarding condition. The audit requires architecture evidence. If you don’t have a governance programme, you can’t produce that evidence in the timeframe the audit process demands.

All three are happening simultaneously, in 2026, for a lot of Dutch organisations that have historically treated governance documentation as the thing you do after you finish shipping.

Architecture Documentation

Compliance Mapping (NIS2, DORA, SOC2)

NIS2

NIS2 Article 21 control mapping completed: each of the ten measures (risk management, incident handling, BCM, supply chain, network security, access control, encryption, vulnerability management, MFA, communications security) mapped to a named Azure control or configuration
In-scope NIS2 obligations confirmed with legal counsel — entity classification (essential vs important), sector, and supervisory authority identified
Significant incident classification criteria documented and aligned with NIS2 Article 23 reporting thresholds — including the 24-hour early warning and 72-hour full notification timelines
Supply chain security assessment completed for all Azure Marketplace third-party services in use, each assessed against NIS2 Article 21(2)(d) criteria

DORA

ICT asset register produced from Azure Resource Graph, classified per DORA Article 3(22) critical asset criteria, and maintained under a documented review cadence
All third-party ICT service providers assessed under DORA Article 28(2) criteria — Microsoft Azure documented as a critical provider, with services consumed, data categories, contractual basis, and concentration risk recorded
Business continuity architecture documented to DORA Article 11 standard: recovery time objectives stated, supporting Azure configuration evidence attached (geo-replication settings, Site Recovery policies, backup vault configurations), and a failover test record present
ICT-related incident register operational, with DORA Article 17 classification criteria applied and at least one tabletop or live test of the major incident reporting procedure completed in the last 12 months
Penetration testing programme in place satisfying DORA Article 26 TLPT requirements (for in-scope financial entities above the size threshold)

SOC2

SOC2 Trust Services Criteria scoping decision documented — which criteria (Security, Availability, Confidentiality, Processing Integrity, Privacy) are in scope, with rationale
Entra ID role assignment inventory produced from Resource Graph, with all Owner and Contributor assignments at subscription scope reviewed, approved, and documented within the last 90 days
Privileged Identity Management configured for all Entra ID roles with subscription-level permissions — just-in-time activation required, with approval workflow and maximum activation duration set
Conditional Access policies documented — MFA enforcement for all users, named location policies, compliant device requirement for production access, sign-in risk policy configurations
Azure Policy compliance report produced and reviewed monthly, with all non-compliant resources either remediated or subject to a documented exception with owner and review date

Operational Governance

That’s 35 items. Not a comprehensive governance framework. A minimum bar — the set of things Dutch organisations running Azure should be able to check off before the end of 2026, given the regulatory environment and the commercial expectations now standard in enterprise procurement.

A Dutch fintech that ran through a version of this checklist in early 2025 found 14 gaps. Not catastrophic ones — no exposed credentials, no missing encryption. But gaps that would have surfaced as findings in a DNB examination or a SOC2 audit: no formal ICT asset register, Microsoft Azure not documented as a critical third-party provider, Key Vault soft-delete retention at 7 days when their own BCP called for 90, and Azure Monitor alert rules covering fewer than 40% of production resources. All 14 were closed within six weeks. The 2025 audit cycle was clean.

According to a 2024 Cloud Security Alliance survey of 1,500 security professionals across European financial institutions, 61% reported that their cloud architecture documentation was materially out of date — meaning it did not reflect changes made in the prior 12 months. Not theory. The majority condition.

FAQ

Who is this Azure governance checklist for?

CTOs, Platform Leads, and compliance owners at Dutch organisations running Microsoft Azure that face NIS2, DORA, or SOC2 obligations in 2026. It assumes a working environment, not a crisis — the goal is a mid-year gap list precise enough to audit against, not a generic “be more secure” framework.

How many items should I expect to fail?

Most organisations going through the 35 items honestly find eight to fifteen they can’t check off with evidence. That range is normal, not a disaster. The list of misses is the useful output — each one becomes a discrete piece of work with an owner, a resolution path, and a self-imposed or regulatory deadline.

What’s the difference between NIS2, DORA, and SOC2 on this checklist?

NIS2 (Cyberbeveiligingswet) requires Article 21 risk-management measures mapped to Azure controls. DORA requires an Article 8 asset register, Article 28 third-party assessment, and Article 11 continuity evidence. SOC2 requires Trust Services Criteria scoping, Entra ID and PIM evidence, and reviewed Conditional Access policies. Each maps to specific Azure configuration.

Which item do teams most often think they have but don’t?

The DORA Article 28 critical-third-party register — Microsoft documented as a critical provider, with concentration risk and exit strategy attached. Teams assume the contractual relationship covers it, but the structured assessment, concentration-risk analysis, and documented exit strategy are usually missing entirely.

The useful output of this checklist is not the number of items you can check off. It’s the specific list of things you can’t — because each gap is a piece of work with an owner, a resolution path, and a deadline that’s either self-imposed or regulatory.

The organisations that get through the rest of 2026 without a compliance finding or a failed audit are the ones that ran this exercise in the first half of the year. Not because they’re more diligent. Because they gave themselves enough time to fix what they found.

So run the 35 honestly. How many can you actually check off today — with evidence, not intention? If you land in the eight-to-fifteen-gaps range, you’re exactly average, and the list of misses is the useful part.

One thing I’m curious about: which item do most teams think they have covered but don’t? My bet is the Article 28 critical-third-party register — Microsoft documented as a critical provider, concentration risk and exit strategy attached. What’s yours?