Independent thinking. Informed defence.

CISO Times

Intelligence for the people behind the defence.

The CISO Decision Brief

How do we…

How do we decide whether an incident is significant under NIS2?

9 decision pointsThe pack behind this answer: Regulatory Incident Notification & Reporting

Add to board memo

The short answer

Recommendation
Test every declared incident against the pack's six indicators, calibrated with counsel, on what it has done or could do. Any one met makes it significant. Record the decision, the indicators and the facts within 4 hours of declaration, the pack's default.
Reasoning
NIS2 calls an incident significant when it has caused or could cause severe operational disruption or financial loss for you, or considerable damage to others, and gives no numbers. The pack's indicators turn those words into questions: service disruption, financial loss, damage to others, attacker capability, recurrence, and the named digital providers' own criteria. Severity sets the pace of the response; the regime is tested separately. The early warning clock already runs from awareness.
Considerations
  • The default values, a service stopped for more than 4 hours and a loss above €1,000,000, come from the pack's severity scale. Where national law or your authority sets a threshold, it wins.
  • Digital providers named in Implementing Regulation (EU) 2024/2690, such as cloud computing and managed security service providers, apply its criteria first, including a direct financial loss above 500,000 euro or 5% of annual turnover, whichever is lower.
  • A scheduled interruption or the planned effect of scheduled maintenance is not significant. Maintenance that overran or broke something unplanned does not qualify.
  • For a financial entity also in NIS2 scope, the pack applies DORA's major-incident test instead. Confirm that with counsel.

The decision, step by step

Select any step for the reasoning behind it and where the pack covers it.

  • Start
  • Step
  • Decision
  • Outcome
  • Loop back
StartAn incident has been declaredStepFix the awareness time: the early warning clock starts thereDecisionDoes our applicability profile say NIS2 applies to us?OutcomeRecord NIS2 as Not applicable, citing the profileStepIf we are a named digital provider, apply its criteria firstStepUse the indicator values calibrated with counselStepTreat Severity 1 as a prompt to test, not as the testStepRecord what is known, and mark each unknownDecisionIs it only a scheduled interruption or planned maintenance?DecisionCould a service we provide stop past the threshold, or degrade widely?DecisionIs our financial loss likely to exceed the Severe threshold?DecisionCould it cause considerable damage to customers or others?DecisionHas an attacker admin access to core systems, or is malware spreading?DecisionDo same-cause incidents in six months together meet an indicator?DecisionDid any indicator turn on a fact we do not yet know?OutcomeSignificant: record Reportable and brief the signatory nowOutcomeRecord Not settled, with a revisit time before the doubt pointStepRecord Not reportable: each indicator, and the fact that failed itDecisionAt the next update, has a fact changed?OutcomeNot significant: keep the record and test again at each update

Keyboard: Tab to a step, arrow keys move along the flow, Enter pins its explanation, + and − zoom, 0 fits the diagram, Esc closes. The text version below has the same content.

Where a step quotes a number, it is the default in the CISO Times pack. Your own standard may set a different one.

Read as text

