DORA for the Financial Sector - Mandatory Competencies 2026

January 17, 2025, marked a milestone in the history of the European financial sector. DORA (Digital Operational Resilience Act) – EU Regulation 2022/2554 – officially entered into force. From that day, every bank, insurance company, payment institution, or investment firm in the European Union must meet new, rigorous requirements concerning ICT operational resilience. This is not another recommendation or voluntary initiative – it’s a legally binding regulation, the violation of which carries severe financial and administrative penalties.

For IT, compliance, risk management, and L&D departments in financial institutions, DORA means one thing: the necessity to build new competencies in the organization on an unprecedented scale. It’s no longer just about “having IT people” or a “security team.” DORA requires documented, measurable knowledge and skills – from the board, through IT managers, to every developer and system administrator. It also requires transformation in managing ICT suppliers, testing resilience, incident management, and continuous risk monitoring.

Is your organization ready? Does your team possess the necessary competencies for effective DORA implementation? This article serves as a comprehensive guide to what DORA requires from the financial sector in 2026, what competencies different roles in the organization must have, and how to build an effective training plan that not only ensures compliance but also strengthens your institution’s competitiveness.

Quick navigation

• DORA in a nutshell: what it is and who it applies to (banks, insurers, fintechs, crypto)
• Timeline: January 17, 2025 – entry into force, what’s next?
• 5 pillars of DORA – key requirements for financial institutions
• ICT competencies required by DORA: risk management, testing, vendor management
• DORA-compliant training plan – who needs to learn what?
• DORA vs NIS2 – differences and intersections of regulations
• Penalties for non-compliance with DORA and how to avoid them
• How EITT prepares financial institutions for DORA
• FAQ: answers to the most common questions about DORA

What is DORA and who does it apply to?

DORA (Digital Operational Resilience Act) is the regulation of the European Parliament and Council (EU) 2022/2554 of December 14, 2022, on the digital operational resilience of the financial sector. It is the first comprehensive EU regulation in history that establishes uniform requirements for ICT risk management across the entire financial sector – regardless of the member state.

Why was DORA created?

The financial sector today is almost entirely dependent on information and communication technologies. Online banking, mobile payments, algorithmic trading, blockchain, cloud processing – all of these constitute the foundation of modern financial services. But this digitalization carries enormous risk: cyberattacks, system failures, problems with external suppliers can paralyze a financial institution within hours, and in extreme cases – threaten the stability of the entire financial system.

Before DORA, each EU member state had its own regulations in this area, which led to discrepancies, unequal competitive conditions, and gaps in supervision. DORA harmonizes requirements across the entire EU, ensuring uniform standards for all financial entities.

Who does DORA apply to?

DORA has an extremely broad scope – it covers practically all financial entities operating in the EU, including:

1. Credit institutions (banks)

• Commercial, cooperative, mortgage banks
• Branches of banks from third countries operating in the EU

2. Investment firms and capital market infrastructure

• Brokerage houses
• Stock exchanges
• Central counterparties (CCPs)
• Central securities depositories (CSDs)
• Transaction repositories

3. Payment institutions and e-money

• Payment institutions
• E-money institutions
• Payment service providers (PSPs)

4. Insurance and reinsurance undertakings

• Insurance companies
• Reinsurance undertakings
• Insurance intermediaries

5. Cryptocurrency platforms

• Crypto-asset service providers (CASPs)
• Issuers of asset-referenced tokens
• Issuers of e-money tokens

6. Other financial entities

• Investment funds (UCITS)
• Alternative investment fund managers (AIFMs)
• UCITS management companies
• Credit rating agencies
• Benchmark administrators

7. ICT service providers for the financial sector (Critical ICT Third-Party Service Providers)

• Cloud computing providers
• Data center providers
• Software as a service (SaaS) providers for finance
• Cybersecurity service providers

This last group is particularly significant: DORA for the first time in history imposes direct regulations on technology providers serving the financial sector. If you’re an ICT provider recognized as “critical,” you’re subject to the supervision of financial authorities, not just IT regulators.

Extraterritoriality of DORA

Similar to GDPR, DORA has extraterritorial reach. It applies not only to entities headquartered in the EU but also:

• Branches of institutions from outside the EU operating in EU territory
• ICT providers from outside the EU providing services to financial entities in the EU

So if a European bank uses services from an American cloud provider, that provider must meet DORA requirements regarding the services provided.

5 pillars of DORA – overview of requirements

DORA is based on five key pillars that together create a comprehensive framework for digital operational resilience:

Pillar 1: ICT Risk Management

What DORA requires:

Every financial institution must implement a solid, comprehensive ICT risk management framework, covering:

• ICT risk identification – mapping all systems, data, ICT-dependent business processes, and related risks
• Protection and prevention – technical and organizational measures safeguarding against risk materialization
• Detection – monitoring systems and procedures enabling early detection of anomalies and incidents
• Response and recovery – incident response plans, business continuity procedures, disaster recovery
• Learning and evolution – post-incident analysis, continuous framework improvement

Key requirements:

• Framework must be documented and approved by the management body (board)
• Requires continuous review and update (at least once a year)
• Must be proportional to the institution’s size, complexity, and risk profile
• Must consider all types of ICT risk: cyberattacks, failures, human errors, natural disasters

What this means for competencies: Risk teams must possess specialized knowledge in ICT risk (not just traditional credit or operational risk). IT risk managers become a key role in the organization.

Pillar 2: ICT-related Incident Management and Reporting

What DORA requires:

Financial institutions must implement:

• ICT incident management processes – from detection, through classification, escalation, response, to resolution
• Incident classification – determining which incidents are “major” and require reporting to the regulator
• Mandatory reporting to supervisory authorities according to strictly defined timelines:
  • Initial notification: 4 hours from classifying the incident as major
  • Intermediate report: after 72 hours (or earlier if status changes)
  • Final report: within one month of incident resolution, containing root cause analysis and remedial actions

Definition of a major ICT incident includes:

• Incidents affecting the availability of financial services
• Incidents causing financial losses above a defined threshold
• Incidents violating data integrity or confidentiality
• High-impact reputational incidents

What this means for competencies: IT ops teams, security operations centers (SOCs), incident response teams must know DORA procedures inside out. This requires training in:

• Classifying incidents according to DORA criteria
• Reporting within defined timelines (4h/72h/1 month)
• Root cause analysis and documentation
• Crisis communication (internal and external)

Pillar 3: Digital Operational Resilience Testing

What DORA requires:

Financial institutions must conduct regular, comprehensive testing of their ICT system resilience, including:

1. Basic tests (for all):

• Vulnerability assessments
• Penetration testing
• Scenario-based testing
• Business continuity tests
• Disaster recovery tests

2. Advanced testing (for the largest institutions):

