Your Board Is Asking About NIS2. Here Is What You Actually Need to Do
In this article
2026 update: This article was originally published in October 2024. Since then, NIS2 enforcement has started, DORA became fully applicable in January 2025, and Belgium has moved into active compliance mode. The core guidance below remains valid. Key updates: Belgium was one of the first EU member states to transpose NIS2 (Law of 26 April 2024, in force since 18 October 2024). The CyFun self-assessment deadline for Belgian entities is 18 April 2026. The ESAs designated 19 Critical ICT Third-Party Providers under DORA in November 2025, including Microsoft, AWS, and Google Cloud. See the updated sections below for current status.
Last month a CTO at a Belgian mid-market company told us something we have been hearing a lot: “I just got out of a board meeting where NIS2 came up for the first time. The board wants to know if we are compliant. I don’t even know if it applies to us.”
It applies. And it almost certainly applies to more organisations than most people think.
EU member states had until 17 October 2024 to transpose the NIS2 Directive into national law, and the original NIS Directive was repealed from 18 October 2024. Belgium was actually one of the first to transpose it into national law, adopting its NIS2 law on 26 April 2024, well ahead of the deadline. The Centre for Cybersecurity Belgium (CCB) is the designated national authority, and the compliance timeline is now in full swing: all in-scope entities should have registered by March 2025, and the CyFun self-assessment submission deadline is April 18, 2026.
For financial services organisations, DORA (the Digital Operational Resilience Act) became fully applicable on January 17, 2025. Unlike NIS2, DORA is a regulation, not a directive, so it applied directly and uniformly across the EU from that date.
If you are a CTO, VP Engineering, IT director, or CISO at a Belgian or European enterprise, this is no longer a conversation you can delegate to the security team and forget about. Here is why, and what to do about it.
NIS2 in Plain Language
The original NIS Directive from 2016 applied to a narrow set of operators of essential services. NIS2 blows that scope wide open. It now covers two categories: “essential” entities (energy, transport, banking, health, water, digital infrastructure) and “important” entities (postal services, waste management, food production, manufacturing, digital providers, and more). If your company has more than 50 employees or more than EUR 10 million in annual turnover and operates in one of these sectors, you are likely in scope.
Three requirements matter most for technology leadership.
First, incident reporting is now mandatory and time-bound. You must submit an initial notification to the national authority within 24 hours of becoming aware of a significant incident. A full incident report must follow within 72 hours. If you have ever tried to assemble a meaningful incident report in 72 hours, you know this is aggressive. Without proper logging, monitoring, and pre-built response processes, it is nearly impossible.
Second, management bodies are explicitly required to approve cybersecurity risk management measures and oversee their implementation. Member states must ensure that management bodies approve cybersecurity risk management measures, oversee their implementation, and can be held liable for infringements by the entity. For essential entities, fines can reach EUR 10 million or 2% of global annual turnover, whichever is higher.
Third, supply chain security gets specific attention. You are responsible for assessing and managing risks from your ICT suppliers and service providers. “We trusted our vendor” is not a defence.
DORA for Financial Services
If you operate in financial services (or provide ICT services to financial entities), DORA adds requirements on top of NIS2. The regulation demands a formal ICT risk management framework, mandatory incident reporting with defined timelines, regular digital operational resilience testing (including threat-led penetration testing for significant entities), and active management of third-party ICT risk.
DORA is not a directive that member states transpose at their own pace. It is a regulation. It has applied directly and uniformly across the EU since January 17, 2025. No ambiguity about national implementation timelines.
The overlap between NIS2 and DORA is significant. DORA is considered lex specialis (special law) relative to NIS2, meaning DORA takes precedence for ICT risk management, resilience testing, and incident reporting in the financial sector. NIS2 still applies for areas DORA does not cover, including registration obligations and general supply chain security beyond ICT. Financial services organisations need to satisfy both.
In November 2025, the European Supervisory Authorities (ESAs) designated the first 19 Critical ICT Third-Party Providers (CTPPs) under DORA, including Microsoft, AWS, Google Cloud, Oracle, and SAP. These providers are now subject to direct regulatory oversight. For enterprises using Azure, this means Microsoft’s cloud operations are under formal EU supervisory scrutiny, which strengthens the compliance story but also raises the bar for how you document and manage your dependency on Azure services.
Why Cloud Makes This Harder and Easier
Cloud infrastructure complicates compliance because your attack surface is distributed, your data flows through services you don’t fully control, and your operational model depends on shared responsibility with your cloud provider. When a regulator asks “where is your data and who can access it?”, the answer in a cloud environment is rarely simple.
But cloud also gives you capabilities that on-premises infrastructure never did. And this is where the conversation with your board should shift from risk to action.
In Azure specifically, several platform capabilities map directly to NIS2 and DORA requirements.
Microsoft Defender for Cloud provides continuous security posture assessment against regulatory frameworks including CIS, ISO 27001, and SOC 2. Its regulatory compliance dashboards show your actual posture against specific controls, backed by evidence from real resource configurations. When an auditor asks about encryption in transit, you show them the dashboard, not a spreadsheet someone updated last quarter.
Microsoft Sentinel gives you the centralized logging and detection capability that NIS2’s incident reporting timelines demand. Without a SIEM that aggregates signals across your environment, meeting that 24-hour initial notification window is a scramble. With Sentinel’s analytics rules and automated playbooks, your team gets alerted to incidents in minutes, not days.
Azure Policy enforces security configurations at scale. When NIS2 requires you to demonstrate that cybersecurity measures are consistently applied, policy-as-code is your evidence. Require encryption on all storage accounts, enforce network segmentation rules, mandate diagnostic settings on every resource. These policies run continuously and flag drift immediately.
Managed Identity eliminates credential-based attack vectors between services. If your architecture still passes connection strings and API keys between components, every one of those secrets is a potential incident waiting to trigger a 24-hour reporting obligation.
What Azure Tools Do Not Cover
Here is where leadership needs to stay honest. Azure provides the technical building blocks, but several critical compliance areas fall outside any cloud provider’s tooling.
Governance processes and documentation are your responsibility. NIS2 requires documented risk management policies, and those policies need board-level approval. No Azure service writes your information security policy or ensures your management team has reviewed it.
People and training are entirely on you. NIS2 explicitly requires cybersecurity training for management bodies. Your CISO can deploy every Defender plan available, but if your board members cannot explain your organisation’s risk posture, you have a compliance gap.
Third-party risk management requires active effort beyond what any tool provides. DORA demands that you maintain a register of all ICT third-party arrangements and assess the risks they introduce. Azure can tell you what resources exist in your tenant. It cannot tell you whether your payroll SaaS provider has adequate security controls.
Incident response planning is about process, not products. The 24-hour notification window only works if you have a tested runbook, clear escalation paths, and people who have practised the process. Sentinel will detect the incident. Your team needs to know what to do next.
Practical First Steps for Leadership
If you are starting from a position of uncertainty (and based on what we see across Belgian mid-market enterprises, most are), here is where to focus energy.
Start with a scoping exercise. Determine whether your organisation falls under NIS2 as essential or important, and whether DORA applies. This sounds basic, but we have seen organisations spend months on technical controls before confirming their regulatory obligations.
Get a baseline of your current security posture. Enable Defender for Cloud’s free CSPM tier across every Azure subscription you own. It costs nothing, takes fifteen minutes to configure at the management group level, and gives you an honest Secure Score. That score is the starting point for every conversation that follows.
Establish incident response capability before you need it. Deploy Sentinel, connect your core data sources (Entra ID sign-in logs, Azure Activity Logs, Defender for Cloud alerts), and build at least basic detection rules. Then write a response plan that maps to NIS2’s notification timelines. Test it. A plan that has never been exercised is not a plan.
Document your third-party ICT relationships. Build a register. Assess each provider’s security posture. Include this in your board reporting. DORA makes this explicit, but NIS2’s supply chain requirements point in the same direction.
Put cybersecurity on the board agenda permanently. Not as a quarterly update buried in an appendix. As a standing item with metrics (Secure Score trends, open incidents, third-party risk status) that board members can understand and act on. NIS2 makes management liability personal. The board needs to demonstrate that they are exercising oversight, not just receiving assurance.
The Urgency Is Real, but Panic Helps Nobody
Belgium transposed NIS2 ahead of most EU member states. The law is in force. The CCB is the supervising authority. Registration deadlines have passed. The next major milestone is April 18, 2026: the deadline for submitting your CyFun self-assessment (at Basic or Important level) or ISO 27001 documentation to the CCB.
No enforcement fines have been publicly documented yet in any EU member state as of early 2026. Regulators have been in registration and documentation mode. But the shift to active supervision, audits, and evidence requests is happening now. Organisations that treated 2025 as a grace period are running out of runway.
For DORA, the picture is similar. Deloitte research indicates that only about half of financial institutions expected full compliance by end of 2025, with nearly 40% targeting 2026. If your organisation is in that group, the window to demonstrate good-faith progress is narrowing.
The organisations in the strongest position are not the ones that achieved perfection. They are the ones that built real capabilities: logging, monitoring, incident response processes, documented governance, board-level security literacy, and a credible CyFun or ISO 27001 assessment. The technical tooling exists and the regulatory requirements are clear. What most organisations still lack is a structured programme to connect the two.
Key Belgian dates: Registration deadline passed (March 2025) · CyFun self-assessment due 18 April 2026 · Critical entities become essential entities 17 July 2026 · Progress report due 18 April 2027
Related: Shared vs Separate Azure Hubs for NIS2 and DORA regulated hub architecture · Microsoft Sentinel in 2026: Ingestion Cost Control building the logging capability NIS2 demands · What an Azure Landing Zone Audit Actually Finds common governance gaps
Need help with your Azure security posture?
We help enterprises design and tune Azure security controls: WAF policies, Sentinel ingestion, Defender for Cloud, identity governance, and NIS2/DORA readiness.
More from the blog
Shared vs Separate Azure Hubs for Regulated Workloads Under NIS2 and DORA
Microsoft Sentinel in 2026 and How to Control Ingestion Costs
