NIS2 Incident Reporting: Setup Guide for SaaS Vendors

NIS2 Article 23 is one of the most operationally demanding requirements in the directive — and the one most SaaS vendors have no process for. The 24-hour early warning window is tight. The definition of “significant incident” is broader than most teams expect. And the fine for missing the notification deadline is up to €10M.

This guide gives you the setup, the templates, and the checklist to build a compliant incident reporting workflow before an incident happens.

What NIS2 Article 23 Actually Requires

Article 23 establishes a three-stage mandatory notification timeline for significant incidents. The clock starts when you become aware of the incident — not when it began.

Stage	Deadline	What to Report	Recipient
Early Warning	24 hours	Incident detected, preliminary assessment, whether attack is suspected	National CSIRT or competent authority
Incident Notification	72 hours	Nature of incident, initial impact assessment, indicators of compromise, cross-border impact	Same authority
Final Report	1 month	Full description, threat analysis, root cause, applied mitigations, preventive measures	Same authority

Critical distinction: Article 23 does not require you to fix the incident within 24 hours. It requires you to notify authorities that you are aware of it. Documentation of awareness is the legal trigger — not remediation.

What Makes an Incident “Significant”?

Under Article 23(3), an incident is significant if it:

Caused or could cause serious operational disruption or financial losses to your organization
Affected or could affect other natural or legal persons by causing considerable material or non-material damage

For SaaS vendors, the practical triggers are (industry-specific guides: fintech, healthtech, SaaS/cloud):

Data breach affecting customer data → significant
Ransomware encrypting production systems, even without data exfiltration → significant (operational disruption)
Sustained DDoS causing service unavailability to customers → potentially significant
Unauthorized access to production databases → significant, even if discovered retrospectively
Third-party API provider breached in a way that affects your service → assess case by case (covered in our supply chain security guide)

Who to Report To

Report to the competent authority in your country of establishment, not your customers’ countries:

Country	Authority	Portal
Germany	BSI (Bundesamt für Sicherheit in der Informationstechnik)	BSI MELDUNG portal
France	ANSSI	anssi.fr
Netherlands	NCSC-NL	ncsc.nl
Italy	ACN	acn.gov.it
Austria	CERT.at	cert.at

For cross-border incidents affecting services in multiple EU member states, you also notify the relevant authority in each affected country.

5 Components of a NIS2-Compliant Incident Reporting Workflow

1. Detection and Classification System

You cannot report an incident you have not detected. Article 23 implicitly requires an ongoing monitoring capability — otherwise you cannot claim “when you became aware.”

Minimum viable detection stack for a SaaS vendor:

Application error monitoring — Sentry, Datadog, or equivalent. Alert on spike in 5xx errors, authentication failures, or unusual access patterns
Log aggregation — centralized logs with 90-day retention minimum (needed for the final report)
External security monitoring — automated scan that detects changes in your external posture (exposed admin paths, certificate issues, new CVEs in your JS stack)

Classification criteria for “significant”:

Does it affect customer data? → Significant
Does it disrupt service for more than a defined threshold (e.g., >1 hour, >X% of customers)? → Significant
Is it ransomware or a targeted attack? → Significant automatically
Is it contained to internal systems with no customer impact? → Likely not significant, document the decision

2. Incident Log Template

Every incident — significant or not — should be logged from the moment of detection. Here is the minimum template:

INCIDENT LOG
============
Incident ID:        [INC-YYYY-MM-DD-001]
Detection timestamp: [ISO 8601 format]
Detected by:        [System / Person]
Affected systems:   [List]
Initial description: [What happened, from what evidence]
Customer impact:    [Yes / No / Unclear — detail]
Severity:           [Critical / High / Medium / Low]
Significant under NIS2: [Yes / No / Assessment pending]
Reporting officer:  [Name, role]
24h notification due: [timestamp]
72h notification due: [timestamp]
1-month report due:  [timestamp]

--- TIMELINE ---
[timestamp] [action taken / observation]

Document every action with a timestamp. If an auditor asks why you took 26 hours to notify instead of 24, your log needs to show what you knew and when.

3. 24-Hour Early Warning Procedure

The early warning does not need to be detailed. The BSI MELDUNG portal asks for:

Organization name and contact details
Approximate date/time the incident was detected
Brief description of what occurred
Whether it appears to be a cyber attack
Estimated impact (operational disruption, data breach, financial)

Who submits it: Designate a reporting officer (CISO, CTO, or Senior Security Engineer) and a backup. Both must have portal accounts registered before an incident occurs. The BSI portal requires account registration in advance.

If you are unsure whether the incident is significant: Report anyway and note that the classification is pending. Failing to report a significant incident is a violation. Reporting a non-significant incident is not penalized.

4. 72-Hour Incident Notification

The 72-hour notification requires more detail. Prepare to answer:

Technical description: What systems were affected, how access was gained (if known)
Affected parties: Number of customers impacted, geographic distribution
Data exposure: Categories of data involved (personal data, customer business data, credentials)
Cross-border impact: Does the incident affect customers in other EU member states?
Indicators of compromise: IP addresses, file hashes, malware signatures if applicable
Containment status: What actions have been taken since detection

If you cannot answer all questions at 72 hours, submit what you have and note “investigation ongoing.” The authorities understand that complex incidents take time to analyze.

