NIS2 Incident Handling Audit Checklist: 28 Controls Under Art. 21(2)(b) — Plus the 5 Most Teams Fail

When a competent authority opens a targeted security audit under NIS2’s Article 32, incident handling is one of the first files they pull — because Article 21(2)(b) names it as a mandatory measure but never says what “having it” actually looks like on paper. That gap between a one-line legal requirement and a real evidence file is where most organisations lose ground, not because their incident response is bad, but because nobody wrote down proof that it works.

This checklist breaks Article 21(2)(b) and its reporting counterpart, Article 23, into 28 auditable controls, each paired with the evidence format an auditor will actually accept. It flags the five controls that fail audits most often, gives you the interview questions your incident response team should be able to answer cold, and closes with a cheat sheet on acceptable evidence formats. None of this replaces legal advice — see the disclaimer below — but it does turn two paragraphs of directive text into something you can walk through department by department.

Who This Incident-Handling Audit Checklist Applies To

Article 21(2)(b) of the NIS2 Directive applies to every essential and important entity within the directive’s scope — the roughly 18 sectors listed in Annexes I and II, from energy and healthcare to digital infrastructure, postal services, and public administration. Incident handling is one of ten mandatory measure categories under Article 21(2), sitting alongside risk analysis, business continuity, and supply chain security. This checklist assumes your organisation has already confirmed it’s in scope and mapped its Article 21 obligations. If you haven’t done that yet, start with our audit preparation guide, then come back here for the incident-handling detail.

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

How NIS2 Auditors Actually Test Incident Handling

Under Article 32 of the NIS2 Directive, competent authorities can subject essential entities to on-site inspections, off-site supervision, and “regular and targeted security audits carried out by an independent body or a competent authority,” plus ad hoc audits “where justified on the ground of a significant incident.” [1] Important entities face a lighter, ex-post version of the same regime under Article 33. Either way, auditors are explicitly entitled to request “evidence of implementation of cybersecurity policies, such as the results of security audits carried out by a qualified auditor” [1] — and the cost of a targeted audit is generally billed to the audited entity, not the regulator.

For incident handling specifically, that evidence obligation traces back to two provisions: Article 21(2)(b), which simply names “incident handling” as one of the ten mandatory measures [2], and Article 23, which sets the operational clock — a 24-hour early warning, a 72-hour incident notification, and a final report no later than one month after the notification. [3] ENISA’s June 2025 technical implementation guidance confirms these provisions don’t come bundled with a ready-made evidence checklist — entities have to build one. [4] Neither article hands you a pre-built list of what to have on the shelf. The 28 controls below are our own organising framework for turning those two provisions, plus what auditors in practice ask to see, into something you can walk through before the auditor does. For the notification chain itself in more detail, see our Article 23 incident notification breakdown; for how the annual internal-audit cycle around all of Article 21 works, see our guide for internal auditors.

The 28-Control Audit Checklist

Each control below maps back to Article 21(2)(b), Article 23, or the effectiveness-review obligation in Article 21(2)(f). The five marked with a warning symbol are the ones evidence packages most often fail on — they get a full section of their own further down.

Detection & Monitoring

#	Control	Evidence auditors expect
1	Continuous logging/monitoring covers critical systems	Log-source inventory plus a SIEM or logging-platform configuration export
2 ⚠	A detection SLA (mean time to detect) is defined and tracked	MTTD dashboard export or monthly detection-performance report
3	Anomaly-alerting rules exist (failed logins, impossible travel, unusual data transfer)	Alert-rule list plus sample triggered alerts
4 ⚠	Log retention period is documented and enforced	Retention policy plus a storage-configuration export showing the enforced window

Classification & Escalation

#	Control	Evidence auditors expect
5	Incident classification criteria cover severity, impact, and cross-border reach	Written classification matrix
6	“Significant incident” threshold is defined against Article 23(3) criteria	Threshold definition document citing Article 23
7	Awareness time is logged at first indicator, not at root-cause confirmation	Incident log timestamp field plus policy wording confirming when the clock starts
8	Escalation path from analyst to decision-maker is documented	Escalation matrix or on-call roster

Regulatory Notification Chain

#	Control	Evidence auditors expect
9	24-hour early-warning procedure and template are ready to use	Early-warning template plus current CSIRT contact sheet
10	72-hour incident-notification procedure and template are ready	Notification template plus a submission log from past incidents or drills
11	One-month final-report procedure and template are ready	Final-report template plus submission log
12	CSIRT/competent-authority contact register is kept current	Contact register showing a last-reviewed date

