DORA Major Incident Report Template (Classification, Art. 19)

DORA major ICT incident: classification thresholds, reporting clock, initial, intermediate and final report fields (ITS Annex I), client notice, cyber threats

ISO・コンプライアンスフルDORA Art. 19; Delegated Reg. (EU) 2024/1772, 2025/301; Implementing Reg. (EU) 2025/302dora major incident report更新 2026/10/29

エディタで開く.mdをダウンロード

使い方: Use it when an ICT-related incident at a financial entity might be major under DORA, to classify it and prepare each report field by field. Fill the roles and the general entity fields before any incident, then the classification worksheet with the time of classification. The main pitfall is waiting for exact figures before classifying, which wastes the four-hour window.

プレビュー

DORA Major ICT-Related Incident Report: [Incident reference]

A working file for classifying an ICT-related incident under the Digital Operational Resilience Act (Regulation (EU) 2022/2554, DORA) and for preparing the initial notification, intermediate report and final report that Article 19 requires for major incidents. It follows Commission Delegated Regulation (EU) 2024/1772 (classification criteria and materiality thresholds), Commission Delegated Regulation (EU) 2025/301 (content and time limits) and Commission Implementing Regulation (EU) 2025/302 (standard forms, with the data fields of its Annex I and the glossary of Annex II). DORA applies from 17 January 2025; texts were checked on 2026-10-30, so check the consolidated texts on EUR-Lex and your competent authority's reporting instructions before use. Replace every [bracketed] value and every row marked Example. This is a documentation format, not legal advice; check the current official text and a qualified professional.

Document control

Field	Value
Document ID	[DORA-INC-2026-001]
Internal incident reference	[INC-NNNN], same as field 2.1
Competent authority reference	[Assigned by the authority, field 3.1]
Financial entity	[Legal name], LEI [20-character LEI]
Type of financial entity	[Credit institution / Payment institution / Investment firm / Other Article 2(1) type]
Competent authority	[Name, Member State]
Reporting channel	[Secure portal or channel named by the authority]
Reporting outsourced (Art. 19(5))	[No / Yes: provider name, notified to the authority on YYYY-MM-DD]
Version	[0.1]
Status	[Assessing / Initial sent / Intermediate sent / Final sent / Reclassified non-major / Closed]
Owner	[@ict-incident-reporting-lead]
Approvers/reviewers	[@ciso], [@cro], [@compliance], [@management-body-delegate]
Classification	[Confidential]
Last updated	YYYY-MM-DD

Approvals

Submission	Approved by	Role	Date and time
Initial notification	[@name]	[Head of compliance or delegate]	YYYY-MM-DD hh:mm
Intermediate report	[@name]	[Role]	YYYY-MM-DD hh:mm
Final report	[@name]	[Role]	YYYY-MM-DD hh:mm

Revision history

Version	Date	Author	Change summary
0.1	YYYY-MM-DD	[@name]	Classification opened
0.2	YYYY-MM-DD	[@name]	Example: Initial notification content approved
0.3	YYYY-MM-DD	[@name]	Example: Intermediate report after recovery of regular activities
1.0	YYYY-MM-DD	[@name]	Example: Final report with root cause and costs

Scope and applicability
Roles, channels and authorisations
Classification
Reporting clock
General information about the financial entity
Initial notification
Intermediate report
Final report
Informing clients
Reclassification, joint and aggregated submissions
Voluntary notification of significant cyber threats
Other reporting regimes
Records, lessons learned and review
Glossary and references

1. Scope and applicability

Question	Answer	Source
Is the entity a financial entity under DORA Article 2(1)?	[Yes / No]	Authorisation or registration
Is the event an ICT-related incident (unplanned event that compromises the security of network and information systems and has an adverse impact)?	[Yes / No]	DORA Article 3(8)
Is it a payment-related operational or security incident for a credit institution, payment institution, account information service provider or electronic money institution?	[Yes / No]	DORA Article 23
Does the incident originate at an ICT third-party provider?	[Yes / No, provider ID in the register of information]	Field 2.8
Is the entity a microenterprise or subject to the simplified framework of Article 16?	[Yes / No]	Affects recurring incident rule (section 3.4)
Is the entity also an essential or important entity under NIS2?	[Yes / No]	Affects weekend rule (section 4.2)

