You are not audited on the directive. You are audited on your evidence.
That distinction is the whole of NIS2 assessment preparation in Belgium, and it is what separates organisations that pass from organisations that have excellent policies. An assessor arrives with a list of controls and asks, for each one, to be shown the thing that proves it works. Not the policy that says it should work. A timestamped configuration export, a log extract, a signed board minute, a recovery test report, a supplier contract clause.
What follows is organised the way the assessor asks, not the way the directive is written. Ten measure categories, and for each one the document or system export that satisfies it.
Who is in scope, and who checks you
Belgium transposed NIS2 through the Law of 26 April 2024, published in the Belgian Official Gazette on 17 May 2024 and in force since 18 October 2024, operationalised by the Royal Decree of 9 June 2024 and amended by the Royal Decree of 15 December 2024. The Centre for Cybersecurity Belgium is the supervisory authority, the national CSIRT and the operator of Safeonweb@Work. Its normative reference framework is CyberFundamentals, usually written CyFun.
Your entity classification determines almost everything else about your assessment.
| Classification | Minimum CyFun level | Supervision | Route to conformity | Cycle |
|---|---|---|---|---|
| Important entity | CyFun Important (Basic accepted as a transitional step until April 2027) | Ex-post: the inspectorate acts when there are grounded indications of non-compliance, such as a reported incident or a complaint | CyFun Important verification by an accredited conformity assessment body under EN ISO/IEC 17029:2019, or an ISO/IEC 27001:2022 certificate whose Statement of Applicability demonstrates equivalence | Three-year cycle with a validity statement and annual surveillance. No routine government audit in advance. |
| Essential entity | CyFun Essential (phased growth via Important is accepted) | Ex-ante: proactive, systematic supervision and periodic checks | CyFun Essential certification by an accredited body under ISO/IEC 17021-1 or EN ISO/IEC 17029, ISO 27001 with equivalence coverage, or direct inspection by the CCB inspectorate | Three-year cycle, full conformity certificate, mandatory annual surveillance audits, evidence submitted to the CCB. |
| Supplier not directly in scope | Market practice: CyFun Basic, or Important where a customer contractually requires it | No direct government supervision; obligations flow from private contracts | CyFun Basic verification statement via an external body, or self-assessment using the CCB CyFun Selection Tool if the regulated customer formally accepts it | Contractually determined. An external verification statement carries a formal three-year validity. |
Two details from this table that catch people out. Verification and certification are not synonyms: Basic and Important are verifications under EN ISO/IEC 17029, Essential is a certification under ISO/IEC 17021-1 or EN ISO/IEC 17029, and the accreditation reference is BELAC document 2-405. And an ISO 27001 certificate does not automatically satisfy the Belgian obligation. The CCB requires the Statement of Applicability to demonstrably mirror the control points of the applicable CyFun level, and the scope must cover every network and information system supporting the regulated service. If you are unsure which category you are in, we have written a scope check, and the framework comparison sits in CyFun versus ISO 27001.
The ten measures, in one paragraph
Article 21(2) of Directive (EU) 2022/2555 sets out ten minimum measures, moderated by the proportionality principle in Article 21(1) which accounts for state of the art, cost and exposure. In order: risk analysis and information system security policies; incident handling; business continuity including backup management and crisis management; supply chain security; security in acquisition, development and maintenance including vulnerability handling and disclosure; policies to assess the effectiveness of risk management measures; cyber hygiene and training; cryptography and encryption; human resources security, access control and asset management; and multi-factor or continuous authentication with secured voice, video, text and emergency communications.
That list is orientation. It is not what you prepare. This is.
The evidence checklist
| Measure | What the assessor inspects | Evidence to have ready | CyFun reference |
|---|---|---|---|
| (a) Risk analysis and security policy | A cyclical risk assessment method, formal threat identification, and demonstrable board involvement in accepting residual risk | Information security policy and ISMS scope; risk register with impact, likelihood and residual scores; signed board minutes formally accepting residual risk; change management reports for infrastructure expansions | GOV.01, RSK.01 |
| (b) Incident handling | Operational response routines, logging and detection, and the ability to report within the statutory 24-hour, 72-hour and one-month windows | Documented incident response plan with escalation schemes; SIEM or SOC detection logs and ticket exports with triage timestamps; evaluation report of a tabletop exercise no older than twelve months; anonymised root cause analysis of a past incident | DET.01, RSP.01-04 |
| (c) Continuity, backup and crisis management | Backup immutability, redundancy of critical systems, and validated recovery objectives | Business continuity and disaster recovery plan; configuration export of immutability or WORM object-lock policies; system reports from bare-metal or database recovery tests actually performed; network topology drawing of the separated backup zone | REC.01-03, PRO.BU |
| (d) Supply chain security | Differentiated supplier risk analysis, contractual enforcement of security requirements, monitoring of external connections | Register of critical ICT suppliers classified by risk category; signed processing agreements containing a 24-hour incident notification clause and audit rights; completed supplier audits or independent attestations | GOV.SC, PRO.04 |
| (e) Acquisition, development and maintenance | Structured vulnerability management, coordinated vulnerability disclosure, patch management within defined SLAs | Patch policy with defined SLAs, for example critical patches inside 14 days; vulnerability scan reports for internal and perimeter infrastructure no older than 90 days; a published security.txt file or CVD page following CCB guidance; penetration test reports with demonstrated remediation validation | PRO.VM, PRO.SM |
| (f) Assessing effectiveness | Cyclical evaluation of whether controls actually work, through internal review, technical audit and management review | Internal or external IT security audit report; management review with decisions on security KPIs; corrective action register with assignment, deadlines and closure evidence; reports of technical verifications and attack simulations | GOV.02, EVAL.01 |
| (g) Cyber hygiene and training | Endpoint hardening baselines, training completion for operational staff and for the board, phishing resilience | Timestamped LMS exports of completed modules per employee; certificates or signed attendance lists for board-level cybersecurity training; aggregated results of periodic phishing campaigns; hardening baselines against a recognised standard such as CIS Benchmarks | PRO.AT, GOV.TR |
| (h) Cryptography and encryption | Systematic strong encryption in transit and at rest, documented key management | Formal cryptography and encryption policy; device management fleet export proving full disk encryption on 100% of active laptops; configuration exports of web servers and load balancers showing TLS 1.0 and 1.1 disabled; key management procedures with rotation and revocation logs | PRO.CR |
| (i) HR security, access control, asset management | Control of the employee lifecycle, least privilege separation, an accurate and dynamic asset register | Current hardware, software and cloud asset register; joiners-movers-leavers policy with evidence of account disablement within 24 hours of departure; quarterly user access review reports; exports of administrator accounts with role-based assignment | ID.AM, PRO.AC, PRO.HR |
| (j) MFA and secured communications | Universal enforcement of MFA for external and privileged access, secure internal communication during network failure | Identity provider conditional access policies enforcing MFA without exceptions; authentication log export proving absence of legacy authentication; configuration evidence of phishing-resistant keys such as FIDO2 or WebAuthn for administrators; a tested out-of-band emergency communication channel | PRO.AU, PRO.CO |
One thing worth knowing before you assemble any of this: screenshots are generally rejected. Assessors treat them as easily manipulated and as lacking fleet-wide context. Valid evidence is a timestamped configuration export in JSON, XML or CSV, a report generated directly by the management platform, or a live demonstration in the console during the assessment.
What an evidence chain actually looks like
Take access control under 21(2)(i). A signed access control policy is not the answer to that question; it is the first of four items. The assessor will ask for the policy that states the rules for privileged access. Then the current export of every account holding administrative access, from the identity environment itself. Then the report of the most recent quarterly access review, with line manager sign-off. Then a sample of people who left in the last three months, matched against the exact deactivation timestamps in the authentication logs, to prove that access was withdrawn within 24 hours as the procedure claims.
Where a document and a configuration disagree, you have a non-conformity. A procedure stating that MFA is mandatory on all systems, sitting next to a configuration export showing that SSH or RDP management ports are reachable with static passwords, produces a serious finding immediately and there is no arguing with it.
The dates that already passed, and the ones ahead
| Obligation | Date | Legal basis |
|---|---|---|
| Registration, digital service providers | 18 December 2024 (passed) | Belgian NIS2 law, Chapter 5; Safeonweb@Work |
| Registration, all other in-scope entities | 18 March 2025 (passed) | Belgian NIS2 law, Art. 14; RD 9 June 2024 |
| Incident: early warning | Within 24 hours of becoming aware of a significant incident | Belgian NIS2 law, Art. 31; Directive Art. 23(4)(a) |
| Incident: formal notification | Within 72 hours | Belgian NIS2 law, Art. 31; Directive Art. 23(4)(b) |
| Incident: interim progress report | On explicit request of the national CSIRT | Belgian NIS2 law, Art. 31; Directive Art. 23(4)(d) |
| Incident: final report | Within one month of the initial notification | Belgian NIS2 law, Art. 31; Directive Art. 23(4)(e) |
| Essential entities submit evidence | 18 April 2026 | CCB enforcement schedule; RD 9 June 2024 Art. 11 |
| Full certification, Essential and Important | 18 April 2027 | BELAC 2-405; CCB transition guidance |
| End of extended remediation periods | 18 April 2028 | CCB implementation note, August 2026 |
Both registration deadlines are behind us. Safeonweb@Work remains permanently open for regularisation, and organisations that missed the date should complete registration immediately rather than wait: failure can be fined between €500 and €125,000, and the CCB has taken a pragmatic line with organisations that come forward before an inspection is opened rather than after. The detail of the reporting stages is in our incident reporting guide.
One scheduling point that is easy to miss: the CyFun 2023 and CyFun 2025 schemes may be applied in parallel until 18 April 2027 under BELAC 2-405. From 19 April 2027 only the 2025 scheme applies. If you are booking an audit now, ask which scheme it will run under.
Sanctions, and what board members are actually exposed to
Administrative fines for essential entities reach €10,000,000 or 2% of total worldwide annual turnover, whichever is higher, with a statutory minimum of €500. For important entities the ceiling is €7,000,000 or 1.4%. These are imposed by the CCB’s sanctions committee on the legal person.
Board members are not personally fined under this regime. What they face is different and, for some, more serious: the competent court can temporarily suspend individuals from exercising management functions where non-compliance is structural and persistent, and shareholders or injured third parties can pursue directors civilly for breach of their statutory duty of care. If you are briefing a board, that is the accurate framing, and it is worth getting right rather than overstating. Our piece on Belgian enforcement covers how the sanctions committee works in practice.
If you opt for inspection by the CCB inspectorate rather than an accredited body, note that the Royal Decree sets a statutory fee of €150 per inspection hour, indexed to November 2023 consumer prices and revised annually on 1 January.
Where mid-market organisations actually fail
Five patterns recur, and none of them are about lacking a policy.
Asset inventory drift. A manually maintained inventory that has fallen behind. The moment an assessor cross-references active IP ranges or cloud tenants against network discovery output, unmanaged virtual servers, forgotten test applications and orphaned device interfaces surface. That is a direct finding under ID.AM, and it is the most common one.
Supplier management without differentiation. Most IT departments have a supplier list. Far fewer have a formal risk classification, signed addenda containing the 24-hour notification clause, and periodic review of supplier security attestations. A list is not a register.
Recovery that has never been tested. Successful backup logs from automated software are not evidence of recovery capability. Assessors want formal restore protocols showing that databases and virtual machines were actually recovered into an isolated environment, with data integrity verified and the stated RTO and RPO validated.
No corrective action register. Organisations run penetration tests and internal audits, and then have nowhere that records the findings, who owns them, when they are due and the documented retest that closed them. Article 21(2)(f) is about the loop, not the test.
Assessor capacity. Only a handful of bodies are accredited in Belgium under the BELAC 2-405 scheme. Organisations that book audit time late risk missing a statutory submission date for reasons entirely outside their control. If your milestone is April 2027, the diary conversation is now.
What a security platform can and cannot evidence
This section matters more than the product section that usually replaces it. No network security architecture, however capable, delivers NIS2 compliance. The line between technical and organisational controls is real and assessors know exactly where it runs.
Technology can supply the operational enforcement and the evidence trail for a specific subset: Article 21(2)(j), by enforcing continuous contextual authentication and removing exposed network ports; Article 21(2)(h), through end-to-end transport encryption and traffic isolation; Article 21(2)(i), through granular dynamic segmentation and role-based access control; and parts of 21(2)(b) and (f), through centralised timestamped logging of session flows and policy violations.
No platform resolves Article 20 and 21(2)(a), which require a formal risk management methodology and a trained, engaged board. None resolves 21(2)(c), which requires business impact analysis and formalised crisis communication structures. None resolves 21(2)(d), which requires legal contracting of supplier clauses and corporate due diligence. And none resolves 21(2)(g), which requires measuring behavioural change across an organisation-wide awareness curriculum.
Read plainly: technology produces the executing evidence for network and access controls. Governance defines and validates the framework that technology operates inside. Jimber sits firmly on the first side of that line, and an honest assessment of what we contribute is four categories of evidence out of ten, not a compliance programme.
The argument that this is oversold
An IT manager who has already been through an ISO 27001 audit will say that most of this is being sold twice, and there is real substance to that.
The ten Article 21 categories map closely onto controls that an ISO 27001 Annex A implementation already covers. The evidence types are largely the same evidence types: access reviews, risk registers, management reviews, corrective action logs. An organisation with a working ISMS has most of this already, and the consultancy market has an obvious interest in presenting NIS2 as a new discipline requiring new projects. Meanwhile the actual regulatory posture for important entities is ex-post: no routine audit, action only where there are grounded indications of failure. Preparing for an inspection that statistically may never come, at the intensity the market recommends, is a real allocation question for a team of three.
Three things make that argument incomplete rather than wrong. The equivalence is not automatic: the CCB requires the Statement of Applicability to mirror the applicable CyFun level, and IT managers who assumed their fresh ISO certificate closed the question have found otherwise. The registration, incident notification and board-training obligations are separate statutory duties that no ISMS discharges. And the ex-post regime describes when you are checked, not what happens then: an assessment triggered by a reported incident is exactly the moment when a missing recovery test or an out-of-date asset register is most expensive. The proportionate reading is not to run a programme, it is to make sure the evidence chain for each of the ten categories can be produced within a week. If you already hold ISO 27001, that is largely a gap analysis rather than a project.
Where to start
Pick the three categories where you are least confident and try to produce the evidence today, as if the assessor were in the room. Not the policy, the export. For most mid-market teams the gaps surface immediately and they are the same three: the asset register does not match reality, no recovery has actually been tested, and the corrective action register does not exist.
Then check two dates. Whether your registration on Safeonweb@Work is complete, and which CyFun scheme your booked audit will run under. If you have not booked, book.
For what the assessment itself feels like on the day, we have written up how CCB conformity assessments run, and the operational IT checklist sits in our guide for IT managers. Running systems past their vendor support date is its own evidence problem, covered in end-of-life systems under NIS2.
If the categories you are weakest on are access control, segmentation, encryption in transit or session logging, that is the part a network platform genuinely evidences. Get in touch and we will walk through which exports we can produce for an assessor, and which four categories those are. For the other six, you need governance work, and we will say so.
Frequently asked questions
What evidence does an assessor ask for in a Belgian NIS2 audit?
Operational evidence: timestamped configuration exports of MFA and least-privilege access, SIEM alert logs, a current asset register, reports of recent recovery and phishing tests, signed supplier contracts with notification clauses, and board minutes approving the risk posture. Policy documents without technical proof produce non-conformities immediately.
Is an ISO 27001 certificate enough for Belgian NIS2 compliance?
Not automatically. The CCB requires the Statement of Applicability to demonstrably cover the controls of the applicable CyberFundamentals level, and the ISMS scope must include every system supporting the regulated service. Registration, management liability and the 24-hour notification duty remain separate statutory obligations regardless.
What is the difference between CyFun Basic, Important and Essential?
They are assurance levels tied to entity classification. Basic and Important are verifications performed under EN ISO/IEC 17029:2019; Essential is a certification under ISO/IEC 17021-1 or EN ISO/IEC 17029. Important entities need Important, essential entities need Essential, and Basic serves suppliers and transitional positions.
Does the CCB audit important entities proactively?
No. Important entities fall under ex-post supervision, so the inspectorate acts only where there are grounded indications of non-compliance, such as a reported significant incident, a supply chain inspection or a formal complaint. Essential entities are supervised ex-ante, with proactive systematic checks.
What are the NIS2 incident reporting deadlines in Belgium?
Three stages to the CCB via Safeonweb: an early warning within 24 hours of becoming aware, flagging suspected malicious intent and cross-border effect; a formal notification within 72 hours with an initial severity assessment and indicators of compromise; and a final report within one month covering root cause and remediation.
What happens if we missed the Safeonweb@Work registration deadline?
The platform stays permanently open for regularisation, so complete it immediately. Failure to register can attract an administrative fine between €500 and €125,000, though the CCB has taken a pragmatic approach with organisations that come forward proactively before an inspection is opened.
Are screenshots acceptable as audit evidence?
Only exceptionally. Assessors generally reject them as easily manipulated and lacking fleet-wide context. Acceptable evidence means timestamped configuration exports in formats such as JSON, XML or CSV, reports generated directly from the management platform, or a live demonstration in the console during the assessment.
Can board members be personally fined under the Belgian NIS2 law?
No. The administrative fines of up to €10,000,000 or €7,000,000 are imposed on the legal person. Directors can face a temporary judicial suspension from exercising management functions where non-compliance is structural and persistent, and can be pursued civilly by shareholders or injured third parties.
Is a penetration test legally required?
It follows from the obligation to cyclically test the effectiveness of risk management measures under Article 21(2)(f) and from vulnerability management under 21(2)(e). Under CyFun Important and Essential, assessors ask for an external penetration test report on publicly reachable interfaces plus a remediation register documenting follow-up.
How do DORA and NIS2 interact for a Belgian financial entity?
DORA takes precedence as lex specialis. Financial entities covered by Regulation (EU) 2022/2554 are exempt under the Law of 26 April 2024 from the risk management, incident notification and supervision obligations in Titles 3, 4 and 5 of the Belgian NIS2 law, and report instead to supervisors such as the NBB or the FSMA.
Can we limit the scope of a CyFun audit to one department?
Yes, provided the limitation is technically and organisationally defensible. Systems placed outside scope must not be able to compromise the integrity or availability of the regulated service. Assessors ask for detailed network segmentation drawings and firewall configurations proving no uncontrolled lateral connections exist.
What does an assessor want to see about backups?
Not backup logs. A business continuity and disaster recovery plan, a configuration export of immutability or WORM object-lock policies, system reports from recovery tests that were actually performed into an isolated environment with data integrity verified, and a topology drawing of the separated backup zone.
