NIS2 Article 23 Field Map: Scan vs Template Split

A SaaSFort scan covers about 5 percent of what NIS2 Article 23 actually demands when you submit an incident notification. The other 95 percent has to be written by a human under time pressure — usually with the BSI Meldeportal open in one window and a Slack channel screaming on the other side.

This article is the honest field map. Every Article 23 evidence field, what the scanner can supply, what the incident-readiness template covers, and how each maps to the German BSI Meldeportal structure.

If you maintain a different position internally — that scans somehow auto-generate incident reports — your first auditor reading the output will catch it. Better to know now.

The Honest Split: 5% Scanner, 95% Template

Article 21 (preventive controls) and Article 23 (incident reporting) answer different questions for different readers. They share NIS2 vocabulary; they do not share evidence.

Question	Article 21	Article 23
What does this answer?	Controls in place, point-in-time	What happened, when, who was hit, what you did
Reader	Auditor pre-event	Regulator post-event
Evidence type	Preventive	Reactive
Generated by scan?	Yes (60 of 60 mapped checks)	No (0 of 60 mapped checks)

Our Article 23 gap analysis walks the underlying technical reasoning. The conclusion is structural: scans observe outside-in posture; incidents are detected via logs, EDR, SIEM, and customer reports — inside-out signals the scanner has no access to. The 24-hour clock starts on internal awareness, not on a scheduled check.

That structural split is exactly what the incident-readiness template is built to fill.

The Article 23 Field Map

NIS2 Article 23 (combined with the BSI Meldeportal implementation) requires 16 evidence fields across the three submission stages. Here is each one, with honest sourcing.

#	Article 23 field	Scan supplies?	Template supplies?	Notes
1	Date/time of awareness	No	Yes	Highest-stakes field. Nobody computes it correctly under stress. Fillable in the awareness-clock worksheet.
2	Incident classification (ENISA RSI taxonomy)	No	Yes	7 categories, dropdown in template.
3	Severity / impact level	No	Yes	Operational, financial, reputational dimensions.
4	Affected services & assets	No	Yes	Scan sees one external domain — does not know your internal asset graph.
5	Number of users affected	No	Yes	Zero user-telemetry signal in scan.
6	Duration of disruption	No	Yes	Scan timestamp ≠ incident timeline.
7	Geographical spread	No	Yes	Not modeled by scanner.
8	Threat indicators (IPs, hashes, domains, MITRE TTPs)	Partial (5%)	Yes	Scan finds exposures (CVE in JS lib, exposed .git, source maps), not live IoCs. Template has full IoC ledger.
9	Suspected malicious cause	No	Yes	Scanner cannot distinguish malicious from misconfiguration.
10	Cross-border element	No	Yes	Multi-CSIRT routing if multiple member states affected.
11	Mitigation actions taken	No	Yes	Reactive, post-event.
12	Recovery / BCP-DRP / RTO-RPO actuals	No	Yes	Out of scanner scope entirely.
13	Root cause analysis (final report)	No	Yes	Requires log forensics.
14	Lessons learned	No	Yes	Post-incident artifact.
15	Notification audit trail (24h/72h/1-month clock)	No	Yes	The awareness-clock worksheet is the audit trail.
16	Internal escalation / comms log	No	Yes	Pre-formatted ledger in template.

Coverage: scanner ≈ 5 percent, template ≈ 95 percent. The 5 percent is real but adjunct: scan output gives you a credible “control regression observed at T=…” line in the early warning, plus a pre-incident exposure register that anchors RCA later.

BSI Meldeportal Field Mapping (CSIRT Format)

For German entities, Article 23 submissions go through the BSI Meldeportal. The Meldeformular structure is its own bureaucratic dialect — knowing how Article 23 fields map to BSI’s field names saves hours during the first 24 hours.

Article 23 evidence	BSI Meldeportal field (DE)	English equivalent
Date/time of awareness	Zeitpunkt der Kenntnisnahme	Time of awareness
Incident classification	Art des Sicherheitsvorfalls	Type of security incident
Severity / impact	Auswirkung auf den Betrieb	Operational impact
Affected services & assets	Betroffene Systeme und Dienste	Affected systems and services
Number of users affected	Anzahl betroffener Nutzer	Number of affected users
Duration of disruption	Dauer der Beeinträchtigung	Duration of disruption
Geographical spread	Geografische Ausbreitung	Geographic spread
Threat indicators	Indikatoren der Kompromittierung	Indicators of compromise
Suspected cause	Vermutete Ursache (vorsätzlich/zufällig)	Suspected cause (deliberate/accidental)
Cross-border element	Grenzüberschreitende Auswirkung	Cross-border impact
Mitigation taken	Bisher ergriffene Gegenmaßnahmen	Mitigation actions to date
Recovery / RTO-RPO	Wiederherstellungsstatus	Recovery status

Trap: the Meldeportal accepts free-text fields, but BSI parses them with structured expectations. Vague entries trigger follow-up requests that compress your 72-hour window. The template’s pre-written field-by-field guidance is calibrated to the wording BSI’s CSIRT analysts are reading for.

The non-German member states use comparable national CSIRT portals — France ANSSI, Italy ACN, Spain CCN-CERT. Multi-jurisdiction filing is covered in our MSP NIS2 compliance guide.

The Awareness Clock — Three Deadlines, One Worksheet

