NIS2 Belgium Readiness Checklist for Businesses

Begin with the services the organization provides, its sector, size, establishment in Belgium, and any special scope rules. The Belgian framework generally distinguishes essential and important entities, but exceptions and sector-specific details matter. Record the legal entities considered, the data used for the size calculation, the relevant services, and who approved the conclusion. This creates a defensible scope note and prevents a security program from being built around an assumption nobody can later explain.

Scope can extend beyond one department or one critical application. The CCB explains that the Belgian NIS2 law concerns the entity as a whole, so supporting networks, identities, suppliers, locations, and operational processes may all need attention. If the conclusion is uncertain, resolve that uncertainty early. A short expert review is cheaper than months of work aimed at the wrong boundary.

NIS2 readiness needs visible management involvement. Name an accountable management sponsor, a security coordinator, technical control owners, an incident lead, and a continuity owner. Define who can accept risk, approve emergency action, contact authorities, and communicate with customers or suppliers. These roles can be combined in a smaller company, but the decisions still need named owners and backups.

Create a simple governance rhythm: a monthly risk and action review during implementation, followed by a recurring management review. Track decisions, overdue actions, accepted risks, incidents, training, supplier issues, and evidence gaps. The objective is not meeting volume. It is proving that cyber risk is understood, funded, followed, and corrected.

Use an inventory of systems, cloud services, privileged accounts, business data, locations, and critical suppliers to understand what must be protected. Then compare the current environment with a recognized framework. The CCB provides the CyberFundamentals Framework, built around govern, identify, protect, detect, respond, and recover. Its structured controls make it useful for turning a broad obligation into assigned work and testable evidence.

Rate each control as implemented, partially implemented, not implemented, or not applicable, and record the evidence behind the rating. Avoid treating a policy as proof that a control operates. A backup policy needs recovery tests; an access policy needs account and configuration evidence; an incident plan needs exercises and lessons learned.

A practical program should connect risk analysis, incident management, business continuity, supplier security, secure acquisition and development, vulnerability handling, effectiveness testing, cyber hygiene, cryptography, access control, asset management, and multifactor authentication. These areas reinforce one another. For example, an asset inventory enables vulnerability management; logging supports incident reporting; supplier records support both access reviews and continuity planning.

Start with controls that reduce several risks at once: protect privileged identities with strong MFA, remove unused access, patch internet-facing systems, verify backups through restoration, centralize important logs, define an incident call tree, and document critical suppliers. Each action should have an owner, a validation method, and evidence that can be reproduced later.

The ability to recognize and escalate a significant incident cannot depend on one person noticing an email. Define what employees, suppliers, and technical teams must report; where they report it; who triages it; and how severity is decided. Keep legal, management, technical, communications, privacy, and insurance contacts available outside the affected systems.

Belgian guidance describes staged notification deadlines for significant incidents, including an early warning and subsequent notification. Build an internal timeline that is faster than the external deadline. Record when the incident became known, affected services, business impact, indicators, containment, assumptions, and decisions. Run a tabletop exercise so the team discovers missing contacts and evidence before a real event.

Evidence should show both design and operation. Useful examples include approved policies, asset exports, risk decisions, MFA and Conditional Access settings, privileged-role reviews, patch reports, vulnerability records, restoration results, incident exercises, supplier assessments, security training, management minutes, and remediation tracking. Date the evidence and identify the system and owner it represents.

Keep a control-to-evidence register rather than a folder of unexplained screenshots. For each requirement, link the policy, implementation evidence, latest operational sample, owner, review date, exception, and open action. This saves time during an internal review and exposes controls that look complete on paper but cannot yet be demonstrated.

In days 1 to 30, confirm scope, registration status, governance, critical services, assets, suppliers, and the baseline gap assessment. In days 31 to 60, close high-risk identity and exposure gaps, validate backups, establish incident escalation, and assign longer projects. In days 61 to 90, test the controls, run an incident exercise, review evidence with management, and approve the next improvement cycle.

Readiness is a maintained operating capability, not a one-time badge. Revisit risk after material business, supplier, technology, or threat changes. A compact, honest register of controls and evidence is more valuable than a polished document set that does not match the live environment.