DORA for Credit Institutions: Compliance Requirements for Banks

If you're a compliance officer at a small or mid-sized credit institution, DORA represents both a challenge and an opportunity. The regulation demands comprehensive documentation of your ICT third-party arrangements—but your institution's existing regulatory maturity means you're better positioned than many to succeed.

The ESA dry run results tell an interesting story: credit institutions had the lowest error rate at 1.9% of data points submitted. Yet even among banks, 93.5% still had at least one data quality error in their submissions. This guide explains exactly what credit institutions need to know to be in the 6.5% that passes on the first attempt.

Credit Institutions Under DORA: Legal Framework

Under Article 2(1)(a) of DORA, the regulation explicitly applies to credit institutions as defined in the Capital Requirements Regulation (CRR). This covers:

• Banks (commercial, retail, private)
• Building societies
• Credit unions (in most Member States)
• Specialized credit institutions

DORA entered into force on January 17, 2025. If you're a licensed credit institution operating in the EU, you are subject to the full scope of DORA requirements.

How DORA Interacts with CRD/CRR

Credit institutions already operate under extensive regulatory frameworks—CRD VI, CRR III, and various EBA guidelines on ICT risk and outsourcing. DORA doesn't replace these but adds a harmonized digital resilience layer across the EU.

What Changed with DORA:

The EBA has amended its Guidelines on ICT and security risk management to integrate with DORA. For credit institutions, the key changes include:

• Centralized incident reporting: Major ICT-related incidents now follow DORA's framework rather than fragmented national approaches
• Third-party risk management: DORA introduces specific requirements for ICT third-party service providers that go beyond existing outsourcing guidelines
• Register of Information: A new mandatory reporting obligation requiring detailed documentation of all ICT arrangements

What Remains Under CRD/CRR:

• Capital requirements and prudential supervision
• Governance requirements (fit and proper, internal controls)
• Liquidity and leverage requirements
• Recovery and resolution planning

The practical effect: compliance officers at credit institutions now manage parallel but interconnected obligations under CRD/CRR and DORA.

The Register of Information: What Banks Must Report

The DORA Register of Information (RoI) requires credit institutions to maintain a comprehensive register of all contractual arrangements with ICT third-party service providers. This isn't just core banking—it covers every technology service supporting your operations.

The 15 Templates

DORA's RoI comprises 15 interconnected templates that banks must complete:

Entity Level (B_01)

• B_01.01: Entity maintaining the register
• B_01.02: Entities making use of ICT services (for groups)
• B_01.03: Branches

Contract Level (B_02)

• B_02.01: Contractual arrangements
• B_02.02: Specific contractual arrangements (intragroup)

Provider Level (B_03)

• B_03.01: ICT third-party service providers
• B_03.02: ICT service providers' subcontractors
• B_03.03: Subcontractors' subcontractors

Service Level (B_04, B_05, B_06, B_07)

• B_04.01: ICT services
• B_05.01: ICT services - Data
• B_05.02: ICT services - All locations
• B_06.01: Functions identification
• B_07.01: Functions - ICT services assessment

Risk Assessment (B_99)

• B_99.01: Entity-level assessment

For credit institutions with extensive ICT ecosystems, this means documenting hundreds or even thousands of data points with strict consistency requirements.

Common ICT Dependencies for Credit Institutions

Banks typically have more complex ICT architectures than smaller financial entities. When building your register, don't overlook:

• Core banking systems — Transaction processing, account management, ledger systems
• Payment infrastructure — SWIFT connectivity, SEPA processing, card scheme connections
• Market data feeds — Bloomberg, Reuters, exchange connectivity
• Trading platforms — Order management, execution management systems
• Risk management systems — Credit scoring, market risk, operational risk platforms
• Regulatory reporting — Systems for COREP, FINREP, AnaCredit
• Anti-money laundering — Transaction monitoring, sanctions screening, KYC platforms
• Cloud infrastructure — AWS, Azure, Google Cloud, private cloud providers
• Security services — SOC providers, threat intelligence, penetration testing
• Communication systems — Email, collaboration tools, secure messaging
• Branch infrastructure — ATM networks, point-of-sale systems, branch connectivity
• Customer channels — Online banking, mobile apps, API banking platforms

Each of these arrangements needs documentation with contract details, criticality assessments, data locations, and subcontractor information.

Why Credit Institutions Performed Best (But Still Failed)

The ESA dry run revealed that credit institutions had the lowest error rate among financial sectors at 1.9% of data points submitted. By comparison:

This relative success likely reflects:

• Established compliance infrastructure from CRD/CRR requirements
• Existing vendor management and outsourcing frameworks
• Larger dedicated compliance teams
• Prior experience with complex regulatory reporting (COREP, FINREP)

Yet 93.5% Still Had Errors

Despite better relative performance, nearly all credit institutions had at least one validation error. The most common issues:

Missing Contract Data (22% of submissions)

Even well-organized banks discovered gaps when mapping contracts to DORA's detailed requirements. Legacy arrangements, informal vendor relationships, and decentralized procurement created documentation challenges.

LEI Validation Issues (32% of submissions)

Credit institutions generally have LEIs, but their ICT providers often don't. Banks reported spending significant time requesting LEIs from smaller technology vendors who had never needed them before.