• TLPT (Threat-Led Penetration Testing) – advanced penetration tests based on real threats
  • Required for institutions deemed “significant” by supervision
  • Conducted by independent external entities
  • Simulate realistic advanced attacks (APTs – Advanced Persistent Threats)
  • Include red team, blue team, white team exercises
  • Frequency: at least every 3 years

Testing requirements:

• Tests must be conducted regularly and proportionally to the risk profile
• Must cover all critical systems and processes
• Test results must be documented and reported to the board
• Must lead to action plans – specific remedial actions

What this means for competencies:

• Penetration testers and ethical hackers become critical for compliance
• Security teams must be able to conduct TLPT or manage external providers
• Internal auditors must understand DORA-compliant testing methodologies

Pillar 4: ICT Third-Party Risk Management

What DORA requires:

This is one of the most groundbreaking (and labor-intensive) pillars. Financial institutions must:

1. ICT Third-Party Register:

• Maintain a complete, current register of all ICT suppliers
• Classify suppliers by criticality (critical vs non-critical)
• Document contracts, scope of services, dependencies

2. Key contractual provisions: DORA specifies mandatory contractual clauses that must be included in contracts with ICT suppliers:

• Right to audit – the financial institution (or designated auditors) has the right to audit the supplier
• Subcontracting – the supplier must inform about subcontractors, the institution has the right to object
• Exit strategy – plans for terminating cooperation and migrating to another supplier
• Data location – clear definition of where data is stored and processed (jurisdiction)
• Supervisory authority access – the regulator has the right to audit the ICT supplier
• SLAs and performance indicators – precisely defined
• Security requirements – cybersecurity standards the supplier must meet
• Incident reporting – the supplier must immediately inform about incidents

3. Due diligence:

• Before contract conclusion – supplier risk assessment
• During cooperation – continuous monitoring and reviews
• Exit planning – contingency plans for contract termination

4. Concentration risk: Institutions must identify and manage concentration risk – a situation where they depend on too few suppliers or one supplier is used by too many critical processes.

What this means for competencies:

• Vendor risk managers must know DORA specifics
• Procurement and legal teams must negotiate DORA-compliant contracts
• Auditors must be able to audit ICT suppliers
• Contract managers must manage the contract lifecycle according to DORA requirements

Pillar 5: Information Sharing on Threats and Vulnerabilities

What DORA requires:

Financial institutions can (and in some cases should) share information about cyber threats, vulnerabilities, and ICT incidents with other institutions and relevant organizations (CERTs, ISACs).

Objectives:

• Increase threat awareness across the financial sector
• Early warning of new attack vectors
• Coordinated defense against systemic threats

Safeguards:

• Information sharing must be voluntary and compliant with competition law
• Confidentiality and data protection principles must be maintained
• Institutions are not liable for sharing information in good faith

What this means for competencies:

• Threat intelligence analysts must be able to collect, analyze, and share intelligence
• Compliance teams must understand the limits of legal information sharing
• Security teams must actively participate in industry initiatives (FS-ISAC, Cyber Threat Alliance)

What IT competencies does DORA require from organizations?

DORA does not directly specify “you must have X certifications” or “Y years of experience.” Instead, it requires financial institutions to ensure sufficient resources, skills, and knowledge for effective ICT risk management. But what does this mean in practice?

Below we present a DORA competency map – a set of key skills that must be present in different roles in the organization.

1. ICT Governance – Board and Senior Management

Who: Board, CEO, CFO, CRO (Chief Risk Officer), CIO, CISO

DORA requirements: Article 5 of DORA clearly states that the management body bears ultimate responsibility for ICT risk management. It cannot delegate this entirely to IT.

Required competencies:

Strategic understanding of ICT risk:

• Ability to assess how ICT risk affects the business model and strategy
• Knowledge of key cyber threats to the financial sector
• Understanding of the institution’s dependencies on ICT systems and external suppliers

Governance framework:

• Knowledge of DORA requirements for ICT risk management
• Ability to approve and oversee the ICT risk management framework
• Understanding when to escalate ICT decisions to the board

Financial awareness:

• Understanding the costs of DORA compliance
• Ability to budget investments in resilience (tests, training, tools)
• Assessing ROI of actions increasing operational resilience

Legal responsibility:

• Awareness of board members’ personal responsibility for DORA compliance
• Knowledge of penalties and sanctions for non-compliance
• Understanding the role of supervision in the context of DORA (EBA, ESMA, EIOPA, NBP, KNF)

Training format:

• 1-2 day executive workshops for the board
• Case studies: ICT incidents in the financial sector and their business impact
• Crisis situation simulations (tabletop exercises)
• Regular briefings (e.g., quarterly) on evolving threats

2. ICT Risk Management – Risk Managers and Auditors

Who: Chief Risk Officer, ICT Risk Managers, Enterprise Risk Managers, Internal Auditors

Required competencies:

Risk assessment methodologies:

• Conducting ICT risk assessments according to DORA
• Mapping ICT threats and their impact on business processes
• Quantifying ICT risk (probability, impact, loss expectancy)
• Integrating ICT risk with enterprise risk management (ERM)

Risk mitigation strategies:

• Designing control measures for ICT risk
• Balancing mitigation costs vs acceptable risk level (risk appetite)
• Managing residual risk

Third-party risk management:

• Assessing ICT supplier risk (due diligence)
• Monitoring suppliers during the contract period (ongoing monitoring)
• Managing supplier concentration risk
• Auditing ICT suppliers

Business continuity and disaster recovery:

• Creating and testing business continuity plans (BCP)
• Disaster recovery planning (DRP)
• Crisis management and crisis communication

Auditing ICT controls:

• Auditing DORA compliance
• Testing the effectiveness of ICT controls
• Root cause analysis of ICT incidents
• Reporting to the board and supervisory authorities

Tools and standards:

• ISO/IEC 27001 (Information Security Management)
• ISO 22301 (Business Continuity Management)
• NIST Cybersecurity Framework
• COBIT (Control Objectives for Information Technologies)

Training format:

• 3-5 day courses on ICT risk management in the context of DORA
• Practical workshops: creating ICT risk registers, risk assessments
• Certifications: CISA (Certified Information Systems Auditor), CRISC (Certified in Risk and Information Systems Control)

3. Cybersecurity and Incident Response – CISO and Security Teams

Who: Chief Information Security Officer (CISO), Security Operations Center (SOC), Incident Response Team, Threat Intelligence Analysts

Required competencies:

Cybersecurity frameworks:

• Implementing DORA-compliant security controls
• Knowledge of standards: ISO 27001, NIST CSF, CIS Controls
• Defense in depth – multi-layered protection

Threat detection and monitoring:

• Configuration and management of SIEM (Security Information and Event Management)
• Threat hunting – proactive threat searching
• Analysis of security logs and alerts
• Using threat intelligence feeds

Incident management:

• Classifying ICT incidents according to DORA criteria (major vs minor)
• Incident response procedures (NIST SP 800-61, SANS Incident Response)
• Cyberattacks: identification, containment, eradication, recovery
• Documenting incidents for compliance purposes

