What are the DORA 5 pillars?
The Digital Operational Resilience Act splits every financial entity's cyber and IT obligations into five blocks: a documented ICT risk management framework, incident classification and reporting, resilience testing, third-party ICT risk management, and voluntary threat intelligence sharing. For payment institutions and e-money institutions, none of this is optional guidance anymore, it's directly applicable EU law under Regulation (EU) 2022/2554, enforced since 17 January 2025.
I've spent the last year helping EMIs and PIs retrofit compliance programmes that were built for PSD2 and AML onto DORA's structure. The good news: if you already run a decent operational risk function, you're not starting from zero. The bad news: DORA is prescriptive in a way EBA guidelines never were, and supervisors are now asking for artefacts, not intentions.
Pillar 1: ICT risk management framework (Articles 5 to 16)
This is the backbone chapter and the heaviest lift. Article 5 puts ultimate responsibility on the management body, not the CTO or a delegated risk committee. The board must approve the ICT risk strategy, set risk tolerance, and sign off budget for resilience work.
Article 6 requires a "sound, comprehensive and well-documented" framework reviewed at least annually, and after major incidents or supervisory findings. Article 8 demands a classified inventory of all ICT assets and their dependencies. Articles 9 to 14 cover protection and prevention, detection, business continuity, backup and recovery, and the "learning and evolving" obligation, meaning post-incident reviews actually change your controls.
Smaller PIs and EMIs exempted under PSD2/EMD2 can use the simplified framework in Article 16, which drops some documentation and governance depth but doesn't remove the underlying duty to identify, protect, detect, respond to and recover from ICT risk.
Pillar 2: Incident management, classification and reporting (Articles 17 to 23)
Article 17 requires a process to detect, manage and notify ICT-related incidents. Article 18 sets the classification criteria for what counts as "major" (client impact, duration, geographic spread, data losses, economic impact, among others), with the quantitative thresholds fleshed out in the related RTS.
Article 19 then drives the reporting clock: once an incident is classified as major, you owe the competent authority an initial notification, an intermediate report once facts change materially, and a final report once root cause analysis is complete. The practical deadlines sit in the implementing technical standards, and they're tight, so the runbook has to exist before the incident, not during it.
Pillar 3: Digital operational resilience testing (Articles 24 to 27)
Article 24 requires a risk-based testing programme covering critical ICT systems, reviewed at least annually. Article 25 lists the baseline methods every entity must run: vulnerability assessments, network security reviews, scenario-based testing, source code review where relevant.
Article 26 introduces Threat-Led Penetration Testing (TLPT), based on the TIBER-EU methodology, for entities your competent authority designates as significant. Most EMIs and smaller PIs won't be in scope for TLPT, but the baseline testing obligation in Articles 24 and 25 applies regardless of size. Article 27 sets independence and competence requirements for testers.
Pillar 4: ICT third-party risk management (Articles 28 to 30, within the wider Chapter V running to Article 44)
This is where most EMIs feel the most pain, because payment institutions run on outsourced core banking platforms, card processors, cloud infrastructure and KYC vendors. Article 28 requires ICT third-party risk to be managed as an integral part of the risk framework, with a board-approved third-party risk strategy and, critically, a Register of Information covering every contractual arrangement with an ICT provider, distinguishing those supporting critical or important functions.
Article 30 sets the mandatory contract clauses: service descriptions, data location, audit and access rights, termination rights, exit assistance periods, and cooperation with supervisors. Contracts signed before January 2025 that lack these clauses are non-compliant today, not on some future renewal date.
Pillar 5: Information-sharing arrangements (Article 45)
The only voluntary pillar, and the one everyone skips. Article 45 lets financial entities exchange cyber threat indicators, tactics and alerts within trusted communities (ISACs, CSIRTs, sector groups), subject to GDPR, confidentiality and competition safeguards. If you join such an arrangement, you must notify your competent authority of participation. It costs little and signals operational maturity to a supervisor assessing your overall posture.
ICT risk management checklist for EMIs and PIs
- Board-approved ICT risk strategy and documented risk tolerance, reviewed at least annually (Art. 5 to 6)
- Classified inventory of ICT assets and their business function dependencies (Art. 8)
- Documented protection, detection, backup and business continuity policies (Art. 9 to 12)
- Incident classification criteria and a tested runbook for initial, intermediate and final reporting (Art. 17 to 19)
- An annual resilience testing programme covering vulnerability scans, scenario testing and, where designated, TLPT (Art. 24 to 27)
- A complete, current Register of Information for every ICT third-party contract, flagging which support critical or important functions (Art. 28)
- Article 30 compliant clauses (access, audit, exit, termination) in every live ICT vendor contract, not just new ones
- A decision on whether to join a cyber threat information-sharing arrangement, and notification to your competent authority if you do (Art. 45)
- Evidence trail: minutes, risk assessments, test reports and audit findings that a supervisor can actually request and review
If you're an EMI or PI mapping these obligations against your current control set, Novafin's DORA operational resilience work is built specifically for this gap-closing exercise. For the third-party piece specifically, we've written a deeper walkthrough of what the Article 28 vendor register actually needs to contain.
If you want a second pair of eyes on where your programme stands, reach out at team@novafin.co or get in touch via our DORA gap audit page.