Belgium Software Supply Chain and AI Security Rules: A 90-Day Plan

Belgian organisations that provide essential or important services have been under the Belgian NIS2 law since 18 October 2024. They must register with the Centre for Cybersecurity Belgium (CCB), manage the security of their network and information systems, including their software suppliers, and report significant incidents with an early warning within 24 hours. Essential entities must also prove their measures through a regular conformity assessment, usually against the CCB's CyberFundamentals (CyFun) framework or ISO/IEC 27001, with the formal assessment due by 18 April 2027 according to the CCB. Banks, insurers and other financial firms answer to DORA through the National Bank of Belgium (NBB) and the FSMA, the Data Protection Authority enforces the GDPR, and anyone who sells software or connected products into the EU now has Cyber Resilience Act reporting duties.

This guide is for the CISO, AppSec and engineering leads, GRC, vendor risk and the data protection officer in a Belgian organisation, and for software makers selling into Belgium, including to the EU institutions. It covers each rule as checked in late October 2026, two recent incidents and a 30/60/90-day plan. This is not legal advice; read the texts with your counsel.

Key takeaways

• The Belgian NIS2 law applies since 18 October 2024. It is the law of 26 April 2024 and replaced the 2019 NIS law. The CCB is the national cybersecurity authority and CSIRT.
• Reporting is phased, in line with Article 23 of the NIS2 Directive: an early warning within 24 hours, an incident notification within 72 hours and a final report within one month.
• Essential entities must prove conformity through CyFun, ISO/IEC 27001 or a CCB inspection: a recognised route by 18 April 2026, the formal assessment by 18 April 2027.
• Financial firms follow DORA, applicable since 17 January 2025, with the NBB and the FSMA as the Belgian supervisors depending on the type of firm.
• EU product and AI rules are live. CRA reporting applies from 11 September 2026 and the main CRA obligations, including the SBOM duty, from 11 December 2027. The AI Act became applicable on 2 August 2026, with high-risk rules now due from 2 December 2027 and 2 August 2028.
• EU institutions buy under their own regulation, Regulation (EU, Euratom) 2023/2841, which reaches their suppliers through contracts.
• Safeguard capabilities covered (all GA): SBOM generation and analysis, software composition analysis, vulnerability management with EPSS and KEV, reachability analysis, policies and gates, autonomous remediation (ships switched off), TPRM, CSAF and VEX upload, the compliance and GRC suite with NIS2, DORA and Belgium Data Protection Act frameworks, Trust Center, AI-BOM discovery, Package Firewall, the CLI and local runner, on-prem and air-gapped deployment, and Zero AI mode.

Who this applies to in Belgium

Belgium is an EU member state: EU regulations such as DORA, the GDPR, the CRA and the AI Act apply directly, and the NIS2 Directive applies through Belgian law. The EU institutions in Brussels follow a regulation of their own.

A software company with no Belgian establishment can still be pulled in: through the CRA if it sells products with digital elements in the EU, and through the contract if it supplies a Belgian NIS2 entity or an EU institution.

The rules, regulator by regulator

Status is as checked on 25 and 26 October 2026. Where Belgian law transposes a directive, we quote the directive article, because the numbering differs.

The Belgian NIS2 law: in force since 18 October 2024

The official title is the Law of 26 April 2024 establishing a framework for the cybersecurity of network and information systems of general interest for public security (Wet tot vaststelling van een kader voor de cyberbeveiliging van netwerk- en informatiesystemen van algemeen belang voor de openbare veiligheid / Loi établissant un cadre pour la cybersécurité des réseaux et des systèmes d'information d'intérêt général pour la sécurité publique). The CCB announced its publication in the Belgian Official Gazette on 17 May 2024. It transposes Directive (EU) 2022/2555, the NIS2 Directive, and repeals the Law of 7 April 2019, the first NIS law. It took effect on 18 October 2024, the EU transposition deadline.

What it asks of an entity in scope:

