Imagine that on Friday afternoon your IT team discovers that the company servers have been encrypted by ransomware. The attacker is demanding a ransom. Backups are corrupted. Systems are down. What will you do first? Who decides? Who contacts whom? When and how will you notify customers and regulators?
If you do not have written answers to these questions prepared in advance, your company does not have an Incident Response plan. This is a serious problem: not only security-wise but also legally. Surveys consistently show that organisations with a prepared IR plan reduce the average cost of a security incident by more than 50% compared to those without a plan.
Why a plan must be prepared in advance
During a cyber incident, chaos reigns: systems fail, employees are alarmed, management pushes for a quick fix, and customers are calling. In such an environment, there is no time to devise procedures, search for contacts, or debate responsibilities. Every minute of delay extends the outage duration and increases damages.
An IR plan is the fundamental document that defines who does what and in what order, before an incident occurs. It is created calmly, thoughtfully, and tested regularly through exercises (so-called tabletop exercises). Only then does it have value.
NIS2 and the obligation to report incidents
For companies subject to the NIS2 Directive (Cybersecurity Act), an incident response plan also has a regulatory dimension. NIS2 imposes so-called... mandatory reporting obligationA serious cyber incident must be reported. NÚKIB within 24 hours from its discovery (preliminary notification) and a detailed report within 72 hours. Companies processing personal data are additionally obliged to report relevant incidents. ÚOOÚ within 72 hours in accordance with GDPR.
Without an IR plan that establishes these deadlines and procedures, compliance with legal obligations during the chaos of an incident is nearly impossible, carrying the risk of sanctions beyond the damage caused by the attack itself.
Six phases of Incident Response
The standard IR framework (based on the NIST SP 800-61 methodology) defines six phases. The plan must cover all of them.
1. Preparation
The preparatory phase covers all activities carried out before an incident: assembling the IR team and defining roles, creating a contact list (internal team, external forensic specialists, lawyers, insurers, regulators, PR), setting up communication channels in case primary systems fail, purchasing and preparing analysis tools, and conducting regular exercises and plan testing.
Preparation also includes technical measures that prevent incidents or simplify the response: monitoring and logging, backups, EDR/SIEM tools, network segmentation. Preparation is an investment that pays off in a crisis.
2. Identification
Identification means recognising that an incident is occurring or has occurred. Detection sources may vary: alerts from SIEM or EDR, employee reports, notifications from external partners, or unfortunately, notification from the attacker. Key questions at this stage: What exactly is happening? When did it start? Which systems are affected? Is the attack still active?
The result of identification is the initial classification of the incident by severity: from a security event (suspicious activity) through an incident (confirmed breach) to a crisis (failure of critical systems or leakage of sensitive data).
3. Containment
The aim of containment is to stop the spread of an incident and limit damage. Short-term containment involves immediate measures, isolating affected systems, blocking compromised accounts, halting suspicious network communication. Long-term containment then includes switching to backup systems, temporary access restrictions, and preparing the environment for recovery.
During containment, it is crucial to preserve forensic evidence, do not delete logs or shut down machines without consulting a forensic specialist. This evidence will be required for root cause analysis, legal proceedings and regulatory reports.
4. Removal (Eradication)
After containing the incident, the root cause is removed, malware from systems, backdoors left by the attacker, compromised accounts, and exploited vulnerabilities. Eradication must be thorough, incomplete removal means a risk of a repeat incident from the same cause. Part of eradication is analysing how the attacker entered, and patching or reconfiguring what allowed entry.
5. Recovery
Recovery involves restoring systems to operational status from backups, clean installations or forensically verified systems. Restoration is carried out progressively and each system is verified before being reconnected to the network. Post-recovery monitoring is intensified, attackers sometimes return and attempt a repeat attack once they see that systems are back online.
6. Lessons Learned
The final and often most underestimated phase for many companies. Within 2 weeks of the incident, the IR team should conduct a retrospective: what happened, how the attacker gained entry, what worked well, what failed, and how to improve the plan and technical measures. Results are documented and implemented; otherwise, the incident is a missed opportunity for improvement.
What an IR plan must contain
A good IR plan is a living document, not an archived PDF. It must be available even if company systems fail (printed copy, offline storage). Key components:
- IR team and roles: who is on the team, who is the manager, who acts as their representative, and what each person's competencies are.
- Contact list: names, telephone numbers, email addresses, internal and external (forensic firm, lawyers, insurance company, NÚKIB, ÚOOÚ, ČTÚ for telecoms, Police of the Czech Republic).
- Incident Classification and an escalation matrix: who to contact depending on the severity of the issue.
- Procedures for specific types of incidents - ransomware, data breach, DDoS, email compromise, insider threat.
- Communication templates - for internal communication, customers, media and regulators.
- Deadlines for reporting regulators in accordance with NIS2 and GDPR.
- Overview of activities - what runs where, where backups are located, and how they are restored.
If your company does not have an incident response plan or you are unsure whether the existing plan will hold up during a real incident, contact the SecureOn team at secureon.czWe offer the creation of IR plans, tabletop exercises and 24/7 Incident Response support in case an incident actually occurs. More about our incident response services can be found at secureon.cz.