It will go wrong at some point. A server gets compromised. A data breach. Ransomware. A configuration error that takes production down. Or a DDoS attack that makes your service unreachable. The question is not whether you will ever face an incident, but whether you are ready when it happens.
Most damage from security incidents is not caused by the attack itself. It is caused by the hours and days that follow: uncertainty about who is in charge, wrong decisions under time pressure, uncoordinated communication and measures that escalate an incident instead of containing it.
A good incident response plan is therefore not a luxury for large organisations. It is the practical set of agreements that determine how your organisation responds when something goes wrong.
The four phases of incident response
1. Preparation
Everything you do now determines how quickly you will respond later. Preparation is about three things: people, systems and procedures.
People: who is responsible during an incident? Who makes technical decisions? Who communicates externally, to customers and media? Who informs the board? Document this, including escalation paths if the first person is not available. During an incident at two in the morning, you do not want a debate about who does what and when.
Systems: do you have basic monitoring in place? Logging of relevant systems, alerts for unusual behaviour, access to central log analysis? Make sure your backups are available and tested. Store access credentials and architecture documentation in a secure, offline-accessible location. When you shut down compromised systems, you still want to be able to access that information.
Procedures: write a basic incident response plan. It does not need to be hundreds of pages. An A4 with a decision tree, contacts and checklist is better than an extensive document that nobody ever reads.
2. Detection and analysis
An incident always starts with a signal. Sometimes it is clear: ransomware announces itself. Sometimes it is subtle: unusual network traffic, a user reporting a phishing email, a warning from an external security service.
During detection, two questions are key. First: is this a real incident or a false positive? There is no point in calling your entire crisis team together for a misconfigured monitoring alert. Second: what is the scope? Which systems are involved? Has data been exfiltrated? Is the attacker still active?
Analyse before you intervene. The reflex during an attack is to shut down immediately. That is sometimes right, but if an attacker is still active, shutting down quickly can mean you lose evidence, alert the attacker and are forced to recover without fully understanding what happened.
Document everything. Timestamps, observations, decisions and the reasons for them. This is not just for the legal and compliance process afterwards. It also helps improve your own approach.
3. Containment, eradication and recovery
Containment means: stop the damage. Isolate affected systems from the network. Block malicious IP addresses. Reset compromised accounts. The priority here is to prevent further spread, not to restore availability.
Eradication follows: remove the malware, close the vulnerability that was exploited, remove backdoors the attacker has left behind. Do this thoroughly. A half-hearted cleanup gives attackers the opportunity to regain access.
Recovery is the controlled return to normal operations. This starts with a clean base: a server you know has not been compromised, restored from a verified backup. Test the recovery before allowing production traffic. Monitor intensively in the first days after recovery.
The incident response cycle
💡 NIS2 reporting: initial notification to the regulator within 24 hours, full report within 72 hours. This runs parallel to your containment and recovery phase.
Source: NIST Computer Security Incident Handling Guide (SP 800-61) · NCSC Incident Response Guide
4. Evaluation
After the incident comes the post-mortem. What exactly happened? How could the attack occur? What worked well in the response and what did not? What measures prevent a recurrence?
A good post-mortem is not about assigning blame. The goal is learning. Write down the findings and translate them into concrete actions with an owner and deadline. File the document as a reference for future incidents.
Notification requirements
If your organisation falls under the NIS2 directive (in the Netherlands: the Cybersecurity Act), you have a legal obligation to report significant incidents. The deadlines are strict: 24 hours for the initial notification to the competent authority, 72 hours for the full incident report and one month for the final report.
Outside NIS2, notification requirements may still apply. Data breaches involving personal data must be reported to the Data Protection Authority within 72 hours. If the individuals concerned are at risk themselves (identity theft, financial damage), they must also be informed.
Notification is not an administrative task you can pick up when things are quiet. Build reporting into your incident response plan. Who is responsible for the notification? What information needs to be available? Which contact at the NCSC or DPA do you use?
Communication during an incident
Communication is one of the most underestimated parts of incident response. Poor communication can double the reputational damage of an incident. Good communication can maintain trust even during serious incidents.
Internal communication: make sure the right team knows what is happening, what the status is and who is making which decisions. Do not create panic, but also do not be reassuring when the situation does not warrant it. Facts, not estimates.
External communication: to customers, partners and media. The basic rule: communicate early, communicate honestly and communicate what you are doing to fix the problem. A statement of "we are investigating an incident and will inform you as soon as we know more" is better than silence. Silence leaves room for speculation.
Decide in advance who the spokesperson is. Not everyone involved in the incident needs to talk to customers or journalists. One voice, aligned message.
Minimum incident response checklist
☐ Record timestamp of first detection
☐ Determine scope and affected systems
☐ Secure log files
☐ Determine containment measures
☐ Activate communication plan
☐ Has personal data been leaked?
☐ Notify DPA within 72 hours
☐ Inform affected individuals (if necessary)
☐ NIS2 notification if applicable
☐ Seek legal advice
☐ Root cause identified?
☐ Action items with owner and date
☐ Write incident report
☐ Update incident response plan
☐ Debrief team
Source: NCSC Incident Response Guide · NIST SP 800-61 · GDPR Art. 33/34
What a plan is not
An incident response plan is not a guarantee that everything will go well. Incidents are by definition unexpected and unexpected situations never fit exactly into pre-conceived scenarios.
A plan is a starting point. It provides structure at the moment when pressure is high and people are inclined to make ad hoc decisions. It ensures the basic steps are taken without having to figure them out while the house is on fire.
Practice with it too. Tabletop exercises, where an incident scenario is played through without anything actually happening, quickly reveal where the plan has gaps or is unclear. One exercise per year is better than none. And then you discover the only copy of the plan is stored on the server you just shut down.
The bottom line
Incident response is the discipline that determines how much damage an attack or outage actually causes. Technical measures determine the size of the attack surface. Incident response determines what happens next.
Start with a simple plan. Document who is in charge, how you determine scope, how you isolate and how you communicate. Store it outside the systems you are protecting. Test it at least once a year. And with every incident: document everything and use it to learn.
An organisation that responds well to incidents recovers faster, communicates better and learns from every incident. An organisation without a plan doubles the damage.
Need help setting up your incident response plan? Contact our team.