The complete operational resilience playbook for credit institutions: ECB SSM supervision, TLPT scoping, ICT risk integration with ICAAP/SREP, third-party concentration risk and incident reporting timelines.
A practitioner-built DORA compliance pack tailored to credit institutions: a 30-point Excel checklist across the five pillars plus an implementation guide (PDF) mapped to CRR/CRD and your SREP.
+ VAT. Instant download (Excel + PDF). One-time purchase, no subscription.
DORA applies to all EU banks: ECB-supervised significant institutions and less significant institutions alike (Article 2(1)(a)). Since 17 January 2025 they must run an ICT risk-management framework, classify and report major incidents (4h / 72h / 1-month), maintain a Register of Information, oversee ICT third parties under Article 30, and perform threat-led penetration testing (TLPT) where their competent authority identifies them.
Building your DORA team? Start with the DORA Compliance Officer, a verifiable certification for the person who runs a bank's DORA programme. Browse all DORA certifications.
Banks operate at the intersection of two structural realities that make DORA particularly consequential. First, modern retail and corporate banking is fundamentally a digital service: core banking platforms, payment rails, mobile channels, anti-money-laundering screening, fraud detection and trading desks all run on ICT stacks where an outage of a few minutes can halt transactions and lead to supervisory notifications and reputational damage. Second, banks are systemically connected, a failure at a single bank can propagate through correspondent banking, payment systems and counterparty exposures across the European financial system.
Before DORA, ICT risk supervision was fragmented across the EBA Guidelines on ICT and security risk management (EBA/GL/2019/04), the EBA Outsourcing Guidelines, sectoral PSD2 incident reporting, and national supervisory practices. This fragmentation produced inconsistent expectations, double-reporting and gaps. DORA replaces the patchwork with a single, directly-applicable Regulation (EU) 2022/2554 with technical standards binding across all 27 Member States.
For credit institutions specifically, DORA elevates ICT risk to the same level of supervisory attention historically reserved for credit and market risk. The ECB's supervisory priorities for 2026-2028 name "strengthening banks’ operational resilience and fostering robust ICT capabilities" as Priority 2, with on-site inspection campaigns on cybersecurity and third-party risk management (ECB Banking Supervision). National competent authorities (BaFin, ACPR, DNB, Banco de España, Banca d'Italia, Finansinspektionen, FMA, CSSF and others) coordinate with the ECB Joint Supervisory Teams (JSTs) to inspect ICT risk frameworks during regular SREP cycles and on-site inspections.
DORA applies directly to all credit institutions authorised under Directive 2013/36/EU (CRD). Three cases shape how the regulation applies day-to-day:
Directly supervised by the ECB under the Single Supervisory Mechanism (SSM), per the ECB list of supervised entities with a 1 July 2026 cut-off. The ECB is their competent authority for DORA (Article 46(a)), and their major incident reports reach it through the national competent authority (Article 19(1)). JSTs lead DORA inspections, often in coordination with the national authority. These banks face the deepest scrutiny: full ICT risk framework reviews, on-site inspections, and SREP integration.
Supervised by national competent authorities. The ECB sets the supervisory framework via the SSM but day-to-day inspection is national. Every LSI applies the full ICT risk management framework of Articles 5 to 15, calibrated by proportionality (Article 4): size does not open the simplified framework of Article 16 to an authorised bank.
The entities referred to in Article 2(5), points (4) to (23), of Directive 2013/36/EU apply the simplified ICT risk management framework of Article 16, unless their Member State has excluded them from DORA under Article 2(4). Post office giro institutions are outside DORA altogether (Article 2(3)(f)).
Which of these describes your institution?
Applies with the ECB as competent authority (Article 46(a)), calibrated by the proportionality principle of Article 4. You file major incident reports with your national competent authority, which transmits them to the ECB immediately (Article 19(1)). If identified for TLPT, you may use external testers only (Article 26(8)).
Next step: TLPT Readiness CheckerApplies whatever your size, calibrated by the proportionality principle of Article 4, with your national competent authority supervising compliance (Article 46(a)). Being small does not open the simplified framework of Article 16 to an authorised bank. TLPT applies only if your competent authority identifies you (Article 26(8)).
Next step: DORA Gap AnalysisApplies by operation of law to an institution exempted under CRD Article 2(5), points (4) to (23), where your Member State has not used the option in Article 2(4). Article 16 replaces Articles 5 to 15 only: incident reporting, the Register of Information and ICT third-party risk still apply, proportionately (Article 4(2)). TLPT does not apply (Article 26(1)).
Next step: DORA Compliance ChecklistDORA does not apply to post office giro institutions (CRD Article 2(5), point (3)). A Member State may also exclude the entities referred to in CRD Article 2(5), points (4) to (23), located in its territory, and must inform the Commission. If you also hold an authorisation listed in Article 2(1), run the scope check for that activity.
Next step: DORA Scope DeterminationNot sure your entity is a financial entity at all? Run the free scope determination.
DORA's 64 articles map onto five operational pillars. Below is what each pillar means specifically for a credit institution, with the binding article references and the related RTS that operationalise them.
Credit institutions must maintain an ICT risk management framework that is documented, board-approved, and integrated with overall risk management. The framework covers identification of ICT-supported business functions, classification of information assets, protection through layered controls (Article 9), continuous threat detection (Article 10), response and recovery procedures (Articles 11–12), and learning from incidents (Article 13). The Commission Delegated Regulation 2024/1774 (RTS on ICT risk framework) specifies minimum content for security policies, network segmentation, identity and access management, encryption, change management and ICT business continuity policy.
For banks, integration with ICAAP and the operational risk inventory under CRR is critical. The board must define ICT risk appetite as part of the broader risk appetite statement and validate that ICT risk is captured in stress testing scenarios.
Banks must operate an end-to-end incident management process that detects, classifies, contains, recovers and reports ICT-related incidents. Major incidents trigger external reporting under harmonised criteria (RTS on classification): clients affected, geographic spread, duration, data integrity impact, economic impact, reputational impact, and impact on critical services. Significant cyber threats (not yet incidents) are reported on a voluntary basis under Article 19.
Reporting timelines are uniform: initial notification within 4 hours of classification (max 24h after becoming aware of the incident), intermediate report within 72h of the initial notification, final report within one month of the latest intermediate report. Banks already submitting PSD2 incident reports use the consolidated DORA template, no double reporting.
All banks must conduct an annual programme of digital operational resilience testing including vulnerability assessments, scenario-based tests, network security assessments, gap analyses, source code reviews where relevant and physical security tests. Testing must cover all critical or important ICT systems and be performed by independent parties, internal testers are acceptable provided independence safeguards are documented. Banks identified by their competent authority under Article 26(8) also conduct Threat-Led Penetration Testing (TLPT) at least every 3 years (see below); a significant institution may use external testers only (Article 26(8)).
This is where banks face the largest operational lift. Article 28 sets the principles and mandates the Register of Information (Article 28(3)), Article 29 requires a preliminary assessment of ICT concentration risk, Article 30 lists the mandatory contractual clauses (audit rights, exit strategies, sub-outsourcing rules, data location), Articles 31 to 44 establish the Oversight Framework for Critical ICT Third-Party Providers (CTPPs). For banks heavily reliant on cloud, SaaS providers, market data vendors and payment infrastructure, this means renegotiating hundreds of contracts, building a real-time register and aligning vendor management with the lead overseer regime.
Voluntary participation in trusted communities for cyber threat information sharing. Banks typically join via FS-ISAC or national sector arrangements. Article 45(1) allows financial entities to exchange cyber threat information and intelligence, including indicators of compromise and tactics, techniques and procedures (TTPs), within trusted communities, under arrangements that fully respect business confidentiality, the GDPR and competition guidelines. Participation, and its end, must be notified to the competent authority (Article 45(3)).
8 questions drawn from the requirements above. Each gap you declare comes back with the course that covers it and the tool that does the work. Your answers stay in this browser.
Has your management body approved an ICT risk management framework covering core banking, payment rails and the cloud estate, with an ICT risk tolerance set within your risk appetite and evidence reused for SREP and ICAAP?
Are your core-banking platforms mapped as critical ICT assets, your legacy ICT systems risk-assessed at least yearly (Article 8(7)), and every change made through a documented change and patch management process (Article 9(4))?
Do core-banking and payment systems supporting critical or important functions have a business impact analysis with RTO and RPO targets, and have you tested the switchover to redundant capacity this year (Article 11(6))?
Does one process classify ICT-related and payment-related incidents (Article 23) against Delegated Regulation (EU) 2024/1772 and file the initial notification within 4 hours of classifying an incident as major, weekends and bank holidays included?
Is every ICT contractual arrangement across the group recorded in your Register of Information at entity, sub-consolidated and consolidated level, with those supporting critical or important functions flagged and LEIs checked?
Do your cloud and other ICT contracts supporting critical or important functions contain the Article 30 clauses, including cooperation with your resolution authority, with a concentration assessment (Article 29) and a tested exit plan (Article 28(8))?
Does your testing programme cover every ICT system supporting critical or important functions at least yearly (Article 24(6)), and have you recorded whether you are identified for TLPT, which a significant institution runs with external testers only (Article 26(8))?
Does your management body follow specific ICT risk training on a regular basis, and do all staff, senior management included, complete digital operational resilience training (Articles 5(4) and 13(6), or 16(1)(h) if exempted under the CRD)?
You declared 0 areas to work on, gaps first. Each one names what to learn and what to use.
Indicative self-assessment based on your own answers, not a compliance opinion. Prices exclude VAT.
Your score and your priorities, each with the course and the tool that cover it. The newsletter only if you tick the box.
For SSM-supervised banks, the most consequential reality is that DORA does not exist in a regulatory silo. The ECB has integrated DORA-aligned ICT risk assessment into the Supervisory Review and Evaluation Process (SREP), the cycle that determines Pillar 2 Requirements (P2R) capital add-ons. This means weak ICT risk management can translate into higher capital requirements, set case by case (see below).
A weak SREP score on ICT risk (3 or 4 on the 1-4 scale) feeds the Pillar 2 Requirement through the operational risk assessment. The ECB's published P2R methodology names ICT risk, third-party risk, business continuity risk and internal risk controls among the drivers considered, and the Joint Supervisory Team sets the add-on case by case using constrained supervisory judgement. The decision ranges that convert a SREP score into basis points are not published, so no public scale exists: treat any bank-level figure you are quoted as an estimate, not a supervisory expectation.
What the ECB does publish is the aggregate. After the 2025 SREP cycle, CET1 Pillar 2 requirements applicable in 2026 stayed broadly stable at 1.2% of risk-weighted assets, and the average overall SREP score improved to 2.5 from 2.6 (ECB Banking Supervision, 18 November 2025).
12 pages turning your DORA programme into supervisory evidence: the DORA→SREP evidence map, how resilience gaps feed Pillar 2 capital, the 25 questions supervisors ask, and a SREP-readiness checklist.
The SREP section above is about Pillar 2. This one is about the framework that sits underneath it. On 26 August 2026 the European Banking Authority opened a consultation on draft Regulatory Technical Standards specifying the operational risk management framework banks must have in place, under the mandate in Article 323(2) of the Capital Requirements Regulation as amended by Regulation (EU) 2024/1623. The reference is EBA/CP/2026/18, and responses are due by 31 December 2026.
The draft opens, before its definitions, with a provision on ICT risk. Article 2(1) requires ICT risk management under DORA and Directive (EU) 2022/2556 to form an integral part of the overall risk management framework. Article 2(2) then allows institutions to rely on strategies, policies, procedures, controls and tools already established under DORA where the RTS asks for arrangements DORA already specifies in detail.
Recital 5 explains why: ICT risk, including ICT third-party risk, is a material component of operational risk, so ICT-related incidents in the scope of operational risk should be identified and treated as operational risk events, drawing on the information already produced by the DORA incident reporting arrangements. In practice that means your incident register has to reach the operational risk event register with a loss amount, a taxonomy category and, under Article 15(3) of the draft, a reconciliation against the accounting records.
Almost all of the proportionality in the draft runs through one number, the business indicator calculated under Article 314 CRR. Six obligations change with it.
| Requirement | At or above EUR 750m | Below EUR 750m |
|---|---|---|
| Framework effectiveness review (Art. 4(4)) | At least annually | At least every two years |
| Reporting to the supervisory function (Art. 11(1)(b)) | At least quarterly | At least annually |
| Annual operational risk loss (Art. 7(1)) | Calculated | Not required |
| Operational risk data set (Art. 9(2) and 9(3)) | Full list | Defined subset |
| Taxonomy consistency (Art. 9(7)) | Required | Recommended |
| Business indicator as appetite proxy (Art. 4(7)) | Not available | Permitted, unless the competent authority requires more |
Two free tools cover this ground: the OpRisk RTS readiness check scores what your DORA arrangements already answer in eight questions, and the consultation response framework sets out all 16 questions with room for your own position. The full mapping, article by article, is in what your DORA work already covers.
Threat-Led Penetration Testing under Article 26 is the most operationally demanding DORA requirement for the banks it applies to. Unlike traditional penetration testing, TLPT simulates realistic adversaries (red team) operating against the live production environment, with only a small "white team" aware. The methodology aligns with the TIBER-EU framework that several NCAs already operated as a voluntary regime.
Article 26(8) requires competent authorities to identify the financial entities that must perform TLPT, based on impact-related factors, possible financial stability concerns (including systemic character) and the entity’s specific ICT risk profile. Delegated Regulation (EU) 2025/1190 sets the detailed criteria (Article 2(1)) and a default population for banks (Article 2(2)(a)):
European banking is now massively cloud-dependent, often on a handful of hyperscalers. DORA Article 29 forces this concentration into the open and subjects it to active supervisory oversight.
Article 28(8) and the related RTS require documented, tested exit strategies for every contract supporting a critical or important function. For cloud, "exit" rarely means "lift-and-shift back to on-premises in a weekend", and DORA sets no fixed exit horizon, but it does require: alternative solutions identified and transition plans developed (Art. 28(8)), a mandatory adequate transition period in the contract (Art. 30(3)(f)), access to and return of data in an easily accessible format (Art. 30(2)(d)), exit plans sufficiently tested and reviewed periodically (Art. 28(8)), and contingency measures to keep the business running (Art. 28(8)).
Commission Delegated Regulation (EU) 2024/1772 sets seven classification criteria. An incident is major when it has affected critical services (Art. 6) and either a successful, malicious and unauthorised access that may result in data losses has occurred (Art. 9(5)(b)), or two or more of the other materiality thresholds are met (Art. 8(1)). For banks, the criteria that most often decide the outcome are:
Art. 9(1). More than 10% of the clients using the affected service or more than 100,000 of them, more than 30% of the financial counterparts, more than 10% of the daily average number or value of transactions, or clients identified as relevant.
Art. 9(4). Impact in two or more Member States: clients and counterparts, branches or group entities, or market infrastructures and third-party providers.
Art. 9(3). Incident lasting longer than 24 hours, or service downtime longer than 2 hours on ICT services that support a critical or important function.
Art. 9(6). Direct and indirect costs and losses that have exceeded or are likely to exceed €100,000, counted without financial recoveries (Art. 7).
Art. 9(5). Impact on the availability, authenticity, integrity or confidentiality of data that harms business objectives or regulatory compliance. A successful, malicious and unauthorised access that may result in data losses is enough on its own, once critical services are affected.
The gate, Art. 6. ICT services supporting a critical or important function, a financial service that requires authorisation, or a successful malicious and unauthorised access. Without it, no combination of thresholds makes the incident major.
The clock starts at classification as major, not at detection, with an outer limit of 24 hours from the moment the bank became aware of the incident (RTS 2025/301, Art. 5(1)(a)). An incident that only becomes major later is notified within 4 hours of that classification (Art. 5(2)). The internal challenge for banks is the speed of classification governance: a clear playbook, an empowered duty officer, and pre-cleared escalation channels to the executive team and NCA contact.
Within 4 hours of classifying the incident as major, and no later than 24 hours after becoming aware of it.
Enter the classification timeWithin 72 hours of submitting the initial notification, and updated when the situation changes.
Follows the initial notificationWithin one month of the latest intermediate report, once the root cause analysis is complete.
Follows the intermediate reportDelegated Regulation (EU) 2025/301, Article 5; classification under Delegated Regulation (EU) 2024/1772. The later deadlines assume each report goes in at its latest permissible time. A deadline falling on a weekend or bank holiday moves to noon of the next working day (Article 5(4)), except for the initial notification and intermediate report of credit institutions, central counterparties, operators of trading venues and essential or important entities under NIS2, or where your competent authority has decided otherwise (Article 5(5) and (6)); the dates shown do not apply that extension.
Article 28(3) requires every financial entity to maintain and update a Register of Information covering all contractual arrangements on the use of ICT services, at entity level and at sub-consolidated and consolidated levels. The register is the single most data-intensive DORA artefact.
Article 28(3) requires a report to the competent authority at least yearly and the full register on request. Your competent authority sets the reporting date, and the register is submitted in the templates of Commission Implementing Regulation (EU) 2024/2956, in xBRL-CSV format. Recurring data-quality problems are missing LEIs, inconsistent service taxonomy, gaps in subcontracting data and unclear function-to-contract mapping.
DORA leaves administrative penalties and remedial measures to national law (Article 50(3)) and sets the minimum powers competent authorities must have (Article 50(4)). For banks under SSM supervision, the ECB's supervisory powers, public notices and Pillar 2 add-ons sit alongside that national regime.
| Violation Type | Who sets the amount | Article |
|---|---|---|
| Failure to comply with ICT risk management requirements (Articles 5-16) | National law of the supervising Member State | Art. 50 |
| Failure to report major ICT incidents within timelines | National law of the supervising Member State | Art. 50 |
| Failure to conduct required resilience testing including TLPT | National law of the supervising Member State | Art. 50 |
| Failure to manage ICT third-party risk (Articles 28-30) | National law of the supervising Member State | Art. 50 |
| Designated critical ICT third-party providers (CTPPs) | 1% of average daily worldwide turnover: the only turnover-based figure DORA sets itself | Art. 35(8) |
| Criminal penalties | Member States may provide for them | Art. 52 |
| Remedial measures (minimum powers) | Orders to cease the conduct, temporary or permanent cessation of a practice, any measure including of a pecuniary nature, data traffic records, public notices | Art. 50(4) |
For a mid-to-large bank starting from a CRD/EBA baseline, full DORA alignment realistically takes 12-18 months. The following sequence reflects what works in practice, the deliverable order matters because several streams have hard dependencies.
Article-by-article gap mapping against current state. Focus areas: ICT risk framework, register completeness, contract clauses, incident classification governance, testing coverage. Output: prioritised remediation backlog with effort estimates.
Update ICT risk appetite statement, board ICT competence assessment, committee charters. Define the three-lines-of-defence operating model. Allocate the budget envelope (Article 5(2)(g)).
Refresh or write: ICT risk management policy, ICT business continuity policy, third-party policy, incident management policy, testing policy. Align with RTS on ICT risk framework and RTS on subcontracting.
The longest workstream. Inventory all ICT contracts, normalise to the ITS taxonomy, capture sub-outsourcing chains, validate LEIs, build data quality controls. Aim for the reporting date set by your competent authority with <5% missing/invalid fields.
Article 30 mandatory clauses. Hyperscaler addendums first (highest concentration), then top 50 vendors by criticality. Use a contract-mapping spreadsheet to track clause-by-clause coverage.
Tabletop exercises with the duty officer team, NCA portal dry-runs, escalation governance test. Aim for <2 hours from classification decision to NCA notification submission.
Annual programme launched: vulnerability scans, scenario tests, code reviews, network assessments. TLPT procurement initiated for banks identified by their competent authority (lead time considerations).
Continuous register update, quarterly board ICT risk reporting, integration of ICT risk findings into ICAAP. SREP inspection readiness reviewed annually.
Use our free calculator to estimate implementation costs, staffing needs, and timeline based on your bank's size and current maturity.
The duty officer who classifies a core-banking or payment outage as major starts the reporting clock, and for a credit institution weekends do not extend the first two deadlines. Your outsourcing function negotiates Article 30 clauses and exit plans with cloud providers that are hard to replace, and keeps the group's Register of Information current. Your risk function ties the ICT risk framework to your risk appetite and SREP evidence. Your management body approves the framework and must keep its ICT knowledge current (Article 5(4)). Each role needs to know what DORA expects of it.
Members of the management body must “actively keep up to date with sufficient knowledge and skills” to understand and assess ICT risk, including by following specific training on a regular basis.
Regulation (EU) 2022/2554, on EUR-Lex Article 13(6) · All staffICT security awareness programmes and digital operational resilience training are “compulsory modules” of staff training, for all employees and senior management, at a level that matches each function.
Regulation (EU) 2022/2554, on EUR-LexUnder the simplified framework of Article 16, the same duty comes from Article 16(1)(h): ICT security awareness programmes and digital operational resilience training for staff and management, according to needs and ICT risk profile.
Owns the DORA programme across the group, the scope position of each entity and the evidence the ECB or your national competent authority may ask for, reusing SREP material where it fits.
The first lesson is open to read before you buy.
Acts as the independent control function of Article 6(4): proposes the ICT risk tolerance within your risk appetite, runs the yearly legacy-system risk assessment and links the framework to ICAAP.
The first lesson is open to read before you buy.
Classifies core-banking, payment and cloud outages against Delegated Regulation (EU) 2024/1772, files with your national competent authority and drafts the initial, intermediate and final reports.
The first lesson is open to read before you buy.
Holds the Article 5(3) role that monitors ICT third-party arrangements: group Register of Information, Article 30 clauses, cloud concentration (Article 29) and tested exit plans.
The first lesson is open to read before you buy.
Approves the ICT risk management framework and ICT risk tolerance, reviews the policy on ICT third-party services and keeps its own ICT risk knowledge current through specific training (Article 5(4)).
The first lesson is open to read before you buy.
For banks & credit institutions: second-line compliance, ICT risk, continuity and third-party oversight for the whole team.
Several people to train? Team seats cost less per learner from 2 seats, on one invoice: see team pricing.
Starting out? DORA Fundamentals is free, certificate included.
The tools that matter most for your sector, and what each one does for you.
Draft the initial notification for a core-banking or payment-rail outage, with the reporting deadlines computed.
Open FreeTest a past core-banking, payment or cloud outage against the major-incident criteria of Delegated Regulation (EU) 2024/1772 before you have to decide live.
Open Free to build · export licence €249 a yearEnter your group's ICT contractual arrangements in the ITS templates, check LEIs and run the EBA validation rules before you report.
Open FreeScore each cloud and core-banking provider on impact, dependency, ease of substitution, data location and contract terms, and see which need an exit plan first.
Open FreeScore governance, documentation, technical controls, monitoring and training before a TLPT on live production systems, if your competent authority identifies you.
Open €149Set MTPD, RTO and RPO for core-banking, payment and treasury systems in one workbook, and record which functions are critical or important.
OpenAll tools: browse the full list. Prices exclude VAT.
Sector-specific DORA requirements compared.
Building Your ICT Risk Management FrameworkPractical guide to a DORA-compliant framework.
DORA Audit: Requirements & ChecklistSupervisory inspections, internal audit duties, scope by pillar and how to prepare.
Compliance Cost CalculatorEstimate DORA implementation costs: free tool.
Third-Party ICT Risk ManagementRegister, Article 30 clauses, the 19 designated CTPPs.
DORA Enforcement & PenaltiesWhat enforcement looks like in practice.
DORA vs NIS2How DORA and NIS2 interact for banks.
TLPT: Threat-Led Penetration TestingComplete TLPT methodology and procurement guide.
DORA for Banking Teams: certify your teamFour role certifications curated for banks: compliance, ICT risk, continuity, third-party. One person or a team licence.
The free Gap Analysis asks 16 questions across all five DORA pillars, about ten minutes of work, and returns your score, your prioritised gaps and a remediation roadmap. No signup.
Run the free Gap AnalysisCredit scoring is the one AI use case in retail banking that Annex III names outright. Fraud detection is explicitly carved out of that same point: a distinction worth getting right before you scope anything.
Once your gap analysis is done, the real work begins: maintaining evidence, tracking incidents, submitting the register of information every year, managing vendor contracts. Resiplan runs all five DORA pillars in one platform designed for banks, no more dozens of spreadsheets or a dedicated team to keep them in sync. Advising several institutions? Each client gets its own separate tenant.
Workbooks, playbooks and certifications built for EU financial entities. Add several to your cart: volume discounts apply automatically.
Take our free 5-minute assessment and get an instant DORA compliance score with personalised recommendations.