.webp)
A cyberattack is no longer a question of if – it is a question of when. Yet many organizations still have no documented plan for what to do when it happens. That is an expensive mistake that organizations rarely see coming until it is too late.
Why do you need a plan?
Without a plan, decisions get made under pressure by people who do not know what to do, in what order, or who to call. The data backs this up: the average time to detect a breach runs to several months, and the cost of an incident without structured response is significantly higher than for organizations that have a working plan in place.
NIS2 also requires documented incident response procedures for essential and important entities. An undocumented process is not enough – the directive requires that the plan is documented, communicated to the right people, and actually holds up under pressure. The reporting obligations within 24 and 72 hours are impossible to meet without the process already in place.
What should the plan cover?
An incident response plan that works in a real crisis needs to address the following:
- Scope and incident definition. What counts as an incident in your organization? Without a clear definition, no one knows when to activate the plan. Define what is required for an event to be classified as an incident, and set criteria for different severity levels.
- Roles and contact details. Who does what when the alarm goes off? The incident manager, technical team, legal counsel, communications lead, and leadership should all be named with up-to-date contact details. And make sure the list is kept current.
- Communications plan. How do you communicate internally during an incident? What do you say to customers, suppliers, and potentially the media? Who has the authority to speak externally?
- Technical runbooks. Step-by-step instructions for the most common incident types: ransomware, data breach, DDoS, account compromise. Anyone on the team should be able to follow the instructions in the runbook under pressure, not just the person who wrote them.
- Reporting requirements. Which authorities need to be contacted, when, and with what information? NIS2, GDPR, and any sector-specific requirements should be mapped out with deadlines.
- Recovery procedures. How do you restore systems and data? From which backups? In what order are systems reconnected? Who signs off that a system is clean enough to bring back online?
- Lessons learned process. What happens after the incident? How do you document what you learned, update the plan, and make sure the same vulnerability cannot be exploited again?
Read our guide: How incident management works — step by step
Download our template
We have developed an incident response plan template designed for organizations subject to NIS2 and GDPR requirements. The template covers all the core components above and is structured to be adapted regardless of whether you are a smaller company or a large organization with complex infrastructure.
It includes instructions for each section, example wording, and a checklist to make sure nothing has been missed.
How to adapt the template to your organization
A template gives you the structure, but it needs to be adapted to your actual environment, your systems, and your roles.
- Industry and regulatory requirements. Financial services, healthcare, and public sector organizations face specific requirements beyond NIS2 and GDPR. Identify which regulations apply to you and make sure your reporting procedures reflect them.
- Company size and structure. In smaller organizations, the same person often carries multiple roles. That is fine, but the plan needs to reflect it. Who is the backup if the incident manager is the one affected or unavailable?
- Technical environment. On-premises and cloud environments are handled differently during an incident. Contact details for cloud providers, incident support SLAs, and procedures for locking accounts in external services all need to be documented.
- Critical systems. Which systems are business-critical? Which processes stop if they go down? The recovery priority order needs to be explicit – it should not need to be debated in the middle of an incident.
Test the plan regularly – tabletop exercises
An untested plan is not a plan. It is a document. Most organizations that have an incident response plan have never run through it. That means the first time the plan is used for real is during an actual crisis.
A tabletop exercise is a structured scenario walkthrough where the incident team works through a realistic attack scenario without any actual systems being affected. You test communication channels, decision-making processes, and technical procedures – and identify the gaps before an attacker does.
If you want to go further, red teaming is the most realistic way to test whether your plan actually holds up. Cyloq runs red team exercises based on real-world attack patterns – ransomware, supply chain attacks, insider threats, and targeted intrusions – where systems are put under genuine pressure. That gives you a far more realistic basis for improving both your technical security and your incident response readiness.
The recommended frequency is at least once a year, and always after significant changes to your organization or infrastructure.
Integrate the plan with your SOC or MSSP
If you have an external SOC or MSSP, your incident response plan needs to be coordinated with them – otherwise you risk running parallel processes that do not talk to each other.
Document escalation paths clearly. When should the SOC escalate to you internally? Who makes the call on isolating systems – you or the provider? What authority do they have to act without waiting for your approval?
The division of responsibilities must be agreed in writing, in advance. Assuming it is "understood" is not enough. During an active incident, there is no time to work out who does what.
Make sure your SOC has up-to-date contact details for your internal roles – and vice versa.
Read more: How incident management works
Download the template or book a meeting
Need help implementing the plan, or want a team that actually shows up when something happens? Cyloq's incident response agreement gives you access to offensive security specialists around the clock – already familiar with your environment before anything goes wrong. Read more about our incident response services or book a meeting.