NIS2 Directive · Multi-AI Analysis · Public Report
The Clock Started
When You Found Out.
An 18-hour ransomware outage. Systems restored. No authority notified. The incident is over — the compliance breach may be just beginning.
Published May 23, 2026 · Xi AI
Position Zero: An 18-hour service disruption from ransomware, with no notification to any competent authority, is a probable violation of NIS2 Article 23 for any entity covered by the directive. The early warning deadline (24 hours) was met in time, but the absence of notification means the obligation was not fulfilled. Retroactive disclosure is possible and likely reduces sanctions — but does not eliminate them.
The Question Submitted to Three AI Systems
We suffered a ransomware attack that locked our systems for 18 hours. Under NIS2, what were our reporting obligations and to which authority? We notified no one. The attack occurred last month. What is our exposure?
Where All Three Systems Agree
These points are confirmed by AI1, AI2 and AI3 without contradiction:
- An 18-hour ransomware outage affecting operations is a "significant incident" under NIS2 Article 23(3) — it has "a significant impact on the provision of services."
- NIS2 requires an early warning within 24 hours of becoming aware of a significant incident. That deadline was reached and passed without notification.
- Notification goes to the national CSIRT or competent authority in the member state(s) where the entity operates and where services were affected.
- Retroactive disclosure is not prohibited and is typically treated as a mitigating factor in enforcement proceedings.
- If the ransomware involved personal data, a parallel GDPR Article 33 notification obligation existed (72-hour deadline to supervisory authority) — and GDPR enforcement is separate from NIS2 enforcement.
The 24 hours in NIS2 do not begin at T+0 of the attack. They begin when the entity becomes aware of a significant incident. "Aware" is the operative word — and it is the word regulators will examine first.
Where the Three Systems Diverge
AI1 — Claude
AI1 focuses on the "aware" threshold. NIS2 Article 23(1) triggers the early warning clock when the entity "becomes aware" of the incident. AI1 argues this creates a meaningful factual question: at what point did the company have sufficient information to know this was a significant incident? A ransomware lock-out is clear. But some incidents have ambiguous early stages. The 18-hour outage leaves little ambiguity — by the time systems were locked, the company was "aware." The early warning deadline expired before systems were restored. AI1 recommends immediate voluntary disclosure to the competent authority with a full incident report, citing the notification failure as a mitigating factor and demonstrating good faith.
AI2 — Gemini
AI2 highlights the dual-track enforcement risk. If personal data was accessed during the ransomware attack — even if encrypted data was not exfiltrated, but was "accessed" by the attacker — a GDPR Article 33 breach notification was also required within 72 hours of the data controller becoming aware. This means two separate violations may have occurred: NIS2 Article 23 (incident notification) and GDPR Article 33 (personal data breach notification). Two different supervisory bodies — the NIS2 competent authority and the data protection authority — may each initiate proceedings. AI2 recommends engaging a lawyer specializing in both frameworks before making any voluntary disclosure, to coordinate the approach across both regulatory channels.
AI3 — DeepSeek
AI3 is the most pragmatic and focuses on enforcement probability and proportionality. Most NIS2 enforcement actions to date (where they have occurred) have targeted entities that failed to disclose AND failed to remediate. A company that restored systems within 18 hours, suffered no data exfiltration, and proactively discloses to authorities after the fact is in a meaningfully different position than one that conceals an incident. AI3 notes that NIS2 competent authorities in most member states are still building their enforcement capacity — the likelihood of a fine for a first-time notification failure with prompt voluntary disclosure and no third-party harm is lower than a strict reading of the sanctions article would suggest. This does not mean ignoring the obligation — it means the context matters for how the company approaches disclosure.
The three systems give three different answers to the same situation — not because they disagree on the law, but because they frame the question differently. AI1 focuses on legal obligation (clear breach, disclose immediately). AI2 focuses on regulatory risk mapping (two agencies, coordinate before disclosing). AI3 focuses on enforcement realism (context matters, authorities are not yet fully operational). All three are correct in their frame.
The operative tension is between AI2 and AI3. AI2 says coordinate before disclosing. AI3 says the context of prompt, voluntary disclosure reduces risk. The synthesis: coordinate the disclosure — but disclose. A coordinated approach that still discloses within days of this analysis is better than one that waits for perfect legal advice and discloses months later.
The question none of them answer directly: what does "aware" mean for internal timeline documentation purposes? The company should document, now, when it first knew what kind of incident it was facing. That timeline will be the first thing a competent authority requests.
The Incident Reporting Cascade — What Was Owed
- T+24h from awareness: Early warning to national CSIRT/competent authority — incident type, systems affected, preliminary assessment. Missed.
- T+72h from awareness: Full incident notification — confirmed nature, severity, indicators of compromise. Missed.
- T+1 month: Final incident report — root cause, remediation actions, recurrence prevention. Can still be filed, late.
- In parallel (if personal data): GDPR Article 33 notification to data protection authority within 72h of awareness of the data breach. Assess separately.
The Blind Spot All Three Systems Miss
None of the three AI systems address the supply chain notification obligation. If the ransomware attack affected the company's ability to serve its clients — and those clients are themselves NIS2-covered entities — those clients may have their own NIS2 incident reporting obligations triggered by the disruption to their operations. The company may be the source of a cascading notification obligation downstream. Clients who discover this have an argument that the vendor's failure to notify them of the incident impaired their own compliance. This creates a contractual and regulatory exposure that is entirely separate from the direct NIS2 violation.
Appendix — Raw AI Responses (unedited)
The three responses below are reproduced without synthesis or editing.
Under NIS2 Article 23, you were required to submit an early warning to your national CSIRT or competent authority within 24 hours of becoming aware of the incident. A ransomware attack causing an 18-hour operational outage clearly meets the "significant incident" threshold. The early warning clock began when you first had knowledge of the attack — not when you resolved it. Since you notified no one, you have missed both the early warning (T+24h) and the incident notification (T+72h) deadlines. My recommendation is voluntary disclosure as soon as possible, with a complete incident report. Proactive disclosure is consistently treated as a mitigating factor in regulatory enforcement across all EU frameworks. You should also assess whether personal data was accessed — if so, a GDPR notification obligation existed in parallel. On sanctions: Article 21(2) and the recitals of NIS2 are clear that supervision should be proportionate. A first notification failure, promptly disclosed, with no data exfiltration, is at the lower end of enforcement priority for most competent authorities currently building their capacity.
Your situation involves at least two parallel regulatory frameworks. NIS2 Article 23 required the early warning and incident notification to your NIS2 competent authority. But if the ransomware attack constituted a personal data breach — meaning an attacker accessed, even temporarily, systems containing personal data — GDPR Article 33 required you to notify your data protection supervisory authority within 72 hours of becoming aware. These are two different authorities with two different mandates. A coordinated disclosure approach, agreed with legal counsel, is essential before you contact either authority. The way you frame the voluntary disclosure, the documentation you provide, and the remediation measures you describe all affect how each authority characterizes the incident. Disclosing to one authority without informing the other can also create complications if the two authorities subsequently communicate. I strongly recommend legal coordination before any disclosure — but I also recommend disclosing, not concealing.
The practical enforcement reality: NIS2 competent authorities in most EU member states are still in the process of building their supervisory infrastructure. France's ANSSI, Germany's BSI, and the Dutch NCSC are among the more mature — but even they are focused on systemic non-compliance and critical sectors, not isolated first-time notification failures. This is not to say ignore the obligation. It is to say that a company which voluntarily discloses a past incident, provides a complete root-cause analysis, demonstrates full remediation, and shows a strengthened cybersecurity posture is in a fundamentally different position from one that is discovered. The sanctions ceiling (€10M or 2% of turnover for essential entities) reflects legislative intent — it does not predict first-year enforcement action for a ransomware victim that notified late but transparently. Document your internal timeline meticulously: when the attack began, when you were aware it was significant, what you did to contain it, when you restored operations. This documentation is your first line of defense in any inquiry.