What is DORA?
The EU's Digital Operational Resilience Act. It is a regulation, not a directive, so it applies directly without national transposition — one rulebook for ICT risk across the EU financial sector.
Around twenty categories of financial entity: banks, insurers, investment firms, payment and e-money institutions, crypto-asset service providers, fund managers, trading venues and more — plus the ICT third-party providers they rely on.
What DORA is, the four-hour notification once an incident is classified as major, and the Annex I report the incident register prepares from your own records. Prepared here; filed by you.
Plays here from YouTube when you press play; nothing is loaded from YouTube before that. Watch on YouTube (opens in a new tab)
The Register of Information, made under Art. 28(9).
B_02.01, B_02.02, B_05.01 and B_06.01, as plain CSV.
Verified against Annex I and the EBA XBRL taxonomy.
Dates that matter
- 16 January 2023Entered into force.
- 17 January 2025Applies. No transposition step — it binds directly.
What people get wrong
The Register of Information is the hardest deliverable
Article 28(3) requires a register of all contractual arrangements for ICT services, at entity, sub-consolidated and consolidated level. The templates come from Implementing Regulation (EU) 2024/2956, and the column numbering was corrected by a corrigendum of 19 September 2025 — the original published Annex numbers one template differently, and that original PDF is still the copy most easily found.
It reaches your suppliers, not just you
Chapter V sets requirements for contractual arrangements with ICT third-party providers, and designates critical providers for direct oversight. Substitutability, exit strategies and sub-outsourcing chains are all in scope.
Threat-led penetration testing, for some
Advanced testing under Article 26 applies to entities identified by their competent authority, on a TIBER-EU-aligned basis. Vivid Risk does not perform or arrange testing.
What Vivid Risk does with DORA
Article citations verified against the Official Journal; in the DORA-led report, citations to the RTS on ICT risk management (Commission Delegated Regulation (EU) 2024/1774), full or simplified framework by your own DORA Art. 16(1) answer; a Register of Information export covering 4 of the 15 templates as plain CSV; and, in the incident register, the Article 19 reporting clocks with the Annex I major-incident report (Implementing Regulation (EU) 2025/302) prepared from your own records.
Both are preparation aids, and Vivid Risk files neither. The Register of Information export is not xBRL-CSV, is not validated against the EBA taxonomy, and cannot be filed with a competent authority. The incident report sheet is for you to check and submit through your competent authority’s own secure channel, and it has not been checked against any authority’s file format.
Article 30, point by point
The register tells you who your ICT providers are. Article 30 governs what the contracts behind it have to say. 9 elements under Article 30(2) bind every contractual arrangement for the use of ICT services, and 6 more under Article 30(3) apply where the service supports a critical or important function — so 15 in total for those. Each is quoted below in the Regulation’s own words.
Article 30(2) applies to every contractual arrangement for the use of ICT services. Article 30(3) adds six further elements where the service supports a critical or important function. Vivid Risk does not read your contracts — nothing is uploaded here and nothing is parsed. Each row records what you tell us your contract contains, and where to find it. Whether a clause you point at actually satisfies the point is a question for your counsel.
Every arrangement — Article 30(2)
9 elementsThese bind any contractual arrangement for the use of ICT services, whatever the service supports.
- 30(2)(a)Description of functions and services, and whether subcontracting is permitted
a clear and complete description of all functions and ICT services to be provided by the ICT third-party service provider, indicating whether subcontracting of an ICT service supporting a critical or important function, or material parts thereof, is permitted and, when that is the case, the conditions applying to such subcontracting
- 30(2)(b)Locations of provision, processing and storage, and advance notice of change
the locations, namely the regions or countries, where the contracted or subcontracted functions and ICT services are to be provided and where data is to be processed, including the storage location, and the requirement for the ICT third-party service provider to notify the financial entity in advance if it envisages changing such locations
- 30(2)(c)Availability, authenticity, integrity and confidentiality of data
provisions on availability, authenticity, integrity and confidentiality in relation to the protection of data, including personal data
- 30(2)(d)Access, recovery and return of data on insolvency or termination
provisions on ensuring access, recovery and return in an easily accessible format of personal and non-personal data processed by the financial entity in the event of the insolvency, resolution or discontinuation of the business operations of the ICT third-party service provider, or in the event of the termination of the contractual arrangements
- 30(2)(e)Service level descriptions
service level descriptions, including updates and revisions thereof
- 30(2)(f)Incident assistance at no cost, or at a cost fixed in advance
the obligation of the ICT third-party service provider to provide assistance to the financial entity at no additional cost, or at a cost that is determined ex-ante, when an ICT incident that is related to the ICT service provided to the financial entity occurs
- 30(2)(g)Full cooperation with competent and resolution authorities
the obligation of the ICT third-party service provider to fully cooperate with the competent authorities and the resolution authorities of the financial entity, including persons appointed by them
- 30(2)(h)Termination rights and minimum notice periods
termination rights and related minimum notice periods for the termination of the contractual arrangements, in accordance with the expectations of competent authorities and resolution authorities
- 30(2)(i)Participation in your awareness programmes and resilience training
the conditions for the participation of ICT third-party service providers in the financial entities' ICT security awareness programmes and digital operational resilience training in accordance with Article 13(6)
Critical or important functions — Article 30(3)
6 elementsThese apply in addition, where the ICT service supports a critical or important function.
- 30(3)(a)Full service levels with quantitative and qualitative targets
full service level descriptions, including updates and revisions thereof with precise quantitative and qualitative performance targets within the agreed service levels to allow effective monitoring by the financial entity of ICT services and enable appropriate corrective actions to be taken, without undue delay, when agreed service levels are not met
- 30(3)(b)Notice periods and reporting of developments with material impact
notice periods and reporting obligations of the ICT third-party service provider to the financial entity, including notification of any development that might have a material impact on the ICT third-party service provider's ability to effectively provide the ICT services supporting critical or important functions in line with agreed service levels
- 30(3)(c)Contingency plans tested, and ICT security measures in place
requirements for the ICT third-party service provider to implement and test business contingency plans and to have in place ICT security measures, tools and policies that provide an appropriate level of security for the provision of services by the financial entity in line with its regulatory framework
- 30(3)(d)Participation in your threat-led penetration testing
the obligation of the ICT third-party service provider to participate and fully cooperate in the financial entity's TLPT as referred to in Articles 26 and 27
- 30(3)(e)Ongoing monitoring: access, inspection and audit rights
the right to monitor, on an ongoing basis, the ICT third-party service provider's performance, which entails the following: (i) unrestricted rights of access, inspection and audit by the financial entity, or an appointed third party, and by the competent authority, and the right to take copies of relevant documentation on-site if they are critical to the operations of the ICT third-party service provider, the effective exercise of which is not impeded or limited by other contractual arrangements or implementation policies; (ii) the right to agree on alternative assurance levels if other clients' rights are affected; (iii) the obligation of the ICT third-party service provider to fully cooperate during the onsite inspections and audits performed by the competent authorities, the Lead Overseer, financial entity or an appointed third party; and (iv) the obligation to provide details on the scope, procedures to be followed and frequency of such inspections and audits
By way of derogation from point (e), the ICT third-party service provider and the financial entity that is a microenterprise may agree that the financial entity's rights of access, inspection and audit can be delegated to an independent third party, appointed by the ICT third-party service provider, and that the financial entity is able to request information and assurance on the ICT third-party service provider's performance from the third party at any time.
- 30(3)(f)Exit strategy and a mandatory transition period
exit strategies, in particular the establishment of a mandatory adequate transition period: (i) during which the ICT third-party service provider will continue providing the respective functions, or ICT services, with a view to reducing the risk of disruption at the financial entity or to ensure its effective resolution and restructuring; (ii) allowing the financial entity to migrate to another ICT third-party service provider or change to in-house solutions consistent with the complexity of the service provided
Reporting a major ICT-related incident
Article 19 requires three reports to your competent authority. Article 19 itself sets no time limits: they come from Commission Delegated Regulation (EU) 2025/301, and the form and channel from Implementing Regulation (EU) 2025/302.
Initial notification
DORA Art. 19(4)(a); RTS Art. 5(1)(a)Due within four hours from the classification of the ICT-related incident as a major ICT-related incident (RTS Art. 5(1)(a)), and no later than 24 hours of discovery.
Intermediate report
DORA Art. 19(4)(b); RTS Art. 5(1)(b)Due within 72 hours of the earlier report being submitted.
Final report
DORA Art. 19(4)(c); RTS Art. 5(1)(c)Due within one month of the earlier report being submitted.
If you classify late
RTS Art. 5(2) Where the financial entity has not classified an ICT-related incident as major within 24 hours from the moment the financial entity has become aware of the ITC-related incident but classifies that ICT-related incident as major at a later stage, the financial entity shall submit the initial notification within four hours from the classification of the ICT-related incident as a major incident.
On a set template, through a set channel
ITS Art. 1(1) Financial entities shall use the template laid down in Annex I to submit the initial notification, the intermediate report, and the final report referred to in Article 19(4) of Regulation (EU) 2022/2554 as follows: (Its points (a) to (c) then say which of the template’s fields each of the three reports must complete, following the glossary in Annex II.)
ITS Art. 4(1) Financial entities shall use secure electronic channels as made available by their competent authority to submit the initial notification and the intermediate and final reports.
What the incident register does
- Runs these three clocks on each incident once you have said you are a financial entity under DORA, beside the other duties the same incident may trigger.
- Counts the limit that runs from classification once you record when you classified the incident as major, and shows which limit binds — including the late-classification case above.
- Prepares the Annex I template: all 76 fields, with up to 13 filled from what the register already holds, and every field Annex II marks mandatory that is still empty counted for you. Your entity details carry forward to your next DORA incident.
- Starts the next clock from the submission time you record: the intermediate report from the initial notification, and the final report from the intermediate one.
Why run DORA reporting in Vivid Risk
Without a tool, this lives in a spreadsheet, an inbox and someone’s memory — at its weakest when it matters, hours from a deadline.
- One entry, every clock
- Log the incident once. DORA, GDPR and your national incident rules each run on their own deadline, side by side — reporting under one does not discharge another.
- The deadlines after the first one
- The intermediate and final reports run from the submissions you record, and an updated intermediate report is shown as owed once you record that regular activities have recovered — the follow-ups that are easiest to miss.
- The report half-written
- The Annex I template pre-filled from what you have already recorded, the mandatory gaps counted, and your entity details already there from your last DORA incident.
- The record DORA asks for anyway
- DORA Art. 17(2) “Financial entities shall record all ICT-related incidents and significant cyber threats.” Every incident sits in one register — including a decision not to report, with your reasoning. Each filing, decision and DORA reporting record you save is fingerprinted into your tenant’s tamper-evident (HMAC-SHA256) chain, so a later change to it can be detected; if adding the link fails, the record is still saved without it.
- The rest of DORA in the same workspace
- The Register of Information export and the Article 30 clause register described on this page, and an assessment cited to the Regulation and its RTS on ICT risk management.
The incident register is part of Compliance Workspace, at €499 a month — bought online, no sales call.
This is a preparation sheet, not a submission. Check every value, then submit the report on the Annex I template through your competent authority’s secure electronic channel (ITS 2025/302 Art. 4(1)). Vivid Risk files nothing. We have not confirmed which file format your authority’s channel accepts, so copy the values across rather than assuming this file can be uploaded as it is.
What the register tells you about classification: Whether an incident is "major" — and so reportable at all — is your own determination under Art. 18, against the criteria and materiality thresholds in Commission Delegated Regulation (EU) 2024/1772. That Regulation is not encoded here and nothing on this screen applies it: the severity you set on an incident is not a DORA classification, and this register cannot tell you whether an incident is reportable.
Questions
Can I file my Register of Information from Vivid Risk?
No. The export is a data-preparation aid: 4 of the 15 templates as plain CSV, with the disclosure in row 1 of every file. It is not xBRL-CSV, is not validated against the EBA taxonomy, and cannot be filed with the Central Bank of Ireland or any other competent authority.
Can Vivid Risk file my major-incident report?
No. The incident register runs the Article 19 clocks and prepares the Annex I template from your own records, but the report goes from you to your competent authority, through the secure electronic channel that authority makes available (Implementing Regulation (EU) 2025/302, Art. 4(1)). DORA Art. 19(5) lets you outsource the reporting to a third party, and you remain fully responsible for it if you do.
Does DORA replace NIS2 for financial entities?
DORA is lex specialis for ICT risk in the financial sector, so where both could apply to the same subject matter, DORA's requirements take precedence. That is a legal question for your own advisers, not something a tool decides.
Does DORA apply to UK financial firms?
DORA binds financial entities authorised in the Union, so it does not bind a firm authorised only in the UK as a financial entity. UK firms have the FCA's and the PRA's own rules on incidents, third parties and operational resilience, which have their own page here. A group with firms on both sides can have both, each for its own firms.
One assessment, every cited framework
The same answers produce your citations across every framework your scored controls are cited to, rather than one questionnaire per regulation.