2. Roles, channels and authorisations

Role	Person	Deputy	Responsibility
Incident commander	[@name]	[@name]	Runs the response, provides facts
Classification lead	[@name]	[@name]	Applies section 3, records the time of classification
Reporting lead	[@name]	[@name]	Drafts sections 5 to 8, tracks the clock
Authorised submitter	[@name]	[@name]	Submits through the authority's channel
Client communications lead	[@name]	[@name]	Section 9
Data protection officer	[@name]	[@name]	GDPR breach assessment in parallel (section 12)

Submit through the secure electronic channel the competent authority provides. If that channel is unavailable, inform the authority through other secure means agreed with it, and resubmit through the channel when it is back if the authority asks (Implementing Regulation (EU) 2025/302, Article 4). Significant credit institutions report to their national competent authority, which passes the report to the ECB (DORA Article 19(1)). Member States may also require a copy to the NIS2 competent authority or CSIRT.

3. Classification

3.1 Decision rule

Under Article 8(1) of Delegated Regulation (EU) 2024/1772, an incident is major when it has affected critical services (Article 6) and either:

the data losses threshold for successful, malicious and unauthorised access to network and information systems that may result in data losses is met (Article 9(5)(b)), or
two or more of the other materiality thresholds in Article 9 are met.

3.2 Criteria and thresholds

Criterion (DORA Art. 18(1))	How to assess (Delegated Reg. 2024/1772)	Materiality threshold (Art. 9)
Critical services affected	Art. 6: ICT services or systems supporting critical or important functions; authorised or supervised financial services; successful malicious unauthorised access	Gate condition for every major incident (Art. 8(1))
Clients, financial counterparts and transactions	Art. 1: count clients and counterparts unable to use the service or adversely affected; transactions with at least one part carried out in the Union	Any of: clients over 10% of those using the service; over 100,000 clients; counterparts over 30%; transactions over 10% of the daily average number or over 10% of the daily average value; relevant clients or counterparts affected
Reputational impact	Art. 2: media coverage, repeated complaints, regulatory requirements likely not met, likely loss of clients or counterparts	Any one of the four conditions
Duration and service downtime	Art. 3: duration from occurrence to resolution; downtime from unavailability to restoration of the prior service level	Duration over 24 hours, or downtime over 2 hours for ICT services supporting critical or important functions
Geographical spread	Art. 4: impact on clients, counterparts, branches, group entities, market infrastructures or providers in other Member States	Impact in two or more Member States
Data losses	Art. 5: availability, authenticity, integrity, confidentiality	Adverse impact on business objectives or regulatory compliance (Art. 9(5)(a)), or malicious unauthorised access that may cause data losses (Art. 9(5)(b))
Economic impact	Art. 7: direct and indirect costs and losses listed in Art. 7(1), gross of recoveries, excluding business-as-usual costs	Costs and losses exceed or are likely to exceed EUR 100,000

3.3 Classification worksheet

Example: Calderfield Payments S.A. card authorisation gateway, partial outage after a failed certificate rotation at its hosting provider (PROV-07 in the register of information). Figures for the affected service: 48,000 merchant clients; daily average 1,250,000 transactions worth EUR 61,500,000.

Criterion	Evidence	Value	Threshold	Met at classification (2026-03-10 08:30)	Met at intermediate report
Critical services	Gateway supports a critical function (card acquiring)	Yes	Gate	Yes	Yes
Clients	9,600 of 48,000 merchants (estimate, then actual)	20%	Over 10%	Yes (estimate)	Yes (actual)
Transactions	312,500 failed of 1,250,000 daily average; EUR 14,760,000 of EUR 61,500,000	25% by number, 24% by value	Over 10%	Counted with clients (same criterion)	Same
Reputational	National news coverage from 10:15, complaint surge	Media coverage	Any condition	No	Yes
Duration	Occurred 06:40 on 10 March, resolved 09:10 on 11 March	26 h 30 min	Over 24 h	Not yet known	Yes
Service downtime	Unavailable 06:40 to 18:20 on 10 March	11 h 40 min	Over 2 h	No (1 h 50 min elapsed)	Yes
Geographical spread	Merchants affected in LU, BE, FR, DE	4 Member States	2 or more	Yes	Yes
Data losses	No integrity or confidentiality impact found	None	Art. 9(5)	No	No
Economic impact	See section 8.3	EUR 97,100	Over EUR 100,000	Not yet known	Not met
Result			Critical services plus 2 or more other thresholds	Major (clients and geographical spread)	Major (four criteria)

