heygrc
NIS 2 incident handling in code

The page fires. Does an incident get opened?

NIS 2's Art. 21(2)(b) requires cybersecurity risk-management measures to include incident handling. In practice an effective process commonly covers detecting an event, assessing and classifying it, containing it, responding, and documenting what happened. That documentation matters beyond the fix itself: Art. 23 requires an early warning to the competent authority or CSIRT within 24 hours and a fuller incident notification within 72, both measured from when you become aware of a significant incident, not from when someone gets around to logging it. But an incident nobody tracked is much harder to assess and report on time, even though the legal clock was already running.

How it shows up in a diff

The shapes the same control failure takes.

Incident handling weakens when a change lets an event get noticed without ever becoming a tracked incident. The recurring shapes:

  • The incident record is dropped

    An alert still pages someone, but the code that opens a tracked incident (with a severity, a timestamp, an owner) is removed, so nothing formal exists to assess, classify, or document.

  • Severity classification is narrowed

    The logic that decides whether an event counts as a reportable incident has its threshold raised or its criteria narrowed, so fewer events reach the classification the handling process, and Art. 23 if it is significant, depends on.

  • Auto-resolution skips the process

    An alert is wired to auto-acknowledge or auto-close instead of routing into the incident workflow, so a real event never gets handled or recorded.

  • The post-incident write-up step is removed

    A required root-cause or timeline document is dropped from the workflow, so incidents close without the record a later reporting or audit needs.

  • Escalation stops if the first responder misses it

    The step that pages a second responder when the first does not acknowledge is deleted, so an incident can go unhandled with no one aware it is open.

Worked example

A page that no longer opens an incident.

A critical alert pages on-call and used to also open a tracked incident record, the thing that carries the severity, the timeline, and the eventual write-up. The incident-tracker integration got flaky under load, so a change removes the call to stop the noise. The page still fires. Nothing is left that classifies the event, tracks it, or could feed a report.

incident/dispatch.ts+0 -1
if (alert.severity === "critical") {  await oncall.page(alert)-  await incidents.open({ alert, severity: "critical" })}
heygrcNIS 2 Art. 21(2)(b)

This keeps paging on-call but stops opening an incident record for a critical alert. Art. 21(2)(b) (incident handling) expects the event to actually be detected and handled, and skipping the record makes that response invisible even though the page still fires. In practice, handling an incident means assessing and classifying it, and if it turns out to be significant, Art. 23's reporting deadlines already run from when you became aware of it, not from when a ticket exists, so an untracked incident makes it harder to show you assessed and reported it in time. Restore the incident record alongside the page, even if the tracker integration needs to be made more reliable separately.

What an auditor does with this

Incident handling is checked against the record, not the page.

An inspection under NIS 2 looks for evidence that incidents actually get detected and handled, with the assessment and classification that in practice makes handling and reporting possible. That record is also what would show the Art. 23 deadlines were met, deadlines that run from awareness of a significant incident regardless of whether a ticket was ever opened. A change that keeps the alert firing but drops the incident record removes that evidence: a page nobody can audit later, and no trail showing detection or response happened. It is visible in the diff to the alerting or incident-management integration.

What this is, and is not

A review, not your incident response.

heygrc flags changes that touch a NIS 2 incident-handling measure and cites the point so the fix happens in the pull request. It does not run your incident response or file your regulatory notifications. It catches the moment a change stops recording an incident it should, at the diff.