sota.io
2026-05-05·15 min read·
## NIS2 Is in Force — and Your Incident Response Architecture Probably Isn't Ready NIS2 (Directive 2022/2555) became applicable across EU member states in October 2024. Every entity in scope — essential or important — now faces legally binding incident reporting obligations under Article 23. Yet the most common gap in SaaS developer teams is not awareness of the law but operational readiness: when a real incident happens at 2 AM, can you actually produce a coherent notification to your national CSIRT within 24 hours? The answer for most teams is no, because NIS2 Art. 23 compliance is not a policy exercise — it is an engineering exercise. It requires automated detection pipelines, structured log retention, pre-drafted notification templates, and clear escalation paths that can run without key-person dependency in the middle of the night. This guide translates Art. 23's three-phase notification timeline into a concrete technical implementation checklist you can work through before your next incident. ## What Art. 23 Actually Requires: The Three-Phase Timeline NIS2 Art. 23(1) establishes a cascading notification obligation triggered whenever an entity experiences what the directive calls a "significant incident": **Phase 1 — Early Warning: within 24 hours** Within 24 hours of becoming aware of a significant incident, you must submit an early warning to your national CSIRT (or competent authority). The early warning must include: whether the incident appears to be the result of unlawful or malicious acts, whether it could have cross-border impact, and the initial nature and scope of the incident. The 24-hour clock starts from the moment your organisation becomes *aware* of the incident — not when the incident began. This distinction matters enormously. If your alerting system detects anomalous behaviour but no human reviews it for six hours, ENISA guidance suggests the clock starts when the alert was generated, not when someone looked at it. **Phase 2 — Incident Notification: within 72 hours** Within 72 hours, you must submit a more detailed incident notification covering: a preliminary assessment of severity, likely causes, applied and ongoing mitigation measures, and cross-border impact where applicable. Member states may also require intermediate updates. **Phase 3 — Final Report: within one month** The final report must include a full description of the incident, the type of threat or root cause, applied mitigation, cross-border impact, and where applicable, lessons learned. The practical challenge is that the 24-hour and 72-hour deadlines run concurrently. You are building the Phase 2 report while simultaneously managing the active incident and completing Phase 1. ## What Counts as a "Significant Incident" Under NIS2 Art. 23(1) ties the reporting obligation to "significant incidents" but delegates the definition to Art. 23(3), which defines significance by criteria including: - The incident causes or could cause **severe operational disruption** or **financial losses** for the entity concerned - The incident has or could have a **significant impact on other natural or legal persons** — a particularly important threshold for SaaS providers, since impact on your customers triggers your reporting obligation even if your internal systems are unaffected - The incident **affects the availability, authenticity, integrity or confidentiality** of network and information systems - The incident involves a **supply chain compromise** affecting downstream entities For SaaS developers, the second and fourth criteria are the most legally significant. A compromise of a shared authentication component, a database breach exposing customer records, or a supply chain attack via a compromised npm dependency can all trigger Art. 23 obligations even if no financial loss to your organisation is immediately apparent. ENISA's incident taxonomy (aligned with NIS2) identifies the following categories as likely to meet the significance threshold: ransomware affecting production, data exfiltration of any non-public data, DDoS causing availability loss above a certain duration, cryptomining via supply chain injection, and insider threat with data access. Your incident classification policy should map your alert categories to these. ## Who to Report To: CSIRTs, NCAs and the Notification Chain NIS2 Art. 8 designates national competent authorities (NCAs) and Art. 10 establishes national CSIRTs. Most member states have designated sector-specific NCAs — for example, BaFin for German financial entities and BSI for the general ICT sector — alongside a national CSIRT (BSI-CERT for Germany, CERT-FR for France, NCSC for the Netherlands). For SaaS providers operating in multiple EU member states, the reporting destination depends on your classification as essential or important entity and your primary establishment. For entities with significant cross-border impact, Art. 23(6) requires coordinated notification across affected member states' CSIRTs via ENISA's facilitation role. The practical implication: your incident response runbook must have CSIRT contact details pre-populated, including the secure submission channel (typically a national portal or encrypted email), the required format (most CSIRTs publish a notification template), and the escalation chain for cross-border incidents. Discovering these details during an active incident adds hours you cannot afford. ## Technical Architecture: What Logs to Keep and How Long NIS2 Art. 21(2)(a) requires entities to implement "policies and procedures for risk analysis and information system security" which encompass logging requirements as a security measure. Recital 79 makes clear that logs supporting incident investigation are part of adequate security. The German BSI's implementation guidance (BSI-Mindeststandard) requires centralised log collection with tamper-evident storage. **Minimum log retention architecture for NIS2 compliance:** Authentication events: at least 90 days hot, 12 months cold. Every login success, failure, privilege escalation, and API key usage. Include source IP, user agent, session ID, and timestamp in UTC with timezone offset. Application access logs: all API requests with response codes and latencies. Minimum 90 days hot. These are your primary evidence for data exfiltration scope assessment. Infrastructure events: cloud provider audit logs (AWS CloudTrail equivalent, VPC flow logs, network ACL changes). These are essential for determining the blast radius of a compromise. 12 months cold minimum. Change management logs: all deployments, configuration changes, and dependency updates. These are critical for supply chain incident analysis. Many ransomware and supply chain incidents begin with a config change or dependency update — your logs must cover this. Security events: WAF blocks, IDS alerts, failed API authentication, rate limit triggers. 90 days minimum. **Storage requirements:** Logs must be stored in a way that preserves integrity. This means either cryptographic signing of log batches or write-once storage with access logging. An attacker who achieves code execution can delete logs unless they are forwarded to an immutable destination before the host is compromised. A sidecar log forwarder writing to a separate account or region — not accessible from your application runtime — is the minimum viable architecture. ## Building an Automated Detection Pipeline That Starts the Clock The 24-hour early warning obligation only starts when you become *aware* of an incident. But regulators increasingly interpret "aware" to mean when your monitoring systems generated an alert, not when a human reviewed it. This interpretation is consistent with NIS2's requirement that entities have adequate detection capabilities as part of Art. 21 security measures. The consequence: if your alerting pipeline fires at 3 AM and sends an alert that sits unread until 9 AM, you have potentially consumed six of your 24 hours before anyone starts the early warning process. **Detection pipeline design for NIS2 timeline compliance:** Tier 1 — Automated detection (within 5 minutes): Your SIEM or anomaly detection system fires an alert. This is when the NIS2 clock arguably starts. Your pipeline should immediately log the detection event with a UTC timestamp and alert ID to a tamper-evident store. Tier 2 — Automatic enrichment (within 15 minutes): The alert automatically collects: affected systems list, estimated user/customer count, initial blast radius assessment, relevant log excerpts. This enrichment should run as an automated workflow, not a manual process. The output populates your Phase 1 early warning template. Tier 3 — Human escalation (within 30 minutes from detection): Your on-call rotation receives a page with the pre-populated early warning draft. The on-call engineer reviews and submits the Phase 1 notification. With automated enrichment, this should take under 30 minutes — not 6 hours. Tier 4 — Parallel investigation (hours 1-72): The detailed investigation runs in parallel with your Phase 1 submission, not sequentially. Your Phase 2 notification is built continuously as investigation progresses, not written from scratch at hour 71. **Paging and escalation requirements:** Your paging system must be able to wake someone at 3 AM. Slack-only alerting is not sufficient — incidents do not respect business hours. PagerDuty, OpsGenie, or equivalent with phone escalation is required. Your on-call rotation must have someone who can make the CSIRT submission decision without waiting for management approval. Pre-authorise the on-call role to submit the early warning. ## What Your Phase 1 Early Warning Template Must Include NIS2 Art. 23(4)(a) specifies that the early warning must state: whether the incident is suspected to be caused by unlawful or malicious acts, whether it could have a cross-border impact, and the initial nature and scope. ENISA's implementing guidance adds that early warnings should follow the national CSIRT's preferred format. Pre-populate a template with your organisation's standard fields so that during an incident you are filling in event-specific details only: ``` EARLY WARNING — [ORGANISATION NAME] Submission time: [UTC timestamp] NIS2 Classification: [Essential / Important Entity] Sector: [your NIS2 sector] National CSIRT: [CSIRT name, country] Incident detected: [UTC timestamp] Incident type: [Data breach / Ransomware / DDoS / Supply chain / Other] Affected systems: [list] Estimated affected users/customers: [count or range] Malicious/unlawful act suspected: [Yes / No / Unknown] Cross-border impact potential: [Yes / No / Unknown — member states: list] Initial scope assessment: [1-3 sentences] Containment status: [Contained / Ongoing / Unknown] Contact: [Name, role, phone, encrypted email] Next update expected: [timestamp, must be within 72h from incident awareness] ``` Having this template in your runbook — accessible without network access, since your incident may involve infrastructure compromise — reduces Phase 1 submission time from hours to minutes. ## Contract Clauses: What to Demand from Cloud Providers Your cloud provider's incident notification obligations flow into your NIS2 Art. 23 obligations. If your cloud provider experiences a security event affecting your infrastructure, you need to be notified in time to meet your own 24-hour early warning deadline. Art. 21(3) and Recital 85 of NIS2 make clear that supply chain security — including security of cloud providers — is part of your obligations. Minimum contractual requirements from your cloud provider: **Incident notification SLA:** Provider must notify you within 4 hours of detecting any incident affecting your environment or shared infrastructure. 4 hours leaves you 20 hours for Phase 1. 24-hour provider SLAs (common in standard DPA templates) consume your entire early warning window. **Scope of notification:** Provider must notify you of incidents affecting: your account directly, shared control plane components, hypervisor or network layer with potential impact on your workload, and any exfiltration of your data from provider infrastructure. **Log access:** You must have access to all infrastructure-level logs relevant to your workload within 1 hour of requesting them during a security incident. This is non-negotiable — you cannot assess blast radius without hypervisor, network flow, and control plane logs. **CSIRT cooperation:** Provider must cooperate with your national CSIRT investigation including providing technical logs and forensic artefacts within the timeframes your CSIRT specifies. **Jurisdiction of CSIRT notification:** If your provider experiences an incident and must themselves notify a CSIRT, you need to know which CSIRT they are reporting to so your notification is coordinated rather than duplicated or contradictory. EU-native providers operating exclusively in EU member states simplify this considerably: there is a single regulatory jurisdiction, a single CSIRT contact chain, and no ambiguity about data access by non-EU governments during incident investigation — a relevant factor given that US government legal process can compel cloud providers to produce forensic data without notifying you. ## The Developer Compliance Checklist: 12 Concrete Actions **Detection and alerting (complete before your next incident):** 1. Implement centralised log aggregation with tamper-evident storage (separate from your application runtime). Verify that log forwarding runs as a sidecar, not in-process. 2. Configure automated alerts for: failed authentication spikes (> 10x baseline), data volume anomalies (exports significantly above baseline), privilege escalation events, and any access to production credentials from CI/CD pipelines. 3. Ensure your paging system has phone escalation for P1 alerts and that on-call engineers have authority to submit CSIRT early warnings without management approval. 4. Test your detection pipeline by running a controlled red team exercise and measuring: time from simulated attack to alert, time from alert to on-call page, time from page to CSIRT submission readiness. **Documentation and templates:** 5. Pre-populate your Phase 1 early warning template with your organisation's standard fields. Store it offline (not only in systems that may be affected by the incident). 6. Pre-populate your Phase 2 incident notification template with standard fields. Include links to your log aggregation system, your CSIRT contact details, and your escalation chain. 7. Document which national CSIRT you report to and which NCA, including secure submission portal URL and encrypted contact. Many member states have online portals for NIS2 notifications — ENISA maintains a registry. 8. Ensure your data processing register (GDPR Art. 30) is current — you will need it to assess which personal data was potentially affected and whether GDPR Art. 33 notification is also triggered. **Contractual and supply chain:** 9. Review your cloud provider DPA and MSA for incident notification SLAs. If the notification SLA is > 4 hours, renegotiate or switch providers. Document the current SLA in your risk register. 10. Review your critical SaaS dependencies (authentication, payment, CDN, DNS) for their incident notification obligations. A compromise of your auth provider is a significant incident for you regardless of whether your systems are directly affected. **Verification:** 11. Conduct a tabletop exercise of a realistic incident scenario (e.g., database credential exfiltration via a compromised CI/CD pipeline). Walk through the full Art. 23 timeline. Identify where the process breaks and fix those gaps. 12. Review your incidents from the past 12 months and assess retrospectively whether any would have met the NIS2 significance threshold. If yes, document what your notification would have looked like. This is both a compliance exercise and a preparation exercise. ## Cross-Border Incidents: Multi-Jurisdiction Notification If your SaaS has customers in multiple EU member states and your incident could affect them, you face coordinated notification obligations across member state CSIRTs under Art. 23(6). ENISA facilitates this via its CSIRT Network, but you must proactively identify which member states are affected and trigger the notification chain. In practice: maintain a data map that shows which customer data resides in or is accessible from which member state, so that when an incident occurs you can rapidly assess whether it triggers single-jurisdiction or multi-jurisdiction reporting. If you are on a US cloud provider with EU region designation but US-parent jurisdiction, the multi-jurisdiction question is more complex — a US government legal process demanding your data does not become a NIS2-reportable incident in isolation, but the resulting data exposure may. EU-native cloud deployment eliminates this ambiguity. Your data does not touch US jurisdiction, your incident investigation operates under EU CSIRT authority, and your notification chain is unambiguous. ## Supply Chain Incidents: When Your Dependency Is the Breach NIS2 Recital 85 and Art. 21(3) explicitly require entities to address supply chain security as part of their security measures. This has direct implications for incident reporting: a significant incident originating in your dependency chain — an npm package compromise, a SaaS vendor breach, a cloud provider incident — triggers your Art. 23 reporting obligation. The practical requirement: your incident response runbook must include a supply chain incident pathway. When you receive a security advisory about a dependency or a notification from a vendor, your triage process must assess whether it meets the NIS2 significance threshold for your organisation and trigger Art. 23 reporting if so. Maintain a supply chain security register that lists your critical dependencies, their security contact channels, and the timeline in which you expect to receive incident notifications from them. This register is also useful for demonstrating your Art. 21(3) compliance to auditors. ## EU-Native Deployment and the Single CSIRT Jurisdiction Advantage When your infrastructure runs entirely in EU member states — on EU-parent cloud providers not subject to US CLOUD Act jurisdiction — your NIS2 incident reporting chain has a clear, unambiguous structure: - Your national CSIRT is the primary notification recipient - Your cloud provider's incident notifications are governed by EU law, not US discovery requests - Log access during incident investigation is not subject to US government compulsion without your knowledge - ENISA coordinates cross-border incidents through the EU CSIRT Network without extra-EU jurisdiction complexity US-parent cloud providers with EU region designations offer geographic data residency but not jurisdictional separation. The CLOUD Act allows US federal agencies to compel US-parent providers to produce data held in EU regions without notifying the EU account holder. If this occurs during an active NIS2 incident, your forensic investigation and your CSIRT notification may be based on incomplete evidence you did not know was missing. For SaaS developers building compliance-critical products — particularly in the financial services, healthcare, and public sector verticals that NIS2 identifies as essential entities — the jurisdictional clarity of EU-native infrastructure is a material risk reduction, not a checkbox. ## What Happens If You Miss the 24-Hour or 72-Hour Deadline NIS2 Art. 36 allows member states to impose administrative fines for NIS2 violations. For essential entities, the maximum fine is €10 million or 2% of global annual turnover (whichever is higher). For important entities: €7 million or 1.4% of global turnover. The breach of Art. 23 reporting obligations — submitting late, submitting an incomplete early warning, or failing to submit at all — is a direct violation subject to these fines. Supervisory enforcement practices vary by member state but are intensifying: BSI (Germany), ANSSI (France) and NCSC (Netherlands) have all indicated increased NIS2 enforcement activity throughout 2026. Beyond fines, late or incomplete incident notification can trigger supervisory audits and additional certification requirements. Early warning submitted promptly and in good faith — even when incomplete — is treated significantly more favourably than late submission of a complete report. When in doubt, submit the early warning with what you know and update it. ## Building Compliance-Ready Incident Response NIS2 Art. 23 compliance is ultimately a systems design problem: you need detection systems that surface significant incidents within minutes of occurrence, enrichment pipelines that assemble notification-ready data automatically, documentation that lets on-call engineers act without waiting for daytime business hours, and contractual commitments from your cloud stack that feed your notification timelines. The developers who will meet the 24-hour early warning deadline under pressure are not the ones who understand the law best — they are the ones who built the systems and ran the tabletop exercises before the incident happened. --- *sota.io is a European-native PaaS that runs exclusively in EU data centres under EU legal jurisdiction. Your logs, your incident artefacts, and your forensic data stay in EU CSIRT territory — with no CLOUD Act exposure. [Start free](https://sota.io) or [read more about our EU data sovereignty approach](https://sota.io/blog).*

EU-Native Hosting

Ready to move to EU-sovereign infrastructure?

sota.io is a German-hosted PaaS — no CLOUD Act exposure, no US jurisdiction, full GDPR compliance by design. Deploy your first app in minutes.

Start free — no credit cardView pricing