NIS2 Article 23: What Your Incident-Response Packet Actually Needs

The first thing a NIS2 auditor asks after a reported incident is not “what happened?” The auditor knows what happened — you already filed the 24-hour early warning and 72-hour notification. The first real question is harder: show me your packet.

The “packet” is the post-incident artefact regulators (and your enterprise customers’ supply-chain reviewers) now expect under Article 23 of NIS2. Notification is the front door. The packet is the file the auditor opens after they walk in. Most SaaS vendors don’t have one ready — and that gap, not the incident itself, is what triggers the second audit cycle.

This is the cornerstone reference: what belongs in the packet, what does not, and a checklist you can run before the next vendor review.

What Article 23 Actually Demands

Article 23 obliges essential and important entities to report significant incidents to their CSIRT or competent authority on a three-stage clock: a 24-hour early warning, a 72-hour incident notification, and a final report within one month. The directive language is procedural. But the BSI’s enforcement guidance — and the reviewer scripts your customers’ auditors are now using — go further: they expect the entity to retain a coherent file per significant incident, not three separate emails.

That file is the packet. Auditors do not specify a format. They specify what they want to be able to verify, in one place, without chasing four people across two quarters.

The Packet — Section by Section

A defensible Article 23 packet has six sections. Skipping any of them is how a routine post-incident review turns into a finding.

1. The Incident Identity Block

One page. Five fields. This is what the auditor reads first and what every other section refers back to.

• Incident ID — your internal reference, not the regulator’s.
• Detection timestamp — when someone at your company knew, not when the breach started.
• Classification — significant / not significant, and the rule you applied to decide. The classification logic is itself audited.
• Lead responder — a named individual. “The on-call team” is not a name.
• Status — open / contained / closed, with the date of the last status change.

If this block is missing or vague, the auditor reads the rest of the packet as draft material.

2. The Three Filings (Verbatim)

Copies of what you sent the CSIRT — not summaries, not retypes. The original 24-hour early warning, the 72-hour incident notification, and the one-month final report, each with the submission receipt or portal confirmation ID. Use the BSI Meldeportal field map if you submitted in Germany — the auditor will cross-check field-by-field.

The reason verbatim copies matter: an auditor will compare what you reported externally to what your internal log says happened. Discrepancies between the two — even minor ones — are the most common Article 23 finding.

3. The Timeline

A single dated table. One row per material event. The level of detail the packet needs is roughly:

Timestamp	Event	Source	Decision
14:02 UTC	Unusual auth-failure spike detected	SIEM rule R-204	Page on-call
14:11 UTC	On-call confirms credential-stuffing pattern	Lead responder	Engage runbook IR-3
14:47 UTC	Affected accounts identified (n=812)	Auth log query	Notify legal

The auditor is reading for two things: did the time-to-detect look credible, and did each decision have an owner. Long gaps without entries — or entries without decisions — get flagged.

4. The Evidence Annex

The non-narrative material the timeline references. SIEM exports, log excerpts, ticket links, screenshots, and the external-posture scan snapshots from before and during the incident (the latter is increasingly asked for under supply-chain reviews — see proving your posture in a vendor audit call).

Two rules: every annex item is referenced by row number from the timeline, and every annex item has a retention timestamp. Material referenced but not retained is treated the same as material that never existed.

5. Root Cause and Remediation

Two short documents, not one essay.

• Root cause analysis — what failed, and why the existing control did not prevent it. Honest is better than thorough. Auditors trust analyses that name a control gap; they distrust analyses that conclude “user error” with no further structure.
• Remediation register — each closure action, the owner, the deadline, the verification method. An action without a verification method (“we updated training”) reads as performative.

The remediation register is also the section that gets re-read at the next audit cycle. If the closure dates passed and the actions did not, the auditor opens a separate finding on follow-through.

6. The Lessons-Learned Memo

One page. Three questions: what worked, what did not, what changes in the runbook. The point of this section is not to be read once — it is to demonstrate to the auditor that the entity has an institutional memory. SaaS vendors who can show three lessons-learned memos across the last 18 months are read differently than vendors with none.

The Auditor-Ready Checklist

Before you call the packet finished, run it against this list. If any item answers “no” or “maybe,” the packet is not ready.

• Incident Identity Block fits on one page with all five fields populated
• All three regulatory filings retained verbatim with confirmation IDs
• Timeline has at least one entry per hour during the active phase
• Every timeline decision has a named owner (not a team)
• Every annex item is referenced by timeline row number
• Annex items have retention timestamps within the regulator-mandated window
• Root-cause analysis names a control gap, not a person
• Remediation register has a verification method for every action
• At least one item in the remediation register has been closed and verified
• Lessons-learned memo is dated and signed by the lead responder
• The whole packet is in a single retrievable location (not five tools)
• Someone who was not on the incident can locate any section in under 60 seconds

Two of those items — “single retrievable location” and “60-second locate test” — are the ones most vendors fail. The other ten are easier than they look once a template is in place.

How This Pairs With the Rest of Your NIS2 Stack

The Article 23 packet does not sit alone. It is one of three artefacts an auditor expects to see together:

1. The Article 21 self-audit — your stable posture, before any incident.
2. The Article 23 packet — your incident handling, per significant event.
3. A current external-posture grade — what attackers and customers see today.

The fastest way to assemble the packet for the next review is to start with the free incident-readiness template bundle (24h / 72h / 30-day templates plus a tabletop script), populate it once during a dry run, and then hand the completed packet to your customer’s auditor as part of an audit-ready handoff. For the live vendor-review version of this conversation, see how to prove your posture in a NIS2 vendor audit call.

FAQ

Is the packet legally required? The packet format is not specified in NIS2. The evidence it contains is required — Article 23 mandates retention of incident information sufficient to support the final report, and competent authorities are entitled to request it. Auditors and customers operationalise that into the packet.

How long must I retain the packet? Member-state transpositions vary; in Germany the BSI guidance points to a minimum of five years for significant incident records. Plan retention longer than the minimum if the incident touched personal data (GDPR clocks separately).

What if no significant incident has occurred? Then you do not have a packet — but you should have the template, populated through at least one tabletop exercise. Auditors read “we have never had an incident” much more favourably when it is paired with “and here is the drilled-but-unused packet.”

Does an external-posture scan substitute for an incident-response packet? No. A scan addresses the Article 21 posture obligation. The packet addresses the Article 23 incident obligation. Auditors expect both; one does not replace the other.

---

Build the packet before you need it. Start with the NIS2 incident response cornerstone, download the free incident-readiness bundle, and validate the external-posture rows with a free scan. The next post-incident review will be a confirmation, not an investigation.