Response & Containment

#	Control	Evidence auditors expect
13	Documented incident response plan names roles and responsibilities	IR plan document with a version history
14	Containment/eradication runbooks exist per incident type	Runbook set (e.g. ransomware, DDoS, data exfiltration)
15	Forensic evidence-preservation procedure is documented	Chain-of-custody log template plus a completed sample
16	Third-party/MSSP incident-response support is under a signed agreement, where used	Signed SLA or contract excerpt covering incident-response duties

Testing & Continuous Improvement

#	Control	Evidence auditors expect
17 ⚠	CSIRT/tabletop dry-runs happen on a defined cadence	Exercise logs, attendance sheet, and the scenario document used
18	Dry-run findings are tracked through to closure	Corrective-action register with due dates and status
19 ⚠	A post-incident review is conducted after real incidents	Post-incident report plus a policy changelog tied to it
20	Lessons learned feed back into policy or training within a set window	Policy diff or training-update record referencing the incident ID

Governance & Accountability

#	Control	Evidence auditors expect
21	Management body has approved the incident-handling policy	Signed policy plus approval minutes
22 ⚠	Board/executive leadership is notified of significant incidents	Board or executive meeting minutes referencing the incident
23	A named accountable role (CISO or equivalent) is documented	Role charter or RACI matrix
24	Effectiveness of incident-handling measures is assessed periodically (Art. 21(2)(f))	Internal audit or self-assessment report

Documentation & Evidence Hygiene

#	Control	Evidence auditors expect
25	Staff in incident-handling roles have documented training	Completion records plus assessment scores
26	Supplier/third-party incident-notification obligations are documented	Contract clause excerpt naming notification duties
27	Incident log is complete and consistent across the reporting period	Full incident log export
28	Corrective-action register is tied to identified instances of non-compliance (Art. 21(4))	CAP register with status and due dates

The 5 Controls That Fail Most Incident-Handling Audits

Across the gap-analysis conversations we support customers through, the same five controls keep coming back as the reason an otherwise solid evidence package gets sent back for more work. None of them are exotic — they’re the ones that quietly stay “on the to-do list” past go-live.

1. No detection SLA (Control 2)

Plenty of teams can say they have monitoring. Far fewer can say how fast that monitoring actually catches something, in writing, with a number attached. Without a defined and tracked mean-time-to-detect, there’s no way to demonstrate the monitoring in Control 1 is doing anything beyond generating logs nobody reads. Fix: pick a realistic MTTD target, pull it from your SIEM or ticketing system monthly, and keep the report.

2. Log retention that doesn’t match the incident timeline (Control 4)

A retention window that’s too short is the single fastest way to fail a post-incident evidence request — if the logs from three months ago are already gone, there’s nothing to hand the auditor, regardless of how good your policy document reads. In practice, auditors expect to see retained, timestamped telemetry that lines up with your incident log, not just a retention policy that states a number. [5]

3. No post-incident review after real incidents (Control 19)

An incident response plan that’s never been checked against reality isn’t evidence of anything — it’s a document. In practice, the evidence that actually holds up combines drill logs with post-incident reports from real events, showing the plan was followed under pressure and revised afterward. [5] A post-incident review without a resulting change to the policy or training material reads, to an auditor, as a box-ticking exercise rather than a functioning control.

4. Board notification with no evidence trail (Control 22)

NIS2 puts incident-handling accountability on management bodies directly, but “the board was told” is not evidence unless it’s written down. The gap here is almost never that the board wasn’t informed — it’s that nobody kept the minutes, or the minutes don’t mention the incident specifically enough to count.

5. Missing or undocumented CSIRT dry-run (Control 17)

This is the control most often skipped entirely, not just under-documented. Running a tabletop exercise without keeping a scenario document, an attendance sheet, and a note on what changed afterward means you did the work but can’t prove it — which, for audit purposes, is close to not having done it at all.

Auditor Interview Questions for Your Incident Response Team

These are the kinds of questions a targeted security audit under Article 32 tends to surface once the document review is done and the auditor starts talking to the people who’d actually run an incident. Walking your IR team through them before the audit does is cheaper than finding the gaps live.

