Article 21(2)(b) Incident handling: NIS2 requirements

What NIS2 incident handling requires before the next incident hits

Article 21(2)(b) requires essential and important entities to have policies and procedures to detect, analyze, contain, respond to, recover from, document and report incidents. If your organization is in scope, a supervisor will expect to see that process working, not just a policy document on file. Under Article 6(6), an incident is an event that compromises the availability, authenticity, integrity or confidentiality of data, or of the services offered by or accessible via your network and information systems. That definition is broader than a malware alert. A misconfiguration that exposes a service, or an outage that cuts a customer-facing function, can qualify, so the process has to catch events that nobody has labeled as an attack yet.

The reporting clock is what makes this measure urgent. Article 23 ties significant incidents to a 24-hour early warning, a 72-hour incident notification and a final report within one month. Those deadlines only work if detection, triage and the significance decision happen fast enough to leave room for them. Before the next incident, confirm who in your organization can declare a significant incident at night and on weekends, which CSIRT or competent authority you report to, and how you will decide whether an event crosses the threshold. The Implementing Regulation (EU) 2024/2690 expects the incident categorization system and communication plans for escalation and reporting to be written down, so these decisions should be recorded before they are needed.

The hard part is proving the process runs in practice. Write the policy, then run it. Test that your monitoring produces alerts on the systems that matter, that a triaged event becomes a tracked case with an owner, and that the case timeline, evidence and reporting drafts can be produced on demand. Schedule exercises at planned intervals and keep the records, including lessons learned from each review. Confirm with your tooling vendors and your own environment which log sources, retention periods and case records you can actually export, because a supervisor will ask for that evidence, not for the intent behind it.

Which systems, teams and suppliers fall inside NIS2 incident handling

Article 21(2)(b) only works if the monitoring, case handling and reporting clock cover the right things. Each scoping choice below changes how much detection and reporting effort the entity must carry, and each one should be settled and documented before the incident handling policy is written.

Network and information systems in scope

Start from the Article 6(6) definition: an incident compromises the availability, authenticity, integrity or confidentiality of data or of services offered by, or accessible via, network and information systems. That reaches beyond core production systems to identity providers, backups, remote access gateways and management planes. Ask which of these produce logs the team can see, and which would let an attacker affect a covered service without leaving a trace in the monitoring stack.

Logging coverage for cloud and SaaS

Detection depends on logs reaching a central point. For each cloud account and SaaS application, confirm which audit trails are enabled, how long they are retained, and whether the entity can export them into its own analysis platform. Where a provider only offers logs through its console, the reporting clock may start before the team can see the event. Document the gaps and the compensating checks.

Roles of IT, security, legal and management

Incident handling splits across teams: IT operations contains and recovers, security analyzes and classifies, legal and data protection assess notification duties, and management decides on escalation and approval. Assign each role by name in the response plan, with a backup for each. A decision that waits for an absent owner can consume the 24-hour early warning window that Article 23 sets for significant incidents.

Managed SOC and monitoring providers

When a managed SOC watches logs or triages alerts, the contract must state who classifies an event, who starts the reporting clock, and how quickly the provider passes information to the entity. Responsibility for the Article 21(2)(b) obligations stays with the entity. Confirm the provider's access to the relevant log sources, its escalation path at night and on weekends, and whether its analysts can take containment actions.

Hosting and cloud suppliers

Hosting providers, data center operators and cloud platforms often hold the logs, the infrastructure and the first evidence of an intrusion. Map which incidents they detect and notify themselves, what their notification terms are, and how they preserve evidence in their environment. Ask for these terms in writing, because an entity cannot assume a supplier will report on its behalf in time.

Suppliers that touch covered services

Software vendors, managed service providers and remote support staff can introduce or reveal incidents without being part of the entity's own network. List suppliers with privileged access or with a route into covered services, and check that their incident notices reach the same case queue. Article 21(2)(d) covers the supplier relationship in more depth, so align the two reviews.

How to build an incident handling process an assessor can test

The sequence below turns the Article 21(2)(b) incident handling measure into a written policy, working roles and channels, tested response procedures and review records that an assessor can check against Implementing Regulation (EU) 2024/2690. Each step closes with an output you can show.