1. Register. Entities in scope register with the CCB through its Safeonweb@work platform. Legal commentary reports that the window for most existing entities closed on 18 March 2025, five months after entry into force, with an earlier date for some digital providers.
2. Govern from the top. Following Article 20 of the Directive, the management body approves the measures, oversees them, can be held liable and must follow training.
3. Take risk-management measures. The Belgian law follows Article 21 of the Directive, which lists ten minimum areas, among them risk analysis and information system security policies (21(2)(a)), incident handling (21(2)(b)), supply chain security including the security aspects of relationships with direct suppliers and service providers (21(2)(d)), and security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure (21(2)(e)).
4. Report significant incidents. Following Article 23 of the Directive, an early warning within 24 hours of becoming aware of a significant incident, an incident notification within 72 hours, and a final report within one month of the notification. In Belgium these go to the CCB as national CSIRT.
5. Accept supervision. Essential entities face supervision before and after an incident, including a mandatory regular conformity assessment. Important entities are supervised after the fact, for example when there is evidence of non-compliance.

Penalties. The Directive sets the ceilings that Belgium applies: for essential entities, administrative fines of at least up to EUR 10 million or 2% of total worldwide annual turnover, whichever is higher; for important entities, at least up to EUR 7 million or 1.4% (Article 34 of the Directive).

Ethical hacking and vulnerability reports. According to the CCB, Articles 22 and 23 of the NIS2 law let any person acting without fraudulent or malicious intent investigate and report vulnerabilities in networks and information systems located in Belgium, provided strict conditions are met, with the report going to the CCB. The CCB says researchers are invited to use an organisation's own disclosure policy first where one exists. If you run systems in Belgium, publish a security contact and a disclosure policy so reporters reach you first.

CyberFundamentals (CyFun): the conformity route

The CyberFundamentals Framework is the CCB's own control framework. It is built on the NIST Cybersecurity Framework structure and mapped to ISO/IEC 27001 and 27002, IEC 62443 and the CIS Controls. It has three assurance levels, Basic, Important and Essential, and the CCB adds a Small starting level for micro organisations. The CCB's guidance describes a selection tool that points an organisation to a level based on factors such as size, sector and exposure.

The Royal Decree of 9 June 2024 implementing the law designates the CCB as national cybersecurity authority and national CSIRT and sets the conformity assessment procedures, mandatory for essential entities and optional for others. The CCB describes three routes:

The dates, as the CCB has communicated them:

• 18 April 2026. Essential entities had to show they were implementing risk-management measures and following a recognised route. For CyFun that meant holding, or actively pursuing, at least a Basic or Important verification, or a signed agreement with an accredited body. Entities on the ISO/IEC 27001 route had to supply their scope, Statement of Applicability and latest internal audit report.
• 18 April 2027. The formal conformity assessment for essential entities: CyFun at the Essential level, or full ISO/IEC 27001 certification with the right scope.

Important entities are not required to undergo the periodic assessment, but they may opt in, and their risk-management duty is the same in substance. Ireland's NCSC is careful to say that CyFun alone does not prove NIS2 compliance; the supervisor decides. If you sell into Belgium, expect customers to ask for your CyFun level or ISO/IEC 27001 scope on security questionnaires.

Financial sector: DORA with the NBB and the FSMA

The Digital Operational Resilience Act, Regulation (EU) 2022/2554, has applied since 17 January 2025. In Belgium the NBB is the competent authority for the firms under its prudential supervision, such as banks and insurers, and the FSMA for the firms under its own supervision.

For software, the articles that matter:

• Article 8: identify and classify ICT assets and map their dependencies, including on ICT third-party service providers.
• Article 9: protection and prevention, including patching and change management.
• Articles 17 to 19: ICT incident management, classification and reporting of major ICT-related incidents. Delegated Regulation (EU) 2025/301 sets the clock: an initial notification within four hours of classifying an incident as major and no later than 24 hours after becoming aware of it, an intermediate report within 72 hours of the initial notification, and a final report within one month of the latest intermediate report.
• Articles 24 to 27: resilience testing, including threat-led penetration testing for designated firms.
• Article 28: ICT third-party risk as part of the ICT risk framework, including the register of information on all contractual arrangements for ICT services (Article 28(3)), which the firm must make available to its competent authority.
• Article 30: key contractual provisions for ICT services, with extra terms for services that support critical or important functions.

NIS2 treats DORA as the more specific act for financial entities (Article 4 of the Directive), so a DORA firm meets its ICT risk and reporting duties through DORA, not twice.

Data protection: the GDPR and the Data Protection Authority

The GDPR applies directly. Belgium's Law of 30 July 2018 fills in the national parts, and the Data Protection Authority, set up by the Law of 3 December 2017, supervises. For software teams the articles to know are Article 25 (data protection by design and by default), Article 28 (processors must give sufficient guarantees), Article 30 (records of processing), Article 32 (security of processing) and Article 33 (notify the authority of a personal data breach without undue delay and, where feasible, within 72 hours). Transfers outside the EEA follow Chapter V of the GDPR.

Makers of products with digital elements: the EU Cyber Resilience Act

The CRA, Regulation (EU) 2024/2847, entered into force on 10 December 2024. According to the European Commission, reporting obligations apply from 11 September 2026 and the main obligations from 11 December 2027. Since 11 September 2026, a manufacturer must report an actively exploited vulnerability or a severe incident affecting its product through the single reporting platform, with an early warning within 24 hours. From December 2027, manufacturers must meet the essential cybersecurity requirements in Annex I, which include handling vulnerabilities for the support period and drawing up an SBOM covering at least the top-level dependencies of the product.

AI: the EU AI Act

The AI Act, Regulation (EU) 2024/1689, entered into force on 1 August 2024. According to the Commission's timeline, prohibited practices and AI literacy duties have applied since 2 February 2025, the rules for general-purpose AI models since 2 August 2025, and the Act became generally applicable on 2 August 2026, when the AI Office and Member State authorities took on supervision and enforcement and the transparency rules began to apply. The AI Omnibus, adopted as a proposal on 19 November 2025, agreed on 7 May 2026 and in force since 27 July 2026, moved the high-risk rules: systems used in the Annex III areas such as critical infrastructure, education, employment and migration from 2 December 2027, and AI integrated into regulated products from 2 August 2028.

For a Belgian deployer, start with an AI inventory, a prohibited practice screen and an AI literacy record. We could not confirm on a primary source which Belgian authorities have been designated to supervise the AI Act, so check the federal government's announcements before you name one in your own documents.

EU institutions as buyers: Regulation (EU, Euratom) 2023/2841

Many software sellers in Belgium have an EU institution, body or agency as a customer. Those Union entities follow Regulation (EU, Euratom) 2023/2841, which sets a high common level of cybersecurity across them. According to the European Parliament's summary of the act, each Union entity must run an initial cybersecurity review, set up an internal cybersecurity risk-management, governance and control framework reviewed at least every four years, appoint a local cybersecurity officer, and adopt a cybersecurity plan within 24 months of entry into force. Significant incidents go to CERT-EU: an early warning within 24 hours of becoming aware, an incident notification within 72 hours and a final report no later than one month after the notification. The Interinstitutional Cybersecurity Board oversees implementation.

The regulation binds the institutions, not their suppliers directly. Its effect on a supplier arrives through the tender and the contract: security questionnaires, incident notice clauses short enough to let the institution meet its 24-hour clock, and requests for component lists and vulnerability handling evidence.

What the rules ask of software and open source

Every regime above asks the same six things of the software you build and buy.

Know what software you run and ship

NIS2 Article 21(2)(a) presumes a risk analysis, which you cannot do without an inventory. CyFun's identify function starts with inventories of physical devices, software platforms and applications. DORA Article 8 asks financial entities to identify and classify ICT assets and their dependencies. The CRA requires an SBOM from manufacturers from December 2027. A per-product SBOM, regenerated on each build, covers all four.

