NIS2 Article 23 Reporting: What to Send in 24h, 72h, and 30 Days (EU SMEs)

Most incidents don’t start with a dramatic “we got hacked.” They often start with subtle signs, such as slower service, unusual login activity, or customer inquiries about irregularities. This often leads to the question: “Is this reportable under NIS2?”

If your organisation falls under NIS2 (check applicability here), the main challenge is not understanding the law, but responding quickly and effectively while your team manages the incident.

This guide offers a practical workflow for Article 23 incident reporting, tailored for SMEs, and includes templates for direct use in your national portal.

See more: NIS2 Compliance Readiness for EU.

TL;DR: What is the NIS2 24–72–30 timeline?

If you become aware of a significant incident, Article 23 expects staged reporting:

• Within 24 hours: early warning (a credible heads-up)
• Within 72 hours: incident notification (initial assessment + impact)
• Within 30 days: Final report (root cause, mitigations, and changes implemented)

Think of it like this:

• 24h: “This looks serious and we’re acting.”
• 72h: “Here’s what we know so far and what it means.”
• 30 days: “This is the complete account and the improvements implemented.”

Quick check to see you in scope of NIS2.

Step 1 — Make a prompt decision: is this a “significant incident”?

This is where SMEs lose time—not from laziness, but from uncertainty. A practical approach is to hold a 10-minute “significance huddle”:

• Incident lead (IT/Security) brings facts
• Business owner (CEO/COO) makes the call
• One person captures the decision trail

Ask three questions:

1. Could this seriously disrupt operations?
2. Could it cause meaningful financial loss?
3. Could it materially affect customers or partners?

If the answer to any question is “possibly, yes,” treat the incident as significant until you can confirm otherwise.

Tip: If you have not already, begin with the NIS2 readiness checklist for EU SMEs. This helps establish key elements such as roles, evidence, and controls before an incident occurs.

Step 2 — What to send within 24 hours (Early Warning)

The 24-hour update is not a forensic report. It’s a clear, calm signal. A good early warning covers:

• what you’re seeing (facts only)
• what’s affected
• what you’re doing right now
• whether malicious activity is suspected (or unknown)
• whether cross-border impact may exist (if applicable)
• when you will update next

The objective is to demonstrate credibility and control, without overstating your knowledge.

Step 3 — What to send within 72 hours (Incident Notification)

By 72 hours, you usually have enough signal to share a first real assessment. Your incident notification should include:

• initial view of severity and impact
• what systems/services are affected
• whether data/confidentiality/integrity is involved
• what you’ve done so far (containment, mitigation, recovery)
• IoCs where available (IPs/domains/hashes/accounts)
• what you’ll do next (monitoring, next update)

If indicators of compromise are not yet available, state this clearly in your report. What matters is: you’re gathering evidence in a structured way.

Step 4 — The final report (within 30 days): tell the full story

The final report demonstrates your organisation’s maturity in incident response. Use this structure:

1. What happened (timeline + severity + impact)
2. Likely root cause / threat type
3. Mitigations applied (and ongoing)
4. Cross-border impact (if applicable)
5. What changed (lessons learned + improvements)

At this stage, broader controls such as incident handling, monitoring, access management, and supplier risk management are important. For a practical overview of baseline measures, refer to Article 21 security measures in plain English.

The SME advantage: build an “evidence pack” from minute one

Most reporting problems come from one simple issue: facts are scattered. Create a single “Incident Reporting Pack” (folder or case) that includes:

A) Timeline

• first detection time
• “awareness time”
• key actions with timestamps

B) Impact snapshot

• affected systems/services
• number of users or customers impacted (an estimate is acceptable initially)
• downtime/degradation window
• financial exposure (approximate range)

C) Working narrative

• your current understanding of the incident (with version history)
• what’s still unknown (explicit)

D) Technical artefacts

• references to relevant logs (not raw data dumps)
• IoCs (when available)
• containment actions taken

E) Decisions & approvals

• who declared it significant
• who approved comms
• who submitted what, when

This approach shifts your response from reactive to demonstrable, which is essential for regulators and enterprise customers.

Templates (copy/paste)

Template 1 — 24h Early Warning

Subject: NIS2 Early Warning — Potential Significant Incident (Company / Service)

Organisation

• Entity name:
• Sector:
• Primary contact (24/7):
• Alternate contact:

What happened (facts only)

• First detected:
• Became aware:
• Affected service/system:
• Current status: ongoing / contained / investigating

Why it may be significant

• Operational disruption: yes/no (why)
• Financial impact likely: yes/no (range)
• Customer/partner impact likely: yes/no

Suspected characteristics

• Malicious activity: yes/no/unknown
• Potential cross-border impact: yes/no/unknown

Actions taken

• Containment steps:
• Mitigation steps:
• Next update ETA:

Template 2 — 72h Incident Notification

Subject: NIS2 Incident Notification (72h) — Significant Incident Update

Summary (max 5 lines)

• What happened:
• What’s impacted:
• Current status:
• Key risk:
• Next actions:

Initial severity & impact

• Availability impact:
• Confidentiality/integrity impact:
• Affected users/customers:
• Duration:
• Notable harm indicators:

Technical details

• Suspected/confirmed vector:
• Systems involved:
• IoCs (if available):
• Evidence pointers (logs, ticket IDs, etc.):

Mitigation & recovery

• Containment:
• Eradication:
• Recovery:
• Monitoring:

Dependencies / cross-border (if applicable)

• Countries potentially impacted:
• Key suppliers/providers involved:

Template 3 — Final Report (within 30 days)

1. Detailed incident description (severity + impact)
2. Likely root cause / threat type
3. Mitigations applied + ongoing
4. Cross-border impact (if applicable)
5. Lessons learned + improvements implemented

Lightweight RACI (to maintain clarity and avoid confusion)

• Incident Lead (Accountable): Head of IT / Security lead
• Business Owner (Approves): CEO/COO
• Legal/Compliance (Consulted): obligations + records
• Comms (Consulted): customer-facing messaging
• Engineering/Ops (Responsible): containment + recovery
• External support (Support): IR / forensics / reporting help

For SMEs, simplicity is key. Clear processes enable faster response.

Common mistakes and how to avoid them

1. Waiting for certainty → missing the 24h window
2. Not recording “awareness time” → timeline becomes arguable
3. Mixing response work with reporting work → one gets dropped
4. No version control → facts drift across teams
5. No single narrative → reports become fragments, not assessments

Would you like a ready-to-use reporting pack?

We can help you turn this playbook into an evidence-backed workflow your team can run under pressure. 24–72–30 reporting templates customized for your environment. Evidence pack structure and defined roles (RACI) to ensure efficiency.

• ISO 27001-minded delivery process • GDPR-aware by design • Experience supporting ISO 27001

Book a Compliance Readiness call

About Sunbytes: Transform · Secure · Accelerate

Sunbytes is founded on three interdependent pillars:

• Transform: We help teams modernise products and delivery—so digital growth doesn’t come with hidden fragility.
• Secure: We make cybersecurity practical and operational, integrating risk management into your delivery processes.
• Accelerate: We help organisations scale with the right people and systems, maintaining both quality and compliance as you grow.

When these three pillars work together, you achieve more than compliance. You create a delivery engine that operates efficiently and withstands regulatory scrutiny, especially during incident response.