Incident Response management: fundamentals, process and emergency communications under NIS-2 & DORA

IT security incidents happen. The question is not whether your organisation will be affected, but whether you will still be able to act at the critical moment. The answer depends on how well you are set up when it comes to incident response management.

According to the IBM Cost of a Data Breach Report 2025 , it takes an average of 241 days globally to fully identify and contain a security incident. A tested incident response plan is one of the most effective levers for limiting damage.

NIS-2 and DORA add further pressure. Both frameworks require that significant security incidents are reported within 24 hours. Processes, communication channels and responsibilities must be defined and tested before an incident occurs.

This article explains how professional incident response management is structured, why it is more than a plan gathering dust in a drawer, what NIS-2 and DORA specifically require, and how to set up your emergency communications so you remain capable of acting when it matters most.

TL;DR – the key points

• Incident response management is the organisational capability to respond to security incidents in a coordinated, documented and timely manner.

• The incident response process follows six phases: preparation, detection, containment, eradication, recovery and post-incident review. Each phase has regulatory implications.

• NIS-2 and DORA both require an early warning within 24 hours. Organisations without automated notification chains will fail to meet this deadline.

• Emergency communications only work if they are set up and practised before an incident occurs. Switching to an unfamiliar out-of-band channel mid-attack costs time – and in the worst case, the deadline.

• FTAPI helps automate notification chains and keep communications secure and independent of primary infrastructure during an incident.

What incident response management is – and what it is not

Incident response refers to the technical reaction to an active security incident: detection, containment and eradication. Incident response management is the overarching framework that organises this reaction – with defined roles, communication channels, documentation requirements and a structured post-incident review. It determines whether the organisation remains capable of acting during an incident.

Cyber resilience expert Dr Daniel Lemmer put it plainly at CPT 2026:

Resilience means accepting that there is no such thing as 100% security. At some point in the supply chain, it will catch up with you. The question is how well prepared you are.

NIS-2 and DORA require demonstrable response capability for exactly this reason – more on that below.

The difference in practice: an incident response team that is purely well-equipped on the technical side can generally contain a security incident. But without clear responsibilities, functioning communication channels and automated notification processes, it is unlikely to respond quickly enough to meet statutory deadlines.

Responding to incidents: the incident response process in 6 phases

A professional incident response process follows a clear structure. Most frameworks – BSI, NIST, ISO 27035 – divide it into six phases. What follows is a summary of what needs to happen in each phase. The general rule: anything that is not well enough prepared will, under time pressure, let you down.

Phase 1: Preparation

The first step is to plan and put in place everything you will need in an emergency. This includes:

• a documented incident response plan

• defined roles within the incident response team and escalation paths

• contact lists for internal and external stakeholders

• tested communication channels

• scenario-specific playbooks

A common mistake is storing emergency plans and contact lists digitally on the primary infrastructure. What happens if that infrastructure goes offline during an attack? Critical documents must always be accessible redundantly and independently of the primary IT infrastructure.

An incident response team should also be cross-functional. Ideally it has five to ten members, including specialists from IT, legal and communications.

A plan is only as good as the rehearsal behind it. Tabletop exercises – crisis simulations in which the entire team, from the CISO to the legal department to senior management, works through realistic attack scenarios in a meeting room – have proven their worth in modern IR management. It is only under this simulated pressure that you find out whether the theoretical communication channels hold up in practice and where the playbooks need improvement.

Phase 2: Detection and analysis

A security incident rarely announces itself clearly. Typical early signals include anomalous network traffic, unusual logins or suspicious file changes. SIEM systems (Security Information and Event Management), EDR tools and SOC monitoring help to detect and classify these signals.

The central task in this phase is to distinguish between a genuine incident and a false alarm, and – if it is genuine – to classify its severity. This is also critical from a regulatory perspective: from the moment a significant incident is confirmed, the 24-hour deadline under NIS-2 and DORA begins to run, in parallel with all technical measures, not after them.

An incident is considered significant if it noticeably disrupts or could disrupt the operations of the affected organisation – for example through the failure of critical systems, unauthorised data access or an impairment of essential services. A practical incident response plan also defines who holds final authority for authorisation and reporting – for example, the CISO in direct coordination with senior management.

Phase 3: Containment

Once a cyberattack is confirmed, the priority is stopping it from spreading: isolating affected systems, blocking compromised access points and segmenting networks. Where possible, systems should be left running so that forensic evidence is preserved for later analysis.

