Being prepared when it matters
It is Friday evening, 10 PM. Your phone rings. The IT administrator calls with a shaky voice: "All files on the file server are encrypted. There is a ransom note on every desktop." What now? If you only start thinking about incident response at this moment, you have already lost valuable time. Security incidents do not follow a schedule, and the first hours often determine whether an incident becomes a catastrophe or whether you can keep the situation under control. This topic page gives you everything you need for professional incident management.
Why every company needs an incident response plan
The question is not whether your company will be affected by a security incident, but when. This is not fearmongering — it is a statistical reality. According to the BSI situation report, thousands of companies in Germany are attacked daily, and attacker methods are becoming increasingly sophisticated. An incident response plan defines in advance who takes on which role in an emergency, which communication channels are used, which external parties need to be involved, and how the technical analysis proceeds.
The plan does not need to be 200 pages long. For mid-market companies, a pragmatic document with clear escalation levels, a contact list, defined roles and step-by-step instructions for the most common scenarios is often sufficient. What matters is that the plan exists, that everyone involved knows it, and that it is practiced regularly.
The four phases of incident management
Professional incident management follows a proven four-phase model. In the preparation phase, you establish the organizational and technical prerequisites: assemble a team, prepare tools, define communication channels. The detection and analysis phase begins as soon as anomalies are identified, with the goal of confirming the incident, determining its scope and identifying the cause. In the containment and eradication phase, you isolate affected systems, remove the threat and restore normal operations. The post-incident phase is often the most valuable: here you analyze the incident, document lessons learned and improve your processes for next time.
Reporting obligations: NIS2 and DSGVO (GDPR)
Beyond technical management, many incidents also trigger legal reporting obligations. NIS2 requires an initial report to the BSI within 24 hours of a significant security incident and a detailed follow-up report within 72 hours. The GDPR requires notification to the competent supervisory authority within 72 hours for data breaches that pose a risk to the rights and freedoms of natural persons. Both deadlines start from the moment the incident is discovered, and they can apply simultaneously when both IT security and personal data are affected.
To meet these deadlines, you need prepared reporting forms, clearly defined responsibilities and established communication channels to the relevant authorities. Anyone who searches for the right phone number only during a crisis loses precious time.
Learning from scenarios
Theory alone does not make a good incident response team. That is why we have created a series of scenario articles that walk through real incident types: from the ransomware attack on Friday evening to CEO fraud, data leaks on the darknet, compromised administrator accounts and supply chain attacks. Each scenario describes the typical initial situation, the necessary immediate actions and the path back to normal operations. These articles are excellent material for tabletop exercises with your team.
Forensics and evidence preservation
A common mistake during incident management is destroying evidence before it has been secured. If you simply reinstall a compromised system, all traces of the attack are lost. For subsequent forensic analysis, insurance claims or criminal investigations, you need preserved evidence. Our article on cyber forensics explains the fundamental principles of evidence preservation that you can follow even without a specialized forensics team.