Handle vulnerabilities on a clock

NIS2 Article 21(2)(e) names vulnerability handling and disclosure. CyFun includes vulnerability management and patching controls. DORA Article 9 covers patching. The CRA requires manufacturers to remediate vulnerabilities without delay for the support period. None of these texts sets a universal patch deadline; you set one, write it down, and show you meet it.

Manage software and ICT suppliers

NIS2 Article 21(2)(d) and 21(3) ask entities to consider the vulnerabilities specific to each direct supplier and the overall quality of their products and secure development practices. DORA Articles 28 to 30 turn this into a register and mandatory contract terms. The EU institutions' regulation does the same for Union entities. Open source maintainers are not contracted suppliers, but their code is in your products, so your own inventory and fix process is the control.

Report incidents fast

One incident can trigger several of these at once, so run them from one runbook.

Build software securely

NIS2 Article 21(2)(e) covers acquisition, development and maintenance. CyFun includes secure development and change management controls. The CRA's Annex I lists secure by design requirements such as no known exploitable vulnerabilities at release and secure default configuration.

Data residency, transfers and AI

None of the Belgian cybersecurity laws requires data to stay in Belgium. The GDPR governs transfers outside the EEA under Chapter V. Some buyers, especially in government, defence and finance, set their own residency or no-cloud rules by contract or policy, and an EU institution may require processing in the EU. AI rules add duties on what systems you use and how, not where they run.

Requirement to evidence map

Real public incidents in or affecting Belgium

Two recent incidents show the supplier side of the rules. We describe only what the organisations and authorities said publicly.

Check-in and boarding systems at Brussels Airport (September 2025)

On the night of Friday 19 September 2025, a cyberattack on the service provider for check-in and boarding systems disrupted several European airports. Brussels Airport said in statements carried by news agencies that weekend that the attack hit that provider and that it was running check-in and boarding manually. The provider's parent company, RTX, told the US Securities and Exchange Commission in a Form 8-K filed on 24 September 2025 that it had become aware on 19 September of a product cybersecurity incident involving ransomware on systems that support its MUSE passenger processing software, which lets several airlines share check-in and gate resources. The filing says these airport systems sit outside the RTX enterprise network on customer-specific networks, that customers shifted to backup or manual processes with some delays and cancellations, and that RTX notified law enforcement and government agencies.

The point for a Belgian NIS2 entity is where the dependency sits: a supplier ran the affected software, which is exactly the relationship NIS2 Article 21(2)(d) asks entities to manage.

Customer data accessed at a Belgian telecoms operator (July and August 2025)

Orange Belgium said on 20 August 2025 that it had detected a cyberattack on one of its IT systems at the end of July, which gave unauthorised access to certain data from 850,000 customer accounts: surname, first name, telephone number, SIM card number, PUK code and tariff plan. The company said no passwords, email addresses or bank and financial details were compromised, that its teams blocked access to the system and tightened security, that it alerted the competent authorities and filed a complaint with the judicial authorities, and it advised affected customers to stay alert to suspicious messages.

A breach like this at a provider of electronic communications can engage both NIS2 and the GDPR Article 33 clock.

The personas who own the problem

CISO

The CISO owns the NIS2 risk-management measures and the conformity route. What they need right now is a credible path to 18 April 2027 if the organisation is essential, and a reportable view of supplier and software risk for the management body, whose members can be held liable. A bad week is a vendor incident nobody can map to systems within hours.

Head of AppSec, product security or VP Engineering

This person owns secure development and vulnerability handling. They need SBOMs per product, a written fix timeline and CI checks that enforce it, and for EU products, CRA reporting live since 11 September 2026. Triggers: a customer's CyFun questionnaire or an actively exploited vulnerability.

GRC and compliance lead