Incident reporting:

• Reporting major incidents to regulators within DORA timelines (4h/72h/1 month)
• Internal and external communication during incidents
• Post-incident review and lessons learned

Penetration testing and vulnerability management:

• Conducting or managing penetration tests
• Vulnerability scanning and patch management
• TLPT (Threat-Led Penetration Testing) – methodology knowledge
• Red team / blue team exercises

Cloud security:

• Security of cloud environments (AWS, Azure, GCP)
• Shared responsibility model in the cloud
• Security controls for SaaS, PaaS, IaaS

Tools:

• SIEM: Splunk, QRadar, Sentinel
• Vulnerability scanners: Nessus, Qualys, Rapid7
• Penetration testing tools: Metasploit, Burp Suite, Kali Linux
• Threat intelligence platforms: MISP, ThreatConnect

Training format:

• 5-7 day cybersecurity bootcamps for financial services
• Hands-on labs: simulations of cyberattacks and incident response
• Certifications: CISSP, CEH (Certified Ethical Hacker), GCIH (GIAC Certified Incident Handler), OSCP (Offensive Security Certified Professional)

4. IT Operations and Infrastructure – DevOps, SysAdmins, Network Engineers

Who: CIO, Head of IT Operations, DevOps Engineers, System Administrators, Network Engineers, Database Administrators

Required competencies:

Operational resilience:

• Designing high availability architectures (HA)
• System and data redundancy
• Load balancing, failover, clustering
• System performance monitoring (SLA/SLO management)

Backup and disaster recovery:

• 3-2-1 backup strategy (3 copies, 2 different media, 1 off-site)
• Testing restore procedures
• Recovery Time Objective (RTO) and Recovery Point Objective (RPO)
• Disaster recovery exercises

Change management:

• Controlled introduction of changes in production environments
• Rollback procedures
• Testing before deployment (dev, test, UAT, prod pipelines)

Configuration management:

• Infrastructure as Code (IaC): Terraform, Ansible, CloudFormation
• Version control for configurations
• Configuration baselines and drift detection

DevSecOps:

• Security built into the CI/CD pipeline
• Automated security testing (SAST, DAST, dependency scanning)
• Container security (Docker, Kubernetes)

Vendor and third-party management:

• Managing environments at suppliers (cloud, SaaS)
• Monitoring ICT supplier SLAs
• Escalating incidents at suppliers

Training format:

• 3-5 day courses on operational resilience and DORA requirements
• Practical workshops: disaster recovery exercises, failover testing
• Certifications: AWS/Azure/GCP certifications (for cloud), ITIL (for service management), DevOps certifications

5. Software Development – Developers and QA

Who: Head of Software Development, Software Engineers, QA Engineers, DevOps Engineers

Required competencies:

Secure coding practices:

• OWASP Top 10 – knowledge of the most common web vulnerabilities
• Input validation, output encoding
• Authentication and authorization best practices
• Secure API design

Security testing:

• Static Application Security Testing (SAST)
• Dynamic Application Security Testing (DAST)
• Dependency scanning (detecting vulnerabilities in libraries)
• Security code reviews

Resilience by design:

• Graceful degradation – systems maintain basic functionality during problems
• Circuit breakers – preventing cascading failures
• Retry mechanisms, timeouts
• Chaos engineering – deliberately introducing failures to test resilience

Operational observability:

• Logging security and operational events
• Structured logging
• Distributed tracing (for microservices)
• Metrics and alerting

Incident response for developers:

• On-call rotations
• Root cause analysis (RCA) and postmortems
• Hotfix procedures

Training format:

• 2-3 day workshops on secure coding and DevSecOps
• Hands-on labs: finding and fixing vulnerabilities in code
• Certifications: CSSLP (Certified Secure Software Lifecycle Professional), CEH (for security-focused devs)

6. Legal, Compliance, and Procurement – Contract Management

Who: General Counsel, Compliance Officers, Procurement/Vendor Managers, Contract Managers

Required competencies:

DORA legal framework:

• Detailed knowledge of the text of the DORA regulation
• Regulatory Technical Standards (RTS)
• Guidelines of supervisory authorities (EBA, ESMA, EIOPA)

Contracts with ICT suppliers:

• Negotiating DORA-compliant clauses (audit rights, exit strategy, subcontracting, data location)
• Service Level Agreements (SLAs) in the context of DORA requirements
• Liability and indemnification clauses
• Termination and transition planning

Vendor due diligence:

• Legal assessment of ICT suppliers before contract conclusion
• Verifying supplier compliance with DORA (for critical providers)
• Vendor onboarding and offboarding procedures

Reporting to regulators:

• Preparing incident notifications to KNF/NBP
• Communication with supervisory authorities
• Compliance documentation for audit purposes

Data protection and GDPR:

• Integrating DORA requirements with GDPR (data processing agreements)
• Cross-border data transfers in the context of cloud computing
• Consent management, data subject rights

Training format:

• 2-3 day legal workshops on DORA for legal and procurement teams
• Case studies: negotiating DORA-compliant contracts
• Templates: contractual clauses, vendor assessment checklists

7. Business Continuity Management – BCM Teams

Who: Business Continuity Manager, Crisis Management Team, Disaster Recovery Coordinator

Required competencies:

Business Impact Analysis (BIA):

• Identifying critical business processes
• Determining RTO (Recovery Time Objective) and RPO (Recovery Point Objective)
• Analyzing dependencies between processes and ICT systems

Business continuity planning:

• Creating Business Continuity Plans (BCP)
• Disaster Recovery Plans (DRP)
• Crisis communication plans

BCP/DRP testing:

• Tabletop exercises – scenario simulations
• Walkthrough tests – procedure reviews
• Full-scale exercises – complete tests with failure simulation
• Post-exercise reviews and action plans

Crisis management:

• Crisis Management Team structure
• Decision-making frameworks during crises
• Communication with stakeholders (clients, media, regulators)

Training format:

• 2-3 day courses on business continuity management for the financial sector
• Crisis simulations (hands-on crisis exercises)
• Certifications: CBCP (Certified Business Continuity Professional), ISO 22301 Lead Implementer

DORA-compliant training plan – who needs to learn what

An effective DORA training plan is not a one-time event but a multi-phase, differentiated program tailored to roles, with continuous learning mechanisms. Below we present a proven roadmap.

Phase 1: Inventory and Prioritization (Month 1-2)

Goal: Understand the current state and identify competency gaps.

Actions:

1. ICT systems mapping:

   • Create a complete inventory of ICT systems in the organization
   • Identify systems critical to business continuity
   • Map dependencies between systems and business processes

2. Vendor inventory:

   • List of all ICT suppliers (cloud, SaaS, infrastructure, security services)
   • Classification: critical vs non-critical
   • Identifying gaps in contracts (lack of DORA-compliant clauses)