Approve the incident handling policy and categorization system
Management approves a written incident handling policy that defines what counts as an incident under NIS2, which is an event affecting the availability, authenticity, integrity or confidentiality of data or services. The policy sets an incident categorization system with severity levels and classification criteria, so every later step uses the same labels. Done means a signed, dated policy with an approved category scheme and a named owner who must review it at planned intervals.
Define escalation and reporting communication plans
Write the communication plans that say who is told, by whom and by when, both internally for escalation and externally for reporting to the CSIRT or competent authority under Article 23. Map each severity level to an escalation path, including the people who can declare a significant incident. Done means an escalation chart that an assessor can trace from a sample incident to the required notifications, with the reporting roles stated.
Assign response roles and build contact lists
Name a person or team for each response role, such as incident commander, technical lead, communications, legal and the individual who files regulatory reports, and name a deputy for each. Build the contact lists with out-of-hours numbers and confirm that each person has accepted the role. Done means a roster with current contact details, alternates and a record of when it was last checked, kept where responders can reach it even if the primary systems are down.
Prepare response manuals and templates
Produce the response manual, incident record template, evidence log and the notification drafts that the reporting roles will use under time pressure. Pre-written templates reduce drafting during an event and give an assessor concrete documents to inspect. Done means a version-controlled document set that matches the policy's categories and roles, with each template linked to the step in the manual that uses it.
Implement monitoring, logging and the reporting channel
Configure logging and detection on systems in scope, then open a simple way for employees, suppliers and customers to report suspicious events, as the implementing regulation requires. Self-hosted open-source tools can carry much of this work: Wazuh can decode and alert on collected logs against its ruleset, OpenSearch Security Analytics can run Sigma-based detectors and record findings, and DFIR-IRIS can hold each case as a single record with its tasks, assets and evidence. Done means a tested alert path, retained logs and a reporting intake with a documented triage owner. Confirm which log sources each tool covers in your environment before relying on it.
Write and test containment, eradication and recovery procedures
Document the response procedures for containment, eradication and recovery, including the communication points with the CSIRT or competent authority. Run tabletop exercises and, where feasible, technical drills at planned intervals, then record what failed and who fixed it. Done means approved procedures, a test calendar and dated exercise reports with corrective actions tracked to closure. Assessors usually ask for the last test record, so keep it current.
Assess recurring incidents and run post-incident reviews
Review each closed incident to identify the root cause where that is possible, and record the lessons learned along with the changes made to controls or the policy. Separately, assess recurring incidents on a quarterly basis, since the implementing regulation requires that review. Done means a post-incident review for each significant case, a quarterly recurring-incident assessment on file and tracked actions that feed back into monitoring rules, training and the risk assessment.

How an assessor tests incident handling under NIS2

This table takes the six areas of Implementing Regulation 2024/2690 that implement Article 21(2)(b) and shows how an assessor would test each one, what evidence to prepare, and where findings usually appear. The assessor is the national competent authority or its designated auditor, but the organization owns the result, so read each row as a question to answer before the assessment starts.

Area	Test approach	Evidence requested	Common findings
Incident handling policy	Check that the policy covers categorization, escalation and reporting communications, and named response roles, then compare it with how staff actually respond.	Approved policy, incident categorization scheme, response manual, escalation chart, contact lists and templates, with approval and review dates.	A policy approved but never tested, roles that name people who have left, or categories no one uses.
Monitoring and logging	Sample log sources and confirm they are collected, retained and reviewed, then check that alerts from them reach a responder.	Log source inventory, retention settings, detection rule set, sample alerts and records showing who reviewed them and when.	Logs collected but never reviewed, sources missing from the inventory, or alerts that never open a case.
Event reporting	Test whether employees, suppliers and customers can report suspicious events, and follow a sample report from receipt to triage.	Reporting channel description, instructions given to staff, suppliers and customers, and a sample of reports with their handling records.	A reporting address that no one monitors, reports that stall before triage, or suppliers never told how to report.
Event assessment and classification	Review sample events to confirm they were assessed and classified against the scheme, and that significance decisions are recorded.	Classification records, triage notes, significance assessments and the timestamps linking detection to decision.	Events closed without classification, inconsistent categories across teams, or no record of why an event was judged minor.
Incident response	Walk through a recent incident to check containment, eradication, recovery and CSIRT or authority communication, and review the latest exercise results.	Response procedures, communication plans, timeline of a past incident, exercise reports and records of changes made after tests.	Procedures written but never exercised, no defined CSIRT contact, or response steps that depend on one person.
Post-incident reviews and recurring incidents	Check that reviews identify root causes where possible, that lessons are documented, and that recurring incidents are assessed quarterly.	Review reports, root cause analyses, lessons learned log, quarterly recurring-incident assessments and evidence that changes were tracked.	Reviews that never reach a root cause, lessons without owners, or no quarterly assessment of recurring incidents on record.

Evidence that proves incident handling works and how to keep it current