GRC owns the mapping from CyFun or ISO/IEC 27001 controls to dated evidence, the assessment with the accredited body and, in financial firms, the DORA register of information. Triggers: the assessment date and supervisor requests.

Procurement and vendor risk owner

Vendor risk owns supplier intake, contract terms and monitoring under NIS2 Article 21(2)(d) and DORA Articles 28 to 30. They need suppliers ranked by criticality, incident notice and component transparency clauses, and alerts when a supplier's product picks up a critical vulnerability. Triggers: renewals and supplier incidents.

Data protection officer

The DPO owns the GDPR Article 33 clock and the record of processing, and needs to know fast whether an incident touches personal data. Triggers: a breach, a complaint or a new AI system.

Step by step: a 30/60/90-day plan that works with or without Safeguard

This plan assumes you are in scope of the Belgian NIS2 law, possibly also DORA or the CRA. Skip what does not apply.

Days 1 to 30: scope, register and inventory

1. Confirm scope and class in writing. Record your sector, size, class and why, and whether DORA, the CRA or an EU institution contract applies.
2. Confirm registration. Check your Safeonweb@work registration is complete and current and keep the confirmation.
3. Pick or confirm your conformity route. Essential entities: confirm the CyFun or ISO/IEC 27001 route and the accredited body, and check the contract covers an assessment before 18 April 2027. Important entities: run the CyFun risk assessment tool to choose a target level even if you do not plan an assessment.
4. Build the software inventory. Generate an SBOM for each product or system you build, starting with internet-facing and critical systems. For the software you buy, list supplier, product, version and where it runs.
5. List suppliers by impact and whether a breach there would trigger your own report.
6. Brief the management body and schedule approval of the measures.

Days 31 to 60: controls, contracts and the drill

1. Map controls. Map your measures to your CyFun level or to ISO/IEC 27001 Annex A. Financial entities add DORA Articles 5 to 30.
2. Set vulnerability timelines. Write down how fast you fix critical and high findings in internet-facing and critical systems, how you use exploit signals such as CISA KEV and EPSS, and who approves exceptions.
3. Add CI checks. Fail builds on known critical vulnerabilities in new dependencies and on licences you cannot use.
4. Update supplier contracts. At renewal, add incident notice inside your own clock, a right to receive an SBOM or component list, and vulnerability disclosure terms. Financial entities check the DORA Article 30 list.
5. Run a tabletop. Use a scenario like the airport case above: a supplier's system you depend on is hit by ransomware. Time how long it takes to say what you depend on, which versions, and whether to file the 24-hour early warning.
6. Makers: test CRA reporting. Walk through a mock actively exploited vulnerability report from intake to the 24-hour early warning.

Days 61 to 90: evidence, monitoring and review

1. Collect evidence per control. For each mapped control, store the artefact the assessor will ask for: policy, inventory, scan result, ticket or minutes, with a date.
2. Monitor continuously. Re-scan inventories on every build and on new advisories, not once a quarter.
3. Run a pre-assessment. Ask the accredited body or an internal team to walk the controls for your CyFun level and record the gaps.
4. Close the management loop. Get the measures approved and record the management body's training.
5. Review AI use. List AI systems in use, screen them against the prohibited practices, record AI literacy measures, and flag any Annex III area use ahead of 2 December 2027.
6. Set the next review. Put the conformity assessment, management review, internal audit and any DORA register cycle on one calendar.

Template: NIS2 supplier clause checklist

Use this at contract renewal. It is a checklist, not contract language; your counsel drafts the clause.

Checklist: the first hour after a supplier or product incident

1. Identify the product or supplier and confirm the advisory or notice.
2. Query your inventory for every system running the product or component, with versions.
3. Mark internet-facing and critical systems.
4. Decide whether the incident may be significant under the NIS2 law.
5. If yes or unsure, prepare the 24-hour early warning to the CCB (DORA entities follow the DORA clock).
6. Check whether personal data is involved for the GDPR 72-hour clock.
7. Record who decided what, and when.

What changes for a foreign software maker selling into Belgium?

