Incident Response Plan: What to Do in the First 72 Hours After a Cyberattack

TL;DR

When a cyberattack hits, the decisions made in the first few hours determine the difference between a contained incident and a catastrophic one. NIS2 requires an early warning to your national authority within 24 hours. DORA requires the same for financial entities. Most organisations do not have a documented, tested plan for what to do in those 24 hours. This guide covers what an effective incident response plan must contain, who needs to be in the room, and how to meet your regulatory reporting obligations without making things worse.

Why most organisations are unprepared

Incident response plans exist in most organisations. They are typically a document that was written once, filed, and never tested. When an actual incident occurs, the document is either not found, out of date, or too generic to be useful under the specific conditions of the attack.

The result is that the response is improvised. Key decisions are made without pre-agreed authority. Communication happens over potentially compromised channels. Evidence is destroyed before it is preserved. Regulatory reporting obligations are missed. And the people who should be leading the response are spending the first hours trying to find out who to call.

NIS2 and DORA have changed the stakes. Missing a 24-hour reporting obligation is no longer just an operational failure. It is a regulatory one, with sanctions attached.

The regulatory reporting timeline

NIS2: three-stage reporting

NIS2 requires essential and important entities to report significant incidents to their national competent authority in three stages. An early warning is due within 24 hours of becoming aware of the incident, indicating whether the incident appears to be caused by malicious or unlawful acts and whether it may have cross-border impact. A full incident notification is due within 72 hours, providing a more detailed assessment of the incident. A final report must follow within one month, including a description of the incident, its likely cause, and the measures taken.

The 24-hour clock starts when you become aware, not when the incident started. If your detection systems identify an incident on a Tuesday morning, the early warning is due by Wednesday morning, regardless of when the attack itself began.

DORA: financial sector specifics

DORA applies to financial entities and introduces a similar three-stage reporting framework, but with sector-specific criteria for what constitutes a major ICT-related incident. DORA also requires financial entities to notify clients and counterparts who may be affected by a major incident, which goes beyond what NIS2 explicitly mandates. The reporting goes to the financial supervisory authority, which in Belgium is the NBB or FSMA depending on the type of entity.

What an incident response plan must contain

An effective incident response plan is not a long document. It is a short, actionable set of procedures with clear ownership. The following elements are essential.

Roles and contact list

Define who leads the response, who is responsible for technical containment, who handles communication, who has authority to take systems offline, and who is the designated contact for regulatory reporting. This must include personal mobile numbers, not just work email addresses. If your communication infrastructure is compromised, email is not a reliable channel.

Incident classification criteria

Not every security event is a reportable incident. Your plan must define the criteria that trigger the response process and regulatory reporting obligations. This includes thresholds for data volume affected, system criticality, whether personal data is involved, and whether the incident has or could have cross-border impact.

First-hour checklist

The first hour is about activation and containment, not investigation. Activate the incident response team. Establish a secure out-of-band communication channel. Isolate affected systems to stop lateral spread without destroying evidence. Assign someone to document everything with timestamps. Notify legal counsel and, if the incident may trigger regulatory reporting, notify the designated compliance contact.

Evidence preservation protocol

The most common and most destructive mistake in incident response is wiping or rebuilding affected systems before forensic evidence has been preserved. System logs, memory dumps, network captures, and disk images are needed to understand what happened, what was accessed, and what data was exfiltrated. Your plan must specify what to preserve, in what format, and who has the authority to rebuild versus who must preserve first.

Communication protocol

Define who is authorised to communicate about the incident externally, what can be said, and through which channels. This applies to press, customers, regulators, and internally. Premature or inaccurate external communication during an active incident creates legal and reputational risk. All external statements during an incident should be approved by legal counsel.

Regulatory notification templates

Pre-draft the early warning notification template for NIS2 and DORA before an incident occurs. You will not have time to write it from scratch during an active incident. The template should include the required fields, the correct regulatory contact, and a checklist of what information must be gathered to complete it.

