Creating an incident response plan: 6 steps for Flemish SMEs

TL;DR: An incident response plan (IRP) describes in advance who does what in the event of a cyberattack, so that your company responds quickly and in a structured manner rather than improvising in a panic. The six steps of the NIST framework (preparation, detection, analysis, containment, recovery and assessment) form the backbone. Under NIS2, a documented IRP is mandatory for essential and important entities in Belgium.

Imagine this: on Monday morning, your IT manager opens his laptop and sees that all company systems have been encrypted. Customers can’t bill, production is at a standstill, and the phone is ringing incessantly. Who do you call first? Who decides whether to shut down the servers? And how do you report this to the CCB within 24 hours, as required by law?

If you have to think about those answers now, you have a problem. Because an incident response plan is not something you draft during the crisis, but long before. This article explains how, as a Flemish SME, you create a workable plan that protects both your business and your legal obligations.

What is an incident response plan?

An incident response plan is a documented roadmap that describes how your organization will respond to a cybersecurity incident. It defines roles and responsibilities, the steps the team goes through, and communication to internal and external parties.

The crucial difference from reactive action: an IRP is created when there is no crisis. You think clearly, weigh options, and document decisions. Compare it to a fire safety plan: you don’t hang up the evacuation map while the building is already on fire.

Without a written plan, your organization relies on improvisation under stress. That leads to slower response times, more costly damage and greater legal risks. The IBM Cost of a Data Breach Report 2025 shows that organizations that regularly test their incident response plan and deploy a prepared team, on average, contain an incident 80 days faster and report significantly lower recovery costs.

Are you still affected unexpectedly? Then follow our 7-step acute response plan. But the purpose of this article is precisely to prevent that panic.

Why does NIS2 mandate an incident response plan?

The Belgian NIS2 law (law of April 26, 2024) makes a documented incident response plan de facto mandatory for all essential and important entities. Article 21 requires organizations to take “appropriate and proportionate technical, operational and organizational measures,” which explicitly include “incident handling” and “business continuity.”

Without a written plan, you won’t be able to prove in an inspection by the CCB (Center for Cybersecurity Belgium) that you are structurally implementing these processes. And that can be costly: essential entities risk fines of up to 10 million euros or 2% of annual global turnover.

But the obligation goes beyond the plan itself. Article 31 of Belgium’s NIS2 law explicitly places responsibility for cybersecurity measures on the governing body. Directors must attend cybersecurity training and can be held personally liable for gross negligence.

The CCB’s CyberFundamentals (CyFun) framework translates these legal requirements into concrete controls. Starting at the Basic level, standard incident response measures are expected. At the Important level, a formal IRP is required, including regular incident team training and detailed communication procedures.

Learn more about the full scope of NIS2 obligations in our comprehensive guide.

The 6 steps of an effective incident response plan

The NIST Cybersecurity Framework structures incident response in a six-phase cycle. For an SME with 50 to 250 employees, it is essential to translate this framework into a workable reality without losing its core.

Step 1: preparation

Preparation is the foundation of any incident response plan. In this phase, you assemble your Cyber Incident Response Team (CIRT), train employees and implement the basic controls that enable rapid response.

For most SMEs, a full-time security team is not realistic. Therefore, work with a virtual CIRT: designated individuals from IT, HR, legal and management who come together in the event of an incident. Establish who is the team leader and who has the decision-making authority to take systems offline, for example.

Also provide a “jump bag”: a physical or digital folder of essential documents available offline when the network is down. Consider contact lists, network diagrams, vendor contracts, and insurance policies.

And make arrangements in advance with an external incident response partner who can scale up when your own IT capacity falls short. During a crisis, it’s too late to compare suppliers.

Step 2: detection

The sooner you detect an incident, the lesser the damage. This phase is all about recognizing anomalies in your systems: unusual login attempts, suspicious network traffic, unexplained file changes.

For SMBs, Endpoint Detection and Response (EDR) tools are a viable solution. This software monitors all endpoints (laptops, servers, mobile devices) and alerts on suspicious behavior. Also consider a Security Operations Center (SOC) as-a-service if your team cannot guarantee 24/7 monitoring.

A common mistake: logs are not kept long enough. Make sure your log files remain available for at least 90 days so that investigators can reconstruct exactly what happened afterwards.

Step 3: analysis and classification

Not every suspicious signal is a crisis. In this step, your team assesses the severity of the incident and determines the appropriate response.

Use a simple classification system:

• Critical: mission-critical systems affected, data may have been leaked, immediate escalation required
• High: major systems affected but impact limited
• Average: suspicious activity detected, investigation needed but no immediate threat
• Low: false alarm or minimal impact

The classification also determines whether you need to file an NIS2 notification. An incident is “significant” if, among other things, it results in serious operational disruption, financial loss in excess of 250,000 euros, or impact on third parties.

Step 4: containment

Once severity is established, the goal is to limit the damage without destroying evidence. This sounds simple, but in practice this is where organizations make the most mistakes.

Concrete actions on containment:

• Isolate affected systems from the network (unplug the network cable, but do not turn off the computer: working memory contains valuable traces)
• Block compromised accounts
• Change passwords of administrator accounts
• Temporarily disable third-party access

Important: document every action you take. This is not only helpful for recovery, but also mandatory for NIS2 reporting and possible criminal investigations.

Step 5: recovery

After containment, remove the threat completely (wipe malware, close backdoors, patch vulnerabilities) and restore systems from clean backups. After recovery, thoroughly test that the threat has actually disappeared before returning systems to production.

Define two core values in advance:

• Recovery Time Objective (RTO): how many hours or days should it take for a system to be operational again?
• Recovery Point Objective (RPO): how much data loss is acceptable? One hour? One day?