The CRA applies to you directly. The Belgian NIS2 law and Regulation 2023/2841 reach you through your customers: expect CyFun questions, SBOM requests and incident notice terms. Managed ICT, cloud and data centre providers should check whether they are entities in their own right.

How Safeguard does this

Safeguard keeps the inventory, supplier requests, gates, fixes and evidence in one place. Commands and YAML below are copied from docs.safeguard.sh as checked in October 2026 and were not run for this post.

1. Inventory the software you build. SBOM generation and analysis (GA) and software composition analysis (GA) produce an SBOM per project across the full transitive dependency tree, in CycloneDX or SPDX. This is the software part of the NIS2 risk analysis and the CyFun asset inventory.

2. Scan where code cannot leave your environment. The Safeguard CLI (GA) includes a local runner (GA) that scans on your own machine and sends only encrypted results. Install and sign in as the docs show:

# macOS and Linux
curl -fsSL https://cli.safeguard.sh/install | bash
safeguard

Then type /login and approve the session in your browser. For a one-off scan of a directory or an existing SBOM:

safeguard scan --dir .
safeguard scan --sbom sbom.json

3. Validate supplier SBOMs. The CLI checks SBOMs against their specifications:

safeguard validate sbom.json --strict -o report.json

4. Run supplier intake in TPRM. In TPRM (GA), add suppliers and request SBOMs. From a vendor, click Request SBOM, select products, set a deadline and send. The docs describe status tracking through to Validated or Rejected and automatic reminders, the first one 7 days before the deadline. Risk assessment scores suppliers from their SBOM analysis, and monitoring flags new vulnerability disclosures across suppliers. For a DORA firm this feeds, but does not replace, the register of information.

5. Load supplier advisories. With CSAF and VEX upload (GA), a supplier's "not affected" statement sits next to the findings for that product version.

6. Map to the EU and Belgian frameworks. The compliance and GRC suite (GA) includes framework pages for EU NIS2, EU DORA and the Belgium Data Protection Act 2018. Each scan of a product checks the framework's scan requirements against what the scan found, including the SBOM. For NIS2 the docs list supply chain security under Article 21(2)(d), vulnerability handling under Article 21(2)(e), the risk analysis inventory under Article 21(2)(a) and incident reporting readiness under Article 23. For the Belgian data protection framework they list requirements tied to GDPR Articles 25, 28, 30, 32, 33 and 5(1)(f) as given effect by the Law of 30 July 2018. The requirement IDs on those pages are Safeguard's own labels, not the regulator's numbering. The NIS2 page also lists policy templates written for NIS2. The docs list no framework page for CyFun by name, so map CyFun controls to the NIS2 evidence yourself.

7. Gate what you ship. With policies and gates (GA), create policies on conditions such as vulnerability severity, CVSS, EPSS or licence. The docs define three actions: Block (the gate fails), Warn (the gate passes with a warning naming the policy) and Notify (the gate passes and a notification is sent). Legitimate exceptions go through the exception workflow with approval. In GitHub Actions, the docs show:

name: Safeguard
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - name: Safeguard scan
        env:
          SAFEGUARD_API_KEY: ${{ secrets.SAFEGUARD_API_KEY }}
          SAFEGUARD_INSTALL_DIR: ${{ runner.temp }}/safeguard-bin
        run: |
          set -eu
          curl -fsSL https://cli.safeguard.sh/install | bash
          "$SAFEGUARD_INSTALL_DIR/safeguard" ci scan --wait --fail-on critical

The docs add that --fail-on-gate all fails the job on a policy gate instead of a severity threshold.

8. Stop risky packages at install time. Package Firewall (GA) is an install-time proxy for npm and pip that blocks malicious, typosquatted and dependency-confusion packages before they reach a developer machine or build.

9. Rank by real exposure. Vulnerability management (GA) adds EPSS and CISA KEV, and reachability analysis (GA) labels findings reachable, conditionally reachable, unreachable or unknown.