Duration and downtime are one criterion, so meeting both counts once. The same applies to clients and transactions.

3.4 Recurring incidents

Incidents that are not major on their own count as one major incident when they occurred at least twice within 6 months, share the same apparent root cause and together meet the Article 8(1) conditions (Delegated Regulation (EU) 2024/1772, Article 8(2)). Assess this monthly. The rule does not apply to microenterprises and to entities under the simplified framework of DORA Article 16. Report recurring incidents in aggregated form (Implementing Regulation (EU) 2025/302, Article 3).

Month assessed	Candidate incidents	Same apparent root cause	Combined thresholds met	Result
[YYYY-MM]	[INC-IDs]	[Yes / No]	[List]	[Major / Not major]

4. Reporting clock

4.1 Time limits (Delegated Regulation (EU) 2025/301, Article 5)

Submission	Time limit	Trigger to update
Initial notification	As early as possible, within 4 hours of classification as major and no later than 24 hours after becoming aware of the incident	If classified as major more than 24 hours after awareness: within 4 hours of classification (Art. 5(2))
Intermediate report	Within 72 hours of submitting the initial notification, even if nothing has changed	Updated intermediate report without undue delay when status or handling changes significantly, and in any case when regular activities have been recovered; also on request of the authority (DORA Art. 19(4)(b))
Final report	No later than one month after the intermediate report or, where applicable, the latest updated intermediate report	When the root cause analysis is complete and actual figures replace estimates (DORA Art. 19(4)(c))

If you cannot meet a time limit, inform the competent authority without undue delay and before the limit expires, with reasons (Art. 5(3)).

4.2 Weekends and bank holidays

Where a time limit falls on a weekend day or a bank holiday in the reporting entity's Member State, the submission may be made by noon of the next working day (Art. 5(4)). This relief does not apply to the initial notification and intermediate report of credit institutions, central counterparties, operators of trading venues and entities that are essential or important under NIS2 (Art. 5(5)), and competent authorities may remove it for other significant or systemic entities (Art. 5(6)). Record which case applies: [Relief applies / Relief does not apply, reason].

4.3 Worked timeline

Event	Date and time (CET)	Deadline computed	Met
Incident occurs (field 3.2) (Example)	2026-03-10 06:40, Tuesday
Detection and awareness (field 2.2) (Example)	2026-03-10 06:52	Initial notification no later than 2026-03-11 06:52 (24 hours after awareness)
Classified as major (field 2.3) (Example)	2026-03-10 08:30	Initial notification by 2026-03-10 12:30 (the earlier of the two limits)
Initial notification submitted (Example)	2026-03-10 11:05	Intermediate report by 2026-03-13 11:05	Yes
Regular activities recovered (field 3.3) (Example)	2026-03-10 18:20	Updated intermediate report without undue delay
Intermediate report submitted (Example)	2026-03-11 15:00	Final report one month later: 2026-04-11 15:00, a Saturday, so by noon on Monday 2026-04-13 under Art. 5(4)	Yes
Incident resolved (field 4.8) (Example)	2026-03-11 09:10
Root cause addressed (field 4.7) (Example)	2026-03-20 17:00
Final report submitted (Example)	2026-04-08 10:00		Yes

Calderfield Payments is a payment institution that is not an essential or important entity under NIS2 in this example, so the weekend relief is available; the team still planned the final report for a working day.

5. General information about the financial entity