3. Skills gap analysis:

   • Identify key roles for DORA compliance
   • Assess current level of knowledge and skills (surveys, interviews, assessments)
   • Determine competency gaps for each role

4. Prioritization:

   • Set training priorities according to:
     • Urgency (DORA compliance timeline)
     • Risk (roles most critical to compliance)
     • Impact (largest competency gaps)

Output:

• ICT Systems Register
• Vendor Register
• Training Needs Assessment Report
• Training Roadmap with priorities

Phase 2: Awareness Training – All Employees (Month 2-3)

Target group: All employees of the financial institution

Goal: Build basic awareness of DORA and digital operational resilience throughout the organization.

Program:

Module 1: What is DORA and why does it apply? (1h)

• Genesis of DORA – why the EU regulated resilience in finance
• Scope of DORA – who it applies to
• 5 pillars of DORA – overview
• Timeline and key dates
• Consequences of non-compliance

Module 2: Digital operational resilience – what does it mean for you? (1h)

• What is operational resilience
• Examples of ICT incidents in the financial sector and their impact
• Every employee’s role in building resilience
• Basic cyberhygiene principles (strong passwords, phishing awareness, device security)

Module 3: Reporting ICT incidents and issues (1h)

• How to recognize an ICT incident
• Internal reporting procedures
• When and to whom to escalate
• Examples: what is an incident and what is not

Format: E-learning (self-paced) + short final test Time: 3h + test (30 min) Output: DORA Awareness Certificate

Frequency: Once a year (annual refresher)

Phase 3: Executive Training – Board and Senior Management (Month 3)

Target group: Board, C-level (CEO, CFO, CRO, CIO, CISO), VP, Senior Management

Goal: Equip senior management with strategic understanding of DORA and awareness of their personal responsibility.

Program (2-day on-site workshop):

Day 1: DORA Strategic Overview

Session 1: DORA Deep Dive (3h)

• Detailed review of 5 DORA pillars
• Management body responsibility (art. 5 DORA)
• Penalties and sanctions for non-compliance
• Case study: ICT incidents and their impact on financial institutions

Session 2: ICT Risk Governance (2h)

• ICT risk management framework – the board’s role
• Risk appetite for ICT risk
• Escalation of ICT decisions
• Integrating ICT risk with enterprise risk management

Session 3: Third-Party Risk – Strategic Perspective (2h)

• Dependence on ICT suppliers – concentration risk
• Strategic decisions: build vs buy vs co-source
• Negotiating terms with key suppliers (cloud, SaaS)

Day 2: Crisis Simulation and Action Planning

Session 4: Crisis Simulation – Tabletop Exercise (3h)

• Simulation of a major ICT incident (e.g., ransomware attack, major cloud outage)
• Crisis decision-making exercise
• Communication with regulators, media, clients
• Post-exercise debrief

Session 5: DORA Compliance Roadmap (2h)

• Gap analysis – where we are, where we need to be
• Action plan – key initiatives and milestones
• Budgeting investments in resilience
• Governance structure for DORA compliance

Session 6: Q&A with DORA experts (1h)

Format: On-site workshop, interactive, with case studies and simulations Time: 2 days (14h) Output: DORA Strategic Action Plan + Executive DORA Leadership Certificate

Frequency: Once a year + quarterly briefings (1h) on regulation updates and emerging threats

Phase 4: Technical Training – IT, Security, Risk Teams (Month 4-6)

Target group: IT Operations, Cybersecurity, Risk Management, Auditors, DevOps, Developers

Goal: Build deep, practical technical competencies necessary for DORA implementation.

Program differentiated by roles:

Track A: ICT Risk Management (for Risk Managers, Auditors)

Course: DORA ICT Risk Management (5 days)

Day 1: DORA Risk Framework

• Detailed analysis of DORA Pillar 1
• Risk assessment methodologies for ICT
• Creating ICT risk register
• Risk quantification and prioritization

Day 2: Third-Party Risk Management

• Vendor due diligence procedures
• Contract risk assessment
• Ongoing vendor monitoring
• Managing concentration risk
• Hands-on: assessing a sample ICT supplier

Day 3: Business Continuity and Disaster Recovery

• Business Impact Analysis (BIA)
• Creating BCP and DRP according to DORA
• RTO/RPO determination
• Hands-on: creating a BCP for a sample process

Day 4: Testing and Auditing

• Auditing DORA compliance
• Testing ICT controls
• Root cause analysis
• Hands-on: auditing a sample system

Day 5: Reporting and Documentation

• Preparing reports for the board
• Reporting to regulators
• DORA compliance documentation
• Workshop: creating a compliance report

Format: 5-day workshop, hands-on exercises Output: DORA ICT Risk Management Professional Certificate

Track B: Cybersecurity and Incident Response (for CISO, SOC, Security Teams)

Course: DORA Cybersecurity & Incident Management (7 days)

Day 1-2: DORA Security Requirements

• DORA Pillars 1 and 3 – security controls
• Defense in depth for financial institutions
• Cloud security in the context of DORA
• Threat landscape for the financial sector

Day 3: Threat Detection and Monitoring

• SIEM configuration and use cases
• Threat intelligence integration
• Security analytics and anomaly detection
• Hands-on: configuring SIEM use cases for DORA

Day 4-5: Incident Response according to DORA

• Classifying ICT incidents (major vs minor)
• Incident response playbooks
• Reporting within 4h/72h/1 month timeline
• Hands-on: incident simulation and full response cycle + reporting

Day 6: Penetration Testing and TLPT

• Penetration testing methodologies
• TLPT (Threat-Led Penetration Testing) – framework
• Red team / blue team exercises
• Managing external pentesters

Day 7: Advanced Topics

• Cloud security auditing
• Container security (Docker, Kubernetes)
• API security
• Capstone exercise: comprehensive security assessment

Format: 7-day bootcamp, intensive, with lab exercises Output: DORA Cybersecurity Specialist Certificate

Track C: Operational Resilience (for IT Ops, DevOps, SysAdmins)

Course: DORA Operational Resilience & Testing (5 days)

Day 1: Architecture for Resilience

• High availability design patterns
• Redundancy, failover, load balancing
• RTO/RPO design considerations
• Hands-on: designing HA architecture

Day 2: Backup and Disaster Recovery

• Backup strategies (3-2-1 rule)
• Testing restore procedures
• Disaster recovery exercises
• Hands-on: DR test scenario

Day 3: Change and Configuration Management

• Secure change introduction
• Infrastructure as Code (IaC)
• Version control for configurations
• Hands-on: Terraform/Ansible for resilience

Day 4: DevSecOps

• Security in CI/CD pipeline
• Automated security testing
• Container security
• Hands-on: secure pipeline setup

Day 5: Testing according to DORA

• DORA Pillar 3 – testing requirements
• Planning and conducting resilience tests
• Test documentation for compliance
• Capstone: full-scale resilience test