10. Fix with pull requests. Autonomous remediation (GA) uses Griffin to open tested, policy gated pull requests that move a vulnerable dependency to a fixed version, one repository at a time or in bulk. It ships switched off, with every category set to Manual, so nothing changes until your team turns it on.

11. Inventory AI. AI-BOM discovery (GA) inventories AI assets, the starting list for AI Act work.

12. Answer customer questionnaires. Trust Center (GA) publishes a page you manage in Compliance, Trust Center, where you share security documents with customers; nothing goes live until you publish it.

13. Choose where it runs. SaaS runs in US, EU and Gov regions. For residency or a no-code-leaves policy, the options are private VPC or dedicated tenancy, full on-prem, fully air-gapped with the AI models inside your environment, the local runner (source code never leaves your machine; only encrypted results are sent) and Zero AI mode (GA), with no LLM in the loop.

Safeguard becomes one of your suppliers once you adopt it, so assess it under the same procedures. Safeguard is designed for FedRAMP High, and its SOC 2 Type II audit is in progress. Safeguard holds no Belgian or EU certification or assessment for these regimes, including CyFun; it helps you produce and keep the evidence they ask for.

What Safeguard does not do

• It does not decide whether you are in scope or whether an incident is significant. Scope under the NIS2 law and significance of an incident are your own assessment. Safeguard gives you the inventory to decide fast; the decision and the report are yours.
• It does not file reports for you. Early warnings go to the CCB, DORA reports to the NBB or the FSMA, CRA reports through the single reporting platform, GDPR notifications to the Data Protection Authority, and Union entity reports to CERT-EU. You file them.
• It does not certify you. There is no CyFun verification, ISO/IEC 27001 certificate or NIS2 attestation from Safeguard. Those come from BELAC accredited bodies or the CCB's inspection, and supervisors judge DORA compliance.
• It does not cover organisational and physical controls in CyFun and ISO/IEC 27001, such as HR security and physical access.
• It does not fix vendor systems or hosted services. When the vulnerable code sits in a service a supplier runs, as in the airport case, the fix comes from that supplier. Safeguard helps you know where you depend on it.
• It does not offer an in-country Belgian SaaS region. SaaS regions are US, EU and Gov. For stricter residency needs use private VPC, on-prem, air-gapped, the local runner or Zero AI mode. Safeguard's EU region is in Frankfurt, Germany, so data stays in the EU.

Common mistakes

• Treating 18 April 2027 as the start date. The CCB expected essential entities to be on a recognised route by 18 April 2026. A late start leaves no time to fix findings before the formal assessment.
• Building three incident runbooks. One runbook with the strictest clock (4 hours for DORA firms, 24 hours otherwise) and a branch per recipient beats separate processes for the CCB, the NBB and the Data Protection Authority.
• Assuming important entities can ignore CyFun. The periodic assessment is not mandatory for them, but the risk-management duty is, and customers ask for the level.
• Assuming the CRA starts in 2027. Reporting has applied since 11 September 2026.

FAQ

When did the Belgian NIS2 law take effect?

The Law of 26 April 2024 was published in the Belgian Official Gazette on 17 May 2024 and took effect on 18 October 2024. It transposes the NIS2 Directive and replaced the 2019 NIS law.

What is the incident reporting deadline under the Belgian NIS2 law?

An early warning within 24 hours of becoming aware of a significant incident, an incident notification within 72 hours and a final report within one month, sent to the CCB as national CSIRT.

What is CyberFundamentals (CyFun)?

The CCB's control framework, built on the NIST Cybersecurity Framework structure and mapped to ISO/IEC 27001, IEC 62443 and the CIS Controls, with Basic, Important and Essential assurance levels. Essential entities can use it to meet their conformity assessment duty.

When is the CyFun deadline for essential entities?

The CCB set 18 April 2026 as the date by which essential entities had to show a recognised route, and 18 April 2027 for the formal conformity assessment at the Essential level or full ISO/IEC 27001 certification.