Field	Data field (Annex I)	Value
1.1	Type of submission	[Initial notification / Intermediate report / Final report / Major incident reclassified as non-major]
1.2	Name of the entity submitting the report	[Legal name]
1.3	Identification code of the submitting entity	[LEI, or the code allowed for a third-party submitter]
1.4	Type of financial entity affected	[Type]
1.5	Name of the financial entity affected	[Legal name]
1.6	LEI code of the financial entity affected	[LEI]
1.7 to 1.9	Primary contact: name, email, telephone	[Contact]
1.10 to 1.12	Second contact: name, email, telephone	[Contact]
1.13	Name of the ultimate parent undertaking	[Name, where applicable]
1.14	LEI code of the ultimate parent undertaking	[LEI]
1.15	Reporting currency	[EUR / other]

6. Initial notification

Field	Data field (Annex I)	Content	Example value
2.1	Incident reference code assigned by the financial entity	[INC-NNNN]	INC-2026-0310
2.2	Date and time of detection	YYYY-MM-DD hh:mm	2026-03-10 06:52 CET
2.3	Date and time of classification as major	YYYY-MM-DD hh:mm	2026-03-10 08:30 CET
2.4	Description of the incident	[What happened, services affected, current status]	Card authorisation gateway partially unavailable since 06:40; about 20% of merchants cannot process card payments
2.5	Classification criteria that triggered the report	[Criteria from section 3]	Critical services affected; clients, financial counterparts and transactions; geographical spread
2.6	Member States affected (if geographical spread met)	[ISO 3166 alpha-2 codes]	LU, BE, FR, DE
2.7	How the incident was discovered	[IT security / staff / internal audit / external audit / clients / financial counterparts / third-party provider / attacker / monitoring systems / authority, agency or law enforcement / other]	Monitoring systems
2.8	Originates from a third-party provider or another financial entity	[Name, identification code and code type]	Yes: hosting provider PROV-07, LEI [LEI]
2.9	Business continuity plan activated	[Yes / No]	Yes, at 07:45
2.10	Other relevant information	[Free text]	Merchants informed through status page from 09:15

7. Intermediate report

7.1 Impact

Field	Data field (Annex I)	Example value
3.1	Incident reference code provided by the competent authority	[Authority reference]
3.2	Date and time of occurrence	2026-03-10 06:40 CET
3.3	Date and time when services, activities or operations were recovered	2026-03-10 18:20 CET
3.4, 3.5	Number and percentage of clients affected	9,600; 20%
3.6, 3.7	Number and percentage of financial counterparts affected	0; 0%
3.8	Impact on relevant clients or financial counterparts	Two large retail merchants identified as relevant were affected
3.9 to 3.11	Number, percentage and value of affected transactions	312,500; 25%; EUR 14,760,000
3.12	Actual figures or estimates	Actual for clients and transactions
3.13, 3.14	Reputational impact and context	Reflected in the media: national news websites in two Member States, complaint volume five times normal
3.15, 3.16	Duration and service downtime	26 h 30 min; 11 h 40 min
3.17	Actual figures or estimates for duration and downtime	Actual: the incident was resolved at 09:10 on 11 March, before this report
3.18, 3.19	Types of impact in Member States and description	Clients in LU, BE, FR, DE unable to accept card payments
3.20, 3.21	Data losses threshold and description	Not met; no data altered or disclosed
3.22	Critical services affected	Card acquiring, supporting a critical function

7.2 Nature and handling

Field	Data field (Annex I)	Example value
3.23, 3.24	Type of incident	Process failure; payment-related
3.25, 3.26	Threats and techniques used by a threat actor	Not applicable, no threat actor involved
3.27	Affected functional areas and business processes	Card authorisation and merchant settlement
3.28, 3.29	Affected infrastructure components	Yes: TLS termination layer of the gateway, fully outsourced to PROV-07, shared by two business functions
3.30	Impact on the financial interest of clients	Yes: lost sales for merchants during downtime
3.31, 3.32	Reporting to other authorities	None
3.33, 3.34	Temporary actions or measures	Yes: traffic failed over to secondary region at 17:55, manual certificate redeployment, merchant fallback guidance
3.35	Indicators of compromise	Not applicable

8. Final report

8.1 Root cause and resolution