Format: 5-day workshop with extensive hands-on labs Output: DORA Operational Resilience Engineer Certificate

Track D: Secure Development (for Developers, QA)

Course: Secure Coding & DevSecOps for DORA (3 days)

Day 1: Secure Coding Practices

• OWASP Top 10
• Input validation, authentication, authorization
• Secure API development
• Hands-on: code review exercise – find vulnerabilities

Day 2: Security Testing

• SAST, DAST, dependency scanning
• Security testing in CI/CD
• Hands-on: integrating security tools in pipeline

Day 3: Resilience by Design

• Circuit breakers, retry mechanisms
• Graceful degradation
• Observability (logging, metrics, tracing)
• Hands-on: implementing resilient microservice

Format: 3-day workshop, code-heavy Output: DORA Secure Developer Certificate

Phase 5: Legal & Compliance Training (Month 5-6)

Target group: Legal, Compliance Officers, Procurement, Contract Managers, DPO

Course: DORA Legal & Compliance Framework (3 days)

Day 1: DORA Legal Deep Dive

• Text of DORA regulation – detailed analysis
• Regulatory Technical Standards (RTS)
• EBA, ESMA, EIOPA guidelines
• National implementations (KNF, NBP)
• Penalties and legal liability

Day 2: Vendor Contracts and Procurement

• Mandatory DORA contractual clauses
• Negotiating contracts with ICT suppliers
• Exit strategies and transition planning
• Vendor due diligence checklists
• Workshop: review of a sample cloud contract

Day 3: Compliance Operations

• Gap analysis methodology
• Creating ICT supplier register (article 28 register)
• Incident reporting procedures to regulators
• Compliance documentation
• Preparing for supervisory audit
• Workshop: preparing incident notification

Format: 3-day workshop with case studies and templates Output: DORA Legal & Compliance Specialist Certificate + template package (contracts, checklists, procedures)

Phase 6: Specialized Certifications (Ongoing, Month 7-12)

Target group: Specialized roles requiring advanced international certifications

Recommended external certifications:

For Risk Managers:

• CRISC (Certified in Risk and Information Systems Control) – ISACA
• CISA (Certified Information Systems Auditor) – ISACA

For Cybersecurity:

• CISSP (Certified Information Systems Security Professional) – (ISC)²
• CEH (Certified Ethical Hacker) – EC-Council
• GCIH (GIAC Certified Incident Handler) – GIAC/SANS
• OSCP (Offensive Security Certified Professional) – Offensive Security

For Business Continuity:

• CBCP (Certified Business Continuity Professional) – DRI International
• ISO 22301 Lead Implementer – accredited training institutions

For Legal/Compliance:

• CIPP/E (Certified Information Privacy Professional/Europe) – IAPP (for GDPR + DORA synergies)

For Cloud:

• AWS Certified Security – Specialty
• Microsoft Certified: Azure Security Engineer Associate
• Google Professional Cloud Security Engineer

Organization support:

• Funding certifications for key employees
• Paid study leave
• Bonuses for obtaining certifications

Phase 7: Continuous Learning and Exercises (Ongoing)

Cyclical activities:

Quarterly update webinars (1h each):

• New regulator guidelines (RTS updates)
• Emerging threats and threat intelligence
• Case studies: new incidents in the financial sector
• Lessons learned from own tests and incidents

Annual DORA refresher for all (3h):

• Reminder of key DORA requirements
• Regulation updates
• New procedures in the organization
• Knowledge test

Semi-annual practical exercises:

• Tabletop exercises (for board and crisis management teams)
• Technical DR tests (for IT ops)
• Incident response simulations (for SOC, CISO, risk teams)
• Vendor audit exercises (for procurement and risk)

Participation in industry initiatives:

• FS-ISAC (Financial Services Information Sharing and Analysis Center)
• Threat intelligence sharing groups
• DORA/cybersecurity/risk conferences (e.g., European Banking Authority events)

DORA vs NIS2 – how they differ and what overlaps

DORA and NIS2 (Network and Information Security Directive 2) are two key EU regulations concerning cybersecurity and resilience that entered into force almost simultaneously. Many financial sector organizations may be subject to both regulations simultaneously. Understanding the relationship between them is crucial for an effective compliance strategy.

Main differences

Aspect	DORA	NIS2
Legal form	EU Regulation (directly applicable)	EU Directive (requires transposition into national law)
Subject scope	Financial sector (banks, insurance, payments, investments, crypto)	All critical and important sectors (energy, transport, health, water, digital infrastructure, finance, and others)
Focus	ICT operational resilience – ability to continue operations during ICT incidents	Cybersecurity – protection of networks and information systems against threats
Third-party providers	Detailed regulations for ICT suppliers, direct supervision over critical providers	Supply chain security requirements, but no direct supervision over suppliers
Testing	Detailed resilience testing requirements, including TLPT (Threat-Led Penetration Testing)	General security controls testing requirements
Incident reporting	Timeline: 4h (initial), 72h (intermediate), 1 month (final)	Timeline: 24h (early warning), 72h (incident notification), 1 month (final)
Supervisory authority	Financial supervision authorities (EBA, ESMA, EIOPA; in Poland: KNF, NBP)	Cybersecurity authorities (in Poland: CSIRT NASK, CSIRT GOV, CSIRT MON) + sector regulators

Intersections and synergies

1. Risk management: Both DORA and NIS2 require an ICT/cybersecurity risk management system. Many elements are similar:

• Risk identification
• Implementation of protective measures
• Monitoring and detection
• Incident response
• Business continuity

Practical action: Create an integrated ICT risk management framework that meets the requirements of both regulations simultaneously. Avoid process duplication.

2. Incident management: Both regulations require reporting incidents to supervisory authorities, but with different timelines and to different authorities.

Practical action:

• An incident in a financial institution may require reporting to both KNF (DORA) and CSIRT (NIS2)
• Create a unified incident classification framework that determines when an incident falls under DORA, NIS2, or both
• Automate reporting – one incident, multiple notifications

3. Governance: Both regulations require management body engagement (board) in cybersecurity/resilience oversight.

Practical action:

• The board should receive consolidated reports covering both DORA and NIS2 compliance
• Board-level committee (e.g., Risk Committee) should oversee compliance with both regulations

4. Supply chain / third-party risk: Both regulations require ICT supplier risk management.

Practical action:

• Vendor risk assessment should evaluate compliance with both regulations
• Contracts with suppliers should include clauses compliant with both DORA and NIS2

5. Testing: Both require regular cybersecurity and resilience testing.

Practical action:

• Combine testing programs – one test cycle can meet the requirements of both regulations
• TLPT (required by DORA) can also serve as advanced testing for NIS2

Comparison table – key requirements

