6 Things Every Incident Response Plan Needs

It was a Tuesday morning in March when a Rotterdam-based logistics firm discovered its file systems were encrypted. By midday, twelve staff members were sitting idle. By the following morning, three key client shipments had been delayed. Three weeks later, they had paid a recovery vendor €80,000 to restore partial access to their data — and they were still explaining the breach to a major client who was reconsidering the relationship.

At no point did the firm lack capable people. What they lacked was a plan.

This story is more common than most Dutch business owners would expect. In 2025, more than 2,100 Dutch organisations were affected by ransomware — a 31% increase on the previous year (Searchlab Cybersecurity Statistics Netherlands, 2026). The average downtime following such an attack is 23 days. And yet, research consistently shows that a significant proportion of Dutch MKB businesses have no documented incident response plan — or have one that has never been tested.

This changed significantly on 15 April 2026, when the Dutch Parliament approved the Cyberbeveiligingswet — the Netherlands’ implementation of the EU NIS2 Directive. The law introduces mandatory incident reporting within 24 hours, cybersecurity risk management requirements, and director-level accountability for security governance. For organisations in scope, an incident response plan is no longer optional. For those outside direct scope, supplier questionnaires from larger clients are making it a practical requirement regardless.

Below are the six things every incident response plan needs — written for IT managers and business owners who want a document that actually works under pressure, not just one that sits in a folder.

When a disruption happens, the first thing that goes wrong is usually not the technical response — it is the human one. In the absence of defined roles, capable people duplicate effort in some areas and miss critical tasks in others. Time that should go into containment goes into figuring out who is supposed to be doing what.

Your incident response plan should answer three questions before an incident happens, not during it:

• Who has decision-making authority during a security incident?
• Who manages internal communication — and to whom does each team member report?
• Who is the designated point of contact for external parties: your IT provider, legal counsel, cyber insurer, and — under NIS2 — the NCSC?

A well-structured plan names specific individuals, not just job titles. It also names backups — because incidents rarely happen when the primary contact is conveniently available. Each named person should have a printed or offline copy of their responsibilities, because incidents frequently affect the systems you would otherwise use to look up that information.

In the middle of an active incident, the last thing your team should be doing is searching email threads for a vendor phone number or trying to remember which account the cyber insurance policy is filed under. Small delays compound quickly. Every minute spent tracking down a contact is a minute not spent on containment.

Your incident response plan should include, in a single location that does not depend on your primary systems being available:

• Internal leadership — named individuals with mobile numbers, not office extensions
• Your IT managed services provider or internal IT lead — with an after-hours contact
• Key software and infrastructure vendors — especially cloud providers, ERP, and backup systems
• Cyber insurance provider — policy number, claims contact, and whether they require incident notification within a specific timeframe
• Legal counsel with data breach experience
• The NCSC Cybersecurity Incident Notification (if you are an essential entity under the Cyberbeveiligingswet)
• Key business partners or clients who may need notification

Keep a physical printed version of this contact list — stored securely off-site or with a trusted person outside the business. A ransomware attack that encrypts your file systems also encrypts any contact list stored on them. Many Dutch companies learned this the hard way.

A common assumption in incident planning is that communication tools will remain available. They often will not. Email may be unavailable if your Exchange or Microsoft 365 environment is affected. Internal messaging tools may be down. Your VoIP system may be unreachable.
Your plan needs to define communication channels that function independently of the systems that might be compromised — and to set expectations for what gets communicated, to whom, and when.

• Define a backup channel: a shared WhatsApp group for key staff, a pre-agreed phone tree, or a designated meeting point for the core team.
• Define who notifies staff — and what they say. Unclear internal messaging during an incident creates rumour and anxiety that makes the situation harder to manage.

• Customer communication: when do clients get notified, and what do they get told? A holding message sent promptly is almost always better than silence.
• Regulatory communication: under AVG (GDPR), a personal data breach must be reported to the Autoriteit Persoonsgegevens within 72 hours of discovery. Under the Cyberbeveiligingswet, essential entities must notify the NCSC of significant incidents within 24 hours. Both clocks start immediately.
• Media and public communication: in most cases, say nothing publicly until legal and leadership have aligned on the message. Define who is authorised to speak externally.

Not all systems carry equal weight. An outage affecting internal HR software is an inconvenience. An outage affecting your payment processing, client-facing portal, or core operational database has immediate financial and reputational consequences.

Your incident response plan should include a documented map of:

• Which systems are essential to your core business operations
• What the acceptable downtime is for each (your Recovery Time Objective, or RTO)
• What data loss is tolerable — how far back can you restore, and what is the cost of restoring versus losing that data (your Recovery Point Objective, or RPO)
• The priority order for restoration if multiple systems are affected simultaneously

This is the section of most incident response plans that is either missing entirely or written in such technical detail that only one person in the organisation can follow it. Both versions fail under pressure.
Recovery procedures need to be specific enough to be actionable and clear enough to be followed by someone who is stressed, working under time pressure, and may not be the usual person in this role.

• Initial containment steps — how to isolate affected systems without destroying evidence needed for investigation
• Who to notify at each stage of the response, and in what order
• Steps for activating backups — including where backup credentials are stored and how restoration is verified
• A clear escalation path: what happens if the initial response does not contain the incident within a defined timeframe
• Documentation requirements: what needs to be logged throughout the incident, and why (evidence preservation for legal and insurance purposes)

Under both AVG and the Cyberbeveiligingswet, organisations may need to demonstrate what happened, when, and how they responded. Real-time logging during an incident is not intuitive — people are focused on fixing the problem, not documenting it. Assign one person specifically to maintain an incident log, even if it is just timestamped notes in a physical notebook.

An incident response plan that has never been tested is a document, not a plan. The gap between the two only becomes visible at the worst possible moment.
Testing serves two purposes. First, it reveals gaps that are not obvious on paper — a contact number that is out of date, a backup restoration process that takes three times longer than estimated, a role description that two people thought they both owned. Second, it builds the kind of muscle memory that lets people respond quickly and calmly when a real incident happens, rather than reading the plan for the first time under pressure.

• A tabletop exercise at least once per year: a structured walkthrough of a simulated incident scenario with the key people named in your plan. No systems need to be touched — just the conversation of “what would we actually do if this happened?”
• A backup restoration test at least twice per year: can you actually restore from your most recent backup, and how long does it take?
• A contact list review every six months: has anyone changed roles, left the business, or changed their mobile number?
• A post-incident review after any real incident, however minor: what worked, what did not, and what needs to change in the plan?

Under the Cyberbeveiligingswet, essential entities are expected to be able to demonstrate that cybersecurity measures — including incident response — are implemented and tested. This means keeping records of your tests, tabletop exercises, and plan reviews. A plan with a revision history and test log is significantly more defensible than one with a creation date of three years ago and no evidence of updates.

A good incident response plan does not prevent incidents. What it does is shorten the window between detection and containment, reduce the cost of recovery, and give your team something to follow when the situation is too stressful for clear thinking.
For Dutch businesses, the urgency has increased. The Cyberbeveiligingswet is now law. NIS2 incident reporting obligations are active. Supplier questionnaires from larger clients are asking directly whether you have documented and tested incident response procedures. The question is no longer whether to have a plan — it is whether yours covers the six things that actually matter when something goes wrong.

Most businesses that have an incident response plan discover gaps the first time they test it. The ones that discover gaps during a real incident pay significantly more to close them.

No technical jargon. No obligation. Just a clear picture of where your plan stands and what, if anything, needs strengthening.