DORA Pillar 2: ICT Incident Management & Reporting, The Clock and the Classification

DORA’s second pillar (Articles 17–23) is where operational resilience meets the regulator. Financial entities must manage ICT-related incidents through a defined process and, for major incidents, report them to their competent authority on a structured timeline. As with NIS2, the deadlines mean the capability has to exist before the incident.

General guidance, not legal advice. The exact thresholds, templates and timelines are set by DORA and its Regulatory Technical Standards, confirm them with your competent authority.

Classification first

You can’t report a “major” incident if you can’t tell a major one from a minor one. DORA requires a classification process based on criteria such as the number of clients affected, duration and service downtime, geographical spread, data losses, criticality of services affected, and economic impact. Getting this scheme defined and documented is the foundation, it’s what starts the reporting clock and keeps grading consistent across whoever is on call.

The reporting timeline

For a major ICT-related incident, DORA establishes a multi-stage notification to the competent authority:

• an initial notification,
• an intermediate report as the situation develops, and
• a final report with root cause and remediation once the incident is closed.

The specific deadlines for each stage are defined in the Regulation and its technical standards. The practical point is the same as under NIS2: you need detection, a contact path to your authority known in advance, and the ability to produce structured reports under time pressure.

The capability behind it

A workable Pillar-2 capability has: centralised logging and monitoring with enough retention to reconstruct events, a documented classification matrix, defined roles and an escalation path, pre-built reporting templates aligned to the RTS, and a post-incident review habit. Most of this overlaps directly with good incident handling generally, DORA just makes the reporting obligation explicit and the timeline binding.

Reducing the number of incidents you’ll ever have to classify and report is the complementary half. Most major ICT incidents trace back to a known, exploited weakness, so a continuous view of which of your systems carry actively-exploited vulnerabilities, which is what SentriKat provides, shrinks the set of bad days you’ll need to report on.

Start here

Define and document your incident-classification matrix, confirm the reporting path and templates for your competent authority, and run one tabletop on a “major incident” scenario end to end, from detection to final report. That turns the obligation from theory into a tested process.

See where incident reporting sits across all five DORA pillars with the free NIS2/DORA readiness check.