NIS2 Belgium After 18 April: From Basic Readiness to Continuous Azure Evidence
In this article
- What changed after 18 April 2026
- The 2027 step-up is already the next pressure point
- What Azure evidence is usually missing
- Defender Secure Score is not enough
- Continuous evidence as the operating model
- Belgian organisations are operationalising CyFun publicly
- Where Governator fits in this picture
- The post-deadline question, plainly
In short: The 18 April 2026 NIS2 checkpoint for Belgian essential entities has passed. Organisations that met it built a binder of point-in-time evidence and named a few owners. The harder question starts now: can you keep that evidence current across your Azure subscriptions, or does it go stale until the next consulting engagement? This post walks through what the post-checkpoint reality looks like for Belgian Azure-heavy organisations, and what continuous evidence actually means in practice.
For many Belgian organisations subject to NIS2, the months leading up to 18 April 2026 looked like a project. Risk register reviewed, controls catalogued, gaps closed (or excepted), evidence binder populated, registration confirmed at Safeonweb, conformity assessment body engaged where needed. A milestone, then a moment of relief.
The relief is misleading. NIS2 is not a one-shot certification. The CCB’s own framing of the 18 April milestone makes the point explicitly: by that date, essential entities had to demonstrate that cybersecurity risk-management measures were effectively being implemented and that they were following a recognised compliance pathway.
For Belgian organisations now in the maintenance phase, the Azure-specific question we are seeing in our recurring readiness engagements is consistent: the binder is dated, the controls are mapped to a snapshot, and nobody can say what changed in the production tenant since the audit closed.
What changed after 18 April 2026
18 April 2026 did not mean the same thing for every Belgian NIS2 entity. For essential entities, it was a formal evidence checkpoint under ex-ante supervision: the CCB can request evidence at any time, on any control, without a triggering incident. For important entities, the CCB’s NIS2 FAQ confirms that 18 April did not create the same administrative submission requirement, but it did not remove the implementation obligation either. After an incident, the CCB may still request evidence that the required measures were correctly implemented.
In both cases, the steady state is “evidence available on demand.” That is a different operating model from the readiness-project frame organisations used to get to the checkpoint.
The supervisory ecosystem is also no longer hypothetical. The conformity assessment body list maintained by the CCB shows the operational reality. Brand Compliance België and What a Work SRL are accredited under ISO/IEC 17029 for CyberFundamentals 2023/2025 at the Basic and Important levels. Belgian Quality Association, Bureau Veritas, DNV, KPMG Certification, Vinçotte and others provide the ISO 27001 pathway recognised under NIS2. The CAB ecosystem exists, the recognised pathways are operational, and Belgian organisations now have to treat this as a live assurance market rather than a theoretical compliance route.
The 2027 step-up is already the next pressure point
For organisations that used the staged CyFun path, the NIS2 transposition sets the next pressure point at 18 April 2027. Entities that initially obtained Basic while targeting Important need to reach Important by that date. Entities targeting Essential need to reach Essential certification. ISO 27001 paths also need to mature from scope, Statement of Applicability and internal audit evidence toward full certification before April 2027.
Each step up is more than a paperwork change. Moving from Basic toward Important or Essential expands the evidence discussion from baseline hygiene into governance, supply chain, monitoring, incident response, resilience, and third-party assurance. Teams that reached the 2026 checkpoint with one Sharepoint folder and a quarterly meeting will struggle to maintain credible evidence at that level.
This gap is what most Belgian organisations are waking up to in May. The 2026 evidence pack ages quickly, and the 2027 expectation is meaningfully higher.
What Azure evidence is usually missing
Patterns we see across Azure-heavy environments are consistent. Most organisations have the raw signals through Defender for Cloud, Azure Policy, and Activity Log. They lack the interpretation layer that turns those signals into evidence a CAB will accept.
Recurring gaps include:
- Subscription Owners and Contributors with no recent activity, no human owner, and no review evidence. This is the service-principal blast-radius problem extended to user accounts.
- Break-glass accounts that exist but lack the access logs and recent-use review you need to defend them.
- Defender recommendations without owners, without exemption metadata, and without a justification trail when an auditor asks.
- Azure Policy non-compliance reported as a count rather than as named workloads, named owners, and remediation timelines.
- Public exposure beyond the Defender map: public IPs, broad NSG rules, exposed management ports, and WAF coverage gaps where a public endpoint is not actually behind the WAF policy you assumed.
- Diagnostic settings and Sentinel ingestion coverage with no completeness evidence (every workload sends the right logs, not just some workloads).
- Backup posture without recent restore-test artefacts, including the soft-delete state, immutable storage, and a documented restore in the last twelve months.
- Key Vault hygiene gaps: purge protection, soft-delete retention, secret and certificate rotation discipline, RBAC over legacy access policies.
- Subscription ownership and management group inheritance with no documented Who-Owns-What and where exemptions have drifted.
- Orphaned resources, exceptions without review dates, and exceptions that outlived their original justification.
- Drift signals: cost or security recommendation counts that changed materially without a corresponding change ticket.
Each of these maps to a CyFun control or NIS2 Article 21 measure with a specific evidence expectation. None of them is hard to collect on Azure. All of them are easy to lose track of between assessments.
Defender Secure Score is not enough
Defender for Cloud is the right place to start, and we cover where it pays back and where it stops in detail. The short version for the post-deadline conversation:
Defender shows technical signal. A resource is misconfigured, a vault is missing purge protection, a public IP is exposed. It does not produce a CyFun control narrative that maps the finding to PR.AC-1 or CY.AM-2. It does not assign ownership at a human level. It does not track exception justification with a review date. It does not bundle these into a board-ready risk view or an auditor-ready evidence pack.
That interpretation is governance work. Treating Secure Score as a compliance metric is one of the most consistent mistakes we see in Azure-heavy NIS2 programs.
Continuous evidence as the operating model
The shape of the post-deadline operating model is straightforward to describe and harder to deliver:
- Azure data is collected continuously (Resource Graph, Defender, Policy, RBAC, Activity Log, Cost, WAF, Storage metrics)
- Findings are mapped to CyFun and NIS2 measures in a way an auditor recognises (per-control evidence, not aggregate scores)
- Each finding has a named owner and a remediation SLA
- Exceptions carry justification, review date, and approval evidence
- Evidence packs regenerate on demand, dated, with the data sources captured
- Drift alerts when the underlying state changes between scheduled reviews
This is the operating model that follows from the CCB’s requirement to demonstrate effective implementation, even if the official language is less prescriptive. The reason most Belgian organisations end up commissioning a fresh consulting deliverable each year is that the in-house alternative requires sustained engineering capacity nobody planned for.
Belgian organisations are operationalising CyFun publicly
Public language around CyFun is shifting from “we are aware of it” to “we report against it.” A few examples that have crossed into annual reports and multi-year plans:
EVS Broadcast Equipment lists Maturity Level 2 of the CyberFundamentals Framework as a cybersecurity governance target in its 2025 annual report. Barco’s 2025 integrated report defines an average cybersecurity maturity CyFun score and confirms the self-assessment is performed at the end of each financial year. GUBERNA’s 2025 reporting states the institute has implemented the recommendations from a security audit, registered at Safeonweb, and is implementing CyberFundamentals. The City of Bruges’s 2026-2031 multi-year plan refers to the CyFun framework as the basis for following NIS2 compliance.
Important caveat: these are public governance signals, not published CAB verification statements. That distinction matters. The point is not that these organisations have publicly proven a CyFun label; the point is that CyFun language has moved into board reporting, public-sector planning, and supplier conversations. Each example above is a public, dated, organisational commitment to the framework’s vocabulary, nothing more.
Taken together, they signal the direction of travel: CyFun maturity is becoming a governance metric that boards expect to see, peer organisations report against, and customers ask for in supplier questionnaires.
The implication for Belgian Azure teams is concrete. Within eighteen months, “we passed Basic” stops being credible by itself. The organisations setting the bar are publishing CyFun maturity scores in annual reports. Yours will be expected to either match that or explain its position.
Where Governator fits in this picture
Governator is the assurance layer GenioCT runs across the Azure tenant. It collects from the standard Azure data planes, maps every finding to a CyFun control and a NIS2 Article 21 measure, assigns owners, tracks remediation and exceptions, and produces evidence packs on demand.
It is not a replacement for compliance expertise. It is the place where the technical evidence and the compliance language meet, so recurring spend goes into a repeatable evidence model rather than into rebuilding the same readiness pack before every review. The shift, in our engagements, is roughly: one structured assessment to baseline the environment, then continuous assurance as a managed service. Drift gets flagged when it happens. Evidence becomes a query, not a project.
For organisations on the Important or Essential pathway with the 18 April 2027 step-up looming, this is the bridge. Recurring readiness assessments (every twelve months, fresh PDF, fresh budget) do not survive a 2027-level evidence demand. Continuous assurance does.
The post-deadline question, plainly
The question Belgian Azure teams should be answering this quarter is not “did we pass Basic?” That moment has passed. It is:
- Could you produce a current evidence pack for any CyFun or NIS2 control today, with named owners and dated artefacts, in five minutes?
- Could you defend an exception when an auditor or the CCB asks why it is still open?
- Would your evidence pack survive comparison against your peer organisations’ published CyFun maturity scores?
If the answer to any of those is “we would need to commission another readiness engagement,” the operating model has not caught up to the regulation. That gap is what the next eighteen months will surface, regardless of which classification path your organisation is on.
If you are on the Belgian NIS2 path and want to discuss what continuous Azure evidence looks like for your environment, start with a Governator-powered Azure Health Check. The first conversation is about whether the evidence is producible, not about another consulting deliverable.
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.
