DORA major ICT incident reporting — the 4h/72h/1-month playbook

Use this playbook when all of the following are true:

• Your entity is in scope of DORA — Regulation (EU) 2022/2554 (credit institutions, payment institutions, investment firms, crypto-asset service providers, central counterparties, trading venues, insurance and reinsurance undertakings, IORPs, crowdfunding service providers, plus the other categories listed in Art. 2). ICT third-party service providers designated as critical under Art. 31 are also in scope.
• An ICT-related incident — defined in Art. 3(8) as a single event or a series of linked events compromising the security of network and information systems or having an adverse impact on the availability, authenticity, integrity or confidentiality of data or on the services provided — has been detected.
• The incident either crosses, or is at risk of crossing, the classification thresholds of Commission Delegated Regulation (EU) 2024/1772.

Do NOT use this playbook for: operational incidents that are not ICT-related (use the applicable sectoral operational-risk reporting rules), classical IT outages that do not approach the materiality thresholds (record internally, no DORA submission), or significant cyber threats that did not materialise as an incident (those use the voluntary Art. 19(2) cyber-threat notification path — distinct from this playbook).

There are two start conditions and three submission gates.

Start conditions:

• Detection: the moment a competent observer in your organisation would conclude the incident has occurred. Document the timestamp.
• Classification: the moment the incident is formally classified as "major" against Reg 2024/1772 thresholds. DORA requires this "without undue delay" — practitioners read this as hours, not days, and supervisors will challenge gaps longer than a single working day.

The 4-hour clock for the initial notification runs from classification, with an additional outer ceiling of 24 hours from detection — whichever expires first is the deadline. Delaying classification does not extend the initial-notification window.

The three gates (each running from classification, per Commission Delegated Regulation (EU) 2025/301 Art. 6):

• Initial notification: within 4 hours of classification, and no later than 24 hours after the incident was detected.
• Intermediate report: within 72 hours of classification, then iterated as material new information arrives.
• Final report: within 1 month of classification.

Submission channel: Italian financial entities file through Banca d'Italia's INFOSTAT platform. Entities under other competent authorities file through that authority's designated channel (BaFin, AMF, CSSF, etc.). The template is binding and identical across the Union — Implementing Regulation (EU) 2025/302 sets the standard forms.

Goal: classify the incident, validate the classification, and file the initial notification within 4 hours of classification (or 24 hours of detection — whichever fires first).

The classification gate is the operational pinch-point. Run the Reg 2024/1772 criteria against the live incident data:

• Number of clients and financial counterparts affected.
• Number and value of transactions affected.
• Reputational impact (media coverage, complaints, regulator queries).
• Duration and service downtime.
• Geographical spread (Member States affected).
• Data losses (confidentiality, integrity, availability, authenticity).
• Critical services affected.
• Economic impact (direct and indirect costs).

If two primary criteria are crossed — or one primary plus the economic-impact threshold — the incident is major and the DORA clock is running.

Minimum content of the initial notification (ITS 2025/302 fields):

• Incident type and high-level description.
• Detection time and classification time (separate fields — supervisors compare them).
• Affected services (which essential or important business services are degraded or interrupted).
• Geographical spread.
• Estimated number of clients and financial counterparts affected.
• Whether the incident is suspected to be malicious.
• A single point-of-contact email and phone number.

What you do NOT need at hour 4: full root cause, complete IoC list, attribution, validated financial impact. The initial notification is preliminary by design.

Failure mode at this gate: waiting to "be sure" before classifying. The regulation expects classification to be revisable — file on the data you have, update at the intermediate report. A delayed classification to dodge the major-incident threshold is the failure mode supervisors actively look for.

Goal: file the intermediate report by hour 72 from classification, then iterate as material new information arrives.

Mandatory additions over the initial notification:

