I’m trying to turn NIS2’s open-ended language into something our team can apply consistently. How should we judge whether an incident is significant, what counts as state-of-the-art, and how do we handle a case that may also fall under DORA?
How are you drawing the line on NIS2 incident reporting?
Asked by
squeaklet
Answers
Try not to make “an incident occurred” the reporting test. Under the NIS2 criteria, assess whether it caused or could cause severe disruption to your services or significant financial loss, or whether it affected or could affect others by causing considerable material or non-material damage. Check your country’s implementation and any sector-specific rules too, since those can add detail.
A phishing attempt stopped before it affected anything is not automatically significant just because someone clicked. A supplier’s compromise is not automatically reportable either, but it could be if your service or other parties are affected, or could be affected, in a serious way. Record the facts, impact, potential impact, and your reasoning. If it does meet the threshold, the early-warning clock generally starts when you become aware of the significant incident, so make sure internal escalation is quick.
Reply to this answer
“State-of-the-art” is not a promise to buy the newest product every year. Think of it as choosing and maintaining measures that are appropriate to your risks, the likely threats, the sensitivity of the systems, and the harm a failure could cause.
For each important control, keep a short trail showing what risk it addresses, what standard or guidance informed the choice, how you tested it, and when you’ll review it. Recognized frameworks can help structure that evidence, but using one does not automatically prove compliance. Document why a measure fits your environment, and why any exception is acceptable. That gives an auditor something more useful than a product list.
Reply to this answer
For the overlap, I’d keep one incident record but two reporting checklists. Track the trigger, clock start, recipient, required content, and deadline separately for NIS2 and DORA. An incident can meet one regime’s threshold and not the other, and sending one notice should not be assumed to satisfy both.
Have the people who classify incidents check the current rules and reporting procedures that apply to your organization, rather than relying on a remembered deadline. If both regimes apply, run both assessments in parallel and keep a shared timeline so nobody waits for one process to finish before acting on the other.
vhs+velour:
So the same event could need two different decisions, even if the facts are identical?
YIP_2:
Yes. The facts can be shared, but each regime has its own scope, test, recipient, and timing. A crosswalk prepared in advance makes that much easier to handle under pressure.
Reply to this answer
Add your answer
Answers are reviewed before publication.
squeaklet:
That helps. If we are genuinely unsure whether it crosses the line, do we wait for more facts?
sundae.exe:
Gather facts quickly, but don’t let uncertainty turn into an untracked delay. Keep a timestamped assessment and check your national authority’s process or get legal advice. If the rules allow an initial warning with limited information, that can be useful while the investigation continues.