At the same time, crisis communications begin. The incident response team is alerted via a channel that operates independently of the compromised corporate IT. If that channel does not exist – or if those involved are not familiar with it – coordination breaks down at exactly the moment it is needed most.

Phase 4: Eradication

Containment is followed by targeted remediation: removing malicious code, closing exploited vulnerabilities and resetting compromised credentials. Every measure taken in this phase must be documented. NIS-2 and DORA require a traceable report covering the cause, scope and countermeasures taken as part of the full notification. Anyone who does not keep a running record here will not be able to reconstruct that report fully later.

Phase 5: Recovery

Systems are restored progressively from clean backups, tested and brought back into operation. How quickly this succeeds depends on whether RTO (Recovery Time Objective) and RPO (Recovery Point Objective) were defined in advance – that is, what levels of downtime and data loss the organisation can tolerate.

One important point regarding deadlines: the full notification to the BSI or BaFin must be submitted within 72 hours of the incident becoming known. This deadline has been running since phase 2. Recovery and the reporting obligation run in parallel, not sequentially.

Phase 6: Post-incident review

After the incident, the entire response should be evaluated, with particular focus on:

• What delayed detection?

• Where did communications break down?

• Which playbooks need to be updated?

The findings should feed directly into updates to the incident response plan and the playbooks. This is the only way incident response management improves with each cycle. As Lemmer noted at CPT 2026, every crisis should be seen as a learning opportunity – that is how genuine resilience is built over time.

One further point: NIS-2 and DORA require a final report within one month of the incident. The post-incident review is therefore not only internally valuable – it is a regulatory obligation.

Incident response plan and playbook: the difference

An incident response plan and an incident response playbook serve different purposes and build on one another. Both are needed. The plan creates the organisational framework; the playbook makes that framework actionable when an incident occurs.

The incident response plan

The incident response plan is the written foundation. It defines how the organisation responds to security incidents, regardless of who happens to be available and which systems are running.

A robust incident response plan covers, for example:

• Scope and definition of significant security incidents, for instance as defined under NIS-2 and DORA

• Roles and responsibilities: who leads the crisis team? Who notifies the BSI or BaFin?

• Escalation paths: who is informed when, and via which channel?

• Contact lists – internal (e.g. CISO, CEO, SOC) and external (e.g. forensic service providers, BSI, BaFin, legal counsel, insurers)

• Out-of-band communication channels for use when the primary infrastructure is unavailable

• Reporting obligations and deadlines under NIS-2 and DORA

• References to scenario-specific playbooks

The plan must be tested and updated regularly. A document that has not been opened in two years is not a real plan when it matters.

The incident response playbook

While the plan sets the framework, the incident response playbook provides the concrete steps for specific scenarios. A ransomware playbook looks different from one covering phishing or data loss, because the indicators, immediate actions and notification paths differ across these types of security incident.

A good playbook is concise, clear and readable under stress. For each scenario, it answers:

• How do I recognise this type of incident?

• What is the immediate action in the first hour?

• Who is notified, and how?

• Which reporting obligations apply?

• What does the recovery path look like?

Playbooks covering the most common scenarios – ransomware, phishing, data loss, insider threats and the failure of critical infrastructure – are typically tested during exercises and revised after real incidents.

What NIS-2 and DORA specifically require

Incident response management was for a long time simply best practice: organisations that were well set up on IT security voluntarily developed structured plans, tested playbooks and defined communication channels. NIS-2 and DORA have changed that. Incident response management is now a legal obligation – with concrete deadlines, documented proof requirements and personal liability for senior management. Organisations that have previously managed without a formal plan no longer have a choice.

Although the two frameworks address different audiences, their requirements for incident response management are structurally almost identical.

The NIS-2 Directive has been formally transposed into German law via the NIS-2 Implementation Act (NIS2UmsuCG) since the end of 2024. In Austria, it is being implemented through the new Network and Information Systems Security Act (NISG 2026), which applies from 1 October 2026. The framework covers critical and important entities (further details are available here).

NIS-2 requires the following in relation to incident response:

• Early warning to the BSI (in Austria: the BKA or CERT.at) within 24 hours of a significant incident becoming known

• Full notification within 72 hours, covering cause, scope and initial countermeasures

• Final report within one month

• Documented processes for incident response, business continuity and crisis management

• Personal liability of senior management for breaches of the reporting obligations

DORA (Digital Operational Resilience Act) has applied since January 2025 to financial undertakings, insurers and their ICT service providers. It requires:

• Classification of ICT incidents according to defined thresholds