These values determine your backup strategy. Learn more about protecting backups from ransomware in our practical guide.

Step 6: evaluation and improvement

The phase most often skipped but explicitly required by NIS2 and CyFun. After each incident (or exercise), evaluate what went well, what went wrong, and what needs to change.

Compile a “lessons learned” report within two weeks of the incident:

• What was the cause?
• How quickly was it detected?
• Were the lines of communication working?
• Was the contact information up to date?
• Which steps take unnecessary time?

This report becomes the input for an update of your IRP. Thus, every crisis (or exercise) becomes a learning moment that structurally strengthens your resilience.

What should it contain? The essential elements

An effective IRP need not be a hundred-page tome. For an SME, a concise but complete document containing these key elements will suffice:

Contact tree: a list of all internal and external contacts, including replacements. Think of the CIRT members, your IT partner, legal advisor, insurer, and the Belgian hotlines (see below). Keep this list also on paper or on a device not connected to the company network.

Escalation matrix: who escalates to whom, at what classification? The IT manager does not have to call the CEO for a false alarm, but in the event of a ransomware attack, the board must be notified within the hour.

Communication protocol: how do you communicate internally when e-mail and Teams are unusable? What message will go to customers, suppliers and the press? Set up templates in advance so that you don’t have to write texts under pressure in a crisis.

Reporting procedure: the NIS2 deadlines worked out in concrete terms:

• Within 24 hours: early warning to the CCB via Safeonweb@Work
• Within 72 hours: complete incident report with assessment of severity and impact
• Within 1 month: final report with cause analysis and actions taken

In the event of a data breach involving personal data, also report to the GBA (Data Protection Authority) within 72 hours of discovery.

Playbooks by scenario: work out the three to five most likely scenarios for your organization. For most SMBs, these are ransomware, Business Email Compromise (BEC), a data breach through a cloud vendor, and phishing with credential theft.

A cybersecurity audit is an ideal starting point to determine which scenarios are most relevant to your organization.

How do you test your plan? Tabletop exercises

An IRP dusting in a drawer provides false security. Tabletop exercises are the most accessible way to test your plan without hitting production systems.

A tabletop exercise is a guided discussion in which your CIRT goes through a fictional incident. A facilitator outlines a scenario (for example, “It’s Tuesday morning, your accounting software is encrypted and the attacker demands 50,000 euros in Bitcoin”) and gradually brings in new information. The goal is not to give the “right” answer, but to expose holes in the plan.

What specifically are you testing?

• Are the escalation lines working? Is the right person informed at the right time?
• Does the decision maker (e.g., the CEO) have the authority to act quickly, such as taking the Web shop offline?
• What if Microsoft Teams or the central mail server goes down? How do you communicate then?
• Does everyone know the 24-hour deadline for CCB notification?

How often? At least annually, and each time after a significant incident or change in your IT environment. Under CyFun Important, periodic testing of the IRP is an explicit control.

Tip: Alternate scenarios. This year ransomware, next year a BEC attack, the year after a data breach through a vendor. That way you train your team on a variety of threats.

Belgian hotlines: who do you call in the event of a cyber incident?

An incident response plan is worthless if the right phone numbers are not up for grabs. In Belgium, the landscape of incident support is structured around the CCB and police departments.

When to call in the police? For any attack where you suspect a criminal offense (ransomware, fraud, data theft). Reporting is also important for insurance claims. The Computer Crime Units (FCCU and RCCU) specialize in digital trace investigations.

Practical tip from the police: do not turn off infected computers, but unplug the network cable from the wall. That way, you preserve the traces in the working memory (RAM) that are crucial to the investigation.

Frequently asked questions about incident response

How often should I test my incident response plan?

At least once a year via a tabletop exercise. Below CyFun Important level, periodic testing is an explicit control. In addition, always test after an actual incident or after major changes to your IT environment, such as a migration to the cloud or an acquisition.

Who belongs on the incident response team?

An effective CIRT includes at least five roles: a team leader (often the IT manager), a technical specialist, a communications manager, a legal advisor (or DPO), and a board member with decision-making authority. In an SME, employees often combine multiple roles.

Should I report an incident to the CCB?

Yes, if you are an essential or important entity under NIS2 and the incident is “significant.” The law defines criteria such as serious operational disruption, financial loss over 250,000 euros, or impact on third parties. Initial notification (early warning) must be made within 24 hours.

Is preparing an IRP covered by the SME portfolio grant?

Yes. Creating an incident response plan as part of cybersecurity consulting is eligible for the VLAIO SME Portfolio. Small businesses receive a 45% grant, medium-sized businesses 35%. Through the VLAIO Cybersecurity Improvement Program, you can even receive up to 50% subsidy.

What is the difference between an IRP and a business continuity plan?

An IRP focuses on the immediate response to a cybersecurity incident: detection, containment, communication and notification. A Business Continuity Plan (BCP) is broader and describes how your organization will continue to operate during any disruption, including fire, flood or power outage. The IRP is the bridge between detection and activation of the BCP.

How long does it take to create an incident response plan?

For an SME with 50 to 150 employees, a workable IRP is achievable within four to six weeks, including an initial risk assessment and one tabletop exercise. With outside guidance, it can be faster. Keep in mind that the plan is a living document that is updated annually.

Avoid the panic: start today

Setting up an incident response plan is not an administrative burden, but an investment that pays off at the first incident. The combination of NIS2 obligations, rising cyber-attacks on Belgian SMEs, and the personal liability of directors makes procrastination increasingly risky.

Cyberplan helps Flemish SMEs create and test an incident response plan as part of a cybersecurity audit. We translate regulatory requirements into a workable plan that fits your company size and industry.

Want to know how prepared your organization is for a cyber incident? Book a no-obligation consultation and find out where your IRP stands in relation to NIS2 requirements.