The 72-hour timeline in detail

Hour 0 to 4: Detection and activation. Confirm the incident is real. Activate the response team. Begin evidence preservation. Establish secure communications. Determine whether regulatory reporting thresholds are likely to be met.

Hour 4 to 24: Containment and early warning. Isolate affected systems. Begin forensic preservation. Determine scope of impact. If thresholds are met, file the 24-hour early warning notification. Brief senior leadership and legal counsel. Assess whether third parties or clients are affected.

Hour 24 to 72: Investigation and notification. Begin formal forensic investigation. Identify the attack vector, the extent of access, and the data affected. Prepare the 72-hour incident notification. If DORA applies, assess the client notification obligation. Begin planning for recovery and remediation.

Day 4 to 30: Recovery and final reporting. Execute remediation. Monitor for persistence or reinfection. Prepare the one-month final report for the regulator. Conduct a post-incident review to identify what failed in detection, response, and containment.

Testing your plan before you need it

A plan that has never been tested is not a plan. It is a document. Tabletop exercises, where your incident response team works through a simulated attack scenario, reveal gaps in roles, communication, and decision-making that are invisible on paper. Red team exercises go further by testing whether your detection and response capabilities would actually identify a real attack in progress.

NIS2 and DORA both expect evidence that your incident response capability is operational, not just documented. A tested, updated plan with tabletop exercise records is the most defensible evidence of operational readiness.

FAQ

What is an incident response plan?

An incident response plan is a documented, pre-approved set of procedures that defines how your organisation detects, contains, investigates, and recovers from a cybersecurity incident. It specifies who does what, in what order, and with what authority. An effective plan is tested before it is needed, not written during an active incident.

What are the NIS2 incident reporting requirements?

NIS2 requires essential and important entities to report significant incidents to their national competent authority in three stages: an early warning within 24 hours of becoming aware, a full incident notification within 72 hours, and a final report within one month. The 24-hour early warning must indicate whether the incident is suspected to be caused by unlawful or malicious acts and whether it may have cross-border impact.

How is DORA incident reporting different from NIS2?

DORA applies to financial entities and introduces a three-stage reporting framework similar to NIS2 but with sector-specific classification criteria for what constitutes a major ICT-related incident. The initial notification under DORA must also be made within 24 hours. DORA further requires financial entities to notify clients and counterparts affected by a major incident, which NIS2 does not explicitly mandate.

What should the first hour of an incident response look like?

The first hour is about activation and containment, not investigation. Activate your incident response team using pre-agreed communication channels. Isolate affected systems to prevent lateral spread without destroying evidence. Establish a secure communication channel outside potentially compromised infrastructure. Document everything with timestamps from the moment the incident is detected. Do not immediately wipe or rebuild systems before forensic preservation.

What is the most common mistake organisations make during a cyberattack?

The most destructive mistake is rebuilding or wiping affected systems before preserving forensic evidence. This destroys the ability to understand what happened, which systems were accessed, and what data was exfiltrated. The second most common mistake is communicating about the incident over email or collaboration tools that may themselves be compromised, alerting the attacker that they have been detected.

How does penetration testing help with incident response preparedness?

Penetration testing improves incident response preparedness in two ways. First, it identifies vulnerabilities before attackers do, reducing the likelihood of an incident occurring. Second, red team exercises and purple team exercises test whether your detection and response capabilities would identify a real attack in progress, revealing gaps in your incident response plan under realistic conditions before they matter.

Related services and resources

Sectricity helps organisations validate their incident response capability through red team exercises that test detection and response under realistic attack conditions. Our penetration testing and compliance-mapped security testing services help NIS2 and DORA entities build the audit-ready evidence trail regulators expect. For a deeper look at red teaming, see our guide on when your organisation needs more than a pentest. Not sure where to start? Begin with a free security scan.