Requirement	DORA	NIS2
Risk assessment	✅ Mandatory, detailed framework	✅ Mandatory, risk-based approach
Incident reporting	✅ 4h/72h/1m to financial authorities	✅ 24h/72h/1m to CSIRT
Business continuity	✅ BCP and DRP, testing	✅ BCP and DR, testing
Vendor management	✅ Detailed, supervision over critical providers	✅ Supply chain security
Penetration testing	✅ Mandatory, TLPT for large	✅ Recommended, doesn’t specify TLPT
Board responsibility	✅ Explicit – art. 5 DORA	✅ Implicit – management bodies
Penalties	✅ Up to 2% of global turnover (RTS)	✅ Up to €10 million or 2% of global turnover

Integrated DORA + NIS2 compliance strategy

1. Unified governance:

• One governing committee (e.g., Cyber & Operational Resilience Committee)
• One framework of policies and procedures (with DORA-specific and NIS2-specific annexes)

2. Integrated risk register:

• One ICT/cybersecurity risk register
• Tagging risks: which fall under DORA, NIS2, or both

3. Consolidated reporting:

• One dashboard for the board showing compliance with both regulations
• Unified KPIs and metrics

4. Shared training programs:

• Most competencies are common (cybersecurity, incident response, risk management)
• Dedicated modules for DORA-specific and NIS2-specific requirements

5. Coordinated audits:

• Internal audits should assess compliance with both regulations simultaneously
• Preparation for multi-regulator audits (KNF + CSIRT)

Consequences of non-compliance – penalties and risks

DORA provides for severe sanctions for non-compliance. The regulation is directly applicable in all EU member states, and supervisory authorities (in Poland: KNF for most financial institutions, NBP for payment institutions) have broad powers to enforce requirements.

Administrative penalties

According to Articles 50 and 51 of DORA, member states must establish effective, proportionate, and dissuasive penalties for violations. Regulatory Technical Standards (RTS) published by EBA specify:

Maximum penalties:

• Up to 2% of annual global turnover of the financial institution for serious violations
• Penalties can be imposed on responsible natural persons (board members, key managers)

Examples of violations subject to penalties:

• Lack of implementation of a solid ICT risk management framework
• Failure to conduct required resilience tests (including TLPT)
• Failure to report major ICT incidents within specified timelines
• Non-DORA-compliant contracts with ICT suppliers
• Lack of due diligence regarding ICT suppliers
• Failure to provide requested information to supervisory authorities
• Non-compliance with supervisory authority recommendations

Additional sanctions and supervisory measures

In addition to financial penalties, supervisory authorities can:

1. Issue orders and recommendations:

• Suspension of specific activities or practices
• Order to remove violations within a specified timeframe
• Order to implement specific remedial measures

2. Activity restrictions:

• Prohibition of providing specific services
• Restriction of business expansion (e.g., ban on opening new branches, implementing new products)

3. Public disclosure of violations:

• Publication of information about violations and sanctions
• Negative impact on reputation and image

4. Order for board changes:

• In extreme cases – requirement to dismiss persons responsible for violations

Civil liability

Beyond administrative sanctions, financial institutions may bear civil liability for damages resulting from non-compliance with DORA:

• Clients can claim compensation for losses resulting from ICT incidents (e.g., loss of access to funds, investment losses)
• Shareholders can sue for decline in stock value caused by incidents and regulatory penalties
• Business partners can claim compensation for losses caused by incidents

Reputational risk

This is often the most severe consequence. Public disclosure of a major ICT incident or regulatory penalties for non-compliance with DORA can lead to:

• Loss of customer trust – mass deposit withdrawals (bank run), service cancellations
• Decline in market value – financial institution shares can rapidly lose value
• Problems attracting new customers – long-term negative impact on brand
• Difficulties recruiting talent – impeded recruitment

Systemic risk

For the largest financial institutions (systemically important – G-SII, O-SII), non-compliance with DORA can lead to:

• Intensified supervision – increased audit frequency, additional capital requirements
• Activity restrictions – expansion ban, restructuring requirement

Enforcement probability

DORA is not “dead letter law.” EU financial supervisory authorities have:

• Extensive audit powers – can demand access to systems, documentation, conduct on-site audits
• Enforcement experience – financial supervision (KNF, EBA, ESMA) has a long history of enforcing compliance (e.g., GDPR, MiFID II, Basel III)
• International coordination – ESAs (European Supervisory Authorities) coordinate supervision across the EU

Conclusion: Non-compliance with DORA is not an abstract risk. It’s a real, high probability of severe penalties and business consequences.

How to avoid penalties – key actions

1. Treat DORA as a board priority:

• CEO and board engagement from the start
• Regular compliance monitoring (board reporting)

2. Conduct thorough gap analysis:

• Assess current state vs DORA requirements
• Identify all gaps

3. Create a realistic action plan with timelines:

• Prioritize actions by risk
• Allocate appropriate resources (budget, people)

4. Invest in competencies:

• Train teams (this article is a roadmap!)
• Hire specialists if internal competencies are lacking

5. Document everything:

• DORA requires documentation of framework, processes, tests, incidents
• “If it’s not documented, it doesn’t exist” – auditor’s approach

6. Test regularly:

• Don’t wait for regulator audit – conduct your own tests and exercises
• Learn from internally found mistakes before the regulator finds them

7. Build a resilience culture:

• Resilience is not just technology – it’s organizational culture
• Every employee must understand their role in building resilience

How EITT prepares financial firms for DORA

At EITT, we understand that DORA is not just a compliance requirement – it’s an operational transformation that requires a deep change in how financial institutions manage technology and ICT risk. Our mission is to support Polish banks, insurers, investment firms, and other financial entities in this transformation by developing their teams’ competencies.

Our approach: from assessment to operational readiness

Phase 1: DORA Readiness Assessment

We start with a comprehensive readiness assessment of your institution:

• Gap analysis – detailed comparison of current state with DORA requirements (all 5 pillars)
• ICT systems inventory – mapping critical systems and their dependencies
• Vendor register review – assessment of contracts with ICT suppliers for DORA compliance
• Skills gap analysis – identifying competency gaps in teams
• Risk assessment – determining areas of highest compliance risk

Output: DORA Readiness Report with action prioritization and recommendations.

Phase 2: Customized Training Programs

Based on the assessment, we create a training program tailored to your institution, including:

For board and senior management:

• DORA Strategic Leadership Workshop (2 days)
  • Board responsibility according to art. 5 DORA
  • ICT risk governance
  • Crisis simulation – tabletop exercise
  • Action planning for your institution

For IT, cybersecurity, risk teams:

• DORA Technical Implementation Bootcamp (7 days)
  • ICT risk management framework
  • Incident management and reporting (4h/72h/1m timeline)
  • Penetration testing and TLPT
  • Third-party risk management
  • Business continuity and disaster recovery
  • Hands-on labs and practical exercises

For legal, compliance, procurement:

• DORA Legal & Vendor Management (3 days)
  • Detailed analysis of DORA regulation and RTS
  • Negotiating DORA-compliant contracts
  • Vendor due diligence
  • Reporting to regulators (KNF, NBP)