An assessor or national authority will not accept a policy that exists only on paper. The cards below cover the documents, records and tool outputs that show Article 21(2)(b) incident handling operates in practice, and the routine that keeps them current between audits.

Signed incident handling policy

The policy is the anchor document. It should name the approving member of the management body, the date of approval, the review cycle and the owner of each procedure beneath it. Check that the policy covers detection, analysis, containment, recovery, documentation and reporting, and that its approval record is kept so an assessor can see it was endorsed at the right level of the organization.

Incident categorization scheme

A categorization system lets staff sort events consistently and decide which ones meet the significance thresholds for reporting. Keep the category list, the criteria for each level and worked examples of how past events were classified. Assessors look for evidence that the same event would be classified the same way by two different responders.

Escalation charts and contact lists

Escalation charts show who is called, in what order and within what time window, from first alert to management and to the CSIRT or competent authority. Contact lists should include out-of-hours numbers for suppliers and legal counsel. Confirm each contact is still in post, because stale names are one of the most common gaps found during reviews.

Response manuals and exercise reports

Response manuals hold the step-by-step containment, eradication and recovery actions for each incident type. Exercise reports prove those steps were tested at planned intervals. Each report should record the scenario, participants, timings, gaps found and the actions assigned to close them, so the manual can be shown to have changed after a test.

Case records and investigation timelines

Each incident should have one case record that links affected assets, indicators, tasks and evidence. DFIR-IRIS keeps this record with a full audit trail, builds a consolidated timeline from the case data and logs evidence with SHA-256 verification and chain of custody. Test a sample case by asking whether an outsider could reconstruct what happened and when.

Detection records from OpenSearch and Wazuh

Security Analytics in OpenSearch (Apache-2.0) records detector matches as findings with rule, log type and severity, and Wazuh (GPL-2.0-only) writes matching alerts to alerts.log and alerts.json with MITRE ATT&CK mapping. Keep the rule sets under version control, retain the findings and alerts for the period your procedures define, and confirm that detections reach a triage queue rather than only a dashboard.

Administrative audit trail data

Administrative actions on collaboration and file platforms are evidence in their own right, especially when an incident involves changes to shared data or access. The admin_audit app in Nextcloud (AGPL-3.0-only) writes additional event information to audit.log in the data directory, or to a path set with logfile_audit. Confirm the log location is included in backup and is protected from modification by the people whose actions it records.

Post-incident reviews and quarterly trend assessments

Post-incident reviews should identify the root cause where it can be determined and record lessons learned with owners and due dates. Separately, recurring incidents must be assessed every quarter. Keep the quarterly assessment as a dated record that lists the trends reviewed, the conclusions and the changes made, so an assessor can see the review process is repeating and feeding improvement.

What meeting incident handling costs in money and effort

This table lists each cost component of an Article 21(2)(b) incident handling program, who is paid for it, whether it is one-time or recurring, and what moves it up or down. Use it to compare an internal build with outside help and to check whether a written quote covers every line. The main takeaway is that open-source tools mainly remove license spend, while staff time, log retention and exercises remain the largest recurring items.

Cost component	One-time or recurring	Who is paid or who bears the cost	What drives it up or down
Log collection and storage	Setup is one-time, storage recurs	Organization for its own infrastructure, cloud or data center provider for storage	Number of log sources, event volume, retention periods set by policy and sector rules, and whether logs are tiered to cheaper storage
Detection tooling (SIEM, EDR, alerting)	Licenses recur, deployment is one-time	Software vendor for commercial licenses, nothing for open-source license fees, organization for hosting	Commercial licensing usually scales with data volume or endpoints. Self-hosted open-source platforms such as Wazuh or OpenSearch Security Analytics remove license fees but keep hosting and operations costs
Engineering time to build detections and integrations	One-time build, recurring tuning	Internal engineers or an implementation partner under a written scope	Number of log types to onboard, custom rule volume, and how many ticketing or case systems must connect. Reusing existing rulesets lowers the initial effort
Case management platform setup	One-time setup, recurring hosting	Internal platform team or implementation partner, organization for infrastructure	Number of integrations, custom case templates, and reporting requirements. Open-source case tools such as DFIR-IRIS remove license spend but not configuration or support effort
Response role time (incident responders, escalation owners)	Recurring	Organization through internal salaries or managed service contracts	Incident volume, on-call coverage model, and whether the organization uses a managed SOC for first-line triage. Quarterly assessment of recurring incidents adds a small standing load
Documentation and policy work (response manuals, contact lists, templates)	One-time drafting, recurring review	Internal legal, compliance and security staff, or an external consultant	Number of entity locations, suppliers and customer groups in the escalation chain, and how often contact details change
Exercises and testing (tabletop and technical)	Recurring at planned intervals	Internal staff time, plus external facilitators if engaged	Frequency set by the organization's own plan, number of scenarios, and whether an outside facilitator runs the exercise. Internal facilitation lowers external fees but requires trained staff
Post-incident review time	Recurring, driven by incidents	Internal responders and management, sometimes external investigators	Number and severity of incidents, depth of root cause analysis, and whether a forensic firm is needed for complex cases
Auditor or supervisor review	Recurring, timing set by the authority or assessor	Organization for preparing evidence, independent auditor or national authority for assessment	Number of evidence artifacts requested, how well logs and case records are organized, and whether the authority runs an inspection or information request