• Updated impact assessment (severity, customer-facing impact, business-process impact, financial impact estimate where available).
• Indicators of compromise: IPs, domains, file hashes, TTPs in MITRE ATT&CK notation.
• Initial root-cause hypothesis (vulnerability exploited, initial access vector, lateral path).
• Containment actions already taken; remediation actions in progress.
• Whether personal data was affected (and therefore GDPR Art. 33 has been triggered in parallel).
• Whether the incident is intentional, and if so the assessed actor type (criminal, nation-state, insider).
• Reclassification status: if the incident has been re-evaluated and the major-classification status has changed, document the basis.

The intermediate report can be filed more than once. Reg 2025/301 expects iteration as state evolves — file early and update; do not optimise for a single perfect submission. INFOSTAT and equivalent national channels accept multiple intermediate reports against the same incident ID.

Failure mode: filing at exactly hour 72 with hypotheses dressed up as conclusions. Supervisors expect honest preliminary hypotheses clearly flagged as such. Retracting a confidently stated root cause at the 1-month report is worse than flagging uncertainty up front.

Goal: file the final report within 1 month of classification.

Final report content (ITS 2025/302 final-stage fields):

• Verified root cause — or a detailed explanation of why root cause is not determinable, with the investigative limits documented.
• Full IoC list with attribution where confidence is appropriate.
• Complete remediation status: which fixes are in production, which are still in flight, target dates for the rest.
• Lessons learned: process changes, control changes, tooling changes, governance changes.
• Cross-references to other regulator notifications filed on the same event (NIS2 Title 13, GDPR Art. 33, sectoral, law-enforcement).
• Direct and indirect costs incurred, including business interruption, recovery cost, regulatory liaison cost, third-party support cost, customer-redress cost.

This is where the quality of the evidence chain is exposed. If every artefact has been signed at write time and the chain is verifiable end-to-end, the final report is a summary document with pointers. If artefacts were assembled by hand from disparate tools during the response, the final report takes multiple person-weeks of cross-tool reconciliation that the team is not staffed for. Supervisors notice the difference.

The full criteria set is in Reg (EU) 2024/1772 Articles 1 to 8, restated here in operational terms.

Primary criteria (incident is major if two are crossed, or one primary plus the economic-impact threshold):

• Clients and financial counterparts affected (Art. 1): absolute number or percentage of clients/counterparts whose use of the service is interrupted, degraded, or whose data is compromised. Materiality thresholds scale with entity size.
• Transactions affected (Art. 2): absolute number or percentage of transactions disrupted or altered.
• Reputational impact (Art. 3): media coverage in a single Member State, repeated complaints from clients or counterparts, loss of clients, regulator query, or impact on third parties' compliance.
• Duration and service downtime (Art. 4): time from start of incident to recovery, with downtime counted against critical or important functions.
• Geographical spread (Art. 5): number of Member States affected, with materiality at two or more.
• Data losses (Art. 6): impact on the availability, authenticity, integrity, or confidentiality of data — including personal data subject to GDPR.
• Critical services affected (Art. 7): incidents affecting the provision of critical or important functions as defined under Art. 3(22) of DORA.