Subcontractor Chain Documentation

DORA requires visibility into subcontractor chains for critical services. Banks discovered their core banking vendors couldn't always provide complete information about their own technology dependencies.

Cross-Template Consistency

The 15 templates must reference each other consistently. A contract ID in B_02 must match exactly in B_04 and B_07. Banks with manually compiled registers found these cross-references error-prone.

Proportionality for Small and Mid-Sized Banks

DORA includes proportionality principles in Article 4, recognizing that a 50-person regional bank shouldn't need the same infrastructure as a global systemically important bank (G-SIB).

What Proportionality Covers

ICT Risk Management Framework

Smaller banks can implement simpler governance structures. You don't need a dedicated Chief Information Security Officer if your scale doesn't warrant it—but someone must own ICT risk with appropriate reporting to management.

Testing Requirements

Basic testing (vulnerability assessments, scenario testing) is acceptable for smaller institutions. Advanced threat-led penetration testing (TLPT) applies to larger, systemically important entities.

Governance Structures

Proportionate board reporting and committee structures based on your institution's complexity.

What Proportionality Does NOT Cover

All 116 validation rules apply. Your submission passes through the same checks as every other credit institution.

Reporting deadlines are identical. No extended timelines for smaller entities.

Practical Steps for Credit Institution Compliance

Step 1: Establish Clear Ownership

DORA compliance touches multiple functions—IT, compliance, legal, procurement, operations. Assign clear ownership with a single accountable executive and a cross-functional working group. For smaller banks, this might be the Chief Compliance Officer with support from IT leadership.

Step 2: Complete Your ICT Inventory

Before touching templates, create a complete inventory:

1. List all systems supporting banking operations
2. Identify the provider for each (internal vs. third-party)
3. Classify which support critical or important functions
4. Map existing contracts and agreements
5. Document known subcontractor relationships

Banks typically discover 20-30% more ICT arrangements than initially estimated during this exercise.

Step 3: Prioritize by Criticality

Focus initial effort on arrangements supporting critical functions:

• Core banking operations
• Payment processing
• Regulatory reporting
• Customer data management
• Anti-money laundering systems

These arrangements require the most detailed documentation including subcontractor chains and substitutability assessments.

Step 4: Engage Providers Systematically

You'll need from each ICT provider:

• Legal Entity Identifier (LEI) or EUID
• Registered name and jurisdiction
• Data processing and storage locations
• Subcontractor information (for critical services)
• Contract terms including exit provisions
• SLA documentation

Create standardized questionnaires and allow adequate time—providers can be slow to respond, and smaller vendors may need to obtain LEIs.

Step 5: Build and Validate Before Submission

Populate the 15 templates with gathered data. Before submission:

• Run validation against all 116 ESA rules
• Check cross-template reference consistency
• Verify all LEIs at gleif.org
• Confirm date formats (ISO 8601)
• Validate country codes (ISO 3166-1)

The Cost of Getting It Wrong

For credit institutions, failed DORA submissions carry specific risks:

Supervisory Scrutiny

Your competent authority sees your data quality. Repeated resubmissions signal operational weaknesses that may invite closer supervision across other regulatory areas.

Resource Drain

Each resubmission cycle consumes compliance resources. For smaller banks with lean teams, this pulls attention from other obligations.

Group Implications

If you're part of a banking group, your data quality affects consolidated reporting. Errors cascade upward.

Reputation

In an industry where trust is paramount, compliance failures—even technical ones—create unwanted attention.

Integration with Existing Frameworks

Credit institutions can leverage existing compliance infrastructure for DORA:

From CRD/CRR Outsourcing Requirements

• Vendor due diligence processes → ICT third-party assessment
• Outsourcing register → Foundation for RoI
• Exit strategy documentation → DORA exit provisions

From Existing ICT Risk Management

• Asset inventories → ICT service inventory
• Risk assessments → Criticality classifications
• Incident management → DORA incident reporting

From Regulatory Reporting Experience

• Data quality processes → RoI validation
• Submission workflows → DORA reporting procedures
• Audit trails → RoI change documentation

The banks that succeeded in the dry run built on these existing capabilities rather than treating DORA as an entirely separate exercise.

Timeline and Ongoing Obligations

DORA has been applicable since January 17, 2025. The Register of Information is not a one-time submission—it's an ongoing obligation:

• Maintain current data — Update the register as arrangements change
• Submit as required — Provide to your competent authority on request
• Document changes — Maintain audit trails of modifications
• Annual reviews — Periodic reassessment of ICT arrangements

Competent authorities may request the register at any time, and the information must be accurate and complete.

Conclusion: Achievable with the Right Approach

Credit institutions have inherent advantages for DORA compliance—established frameworks, existing vendor oversight, and regulatory reporting experience. The 1.9% error rate in the dry run demonstrates this.

But even with these advantages, the path to clean submission requires:

• Clear ownership and cross-functional coordination
• Systematic ICT inventory and provider engagement
• Rigorous validation before submission
• Tools that handle the 116 rules automatically

The 93.5% overall failure rate shows what happens without proper preparation. Credit institutions can—and should—perform better. The building blocks are already in place.