How DORA Applies to Banks
DORA Article 2 brings credit institutions authorised under the Capital Requirements Directive within its scope — effectively every EU bank. Both significant institutions (supervised directly by the ECB under the Single Supervisory Mechanism) and less significant institutions (supervised by national competent authorities) must comply.
The proportionality principle allows the depth of obligations to scale with institution size, complexity, and risk profile. Smaller, less complex banks face lighter requirements for resilience testing and governance. Significant institutions face the full breadth of DORA's obligations, including threat-led penetration testing and enhanced supervisory engagement.
Group-level requirements apply where a banking group has multiple regulated entities. The register of information must be maintained at both entity and group level, and ICT risk management must be consistent across the group.
Banking-Specific DORA Requirements
Several DORA requirements take on a particular character for banks because of how central ICT is to core banking operations:
ICT Risk Management for Core Banking
Core banking systems, payment processing, and customer channels are almost always designated as supporting critical or important functions. This triggers DORA's strictest ICT risk management requirements: board-approved frameworks, formal risk assessments, segregation of duties, and comprehensive incident response capabilities.
Incident Classification and Reporting
Banks must classify ICT-related incidents against DORA's materiality thresholds and report major incidents to national competent authorities within defined timeframes. For banks, this integrates with existing EBA guidelines on major incident reporting and PSD2 incident notification requirements.
Digital Operational Resilience Testing
All banks must conduct basic resilience testing — vulnerability assessments, network security reviews, scenario-based testing. Significant institutions must additionally undertake threat-led penetration testing (TLPT) every three years, following the TIBER-EU or equivalent methodology.
Third-Party Risk for Core Systems
Banks depend heavily on ICT third-party providers — cloud infrastructure, core banking software, payment gateways, identity providers. DORA requires comprehensive due diligence, specific contractual provisions, and ongoing monitoring for all ICT service arrangements. Critical providers may be designated for direct ESA oversight.
DORA Document Requirements for Banks
DORA is a documentation-heavy regulation. Banks must be able to produce, on request to supervisors, a comprehensive set of documents evidencing their compliance across all five pillars:
- •ICT risk management framework — approved by the management body, covering governance, risk identification, protection, detection, response, and recovery
- •Business continuity and disaster recovery plans — with evidence of regular testing and lessons learned
- •Incident response playbooks — classification procedures, escalation paths, communication protocols, regulatory notification templates
- •Register of information — see the dedicated register guide for field-level requirements
- •Third-party contracts — with DORA-mandated provisions including audit rights, exit strategies, and sub-outsourcing controls
- •Testing documentation — test plans, methodologies, results, remediation tracking, management sign-off
- •Board and committee reporting — evidence that ICT risk is being actively monitored and managed at senior level
DORA and Existing Banking Regulation
Banks are already subject to a dense regulatory stack covering ICT risk, operational resilience, and third-party management. DORA does not replace this stack — it layers on top, codifying some existing expectations and adding new specific requirements:
- •CRD/CRR — the Capital Requirements Directive and Regulation provide the overall prudential framework, including operational risk capital requirements and outsourcing expectations
- •EBA Guidelines on ICT and Security Risk Management — much of the ICT risk content in DORA originated from these guidelines; DORA makes many of the guideline expectations binding law
- •PSD2 — payment services providers have specific operational and security requirements under PSD2, which overlap with DORA
- •SSM supervisory expectations — the ECB has issued specific guidance on cyber resilience, ICT third-party risk, and related topics that intersect with DORA
The practical task for most banks is integration — mapping existing ICT governance and documentation to DORA's structure, identifying genuine gaps, and building the new documentation DORA requires (particularly the register of information) without duplicating what already exists.
How ComplyLoft Auditor Helps Banks
The ComplyLoft Auditor can be configured with DORA requirements as the assessment framework and run across a bank's existing ICT governance documentation. It flags potential gaps and provides a structured starting point for review — reducing the manual effort of mapping existing documentation to DORA's structure.
- •Audit ICT risk management documentation against DORA Chapter II requirements
- •Review ICT third-party contracts for DORA-mandated provisions
- •Support register of information completeness checks across banking ICT arrangements
- •Assess incident response documentation against DORA reporting and classification thresholds
- •Cross-reference DORA requirements with existing CRD/CRR, EBA, and SSM documentation to identify genuine gaps
ComplyLoft Auditor identifies potential compliance gaps and provides a structured starting point for review. All outputs require human review and sign-off. ComplyLoft does not guarantee compliance.