Incident response planning: a practical checklist for Belgian businesses

Most organisations discover the gaps in their incident response plan during an incident. That’s a bad time to find out that nobody knows who owns the decision to notify the CCB, that your backup administrator credentials are stored in the system you just encrypted, or that your legal team has never heard of the NIS2 24-hour reporting window.

This post works through what an incident response plan needs to cover, what NIS2 adds to the requirements for Belgian organisations, and a checklist you can use to stress-test what you already have.

What incident response planning is actually for

An IR plan isn’t a document you write to satisfy an auditor. It’s the thing your team reaches for at 2am when the phone rings and the EDR is lighting up.

A plan that lives in a SharePoint folder and hasn’t been tested is not a plan. It’s a liability. When people are stressed and uncertain, they fall back on what they’ve rehearsed. If they haven’t rehearsed anything, they improvise, and improvised incident response is usually slow, disorganised, and expensive.

The goal is a plan short enough that people will actually read it, clear enough that they can follow it under pressure, and tested often enough that the key steps are close to automatic.

The five phases

Most IR frameworks (NIST SP 800-61 is the most widely used reference) organise response into five phases. Your plan needs to address each one.

1. Preparation

Everything you do before an incident happens. This includes:

• Defining your incident classification system (what counts as a P1, P2, P3)
• Maintaining an up-to-date asset inventory so you know what you have
• Establishing and testing your communication tree (who calls whom, on what channel, when)
• Setting up out-of-band communication capability (if your email is compromised, how do you communicate?)
• Ensuring backup administrator credentials exist and are stored somewhere physically separate from production systems
• Running tabletop exercises at least once per year

2. Detection and analysis

How you find out something is happening and determine what it is:

• Centralized log collection with retention sufficient for forensic investigation (minimum 12 months for NIS2-scoped organisations)
• Alert triage process: who receives alerts, how are false positives handled, what triggers escalation
• Initial classification: is this a security incident or an operational issue?
• Scope assessment: what systems are affected, what data may be involved, is the attacker still present?

3. Containment

Stopping the spread before you start cleaning up:

• Short-term containment: isolate affected systems without destroying forensic evidence
• Decision authority: who can authorise isolating a business-critical system? This decision needs an owner before the incident, not during it
• Evidence preservation: take forensic images before reimaging
• Long-term containment: temporary fixes that let you keep operating while you investigate

4. Eradication and recovery

Removing the threat and restoring normal operation:

• Identify and remove all malicious persistence mechanisms (not just the obvious ones — assume the attacker has multiple footholds)
• Patch the initial access vulnerability before reconnecting systems
• Restore from clean backups, not from potentially compromised snapshots
• Verify backups actually work before you need them — this sounds obvious and is routinely skipped
• Staged recovery: bring systems back in order of business priority with monitoring in place

5. Post-incident activity

What you do after the dust settles:

• Timeline reconstruction: what happened, when, in what order
• Root cause analysis: how did the attacker get in, what could have stopped them earlier
• Lessons learned: what changes to controls, processes, or tooling would improve your position
• Report completion (see NIS2 requirements below)

NIS2 requirements for Belgian organisations

Belgium transposed NIS2 through the NIS2 Act of 26 April 2024, with enforcement by the Centre for Cybersecurity Belgium. For essential and important entities, incident response now has mandatory notification requirements that most organisations haven’t fully absorbed.

The three-stage notification process

When a significant incident occurs, NIS2 requires:

Early warning (within 24 hours): Notify the CCB that an incident has occurred. This is a brief notification, not a full report — you’re telling them something is happening and whether you suspect a malicious or cross-border dimension.

Incident notification (within 72 hours): A more detailed notification covering initial assessment, severity, affected systems, and indicators of compromise if available. Similar to GDPR’s 72-hour data breach notification, but broader in scope — it covers any incident affecting the availability, integrity, or confidentiality of network and information systems, not just personal data.

Final report (within one month): A detailed account of the incident, its impact, the root cause, and the measures taken. The CCB may request this sooner for significant incidents.

For incidents that also involve personal data, GDPR notification to the Data Protection Authority runs in parallel.

What “significant” means

Not every incident triggers notification. A significant incident is one that:

• Has caused or can cause severe operational disruption to your services
• Has caused or can cause financial loss to your organisation
• Has affected or can affect other organisations or individuals

In practice, the threshold is lower than many organisations assume. Ransomware affecting business-critical systems, a confirmed data breach, or a successful account compromise with data access are all likely to qualify.

CCB contact

The CCB has a dedicated incident reporting mechanism. Make sure someone in your organisation knows how to reach them before an incident: cert.be is the operational security centre, and CCB’s website provides the formal reporting channels for NIS2 notifications.

The checklist

Use this to identify gaps. A plan that answers “no” or “don’t know” to these items is incomplete.

Preparation

• We have an incident classification system with defined severity levels
• We have an up-to-date asset inventory covering all critical systems
• Our communication tree is documented, tested, and includes personal contact numbers
• We have out-of-band communication capability that doesn’t depend on potentially compromised systems
• Backup administrator credentials are stored offline or in a separate credential vault
• We have run a tabletop exercise in the last 12 months
• Our IR plan has a named owner who is responsible for keeping it current

Detection

• We have centralised log collection with at least 12 months retention
• Someone is responsible for reviewing alerts (either in-house or via managed SOC)
• We have a defined escalation path from alert to declared incident
• Our EDR/XDR coverage is complete (no unmonitored endpoints)

Containment and response

• We have defined decision authority for isolating critical systems
• Our team knows how to preserve forensic evidence before reimaging
• We have tested whether our backups actually restore correctly
• We have a legal contact available for incidents involving data or regulatory implications

NIS2 compliance

• We know which NIS2 tier we fall under (essential or important entity)
• We have a process for determining whether an incident is “significant” within the first few hours
• Someone owns the 24-hour CCB early warning obligation — they know what to send and how
• We have a process for the 72-hour detailed notification
• Our GDPR data breach notification process runs in parallel and is coordinated with NIS2 notification

Post-incident

• We conduct a formal post-incident review after every P1/P2 incident
• Lessons learned result in documented changes to controls or process
• We have a record of past incidents and responses for regulatory and insurance purposes

Testing your plan

A plan that’s never been tested is an estimate. Tabletop exercises are the minimum — a facilitator walks your team through a scenario and the group talks through what they would do. No systems are touched, but the decision points and communication gaps become visible.

More rigorous testing involves simulated incidents with technical components: your SOC receives a realistic alert, your team responds as if it were real, and you see how the process actually flows. This is where you find out that the person who owns the 24-hour CCB notification is on holiday and nobody knows the backup, or that the decision to isolate the production database sits with someone who doesn’t have a work mobile number on file.

Run a tabletop at least annually. Run a more realistic simulation if you can afford to.

Talk to us

TSO provides incident response planning support and tabletop exercise facilitation for Belgian organisations, as well as on-call incident response retainer services. If you need help building or testing your IR plan, or if you want a team you can call when something goes wrong, contact us.