For all employees:

• DORA Awareness Program (e-learning, 3h)
  • DORA basics and digital operational resilience
  • Every employee’s role
  • Reporting ICT incidents

Phase 3: Practical Tools & Templates

We don’t just teach theory – we provide ready-to-use tools:

• DORA Gap Analysis Template – Excel/checklist for self-assessment
• ICT Risk Register Template – ready framework for risk mapping
• Vendor Assessment Checklists – for ICT supplier due diligence
• Contract Clauses Library – sample DORA-compliant clauses for supplier contracts
• Incident Classification Decision Tree – help in classifying incidents (major vs minor)
• Incident Reporting Templates – ready forms for reporting to KNF/NBP
• BCP/DRP Templates – sample continuity and recovery plans
• Testing Program Template – DORA-compliant resilience testing plan

Phase 4: Simulation Exercises

Theory is one thing, practice is another. We offer:

Crisis Tabletop Exercises:

• Simulation of a major ICT incident (cyberattack, cloud failure, supplier failure)
• Crisis management procedures exercise
• Testing internal and external communication
• Identifying gaps in procedures

Technical DR Tests:

• Simulation of critical systems failure
• Testing disaster recovery procedures
• Measuring RTO/RPO
• Post-exercise review and action plan

Incident Response Simulations:

• Realistic cybersecurity incident simulation
• Full incident response cycle exercise
• Testing DORA timeline reporting
• Debriefing and lessons learned

Phase 5: Continuous Support & Advisory

DORA is not “train and forget.” We offer continuous support:

• 12-month access to DORA experts – ability to ask questions, consultations
• Quarterly update webinars – new EBA/ESMA/EIOPA guidelines, emerging threats
• Annual refresher training – updating team knowledge
• Mock audits – regulator audit simulation with feedback
• 24/7 Helpdesk – support in crisis situations (incidents, audit preparation)

Why EITT?

• 500+ experts with experience in IT, cybersecurity, risk management, compliance, audit
• 2,500+ trainings conducted for leading financial institutions, corporations, public administration
• 4.8/5 average rating from training participants – confirmation of quality and practical approach
• Financial sector specialization – deep knowledge of the specifics of banks, insurers, investment firms
• Practical approach – case studies from the Polish market, real-world scenarios, hands-on exercises
• Certified experts – our trainers hold international certifications (CISSP, CISA, CRISC, CEH, CBCP, ISO 27001 Lead Auditor)
• Experience in compliance regulations – we supported companies in preparing for GDPR, PSD2, MiFID II, AML6

Dedicated offering for financial institutions

We have prepared DORA Readiness packages tailored to institution size:

START Package (for small institutions, 50-200 employees):

• Gap analysis (2 days on-site)
• Awareness training for all employees (e-learning)
• 3-day technical workshop for IT/security teams (up to 15 people)
• 1-day workshop for board
• Template and checklist package
• 3 months expert support

STANDARD Package (for medium institutions, 200-1000 employees):

• Comprehensive gap analysis (5 days on-site)
• Awareness training for all (e-learning)
• 7-day technical bootcamp for IT/security/risk (up to 30 people)
• 2-day workshop for board with crisis simulation
• 3-day legal & vendor management course (up to 15 people)
• Template, checklist, procedures package
• 1 tabletop exercise
• 6 months expert support + quarterly webinars

ADVANCED Package (for large institutions, 1000+ employees):

• Extended gap analysis (10 days on-site)
• Awareness training for all (e-learning + workshops)
• Multiple technical bootcamps (for different locations/teams)
• Executive workshops + quarterly board briefings
• Legal & vendor management intensive
• Full suite of templates, procedures, playbooks
• Multiple simulation exercises (tabletop, DR test, incident response)
• 12 months comprehensive support + mock audits
• Dedicated DORA Advisor (fractional consultant)

Don’t wait. DORA has been in force since January 2025. Supervisory authorities have already started audits. Companies that invest in team preparation now will avoid penalties and build a real competitive advantage in the form of operational resilience.

👉 Check our cybersecurity, GRC, and risk management trainings 👉 Contact an EITT expert to discuss your institution’s needs

FAQ – most common questions about DORA and competencies

Does DORA apply only to large banks or also to smaller financial institutions?

DORA has a broad scope and covers practically all financial entities in the EU, regardless of size:

• Banks – all, from the largest to small cooperative banks
• Payment institutions and e-money – including small fintechs
• Insurance companies – all, regardless of size
• Investment firms – including small brokerage houses
• Cryptocurrency platforms (CASPs)

Proportionality: DORA provides for the principle of proportionality – smaller, less complex institutions can apply a simplified approach. For example:

• TLPT (advanced penetration tests) are required only for large, systemically important institutions
• ICT risk management framework should be proportional to size and complexity

But: Even a small institution must meet basic DORA requirements (risk management, incident reporting, vendor contracts, basic testing).

How much time do we have to implement DORA?

DORA entered into force on January 17, 2025. This means that from that date, financial institutions must be compliant with the requirements.

In practice:

• If you haven’t started preparations yet – start immediately
• Supervisory authorities (KNF, NBP) have already started compliance audits
• Lack of compliance can result in penalties and orders for immediate violation removal

Action timeline:

• Immediately (month 1-2): Gap analysis and prioritization
• Month 2-6: Team training, process and documentation updates, renegotiation of supplier contracts
• Ongoing: Regular tests, exercises, continuous improvement

What are the most common mistakes of financial institutions in DORA preparations?

1. Treating DORA as an “IT project”: DORA is not just IT. It’s a transformation covering risk management, legal, procurement, operations, HR (training), board. Common mistake: CIO gets the task “implement DORA” without other departments’ engagement.

2. Underestimating vendor management: Pillar 4 (third-party risk) is the most time-consuming. Renegotiating hundreds of contracts with ICT suppliers can take months. Many institutions discover this too late.

3. Lack of board engagement: Art. 5 DORA explicitly requires board engagement. If the board treats DORA as a “technical requirement” and delegates everything to CIO – that’s a DORA violation.

4. Insufficient training: Organizations invest in tools (SIEM, firewalls) but neglect training people. Meanwhile, most ICT incidents result from human error (phishing, misconfiguration).

5. Lack of practical testing: Having procedures on paper is not the same as them working in practice. DORA requires regular testing. Many institutions have “beautiful” BCP/DRP that have never been tested – and turn out to be useless during a real incident.

6. Ignoring concentration risk: Institutions often don’t realize how dependent they are on 1-2 key suppliers (e.g., one cloud provider for all critical systems). This is enormous risk.

Can we rely on our cloud provider’s assurances about DORA compliance?

Partially, but with great caution.

What the cloud provider can do:

• Provide DORA-compliant infrastructure (security controls, resilience, SLA)
• Provide certificates and audits (ISO 27001, SOC 2, etc.)
• Enable audit (according to DORA requirement)
• Report infrastructure-related incidents