The same flow written out: each step, its reasoning and where the pack covers it. 20 steps.

  1. Start

    An incident has been declared

    NIS2 makes an incident significant if it has caused or could cause severe operational disruption of your services or financial loss for you, or considerable material or non-material damage to others. The Directive sets no numbers. Every declared incident gets a recorded NIS2 decision, whether or not a report follows, within 4 hours of declaration in the pack's default.

    In the pack

  2. Step

    Fix the awareness time: the early warning clock starts there

    Awareness is the time the incident was declared, or earlier where the record shows reasonable certainty earlier. The 24-hour early warning clock runs from it, not from the decision. A decision taken at hour 3 leaves 21 hours for the early warning, not 24.

    In the pack

  3. Decision

    Does our applicability profile say NIS2 applies to us?

    Only essential and important entities report under NIS2. Settle that once, before any incident, in a profile your executive management approves, so the screen does not start by arguing about scope. If there is no profile yet, or it is unclear, run the test anyway and settle scope with counsel.

    In the pack

    See also

  4. Outcome

    Record NIS2 as Not applicable, citing the profile

    One line in your notification log, with the profile as the reason. Not applicable means the regime cannot apply to you. It is different from Not reportable, which means NIS2 applies and the test was not met. Review the profile at least once a year and whenever your status, services or authorities change.

    In the pack

  5. Step

    If we are a named digital provider, apply its criteria first

    Cloud computing, data centre, managed service and managed security service providers, among others, are named in Implementing Regulation (EU) 2024/2690. For them that Regulation's own criteria decide, including a direct financial loss above 500,000 euro or 5% of annual turnover, whichever is lower. The pack's indicators only add to it. Everyone else goes straight to the indicators.

    In the pack

  6. Step

    Use the indicator values calibrated with counsel

    The indicators are the pack's way of turning the Directive's words into questions, not legal thresholds. Before first use, counsel checks them against national law and the authority's guidance and confirms the values fit your size. Where the law or the authority sets a threshold, enter it and use it instead. Seek legal advice where a test is unclear, but never wait for it past the doubt point.

    In the pack

  7. Step

    Treat Severity 1 as a prompt to test, not as the test

    The incident pack's Severity 1 reads 'likely a significant incident', and the indicators carry its service, money and spread levels, so a Severity 1 on service or money is presumed significant. Severity still only says how fast you respond, and the regime is tested separately. Damage to others does not come from the severity scale at all, so run every indicator whatever the severity.

    In the pack

    See also

  8. Step

    Record what is known, and mark each unknown

    Put the facts in one record that every report will be drafted from: services affected, money, people and organisations harmed, systems and suspected cause. Mark each fact still unknown and name who is finding it out. Then apply the test anyway. Waiting for the investigation is the commonest mistake.

    In the pack

  9. Decision

    Is it only a scheduled interruption or planned maintenance?

    A scheduled interruption of service, or the planned effect of scheduled maintenance, is not a significant incident. The Implementing Regulation says so for the providers it binds, and the pack applies it to every entity. Maintenance that overran or broke something unplanned does not qualify.

    In the pack

  10. Decision

    Could a service we provide stop past the threshold, or degrade widely?

    Operational disruption. Has a service you provide in your NIS2 sector stopped, or could it stop, for more than the threshold (the pack's default is 4 hours), or is it degraded for a large share of its users? 'Could' counts: test what the incident is capable of doing, not only what it has done.

    In the pack

  11. Decision

    Is our financial loss likely to exceed the Severe threshold?

    Financial loss for you. The pack's default threshold is €1,000,000, the Severe level of its risk scale. A fraudulent payment above it is significant even with no service disruption.

    In the pack

  12. Decision

    Could it cause considerable damage to customers or others?

    Damage to others, material or non-material: customers or other organisations with their operations stopped or money lost, personal data exposed at scale, or harm to health or safety. A fault in a service you provide that stops customers' own operations meets it. In the pack's example, 212 customers' details sent to one business customer, which deleted them, did not, although it was still a GDPR notification.

    In the pack

  13. Decision

    Has an attacker admin access to core systems, or is malware spreading?

    Capability. If an attacker holds administrator-level access to core systems, or malware is spreading, the disruption, loss or damage above could follow unless it is stopped. This lets you decide in the first hours. In the pack's example, ransomware spreading on an office network was significant before any service had stopped.

    In the pack

  14. Decision

    Do same-cause incidents in six months together meet an indicator?

    Recurrence. Incidents with the same apparent cause, at least twice in six months, are tested together against disruption, loss and damage to others. The Implementing Regulation does this for the digital providers it binds, and for financial loss only; the pack applies it to every indicator as good practice.

    In the pack

  15. Decision

    Did any indicator turn on a fact we do not yet know?

    If an indicator could be met but the fact that decides it is still unknown, the decision cannot be settled yet. Do not record Not reportable to fill the gap. If no indicator depends on an unknown, the incident is not significant on the facts known.

    In the pack

  16. Outcome

    Significant: record Reportable and brief the signatory now

    One indicator is enough. The executive incident lead decides to report and records which indicators were met and on what facts. The early warning is due within 24 hours of awareness, the incident notification within 72 hours, and the final report within one month of that notification. Call whoever submits reports so they confirm they can sign in to the channel now.

    In the pack

    See also

  17. Outcome

    Record Not settled, with a revisit time before the doubt point

    Record the missing fact, who is finding it out, and when you will decide again. If it is still not settled 6 hours before the early warning deadline, the pack's default, treat the incident as significant and report on the facts known. Brief the signatory now, as for a Reportable decision.

    In the pack

    See also

  18. Step

    Record Not reportable: each indicator, and the fact that failed it

    'Low impact' is not a reason. Name each indicator and the fact that shows it was not met. If the incident is Severity 1 or 2 when the decision is recorded, the executive incident lead decides not to report; at Severity 3 or 4 the incident manager may record it.

    In the pack

  19. Decision

    At the next update, has a fact changed?

    A decision not to report is revisited at every incident update and at once when a fact changes, and the result is recorded even when unchanged. If the incident becomes significant later, the NIS2 clocks start when the record shows the fact that met the test was known.

    In the pack

  20. Outcome

    Not significant: keep the record and test again at each update

    The record is your defence if an authority later asks why it was not told: the profile, the decision line, the facts as they stood, every revisit, and counsel's calibration of the indicators. Check the other notices the screen covers too: contracts, your cyber insurer and a crime report.

    In the pack

Practical checklist

  1. Confirm from the applicability profile that you are an essential or important entity.
  2. Fix the awareness time: the 24-hour early warning clock runs from it.
  3. Apply the Implementing Regulation's criteria first if it names you as a digital provider.
  4. Record what is known in one fact base, and mark each unknown with who is finding it out.
  5. Test each indicator on what the incident has done or could do, including same-cause incidents in the last six months.
  6. Record Reportable, Not reportable or Not settled within 4 hours of declaration, with the indicators and facts.
  7. Treat a decision still not settled 6 hours before the early warning deadline as significant, and report on the facts known.
  8. Revisit a Not reportable decision at every update and at once when a fact changes.

Evidence to have ready

  • The applicability profile showing your NIS2 status and authority.
  • Counsel's calibration record for the indicators, with any national guidance used.
  • The decision line: each indicator met or not, the facts behind it, who decided and when.
  • The fact base as it stood at the decision, and every revisit with its result.

Assumptions

  • You are an essential or important entity under NIS2, and a profile approved before any incident says so and names your CSIRT or competent authority.
  • The indicator values shown (a service stopped for more than 4 hours, a loss above €1,000,000) are the pack's defaults, taken from its incident severity scale. Your counsel, national law or authority may set others, and theirs win.
  • You are not also a financial entity under DORA. For one, the pack treats DORA's incident reporting as replacing NIS2's and applies DORA's major-incident test instead; confirm that with counsel. That is “How do we decide whether an ICT incident is major under DORA?”.

Not covered here