Economic-impact threshold (Art. 7, secondary): direct and indirect costs exceeding the financial-entity-specific threshold (typically 100,000 EUR or 0.1% of the previous year's gross income, whichever is higher).

Recurring incident rule (Art. 8(2)): individually non-major events that recur on the same root cause and aggregate to cross a primary threshold within six months also qualify as major. This catches the "death by a thousand cuts" pattern.

Significant cyber threat (Art. 18, voluntary): credible threats with the potential to result in a major incident — for example, a verified attempt by a known threat actor against your sector — are reported on a voluntary basis through the same channel. The supervisor uses these for sector-wide threat intelligence; the entity gets early visibility on adversary behaviour.

Across all three submissions, plan to have ready (each artefact signed at write time, timestamped, with chain-of-custody preserved):

• Incident timeline log: timestamps of detection, classification, initial-notification submission, intermediate-report submissions, eradication completion, final-report submission. No manual back-edits — supervisors check.
• Classification worksheet: for each of the eight primary criteria, the value at classification time, the source of the value (SIEM query, business-impact tool, customer-care ticket count), and the rationale for crossing or not crossing the threshold.
• Detection-system telemetry export covering the incident window plus 14 days before. Original timestamps preserved.
• Containment action log: firewall blocks, account disablement, system isolation, with timestamps and approvers.
• Remediation action log: patches applied, configurations changed, rebuild events, with timestamps and approvers.
• IoC list with provenance: where each indicator came from (internal hunt, threat-intelligence feed, vendor advisory).
• Root-cause analysis document with version history: each revision preserved.
• Communications log: notifications to staff, clients, counterparts, supervisors, law enforcement, with channel and content.
• Cost log: direct and indirect costs accrued daily, used to validate the economic-impact threshold at the final report.

Submission channel evidence: keep the INFOSTAT submission receipt for each report (initial, intermediate iterations, final) — Banca d'Italia stores them server-side but the entity holds the primary record under Art. 13 record-keeping rules. The Banca d'Italia DORA incident page is the authoritative source on the Italian submission flow and the templates pinned there are the binding versions.

The operational lesson from peer financial entities running through their first DORA submissions in 2025-2026: pre-build this evidence chain with a continuous-evidence platform that signs every artefact at the moment of creation. The classification decision itself — clients affected, transactions affected, downtime, data integrity — becomes a query against signed telemetry rather than a stand-up cross-tool reconciliation under a 4-hour deadline. The engineering position the Zero Hunt team takes on this is the Automatic Compliance rail: every artefact signed at write time, every classification decision auditable end-to-end, exports parameterised per regime so the same evidence base produces DORA, NIS2, GDPR and sectoral submissions in parallel without re-keying.

1. Delayed classification to dodge the major threshold. Supervisors actively look for incidents that sat at "under review" for days before being classified as not major. The "without undue delay" requirement is enforced — document the classification decision and its basis on the same day as the incident.

2. Filing the initial notification at hour 24 from detection, not hour 4 from classification. The 24-hour ceiling is the *outer* limit; the 4-hour clock from classification fires first in most cases. Teams that train only on the 24h number miss the gate routinely.

3. Single-shot intermediate report. Reg 2025/301 expects iteration. Filing once at hour 72 and going silent until month 1 is non-conformant. File at 72h, file again when material new information arrives.

4. Inconsistent cross-regime narratives. A single event triggers DORA Art. 19 + NIS2 Title 13 + GDPR Art. 33 + sectoral notifications in parallel. The narrative across submissions must be consistent — supervisors compare them. Build one evidence base, export per regime; do not let separate teams draft separate narratives.

5. Manual evidence assembly during response. The bandwidth conflict between incident response and regulator-grade evidence assembly is the single most common failure mode reported by peer financial entities. Pre-signed continuous evidence rails turn the final report from a reconstruction exercise into an export. The methodology angle on this is covered in TLPT (Threat-Led Penetration Testing) — the same evidence discipline that satisfies DORA Art. 26 TLPT attestation satisfies Art. 19 incident reporting.

6. Treating Banca d'Italia INFOSTAT as the only submission. Italian financial entities also have sectoral notification duties to Consob (investment services), IVASS (insurance) and AgID (digital identity). Check the sectoral notification table — some sectoral deadlines are shorter than DORA's 4 hours, in which case the sectoral clock dominates.

Cross-regime combinations typically seen in 2025-2026:

• EU bank or payment institution: DORA Art. 19 (4h/72h/1m) + NIS2 Title 13 if essential or important entity (24h/72h/1m) + GDPR Art. 33 if personal data (72h) + sectoral to Banca d'Italia / Consob / IVASS. Four exports of one evidence base.
• EU investment firm: DORA Art. 19 + ESMA MAR if market abuse implications + GDPR Art. 33.
• EU insurance undertaking: DORA Art. 19 + IVASS sectoral + GDPR Art. 33 + NIS2 Title 13 if essential.
• Critical ICT third-party provider (Art. 31): notification to ESA Lead Overseer + cascading notifications to in-scope client entities, each of which has its own DORA Art. 19 obligation.

In every combination, the evidence base is the same. The submissions are different summaries of one underlying record. Building the record once — and exporting per regime — is the operational difference between a 1-month final report that fits on three pages and a 1-month final report that drives a team to overtime.