What the cloud provider will NOT do for you:

• Won’t conduct your ICT risk assessment
• Won’t ensure that you use their services in a DORA-compliant manner
• Won’t conduct your resilience tests
• Won’t report incidents to KNF/NBP (that’s your obligation, not theirs)

Responsibility model: In the cloud, the shared responsibility model applies:

• Cloud provider is responsible for security OF the cloud (infrastructure, hardware, networking)
• You are responsible for security IN the cloud (your data, applications, configuration, access management)

DORA contractual requirements: The contract with the cloud provider must include DORA-compliant clauses:

• Right to audit (you or designated auditors)
• Exit strategy – ability to migrate to another provider
• Data location (jurisdiction)
• Supervisory authority access (KNF, NBP)
• Incident reporting

Practical step: Conduct a review of the contract with the cloud provider and negotiate additional clauses if DORA requirements are missing.

Who in the organization should be responsible for DORA compliance?

DORA requires a multidisciplinary approach. Typical responsibility structure:

Strategic level – Board:

• CEO – ultimate responsibility
• Board – oversight, framework approval, risk appetite
• Risk Committee (board committee) – compliance oversight

Operational level – Management:

• CRO (Chief Risk Officer) – ownership of ICT risk management framework
• CIO (Chief Information Officer) – responsibility for IT operations, resilience, vendor management
• CISO (Chief Information Security Officer) – cybersecurity, incident response
• COO (Chief Operating Officer) – business continuity, operational resilience
• General Counsel / Chief Compliance Officer – legal interpretation, regulatory reporting, vendor contracts
• CFO (Chief Financial Officer) – budgeting investments in resilience

Execution level:

• IT Risk Manager – day-to-day risk management
• Vendor Risk Manager – third-party risk management
• Incident Manager – ICT incident management
• Business Continuity Manager – BCP/DRP
• Internal Auditor – DORA compliance audits

New role: DORA Compliance Officer? Many institutions create a dedicated role of DORA Coordinator or Digital Operational Resilience Officer, which coordinates the activities of all the above-mentioned teams and is a single point of contact for the regulator.

In small institutions: Functions can be combined (e.g., CIO + CISO, CRO + Compliance), but basic knowledge and responsibility must be clearly defined.

What certifications are most valuable for DORA compliance?

For Risk Managers:

• CRISC (Certified in Risk and Information Systems Control) – ISACA, focus on IT risk
• CISA (Certified Information Systems Auditor) – ISACA, IT controls audit

For Cybersecurity Professionals:

• CISSP (Certified Information Systems Security Professional) – (ISC)², most recognized security certification
• CEH (Certified Ethical Hacker) – EC-Council, for penetration testers
• GCIH (GIAC Certified Incident Handler) – GIAC/SANS, incident response

For Business Continuity:

• CBCP (Certified Business Continuity Professional) – DRI International
• ISO 22301 Lead Implementer – business continuity management systems

For Cloud Security:

• AWS Certified Security – Specialty
• Microsoft Certified: Azure Security Engineer Associate
• Google Professional Cloud Security Engineer

For Compliance/Legal:

• CIPP/E (Certified Information Privacy Professional/Europe) – IAPP, for GDPR + DORA synergies

IMPORTANT: Certifications are valuable, but don’t replace DORA-specific training. We recommend a combination: general industry certifications + dedicated DORA training.

How often must we conduct operational resilience tests?

DORA doesn’t specify one rigid frequency – it requires tests to be conducted regularly and proportionally to the institution’s risk profile. EBA guidelines suggest:

Basic tests (for all institutions):

• Vulnerability assessments: At least quarterly (4x/year)
• Penetration tests: At least once a year
• Business continuity tests (BCP): At least once a year
• Disaster recovery tests (DRP): At least once a year
• Scenario-based testing: As needed, but minimum once a year

TLPT (Threat-Led Penetration Testing) – for large institutions:

• At least once every 3 years
• Required for institutions deemed “significant” by supervision (typically: large banks, capital market infrastructure)

Best practice:

• Don’t wait until year-end – spread tests evenly throughout the year
• Different types of tests in different periods (e.g., Q1: pentest, Q2: DR test, Q3: BCP exercise, Q4: tabletop)
• After each test: documentation + action plan + recommendation implementation + retest

IMPORTANT: Test results must be reported to the board and lead to specific remedial actions.

Will DORA affect our cloud computing strategy?

Yes, but it doesn’t mean abandoning the cloud. DORA doesn’t prohibit cloud computing – on the contrary, a well-designed cloud strategy can increase operational resilience (redundancy, scalability, disaster recovery).

What changes with DORA:

1. Cloud provider selection:

• You must ensure the provider meets DORA requirements (security, resilience, auditability)
• Provider must agree to DORA-required contractual clauses (audit rights, exit strategy)
• Large providers (AWS, Azure, GCP) already offer DORA-compliant frameworks

2. Multi-cloud and avoid concentration risk:

• DORA requires managing supplier concentration risk
• Consider a multi-cloud strategy (different providers for different workloads) or hybrid cloud (part on-premise, part cloud)
• Exit strategy – realistic plan for migrating to another provider or returning on-premise

3. Data location and sovereignty:

• DORA requires contracts to specify data processing location
• For financial institutions in the EU: data should be processed in the EU (GDPR + regulatory requirements)
• Configure cloud region policies

4. Enhanced monitoring and logging:

• Increased visibility of what’s happening in the cloud
• Integrate cloud logs with your SIEM
• SLA monitoring and deviation alerting

5. Testing cloud resilience:

• Regularly test failover between availability zones/regions
• Test disaster recovery in the cloud
• Chaos engineering – deliberately introducing failures in cloud environment to test resilience

Strategy: Cloud can be an enabler of DORA compliance if you use it consciously and according to regulation requirements.

---

Conclusion: DORA is not a barrier to innovation or digitalization of the financial sector. It’s a quality standard that raises the bar for the entire industry and builds customer trust. Institutions that invest in their teams’ competencies and treat DORA as an opportunity to build competitive advantage will win in the long term.

Ready for DORA? Contact EITT to receive a personalized training and support offer for your financial institution.

👉 Check our cybersecurity, GRC, and risk management trainings 👉 Schedule a free DORA Readiness consultation

Read Also

• IT Training for Banks - Financial Sector Specifics
• IT Competencies in Manufacturing and Industry 4.0 - Training Plan
• Mandatory IT Training in Regulated Industries - 2026 Checklist

Develop Your Skills

This article is related to the training DORA regulation: ensuring digital operational resilience in the financial sector and for ICT providers. Check the program and sign up to develop your skills with EITT experts.

Read also

• IT Training for Banks - Financial Sector Specifics
• Mandatory IT Training in Regulated Industries - 2026 Checklist
• Cyber security in the company: the NIS2 directive, DORA and building resilience