Cyberattacks are now part of everyday business reality. Organizations that are not prepared risk far more than data loss — including operational disruption, legal consequences, and significant reputational damage. This is why the EU’s NIS2 Directive places greater responsibility on organizations and requires clear measures for handling security incidents.
An incident response plan provides a practical and transparent way to support NIS2 compliance.

Incident response plan – definition

An incident response plan combines organizational and technical preparations with clearly defined measures to respond quickly and effectively to disruptions or threats. Its goal is to minimize the impact of incidents and limit operational consequences as much as possible.

Detecting security incidents – with a NIS2-compliant incident response plan

An incident response plan typically consists of six sequential phases. When implemented correctly, these steps help organizations manage security incidents in a structured way, reduce potential damage, and meet regulatory requirements such as those set out in the NIS2 Directive.

1. Building an incident response plan: laying the foundation

During the preparation phase, the focus is on establishing the organizational and technical foundations needed to respond effectively in an emergency. A key element is developing an incident response policy that covers the following aspects:

• Roles and responsibilities

• Scope and overlaps (for example with GDPR requirements)

• Playbooks for common threat scenarios, including contact lists, workflows, and communication plans

• Technologies such as SIEM or intrusion detection systems

• Risk analyses and prioritization

It is important to review these elements regularly and update them when changes occur. Appointing and training an incident response team is also crucial for effective execution.

2. Identification: detecting and assessing security incidents

Once the foundation is in place, the next step is the early detection of potential security incidents — ideally before major damage occurs. IT systems must be able to identify anomalies and automatically flag suspicious activity.

At the same time, organizations must verify whether the situation actually constitutes a relevant incident. If confirmed, an initial assessment follows:

• How severe is the incident?

• Which systems are affected?

A fast and well-informed assessment at this stage is essential for determining further actions and meeting reporting obligations under regulations such as NIS2 or the GDPR.

3. Containment: controlling and limiting the impact

Once an incident is confirmed, the priority is to contain it and prevent further spread. Initial actions typically include short-term measures such as isolating affected devices or network segments. This is followed by stabilization efforts to regain control of systems, analyze vulnerabilities, and prepare for full remediation.

At this stage, communication plans are often activated to ensure transparency internally and, where necessary, externally.

4. Eradication: eliminating the risk

The next step is to systematically remove the root cause of the incident. The security team removes malware, closes security gaps, and disables compromised accounts or access points. In addition, the team analyzes the technical vulnerabilities that enabled the attack in the first place, helping prevent similar incidents in the future.

5. Recovery: restoring systems

The return to normal operations begins once the incident has been fully resolved. Before systems are brought back online, they are thoroughly verified. If needed, clean backups are used to restore affected systems. All actions and decisions are carefully documented to ensure transparency and traceability.

6. Post-incident review: learn, improve, update

After one incident, the next may already be just around the corner. That’s why the incident response team conducts a structured post-incident review. Key questions include what worked well and where delays or uncertainties arose.

Based on these insights, the response plan is updated — covering playbooks, communication channels, and responsibilities. Existing procedures are refined, and new roles and responsibilities are defined where needed.

How can the right tools help

A NIS2-compliant incident response plan ultimately depends on how effectively it can be implemented in practice. The right tools can support every phase:

• End-to-end encryption protects sensitive information — from the initial risk report to the official incident notification.

• Role-based access controls ensure that only authorized individuals can access security-relevant data.

• Versioning and logging enable full traceability, even during subsequent audits.

• Communication and documentation remain within a secure system, without insecure workarounds or data silos.

• External partners, such as IT service providers or authorities, can be securely integrated while maintaining a high level of security.

Tresorit offers all these capabilities within a single solution to effectively support organizations in meeting the requirements of the NIS2 Directive: confidential data rooms, defined role structures, secure communication channels for collaboration, and documented access histories enable companies to manage sensitive information transparently and in a compliant manner.

Building a security culture

An incident response plan is far more than just another document in the compliance folder. When implemented effectively, it becomes the backbone of structured, transparent, and secure action — both in day-to-day operations and in critical situations.

Organizations that rely on well-designed processes and secure digital tools not only meet regulatory requirements but also strengthen their overall resilience.

A missing incident response plan isn’t the only challenge companies face. Make sure you avoid these seven common NIS2 compliance mistakes.

Learn more about how Tresorit can support NIS2 compliance for your organization.