The single highest-leverage field in Article 23 is also the one teams compute incorrectly under stress. The clock starts at awareness, not at detection. Awareness is when your organization’s responsible function recognized the incident is significant — typically a documented escalation moment, not the first alert ping.

The three deadlines, computed from awareness:

Stage	Formula	What gets submitted
Early warning	awareness + 24h	Acknowledgement of awareness, preliminary nature, suspected attacker (if known)
Incident notification	awareness + 72h	Initial impact assessment, IoCs, cross-border effect
Final report	notification + 1 month	Root cause, mitigation applied, preventive measures

The awareness-clock worksheet inside the incident-readiness template pre-computes these for you with timezone normalization (BSI runs on CET/CEST; multi-region SaaS teams on UTC). Five fillable fields:

• incident_detected_at (your monitoring/alert timestamp)
• awareness_declared_at (the human escalation moment — this is the clock-start)
• early_warning_due_at (= awareness + 24h)
• notification_due_at (= awareness + 72h)
• final_report_due_at (= notification + 30d)

The detection-vs-awareness distinction is what auditors will probe most. Documenting awareness in writing — with timestamp, who escalated, what evidence triggered escalation — is the single best investment in the first hour. Without it, a regulator defines awareness for you, less generously, after the fact. For the broader 24-hour notification breakdown, see our BSI 24-hour template + tabletop guide.

Internal Communications Log Format

Article 23 expects an audit trail of internal communications during the incident response. BSI inspections under §29 BSIG consistently request this log even when the formal Article 23 submission is complete.

The minimum-viable log structure (pre-formatted in the template):

timestamp	actor	action	recipient	channel
2026-05-02T21:47Z	on-call SRE	escalated suspected ransomware in prod-eu-west-1	CTO	PagerDuty
2026-05-02T21:51Z	CTO	declared awareness, started 24h clock	CEO, CISO	phone
2026-05-02T22:04Z	CISO	notified external IR retainer	external IR firm	email

Five fields, append-only, never deleted. The auditor question that breaks unprepared teams: “Show me when leadership was first told.” If the answer requires forensic Slack reconstruction, the company has already lost the framing.

How This Connects to the Incident-Readiness Template

The field map above is the index. The free incident-readiness bundle is the executable form. It includes:

• The 24h / 72h / 1-month notification templates (DE + EN, .docx)
• The awareness-clock worksheet (fillable)
• The internal-comms log (pre-formatted ledger)
• A tabletop exercise with three scenarios (ransomware, supply-chain, data exfiltration)
• The CSIRT-format mapping above as a printable one-pager

The bundle is email-gated, free, no credit card. New SaaSFort accounts also receive a 14-day Growth trial automatically — useful because the scan output supplies the 5 percent that is derivable: pre-incident exposure baseline, control regression detection between scans, and remediation evidence in the final report (Article 23 final reports require “measures applied to prevent recurrence” — a closed-gap scan is reusable evidence).

For broader context on where Article 21 evidence comes from, the NIS2 Article 21 self-audit template covers the preventive side of the same compliance program.

FAQ

Why doesn’t SaaSFort just generate Article 23 reports automatically?

Because the data isn’t there to generate. Article 23 evidence comes from internal logs, EDR, SIEM, customer reports, and human judgment about classification and impact. An external scanner has no path to those signals. We could fake it, but the first auditor would catch it. Templates are the honest answer.

Is this field map BSI-specific or does it apply to all EU member states?

The 16 evidence fields apply across all NIS2 implementations — they come from the Directive itself. The Meldeportal field-name mapping is BSI-specific (Germany). For ANSSI (France), ACN (Italy), and CCN-CERT (Spain), the field structures are similar but with different bureaucratic dialect; the underlying evidence is the same.

What if my company experienced a “near miss” — do I still notify?

Article 23 only triggers on significant incidents — operational disruption, financial loss, or considerable damage to other persons. A near miss without disruption typically does not trigger notification. Document it internally regardless: future inspections look for evidence of mature triage, not just submitted reports.

Can the awareness clock be reset if new information emerges?

No. Once awareness is documented, the clock runs. New facts go into the 72-hour notification or final report. Resetting awareness retroactively is a credibility-destroying move under inspection — auditors specifically test for it.

My company is a sub-50-person SaaS vendor selling to NIS2-scoped buyers. Does Article 23 apply to me?

Directly, only if you are independently in scope. Cascading: yes — your customer’s Article 21(2)(d) supply-chain obligation will pull notification timelines and evidence from you contractually. The same template works for both direct and cascade obligations. See our B2B SaaS supply chain compliance guide.

What’s the relationship between Article 23 and GDPR’s 72-hour breach notification?

They overlap on personal-data incidents but operate independently. NIS2 Article 23 goes to BSI / national CSIRT; GDPR Article 33 goes to the data protection authority. The same incident may trigger both notifications on different deadlines. Our NIS2 vs GDPR guide covers the dual-track filing strategy.

---

Templates document. Scans verify. Together they cover Article 21 and Article 23. Download the free incident-readiness bundle — 24h/72h/1-month templates, awareness-clock worksheet, internal-comms log, tabletop exercise, BSI Meldeportal field-map. New accounts also get a 14-day Growth trial — run a baseline scan to lock in your pre-incident exposure register. For the complete framework, download our free SaaS Security Playbook 2026.