Skip to content
AuditFront
Art.21.2b NIS2

NIS2 Art.21.2b: Incident Handling Procedures

What This Control Requires

The measures referred to in paragraph 1 shall include at least the following: (b) incident handling.

In Plain Language

When a security incident hits, the difference between a contained event and a full-blown crisis usually comes down to preparation. NIS2 requires organisations to maintain incident handling procedures covering the full lifecycle - detection, classification, containment, eradication, recovery, and post-incident analysis. The objective is to minimise impact and restore normal operations as fast as possible. Good incident handling starts long before an incident occurs. You need defined incident categories and severity levels, established escalation paths, a trained response team, and playbooks for the most likely scenarios. When something goes wrong at 2am, nobody should be figuring out the process for the first time. Equally important is what happens after the incident. Post-incident reviews should identify root causes, evaluate how effectively the team responded, and produce concrete improvements. Those lessons need to feed back into your risk management framework, updating risk assessments and controls. An incident you do not learn from is an incident wasted.

How to Implement

Write a formal incident response plan covering all phases: preparation, identification, containment, eradication, recovery, and lessons learned. Get it approved by management and make sure every response team member can access it quickly. Define clear incident classification criteria with severity levels (critical, high, medium, low) and unambiguous criteria for each. Establish escalation procedures specifying when and how to involve senior management, legal counsel, regulators, or external parties. Appoint an incident response team with clearly defined roles and responsibilities. Ensure they receive regular training on handling procedures, forensic techniques, and communication protocols. A team that only reads the plan during an actual incident is not a prepared team. Build playbooks for the scenarios you are most likely to face: ransomware, data breaches, DDoS attacks, insider threats, and supply chain compromises. Each playbook should give step-by-step guidance for detection, containment, and recovery specific to that scenario. Deploy the right tooling: SIEM, endpoint detection and response (EDR), network monitoring, and forensic analysis capabilities. Make sure logs are being collected and retained according to your logging policy - you cannot investigate what you did not record. Run incident response exercises regularly. Tabletop simulations are low-effort and high-value; technical drills test your tools and processes under pressure. Document outcomes and use them to sharpen your capabilities. After every significant incident, conduct a formal post-incident review producing a root cause analysis report. Track all follow-up actions and hold people accountable for completing them within defined timeframes.

Evidence Your Auditor Will Request

  • Formal incident response plan approved by management
  • Incident classification and severity matrix
  • Incident response team roster with roles and contact details
  • Incident playbooks for common threat scenarios
  • Records of incident response exercises and post-incident reviews

Common Mistakes

  • Incident response plan exists but has never been tested through exercises
  • Incident classification criteria are vague, leading to inconsistent severity assignment
  • Post-incident reviews are not performed or their recommendations are not tracked
  • Incident response team members have not received recent training
  • No clear escalation path to management or regulatory notification procedures

Related Controls Across Frameworks

Framework Control ID Relationship
ISO 27001 A.5.24 Related
ISO 27001 A.5.25 Related
SOC 2 CC7.3 Related

Frequently Asked Questions

How often should we test our incident response plan?
Annually at the absolute minimum, but more often is better. Tabletop exercises are low-disruption and can easily run quarterly. Full technical drills are more involved but aim for semi-annually. Also test after significant infrastructure changes or when the threat landscape shifts meaningfully.
What is the difference between incident handling under Art.21 and incident reporting under Art.23?
Art.21.2(b) is about your internal processes for managing incidents - how you detect, contain, and recover. Art.23 is about the external obligation to report significant incidents to competent authorities and affected parties within specific timeframes. You need both, and they should be tightly integrated so your internal handling process automatically triggers the reporting workflow when thresholds are met.

Track NIS2 compliance in one place

AuditFront helps you manage every NIS2 control, collect evidence, and stay audit-ready.

Start Free Assessment