Your IT service provider receives an alert at 2 a.m.: ransomware on the file server. No one knows who to call, who has the authority to take systems offline, or who should inform the customers. By the time someone figures that out, the attacker has had plenty of time to encrypt files and leave a note asking for payment in Bitcoins. You want to prevent this, which is why an incident response plan is essential.
And that’s assuming you even get an alert at 2 a.m.; otherwise, you’re in for an unpleasant surprise in the morning.
Incident response is the process by which an organization detects a security incident, contains or eliminates it, and recovers from the damage. The NCSC describes it as the set of actions taken to "respond quickly, calmly, and adequately to limit damage and minimize recovery efforts." During an incident, this means no panic, but rather a pre-agreed sequence of steps.
An incident response plan (IRP) is the document that outlines those steps: who does what, in what order, and when. Without that document, you are forced to improvise during an incident. And that is exactly the moment when you do not want to be improvising.
Organizations without an IRP generally react more slowly to security incidents and are therefore less prepared for these critical moments.
Every minute spent determining who has the authority to intervene is a minute an attacker spends moving further through your network. The first 60 minutes after discovery are crucial to the outcome of a cyberattack. That hour determines whether an incident remains an isolated issue or affects the entire company.
Who decides to take a server offline? Who calls the customer? Who reports the incident to the Data Protection Authority (AP)? Who has the authority to make specific decisions? Unclear responsibilities mean improvising during the incident. A clear division of roles is therefore essential. To set this up, you can use a RASCI matrix, which defines who has which responsibility in the event of a security incident.
This is not an abstract risk. IBM research shows that the average cost of a data breach is nearly 5 million dollars worldwide. The largest portion of that amount is not in system recovery, but in downtime, legal proceedings, and reputational damage. These types of costs can add up quickly when companies are unprepared and react chaotically to cyberattacks.
Most incident response plans, whether they come from Microsoft or a small Dutch business, can be traced back to the same model: NIST SP 800-61, the Computer Security Incident Handling Guide from the U.S. National Institute of Standards and Technology. NIST distinguishes four main phases (preparation, detection & analysis, containment/eradication/recovery, and post-incident activity). Many practical variants, including the SANS framework, split containment and recovery into separate steps for better guidance. We also use this more detailed structure ourselves:
This phase covers everything an organization does before an incident occurs. This includes securing systems and applications, security awareness training for employees, setting up centralized monitoring, and, of course, drafting an incident response plan. The best thing a company can do is prepare for an incident by practicing it. A table-top exercise is often used for this, where you sit down with key stakeholders and simulate a scenario in which an incident occurs.
Distinguishing signals from noise. This means we must monitor and detect what is important. Once we detect something, it must be analyzed. Not every alert is necessarily a cyberattack. The faster we detect and analyze anomalies, the sooner we can intervene.
Isolating the affected system or compromised user from the company network without impacting the rest. This is often the phase where the most chaos occurs if roles are not clearly defined: someone must have the authority to take a server offline, even if it means a loss of productivity. Speed is essential in this phase to keep the impact as small as possible.
Actually removing the threat. This could involve reinstalling a laptop and restoring accounts and network connections to their previous state. Backups and recovery procedures of any kind are important for this phase. If there are no backups, restoring systems can become a very long and time-consuming task after a cyber incident. In this phase, the acute threat has often passed, and it is also important to look at the root cause of the incident.
This phase is skipped most often, yet it is exactly what can improve your IRP. What went well, what took too much time, which step in the plan didn't match reality? Without this step, you will repeat the same delays and mistakes during the next incident.
A plan on paper solves nothing if no one sees the first signs. That is where Managed Detection and Response (MDR) makes the difference: it covers exactly the phases where the most time is lost.
At Peakproteqt, that happens during and outside office hours. Your environment is monitored continuously, and in the event of a concrete threat, our team intervenes within 10 minutes, not the next morning when someone happens to open a dashboard. In addition, you can also keep an eye on things yourself via our MDR dashboard. During periodic CyberCheck-In meetings, we discuss what happened and whether your plan still aligns with reality. The evaluation phase is baked into the service rather than being an additional task.