• Early warning to the relevant financial supervisory authority (BaFin, EBA) within 24 hours for serious incidents

• Full notification within 72 hours, final report within one month

• Documented and regularly tested incident response plans

• Active ICT third-party risk management – the security of suppliers and service providers forms part of an organisation's own DORA obligations

The requirements of both frameworks overlap significantly: identical reporting deadlines, the same requirements for documentation, access controls, encryption and business continuity.

One important distinction: financial undertakings that fall directly under DORA – banks, insurers and payment service providers – are exempt from NIS-2. DORA replaces NIS-2 for these organisations. ICT service providers supplying financial undertakings may, however, fall under both frameworks. For them, building DORA-compliant incident response processes largely lays the structural foundation for NIS-2 compliance as well.

Emergency communications: the most common bottleneck in a real incident

Picture the following scenario: Monday morning. Your SOC reports anomalous network traffic. Two hours later it is clear: Active Directory has been compromised, corporate email runs on the same server and is down, Microsoft Teams is no longer working.

The 24-hour deadline for the NIS-2 early warning is running. But the crisis team cannot coordinate. Contact lists are in Exchange, which is offline. Emergency plans are stored on a SharePoint that is also unavailable. External forensic specialists cannot be reached securely.

This is not an extreme scenario. It can be the typical sequence of events in a serious attack. To avoid this situation, you need communication channels that are set up redundantly – and your incident response team needs to be familiar with them before an incident occurs.

For out-of-band communications to work in a real incident, they need four properties:

• Independence: The channel must not share any server, domain or credentials with the primary infrastructure. A separate setup, separate credentials and, ideally, separate devices for the crisis team.

• Encryption: During a crisis, the most sensitive information the organisation holds is being communicated: incident details, forensic findings, decisions taken by the crisis team, contacts at regulatory authorities. All content must be transmitted and stored with end-to-end encryption – especially under time pressure.

• Availability and stability: The channel must be reachable when internal systems are offline. This rules out any solution that itself runs on the compromised infrastructure.

• Familiarity and routine: A channel introduced for the first time during an incident will not be used. Staff, crisis team members and external partners must know the channel, have tested it and be practised in using it.

Why manual notification chains fail against the 24-hour deadline

Twenty-four hours sounds like plenty of time. In practice, it is not. During a real incident, forensic analysis, containment measures, internal situational assessment and coordination with external service providers are all running simultaneously. Somewhere in the middle of all that, a structured and complete early warning to the BSI or BaFin needs to be produced.

Organisations that rely on manual processes simply run out of capacity. The notification arrives late, is incomplete or contains errors. Under NIS-2 and DORA, this can result in fines and personal liability for senior management.

Automated notification processes solve this structurally: defined events automatically trigger notifications and reporting workflows. Deadlines are tracked visibly. Documentation is generated continuously as an audit trail. The right people are informed without manual handoffs. The incident response team can focus on technical containment while the reporting obligations run reliably in the background.

Implementing incident response management with FTAPI

FTAPI can serve as a central building block for effective incident response management under NIS-2 and DORA. The platform provides the tools for notification chains, crisis communications and documentation.

• Notification chains and escalation processes: SecuFlows Advanced allows internal notification paths to be mapped digitally and automated. Incoming incident reports trigger defined workflows, deadlines are tracked and documentation is generated automatically in the background.

• Out-of-band communications: SecuMails provides a communication channel that operates independently of the internal email infrastructure – end-to-end encrypted and with full audit logging.

• Crisis documentation and emergency plans: Via SecuRooms, crisis teams can access emergency plans, playbooks and forensic documentation from any device, even when internal file shares are unavailable. All actions are logged automatically.

• Data exchange with external partners: Logs, forensic findings and sensitive data can be shared with forensic specialists, CERTs and regulatory authorities via FTAPI in an encrypted and access-controlled manner, without any media breaks.

Conclusion: incident response management must be lived, not just documented

An incident response plan that has never been exercised is just a document. The incident response process must be trained, reviewed and practised regularly if it is to work when it matters – and if organisations are to be genuinely resilient.

NIS-2 and DORA mark a turning point here. Incident response management moves from voluntary best practice to a legal obligation. Organisations that have not prepared their emergency communications, automated their notification chains and exercised their incident response plan now risk personal liability for senior management, significant fines and a loss of trust among customers and partners.

FTAPI supports this as a central building block. The platform brings together secure emergency communications, automated workflows for notification chains and tamper-proof documentation.