What your team keeps, what a partner builds and what the auditor checks

The organization owns its incident handling program. The management body approves the incident handling policy, sets the risk appetite for incidents, and decides how significant incidents are reported to the CSIRT or competent authority under Article 23. The security team owns the day-to-day work: triaging alerts, classifying events, running the response, and writing the post-incident reviews that record root causes and lessons learned.

Policy approval: Management approves the incident categorization system, escalation paths and named response roles, and records that approval.
Reporting decisions: The accountable person decides whether an event is a significant incident and who signs the early warning, notification and final report.
Detection and response ownership: Staff monitor logs, close or escalate alerts, and run containment and recovery steps on their own systems.
Quarterly recurrence review: The security team assesses recurring incidents each quarter and feeds results into risk treatment.
Exercises and lessons learned: Staff plan and join tests of the response process and act on the findings.

Before you sign any outside contract, confirm that a named internal owner can explain every reporting decision without a consultant in the room.

Where incident handling programs usually fall short

Most incident handling programs fail at the joins between steps: a plan that was never exercised, logs nobody reads, and classifications that do not trigger the right clock. The cards below name six recurring gaps under Article 21(2)(b) and the fix for each, so that the policy, the monitoring and the Article 23 reporting duties work as one process.

Policy that nobody has tested

The incident handling policy exists on paper, but no one has run it against a realistic scenario, so roles, contact lists and escalation charts fail under pressure. Article 21(2)(b) expects response procedures to be tested at planned intervals, including communication with the CSIRT or competent authority. Schedule a tabletop exercise each year, record who was unreachable or unclear, and update the manual from the findings. Ask your team to show the last test report, not the policy text.

Logs collected but never reviewed

Many organizations forward logs to a central store but no rule set turns them into alerts and no analyst owns the queue. Collection without detection gives an evidence trail with no incident trail. Define detection content for critical systems, such as Sigma-based detectors in OpenSearch Security Analytics or the built-in Wazuh ruleset, and assign a named owner for triage. Confirm that alerts reach a channel someone watches outside business hours.

No reporting channel for suppliers

Employees often know how to report a suspicious event, but suppliers, contractors and customers usually have no simple route to do so. The implementing regulation requires entities to give all three groups a simple mechanism to report suspicious events. Publish a monitored reporting address or form in supplier contracts and on the customer portal, route submissions into the same case queue as internal alerts, and acknowledge each report. Test the channel with an external sender once a year.

No link between classification and Article 23 deadlines

Analysts classify incidents by technical severity, while the Article 23 clock depends on whether an incident is significant. Without a written mapping, an incident can pass the early warning deadline before anyone asks the question. Write a classification matrix that states which technical conditions make an incident potentially significant, assigns the decision to a named role, and starts the reporting timer at the moment of classification. Record the timestamp of each decision in the case.

Post-incident reviews that skip root cause

Reviews often close with a ticket and a summary of symptoms, leaving the cause in place for the next attacker. The implementing regulation asks for root cause identification where possible and documented lessons learned. Give every review a fixed template with a root cause field, a list of control changes, and an owner for each action. Track open actions to closure and feed the lessons into the risk assessment and policy updates.

No quarterly review of recurring incidents

Repeated low-severity events, such as the same phishing pattern or failed logins from one network, are often closed one by one and never assessed together. The implementing regulation requires recurring incidents to be assessed on a quarterly basis. Tag each case with a category and asset, run a quarterly report that groups repeats, and decide whether each group needs a control change or a risk treatment. Record the decision, even when the outcome is no change.

Questions buyers ask about NIS2 incident handling

How much effort does a NIS2 incident handling process take to build and run?