5. 1-Month Final Report Structure

The final report is the full post-mortem formatted for regulators. Required sections under NIS2 Article 23:

Detailed description — what happened, step by step, with timestamps
Threat actor analysis — if identified: attribution, TTPs (tactics, techniques, procedures), motivation
Root cause — the technical and process failures that allowed the incident
Scope of impact — final count of affected users, data categories, service disruption duration
Mitigations applied — what you changed during the incident to contain it
Preventive measures — what you are changing post-incident to prevent recurrence
Ongoing actions — if mitigation is still in progress

3 Incidents SaaS Vendors Most Commonly Mishandle

1. Third-Party API Breach

A payment processor or identity provider you depend on is breached. Are you the victim or the operator?

The answer: You are likely both. As an ICT service provider, your customers depend on the availability and integrity of your service. If the third-party breach caused your service to be unavailable or data to be exposed, you are responsible for reporting under NIS2 — regardless of whether the root cause was your infrastructure or a supplier’s.

Action: Your supply chain security assessment under Article 21(2)(d) should define contractual incident notification requirements with critical vendors. If your payment processor doesn’t notify you within 2 hours of a breach, your 24-hour window is already compromised.

2. Ransomware With No Data Exfiltration

A ransomware attack encrypts your backups and internal systems but customer-facing services remain operational and no data was exfiltrated.

Is it significant? Yes. Ransomware represents a serious operational disruption even if customer data was not exposed. The ENISA NIS2 incident reporting guidelines are explicit: operational disruption to your own organization counts, not just customer-facing impact.

Report the incident. Explain in the 72-hour notification that customer services were not disrupted and no data was exfiltrated — this context matters for the authority’s severity assessment.

3. Unauthorized Access Discovered Retrospectively

Your log analysis reveals that an attacker had read access to a database for 3 weeks. You discover this today.

When does the 24-hour clock start? From today — the moment you became aware. Not 3 weeks ago when the access began.

Document precisely when the discovery occurred, who made it, and what evidence triggered the investigation. Your incident log timestamp from the moment of discovery is your legal reference point. Connect this to your NIS2 audit preparation evidence package — retrospective access discoveries are exactly why continuous monitoring and log retention matter.

Your Incident Reporting Evidence Package

The incident reporting workflow does not operate in isolation. It connects directly to your pre-incident security posture.

When an incident occurs, authorities will ask: “What security measures did you have in place?” Your ability to answer this question — with evidence — determines whether the incident is treated as an isolated failure or a systemic negligence finding.

The evidence package that matters:

External security scan from before the incident — proves your security headers, certificate configuration, and DMARC policy were in place. An automated scan result with a date stamp is objective evidence that the Article 21 technical controls were implemented
NIS2 compliance report — shows which Article 21(2) controls passed at the time of the incident
Scan history — demonstrates continuous monitoring, not a one-time check before an audit

A vendor who can show a Grade B external posture scan from the week before an incident is in a fundamentally stronger legal position than one who cannot demonstrate any pre-incident monitoring. The same logic applies for B2B SaaS vendors facing supply chain cascade audits — your buyer’s NIS2 obligations cascade to you.

Run your baseline scan at saasfort.com/scan — free, no account required. New accounts get a 14-day Growth trial (50 scans/month, NIS2 export, multi-domain) with no credit card required. The NIS2 compliance PDF is what you attach to your final incident report.

NIS2 Incident Reporting Checklist — Article 23

Run through this before an incident happens, not during one:

FAQ

Q: What counts as a “significant incident” for a SaaS company?

Under NIS2 Article 23(3), an incident is significant if it causes serious disruption to services or financial losses. Practical triggers for SaaS: a data breach affecting customer data, ransomware encrypting operational systems, a sustained DDoS causing service unavailability, or unauthorized access to production databases. When in doubt — report. The penalty for reporting a non-significant incident is zero.

Q: Can I report in English to the BSI?

Yes. The BSI MELDUNG portal accepts reports in German and English. The notification forms are available in both languages. If the incident is complex and your legal team drafts the notification, English is acceptable.

Q: What happens if I miss the 24-hour notification window?

Missing the early warning deadline is itself an NIS2 violation, separate from the underlying incident. Fines: up to €10M for essential entities, up to €7M for important entities under Germany’s NIS2UmsuCG implementation. Document why the delay occurred — authorities distinguish between a 26-hour notification with a documented reason and a 5-day notification with no explanation.

Q: Does Article 23 apply if I’m a SaaS vendor serving NIS2-regulated customers but not in scope myself?

Directly, only if you are yourself an “important” or “essential” entity. But your enterprise customers who are in scope are required under Article 21(2)(d) to assess your incident response capabilities as part of their supply chain security. Expect security questionnaires to include incident notification requirements, contractual SLAs for notifying customers within 4-8 hours of incidents, and requests for your incident response plan as standard procurement terms. Building the workflow described here positions you to answer these questions — and close deals faster.

Build your pre-incident evidence package now: saasfort.com/scan — 60 checks, A–F grade, NIS2 Article 21 compliance PDF. 14-day Growth trial free, no credit card. Download our free SaaS Security Playbook 2026 for the full incident-response framework. Related: NIS2 CEO liability guide | NIS2 October 2026 deadline action plan | NIS2 compliance checklist for German SMBs