NIS2 Directive incident reporting timelines: 24h early warning vs 72h notification — who handles what in your org?

The 24h/72h NIS2 clock is one of those requirements that sounds straightforward until you realize your incident detection pipeline has a 6-hour mean-time-to-detect. The early warning at 24 hours isn't supposed to be a full root-cause analysis — it's a 'we know something happened and we're looking' notification. What we've implemented: a tiered reporting structure where the SOC team owns the 24h trigger (they just need to confirm 'significant impact' based on predefined criteria), and the legal/compliance team takes over for the 72h detailed report. The handoff happens automatically via a Jira ticket that gets created when the initial alert fires. The hardest part isn't the timeline — it's the 'significant impact' assessment. NIS2 Article 23 requires you to determine whether the incident has caused or is likely to cause 'severe operational disruption' or 'financial loss.' That's a legal judgment, not a technical one. We've trained our incident commanders with a decision matrix that maps technical indicators (affected users, data types, revenue impact) to the NIS2 thresholds. Key lesson: don't wait until an incident to figure out who calls the regulator. Have a designated person whose name is in your incident response plan, with a backup. The regulator doesn't care about your internal process gaps.