Field	Data field (Annex I)	Example value
4.1	High-level root cause	Process failure
4.2, 4.3, 4.4	Detailed and additional root cause classification	Insufficient or failed ICT operations: certificate rotation at the provider deployed an incomplete certificate chain
4.5	Information about the root causes	Provider's automated rotation lacked a pre-deployment chain validation; Calderfield's monitoring checked expiry dates but not chain validity
4.6	Incident resolution summary	Certificate chain corrected, failover completed, backlog of deferred authorisations reprocessed
4.7	Date and time root cause addressed	2026-03-20 17:00 CET
4.8	Date and time incident resolved	2026-03-11 09:10 CET
4.9	Permanent resolution date differs from plan	No
4.10, 4.11	Risk to critical functions for resolution purposes, information for resolution authorities	Not applicable to a payment institution in this example

8.2 Recurring incidents

Field	Data field (Annex I)	Example value
4.15	Non-major incidents recurring	No
4.16	Dates and times of recurring incidents	Not applicable

8.3 Economic impact

Cost type (Delegated Reg. 2024/1772, Art. 7(1))	Example amount (EUR)
(a) Expropriated funds or financial assets	0
(b) Replacement or relocation of software, hardware or infrastructure	0
(c) Staff costs, including overtime	21,400
(d) Fees for non-compliance with contractual obligations	0
(e) Redress and compensation to customers (merchant fee waivers)	38,500
(f) Forgone revenues	9,800
(g) Internal and external communication	4,200
(h) Advisory costs (forensic review)	23,200
Gross direct and indirect costs and losses (field 4.13)	97,100
Financial recoveries, reported separately (field 4.14): service credits from PROV-07	12,000
Economic impact threshold of EUR 100,000 met (field 4.12)	No

Exclude business-as-usual costs such as general maintenance, post-incident improvements and insurance premiums (Art. 7(2)).

8.4 Remediation actions

Action ID	Action	Owner	Due	Status
REM-01 (Example)	Add certificate chain validation to synthetic monitoring	[@sre-lead]	2026-04-15	[Open / Done]
REM-02 (Example)	Contract change: provider to run pre-deployment validation and give 48 hours notice of rotations	[@vendor-manager]	2026-06-30	[Open / Done]
REM-03 (Example)	Exercise automatic regional failover quarterly	[@platform-lead]	2026-06-30	[Open / Done]
[REM-NN]	[Action]	[@owner]	YYYY-MM-DD	[Status]

9. Informing clients

DORA Article 19(3) requires the financial entity, when a major incident has an impact on the financial interests of clients, to inform them without undue delay about the incident and the measures taken to mitigate its effects. For a significant cyber threat, inform potentially affected clients, where applicable, of protective measures they may consider.

Time	Channel	Audience	Message summary	Approved by
2026-03-10 09:15 (Example)	Status page and email	Affected merchants	Outage, fallback options, next update time	[@comms-lead]
2026-03-10 18:40 (Example)	Email	Affected merchants	Service restored, fee waiver for the day	[@comms-lead]
[Time]	[Channel]	[Audience]	[Summary]	[@name]

10. Reclassification, joint and aggregated submissions

Reclassification: if further assessment shows that a reported incident never met the Article 8 conditions, notify the authority that it is reclassified as non-major, using the "type of submission" and "other information" fields (Implementing Regulation (EU) 2025/302, Article 5).
Joint submission: the initial, intermediate and final reports may be submitted together where regular activities have recovered or the root cause analysis is complete, provided each time limit is still met (Article 2).
Outsourced reporting: inform the authority of an outsourcing arrangement before the first report (Article 6). The financial entity remains fully responsible (DORA Article 19(5)).
Aggregated reporting by a third-party provider: allowed only under the conditions of Article 7, including that the incident originates at the provider, affects entities in one Member State supervised by the same authority, and the authority has permitted it. It is not available to significant credit institutions, trading venues and central counterparties.

11. Voluntary notification of significant cyber threats