The effort depends mainly on the size of the estate, how many log sources feed detection, how many entities and Member States the process must cover, and how much of the response is already written down. Build effort covers the incident handling policy, a categorization scheme, escalation charts, contact lists, response manuals, reporting templates and the detection pipeline that feeds them. Run effort is recurring: alert triage, case documentation, quarterly review of recurring incidents, post-incident reviews and periodic exercises. Ask any provider for a written scope listing each deliverable, the systems in scope and who performs each task before comparing quotes.

Can our own team build the NIS2 incident handling process in-house?

Often yes, provided the team has staff who can write the policy, run detection engineering and lead an investigation. The Implementing Regulation (EU) 2024/2690 expects documented roles, tested response procedures and communication plans with the CSIRT or competent authority, so management must own the decisions even if engineers do the technical work. Organizations that lack in-house incident responders, or that cannot staff a response outside office hours, often bring in an implementation partner for the documentation and tooling and keep decision rights internally. An independent auditor or assessor will test the result; no partner can issue the compliance evidence on the organization's behalf.

What does the incident handling work need from our staff?

It needs named people in four roles: an incident lead who declares and coordinates incidents, analysts who triage and investigate alerts, a decision maker who approves external notifications, and a communications owner for internal and supplier messages. Staff also need to report suspicious events through a simple channel, which the regulation requires for employees, suppliers and customers. Analysts need hands-on training in the tools that hold cases and evidence, and the wider organization needs short awareness on how to escalate. Confirm with the provider how many people the design assumes, how they rotate for out-of-hours cover, and what training is included.

How long does it take to set up NIS2 incident handling?

No duration is fixed by NIS2 or the implementing regulation, so the timeline depends on the starting point, the number of systems in scope and how quickly decisions are made internally. Ask for a written schedule that breaks the work into policy, detection, case management, response procedures, reporting templates and the first test exercise, with a named owner and a date for each milestone. Check that the schedule includes time for the exercise, because the regulation expects response procedures to be tested at planned intervals and a process that has never been exercised is hard to defend to a supervisor.

Are open-source tools enough for NIS2 incident handling?

Open-source tools can cover much of the technical workload, but they do not cover the policy, roles, communication plans or evidence that the regulation requires. DFIR-IRIS (LGPL-3.0-or-later) can hold each case as one record with assets, indicators, tasks, evidence logged with SHA-256 verification and chain of custody, and an audit trail. Wazuh (GPL-2.0-only) and OpenSearch Security Analytics (Apache-2.0) can collect logs, match them against rules and raise alerts that feed the case. Gaps remain: confirm whether each tool meets your retention, availability and reporting needs, and check that the detections map to the threats your sector faces. Tool choice does not replace the process owners.

How does incident handling connect to Article 23 reporting and GDPR breach notification?

The incident handling process is the source of the facts that Article 23 reporting needs. Under NIS2, a significant incident triggers an early warning, a notification and a final report on fixed deadlines, so the triage and classification steps must decide quickly whether an event is significant. GDPR breach notification runs on its own clock for personal data breaches, so one incident may require two notifications to two authorities with different content. Build a single case record that feeds both, define who decides each notification, and rehearse both paths in the same exercise. Confirm the exact deadlines and thresholds against the legal texts and your national transposition law with counsel.

How DeployOpen scopes and prepares incident handling evidence

DeployOpen works on the incident handling measure as a written, fixed-scope engagement inside your own infrastructure. We prepare the detection, case management and response systems and the documents that show they work, while your organization keeps ownership of the policy, the decisions and the reporting to authorities.

How we scope

Agree in writing which systems, log sources and business services fall under the incident handling policy and procedures.
Confirm the incident categorization scheme, escalation paths and named response roles your organization will approve.
Record the Article 23 reporting contacts, CSIRT or competent authority touchpoints and who signs off each notification.

How we build

Deploy and configure open-source detection and case tools, such as Wazuh, OpenSearch Security Analytics and DFIR-IRIS, in your environment.
Write response manuals, escalation charts, contact lists and report templates for your teams to review and adopt.
Test detection rules and run tabletop or simulated incidents to confirm alerts reach responders and cases are recorded.

How we hand over

Deliver runbooks, configuration records, case audit trails and test results as a documented evidence set for your assessor.
Walk your security, IT and management staff through the process so they can run it without our involvement.
Provide a list of gaps and open decisions that remain with your organization, such as quarterly recurring-incident reviews and post-incident root cause sign-off.

How we support

Ongoing support, upgrades and continuous testing of the incident handling tooling are available as a retainer.
Confirm with us which periodic exercises and review cycles the retainer covers before signing.
Engage an independent auditor or certification body for any formal assessment, since DeployOpen prepares evidence but does not issue reports.