DORA

at a glance

what it is

An EU regulation. It applies directly, with no national law in between.

who it covers

20 types of financial entity, and the ICT third-party providers that serve them.

the size line

None. Every covered entity is in scope, and the work scales with size and risk.

fine ceilings

No EU figure. Member states set them, so check yours.

who answers

The management body is ultimately responsible for ICT risk.

status

Applying now. A proposal would change how incidents are filed, and is still in committee.

basis DORA Art. 2(1), 4(1), 5(2), 50(3), 64

does it apply to you?

the whole job, in order

Phases, with who carries each step and the proof it leaves. Open a phase to see its steps.

• put management in charge

  Settle which role you play under DORA, who answers for ICT risk and how much risk the company accepts.

  4 steps
• build the ICT risk framework

  Document the framework and the things it protects, then put the basic controls in place.

  6 steps
• list every ICT contract

  Know which ICT services you buy, which of them support a critical or important function and what your policy says about them.

  5 steps
• classify and report incidents

  Decide who handles an incident, how it is classified and how the supervisor hears about it on time.

  6 steps
• test resilience

  Run a testing programme in proportion to your size and risk, and fix what it finds.

  4 steps
• get the contracts right

  Check providers before you sign, write the required terms into the contract and plan how to leave.

  8 steps
• show it keeps working

  Keep the proof together, review the framework on a rhythm and report to management.

  5 steps

the dates

What applies when. The reference sits under each date.

1. 17 January 2025DORA appliesDORA Art. 64applies now

the fine ceilings

The ceilings each text sets. The reference sits under each.

• DORAno EU figure; member states set the penaltiesDORA Art. 50(3)

  Look it up in your national act and ask your supervisor.

what it asks, and ways to meet it

The rule says what must be true in the company. It names no tools or methods: you choose them, and the people implementing it and the board answer for the choice. Under each requirement are the controls that usually deliver it. That grouping is our reading of the rule, not a list from the act.

1. DORA Art. 6(1)

   A documented ICT risk management framework.

   • risk register
2. DORA Art. 8(1)

   Identify and document functions, assets and dependencies, reviewed at least yearly.

   • asset inventory
3. DORA Art. 9(4)(c)

   Limit physical and logical access to what approved functions need.

   • privileged access
   • access reviews
4. DORA Art. 9(4)(d)

   Policies and protocols for strong authentication.

   • multi-factor authentication
   • encryption and key management
   • single sign-on and directory
5. DORA Art. 9(4)(f)

   Appropriate and comprehensive documented policies for patches and updates.

   • endpoint management
6. DORA Art. 10(1)

   Mechanisms to promptly detect anomalous activities, regularly tested. Detection sets alert thresholds and automatic alerts to the staff in charge of response, and gets enough resources to monitor user activity.

   • logging and monitoring
7. DORA Art. 12(1)

   Written backup policies and procedures: the scope of the data, the minimum frequency based on criticality or confidentiality, and restoration and recovery procedures.

   • backup and recovery
8. DORA Art. 12(2) and 12(3)

   Backup systems that can be activated without harming security or data, periodic testing, and restoration on systems physically and logically separate from the source.

   • backup and recovery
9. DORA Art. 13(6)

   ICT security awareness programmes and digital operational resilience training as compulsory modules, for all employees and senior management, at a level that fits their functions.

   • awareness training
10. DORA Art. 17(1)

    Financial entities define, establish and implement an ICT-related incident management process to detect, manage and notify incidents.

    • incident management
11. DORA Art. 17(2)

    Record all ICT-related incidents and significant cyber threats, and follow up so that root causes are identified, documented and addressed.

    • incident management
12. DORA Art. 17(3)(b)

    Procedures to identify, track, log, categorise and classify ICT-related incidents.

    • logging and monitoring
13. DORA Art. 19(1)

    Report major ICT-related incidents to the competent authority.

    • incident management
14. DORA Art. 25(1)

    Testing such as vulnerability scans, network assessments and scenario tests.

    • vulnerability management
15. DORA Art. 28(3)

    A register of all ICT contracts, separating those that support critical or important functions.

    • supplier management
16. DORA Art. 30(2)

    Minimum contract terms: locations, data protection, data return, service levels, assistance.

    • supplier management

how it fits with the others

• NIS2

  NIS2 steps aside where DORA covers you.

• GDPR

  DORA overlaps with NIS2 and GDPR. The guide shows where.

the work under this rule

• incident reportingFor the board and the owner of IT: one event can start three clocks at once, each to a different authority. The hours are easy to remember. The hard part is that someone must be allowed to say this counts before the investigation is finished.
• supplier riskYour suppliers' failures count as yours. NIS2, DORA and GDPR ask for the same three things: know who your suppliers are, check them in proportion, and put security in the contract.
• the board's partFor directors and the chair: security decisions now need a director's signature. A board does not have to understand firewall rules. It has to see risks, cost and choice, decide, and be able to show that it did.
• access controlFor the owner of IT: who can get in, who approved it and when someone last checked. NIS2, DORA and GDPR all ask for this, so one review done properly answers all three.
• risk assessmentEvery rule asks for measures that fit the risk. A short written assessment lets you show that yours do, and gives you an honest reason to do less where the risk is low.
• backups and recoveryFor the owner of IT and the chief executive: a backup counts once you have restored from it. One timed restore tells you more than a plan, and it leaves a record that the control runs.
• trainingNIS2, DORA and GDPR ask for training, and the AI Act adds its own. One small programme with one attendance record answers them all. The failure that shows up is having no record.
• patching and checking it worksPatch on a schedule you wrote down, handle the reports that come in, and test once a year whether the rest of your controls run. Companies skip the last part because nothing breaks when they do.