Do Belgian banks report incidents to the NBB or the CCB?

Financial entities under DORA report major ICT-related incidents to their competent authority, the NBB or the FSMA, under DORA's own clock. NIS2 treats DORA as the more specific act for them.

Does Belgium require SBOMs?

No Belgian law requires an SBOM by name. The CRA requires manufacturers to draw up one from 11 December 2027, and NIS2 supply chain duties, CyFun inventory controls and DORA asset identification all lead buyers to ask for one.

Who supervises data protection in Belgium?

The Data Protection Authority (Gegevensbeschermingsautoriteit / Autorité de protection des données), under the GDPR, the Law of 3 December 2017 that created it and the Law of 30 July 2018.

Does Safeguard have a Belgian data centre?

No. SaaS runs in US, EU and Gov regions. Safeguard's EU region is in Frankfurt, Germany, so data stays in the EU. For residency, use private VPC, on-prem or air-gapped deployment, the local runner or Zero AI mode.

Most of the plan above comes down to two things: knowing which software and components you run, and closing the gap between a published fix and the fix running in production. The block below describes how Safeguard closes that gap for the open source you build on, which is also where an assessor's question about vulnerability handling usually lands.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo shows the local runner: you set it up on your own machine, approve it with its device code, then scan from the terminal. For a Belgian hospital, bank or public body with a policy against granting a cloud service repository access, this is the route to an SBOM and findings for its critical systems.

Click through it at your own pace, or open it full screen.

The second demo is a real CLI session: asked to fix the lodash CVE in a repository, it reads the finding and advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, prints a summary and pushes nothing. The same flow fits the vulnerability timelines you set in days 31 to 60 of the plan.

Click through it at your own pace, or open it full screen.

Quick check

Related reading

• NIS2 supply chain evidence for EU operators
• DORA for financial services: third-party ICT risk
• CRA Article 14 vulnerability reporting
• EU Cyber Resilience Act SBOM obligations
• France software supply chain and AI security rules: a 90-day plan

Sources

• CCB, NIS2: 18 April 2026 deadline, what essential entities must have in place (read through search extracts; the CCB site blocked direct fetches)
• CCB, The NIS2 law (read through search extracts)
• CCB, Adoption of the NIS2 Royal Decree (read through search extracts)
• CCB, Publication of the NIS2 law in the Belgian Official Journal (read through search extracts)
• CCB, Legal framework for reporting vulnerabilities (read through search extracts)
• CCB CyberFundamentals guide, levels and key measures (read through search extracts)
• NCSC Ireland, CyFun FAQ
• FSMA, Digital Operational Resilience Act
• Belgian Data Protection Authority
• European Parliament Legislative Observatory, summary of Regulation (EU, Euratom) 2023/2841
• European Commission, AI Act regulatory framework and timeline
• European Commission, Cyber Resilience Act
• RTX Corporation, Form 8-K filed 24 September 2025
• Connecticut Public (AP), Cyberattack disrupts check-in systems at major European airports (20 September 2025)
• Orange Belgium, Orange Belgium informs its customers about a cyberattack (20 August 2025)
• Safeguard docs, EU NIS2 Directive framework
• Safeguard docs, Belgium Data Protection Act 2018 framework
• Safeguard docs, EU DORA framework
• Safeguard docs, Safeguard CLI
• Safeguard docs, CLI usage
• Safeguard docs, GitHub Actions
• Safeguard docs, Policies and Gates
• Safeguard docs, TPRM SBOM Requests
• Safeguard docs, Generate SBOM
• Safeguard docs, CSAF/VEX Upload
• Safeguard docs, Reachability Analysis
• Safeguard docs, AI Remediate
• Safeguard docs, Package Firewall
• Safeguard docs, Trust Center
• Safeguard docs, Air-Gapped Deployment

Start with the free tier at safeguard.sh/download and read the Safeguard docs.

Last reviewed: 25 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.