A cyber threat is significant when all conditions of Article 10 of Delegated Regulation (EU) 2024/1772 are met: it could affect critical or important functions or other parties; it has a high probability of materialising, considering vulnerabilities, threat actor capability and intent, and persistence; and, if it materialised, it could meet the critical services criterion or the clients or geographical spread thresholds. The notification content follows Article 6 of Delegated Regulation (EU) 2025/301 and the 20 fields of Annex III to Implementing Regulation (EU) 2025/302.

Annex III fields	Content
1 to 11	Submitting entity, financial entity, LEI, contacts
12	Date and time of detection
13, 14	Description and potential impact
15	Classification criteria that could be met
16, 17	Status and actions to prevent materialisation
18	Notification to other stakeholders
19, 20	Indicators of compromise, other information

12. Other reporting regimes

Regime	When it applies	Clock	Link
GDPR Articles 33 and 34	Personal data breach	72 hours to the supervisory authority where feasible; data subjects without undue delay if high risk	`compliance/personal-data-breach-assessment`
NIS2	DORA is the sector-specific act for financial entities in its scope; Member States may require DORA reports to be shared with NIS2 authorities or CSIRTs (DORA Art. 19(1))	As DORA	`compliance/nis2-security-measures`
Payment-related incidents	Credit institutions, payment institutions, account information service providers and e-money institutions report operational or security payment-related incidents under DORA (Art. 23)	As DORA	This template
Contracts and group policy	Client contracts, group reporting lines	[Contract terms]	[Reference]

Check the consolidated texts for later amendments, including any change to how and where incident reports are submitted.

13. Records, lessons learned and review

Record every ICT-related incident and significant cyber threat in the incident register required by DORA Article 17, whether or not it is major.
Keep copies of each submission, its acknowledgement and the evidence behind each figure.
Run a post-incident review and feed lessons into the ICT risk management framework (DORA Article 13) and the business impact analysis.
Report major incidents and remediation status to the management body.
Review this template and the classification worksheet after each major incident and at least [annually].

14. Glossary and references

14.1 Glossary

Term	Meaning in this document
ICT-related incident	An unplanned event or linked events that compromise the security of network and information systems and have an adverse impact on availability, authenticity, integrity or confidentiality of data or on services
Major ICT-related incident	An ICT-related incident that meets the Article 8 conditions of Delegated Regulation (EU) 2024/1772
Significant cyber threat	A cyber threat meeting the Article 10 conditions of Delegated Regulation (EU) 2024/1772
Critical or important function	A function whose disruption would materially impair financial performance, continuity of services or regulatory compliance
Competent authority	The supervisor designated under DORA Article 46
LEI	Legal Entity Identifier, 20 characters
Classification time	The time the entity concluded that the incident is major, field 2.3

14.2 References

Reference	Version or date	Use
Regulation (EU) 2022/2554 (DORA), OJ L 333, 27.12.2022	Applies from 17 January 2025; check the consolidated text	Articles 3, 17 to 20, 23
Commission Delegated Regulation (EU) 2024/1772	Adopted 13 March 2024, published 25 June 2024	Classification criteria and thresholds
Commission Delegated Regulation (EU) 2025/301	Adopted 23 October 2024, published 20 February 2025	Content and time limits
Commission Implementing Regulation (EU) 2025/302	Adopted 23 October 2024, published 20 February 2025	Forms, Annex I fields, Annex II glossary, Annex III and IV cyber threat forms
Competent authority reporting instructions	[Version and date]	Channel and technical format

Standard and licence note

Based on Regulation (EU) 2022/2554 (DORA), Commission Delegated Regulations (EU) 2024/1772 and (EU) 2025/301 and Commission Implementing Regulation (EU) 2025/302, as published in the Official Journal of the European Union. EU legislative texts are free to reuse. Article numbers and Annex I field numbers and names are cited; requirements are summarised in original wording and no legal text or form is reproduced in full. Check the consolidated texts at https://eur-lex.europa.eu/eli/reg/2022/2554/oj, https://eur-lex.europa.eu/eli/reg_del/2024/1772/oj, https://eur-lex.europa.eu/eli/reg_del/2025/301/oj and https://eur-lex.europa.eu/eli/reg_impl/2025/302/oj, and your competent authority's instructions, before use. This is a documentation format, not legal advice; check the current official text and a qualified professional. Template licence: MIT.