• What’s your mean time to detection over the last 12 months, and how is it calculated?
• Show me the log retention configuration on your SIEM or logging platform — where is that window documented?
• Walk me through the last incident you classified as not significant. What made you confident it didn’t cross the Article 23(3) threshold?
• When did the 24-hour clock start on your most recent incident, and how do you know that’s the correct start time?
• When did you last run a tabletop exercise, who attended, and what changed in your policy or training afterward?
• Pull up the board or executive minutes where your most recent significant incident was discussed.
• Show me a corrective action that came out of a post-incident review, and where it’s tracked to closure.
• If a managed security provider handles detection for you, what does the contract say about their obligation to notify you?
• How do you keep your CSIRT and competent-authority contact details current?
• Show me the incident log for the last reporting period — is it complete, or are there entries that were never closed out?

Evidence Format Cheat Sheet

Acceptable evidence formats vary somewhat by member state, so treat the list below as a strong starting point rather than a universal standard. Germany’s BSI, for example, names a specific set of accepted evidence types for its national NIS2 implementation — internal policies, work instructions, checklists, staff training records, signed agreements, factsheets, audit reports, certifications, and examination results. [6] That list maps well onto the 28 controls above.

Evidence type	Acceptable format	Note
Policies & procedures	Version-controlled DOCX or PDF, with approval signature	Undated or unapproved drafts don’t count as evidence
Logs (detection, access, incident)	Exported CSV, PDF, or platform screenshot with timestamps	Must cover the retention window claimed in your policy
Training records	LMS completion export or signed attendance sheet	Completion rate alone is weak; pair with assessment scores where possible
Meeting minutes (board, management)	Signed PDF or DOCX	Must name the specific incident or decision, not just “cybersecurity update”
Contracts & supplier agreements	Signed PDF excerpt covering the relevant clause	Full contract not required — the notification/incident clause is what’s checked
Independent audit reports/certifications	PDF report from a qualified auditor or certification body	Can support, but does not automatically substitute for, a targeted NIS2 audit [1]

FAQ

Does Article 21(2)(b) legally require exactly 28 controls?

No. Article 21(2)(b) itself is a single phrase — “incident handling” — with no numbered sub-list. The 28 controls in this article are our own organising framework, built from that requirement, Article 23’s reporting timeline, and the evidence Article 32 audits ask for in practice. Treat it as a working structure, not a legal enumeration.

How often should we run a CSIRT tabletop dry-run?

The directive doesn’t set a number. As a general guideline, most practitioners treat an annual dry-run as the floor for essential entities, with more frequent exercises for higher-risk profiles or after a significant change to the IR plan. Confirm expectations with your own competent authority where possible.

What counts as “becoming aware” for the 24-hour clock?

Article 23 starts the clock from when the entity becomes aware of the significant incident — not from when root cause is confirmed. [3] Waiting for a full technical picture before submitting the early warning is a common way this control gets missed.

Does an ISO 27001 certification satisfy the incident-handling audit requirement?

Article 32 allows competent authorities to accept “the results of security audits carried out by a qualified auditor” as evidence of implementation. [1] An ISO 27001 audit can support your case, but acceptance isn’t automatic or guaranteed — confirm with your competent authority rather than assuming certification alone closes the question.

We don’t have all 28 pieces of evidence yet. Where do we start?

Start with the five controls covered above — detection SLA, log retention, post-incident review, board notification evidence, and the CSIRT dry-run. They’re the ones evidence packages fail on most often, and closing them first gives you the biggest reduction in audit risk for the least effort.

Twenty-eight controls sounds like a lot until you notice that most organisations already have partial evidence for two-thirds of them — the real audit risk concentrates in the five controls above. Close the detection SLA, the log retention window, the post-incident review habit, the board evidence trail, and a documented CSIRT dry-run, and the rest of this checklist becomes a filing exercise rather than a rebuild.

Sources

1. NIS 2 Directive, Article 32: Supervisory and enforcement measures in relation to essential entities — nis-2-directive.com
2. NIS 2 Directive, Article 21: Cybersecurity risk-management measures — nis-2-directive.com
3. NIS 2 Directive, Article 23: Reporting obligations — nis-2-directive.com
4. NIS2 Technical Implementation Guidance — ENISA (European Union Agency for Cybersecurity), published 26 June 2025
5. Your NIS2 Audit Evidence Guide: Logs, Training Records & KPIs — Kymatio
6. NIS-2 Risikomanagementmaßnahmen (§30 BSIG) — BSI, Germany’s Federal Office for Information Security