One year ago, on January 17, 2025, the DORA regulation (Digital Operational Resilience Act) stopped being the future and became reality. Financial institutions across the European Union had to demonstrate that their ICT systems were resilient to disruptions, incidents, and cyberattacks. Twelve months of intensive work, audits, and adjustments have passed.

Today we can look back and assess what succeeded, where problems arose, and what lessons can be drawn for organizations still improving their digital resilience programs. This article summarizes the first year of living with DORA.

What is DORA and why does it change the rules of the game?

DORA is Regulation (EU) 2022/2554 of the European Parliament and of the Council, which entered into force on January 16, 2023, but became applicable only from January 17, 2025. This two-year transitional period was meant to give financial institutions time to prepare.

The regulation introduces uniform requirements for digital operational resilience for financial sector entities. It covers banks, insurance companies, investment funds, payment institutions, crypto-asset firms, and - importantly - ICT service providers to the financial sector.

DORA changes the rules of the game because:

It harmonizes requirements - instead of a patchwork of national regulations, we have one European standard
It covers the supply chain - ICT providers are subject to oversight, not just financial institutions
It requires testing - having policies is not enough, resilience must be regularly verified
It introduces incident reporting - a unified system for reporting serious ICT incidents

📚 Read the complete guide: IAM / Zero Trust: Zarządzanie tożsamością i dostępem - od podstaw do Zero Trust

How did financial institutions handle implementation?

The first year of DORA application brought varied experiences. Large institutions that started preparations early went through the process relatively smoothly. Smaller entities often struggled with lack of resources and competencies.

Implementation leaders

Systemically important banks and large insurance groups generally managed well. They had dedicated teams, budgets, and experience with earlier regulations (e.g., EBA guidelines on outsourcing). For them, DORA was an evolution, not a revolution.

Key success factors included:

Early start of preparations (2023)
Establishing dedicated project teams
Board engagement from the beginning
Leveraging existing frameworks (ISO 27001, COBIT)
Proactive cooperation with ICT providers

Entities with challenges

Smaller institutions - regional cooperative banks, small investment firms, fintechs - often struggled with fundamental problems. They lacked people with appropriate competencies, budgets for tools, and ICT risk management systems.

The most common challenges included:

Lack of ICT asset inventory
Incomplete provider registers
Outdated risk analyses
Missing business continuity plans for cyber scenarios
Inadequate contracts with providers

Which DORA requirements proved most difficult?

After one year of application, we can identify areas that caused institutions the most problems. This is valuable knowledge for organizations still improving their programs.

Third-party ICT risk management

Articles 28-30 of DORA concerning management of risk related to external ICT providers proved exceptionally demanding. Institutions had to:

Create a complete register of all ICT provider contracts
Conduct due diligence on each critical provider
Renegotiate contracts, introducing required clauses
Implement provider monitoring and exit plans

The problem was scale. A typical medium-sized bank has hundreds of ICT providers. Classification, risk assessment, and contract renegotiation is a process measured in months.

Digital resilience testing

Chapter IV of DORA requires regular resilience testing. For systemically important entities, this means advanced threat-led penetration testing (TLPT) at least once every three years.

Testing-related challenges included:

Lack of qualified teams to conduct TLPT
High costs of external penetration tests
Difficulties testing production environments without disruption
Coordination of tests with ICT providers

Incident reporting

DORA introduces the obligation to report serious ICT incidents to competent authorities. Institutions had to build incident classification processes, determine reporting thresholds, and prepare notification templates.

In practice, it turned out that:

The definition of “serious incident” required interpretation
Reporting deadlines (initial notification within 4 hours) are demanding
Integration with existing incident management processes was complex
Lack of unified reporting tools at European scale

How did supervisors approach enforcement?

The first months of DORA application were characterized by a pragmatic approach from regulators. The Financial Supervision Authority and other European supervisory bodies focused on verifying progress, not imposing penalties.

Educational approach

Supervisors adopted a “help first, then enforce” strategy. They organized workshops, published interpretive guidelines, and answered institutions’ questions. This approach helped resolve many practical doubts.

First inspections

Toward the end of 2025, the first thematic inspections regarding DORA began. They focused on:

Completeness of ICT provider registers
Quality of risk analyses
Business continuity plan readiness
Incident reporting processes

Inspection findings

Reports from the first inspections indicate recurring problems:

Provider registers are complete, but risk classification is sometimes superficial
ICT risk analyses don’t always consider supply chain scenarios
Business continuity plans exist but are rarely tested under cyber conditions
Incident reporting processes need refinement

What changed in relationships with ICT providers?

DORA fundamentally changed the dynamics between financial institutions and their technology providers. This is one of the most visible changes from the first year.

New bargaining power

Financial institutions gained arguments in negotiations. DORA requirements for contractual clauses (audit rights, exit plans, SLAs) became market standard. Providers who refused to accept them lost contracts.

Provider consolidation

Many institutions used DORA as an opportunity to review and consolidate their provider base. Reducing the number of ICT providers by 20-30% was not uncommon. Fewer providers means easier risk management.

Increased costs

ICT providers passed some compliance costs to clients. Audits, certifications, extended SLAs - all of this costs money. Financial institutions report ICT service spending increases of 10-15% year over year.

Critical providers under scrutiny

DORA introduces the concept of “critical ICT service providers,” who may be subject to direct supervision by European authorities. The list of such providers (mainly large cloud players) is being finalized. This changes these firms’ position - from commercial suppliers they become quasi-regulated entities.

How has DORA affected cybersecurity in practice?

The fundamental question: has DORA actually improved financial sector security? After one year, a definitive answer is difficult, but positive trends are visible.

Increased board awareness

DORA requires board engagement in ICT risk management. Article 5 of the regulation explicitly places responsibility on management bodies for establishing, approving, and overseeing implementation of ICT risk management frameworks.

This translated into:

Regular ICT risk reporting at board level
Higher cybersecurity budgets
Hiring security experts in leadership positions
Including cyber risk in business strategy

Process systematization

Institutions that previously had fragmented approaches to ICT security had to systematize them. The DORA framework forced:

Complete asset inventory
Regular risk reviews
Policy and procedure documentation
Control testing and validation

Improved incident detection

The incident reporting obligation motivated institutions to invest in monitoring and detection. Better SIEM tools, extended logging, alert automation - all of this improves threat detection capability.

What lessons are there for organizations still preparing?

Although the formal deadline has passed, many organizations are still improving their DORA programs. Here are lessons from the first year that may help.

Start with fundamentals

Don’t try to build advanced mechanisms without solid foundations. Complete ICT asset inventory and provider register are the foundation. Without this, further actions will be ineffective.

Automate where possible

Manually managing hundreds of providers and thousands of assets is impossible. Invest in tools for:

Automated inventory
Business continuity monitoring
Provider risk management
Incident reporting

Engage the business

DORA is not just an IT project. Engage business process owners in identifying critical functions and assets. They know best what’s essential for the company to operate.

Test regularly

Plans without testing are worthless. Conduct regular exercises:

Tabletop exercises for cyber scenarios
Failover system tests
Incident simulations with provider participation
Crisis communication plan tests

Build relationships with supervisors

Proactive communication with authorities pays off. Regulators appreciate institutions that report problems and seek solutions rather than hiding shortcomings.

What will the second year of DORA application bring?

Looking to the future, we can expect several trends in 2026 and beyond.

Stricter enforcement

The “soft” enforcement period is ending. Supervisors will increasingly rigorously verify compliance and impose sanctions for significant shortcomings.

Practice standardization

The market will converge around common standards and practices. Industry frameworks, contract templates, testing methodologies - all of this is crystallizing.

Critical provider oversight

European supervisory authorities will begin direct oversight of critical ICT providers. This will change the dynamics of cloud services market for the financial sector.

Integration with other regulations

DORA will increasingly integrate with other regulations - NIS2, AI Act, Data Act. Institutions must think about compliance holistically, not in silos.

How to measure DORA program success?

After a year of application, it’s worth asking: how do we know our DORA program works? Here are key metrics.

Operational metrics

Mean time to detect incident (MTTD)
Mean time to respond to incident (MTTR)
Percentage of ICT assets in inventory
Percentage of providers with current risk assessments
Number of resilience tests conducted

Risk metrics

Number of identified control gaps
Percentage of critical assets with continuity plans
Average time to remediate vulnerabilities
Number of incidents affecting service availability

Business metrics

DORA program operational costs
Impact on service availability (SLA)
Customer satisfaction with service reliability
Audit and inspection results

What technologies support DORA compliance?

Effective DORA implementation requires appropriate tools. After a year of application, technology categories that best support compliance have crystallized.

GRC platforms

Integrated platforms for risk, compliance, and audit management (Governance, Risk, Compliance) are the foundation of a DORA program. They allow centralizing documentation, tracking tasks, and generating reports for supervisors.

Provider management tools

Dedicated Third Party Risk Management (TPRM) systems automate provider risk assessment, monitor their financial health and security, and manage contract lifecycles.

Testing solutions

Automated penetration testing platforms, such as RidgeBot, enable continuous security validation without engaging expensive external red teams. This is particularly important given DORA requirements for regular testing.

SIEM and SOAR systems

Advanced systems for log collection, event correlation, and response automation are essential for meeting incident detection and reporting requirements.

Summary of the first year with DORA

One year of DORA application brought fundamental change to the financial sector. Digital operational resilience is no longer an optional add-on - it has become a regulatory requirement with concrete consequences for shortcomings.

Key lessons:

For financial institutions:

DORA is a marathon, not a sprint - program improvement will take years
Investments in automation pay off
Provider relationships require strategic approach
Resilience testing must be continuous, not one-time

For ICT providers:

The financial sector demands higher standards
Transparency and audit readiness are fundamental
Investing in certifications and compliance is worthwhile

For the entire ecosystem:

DORA raises the bar for cybersecurity in finance
European harmonization facilitates cross-border activity
ICT supply chain oversight is the future of regulation

The second year of DORA application will bring further challenges - stricter enforcement, critical provider oversight, integration with other regulations. Institutions that treated the first year as a sprint to check a box will have problems. Those that built solid foundations are well prepared for the future.

Need support in improving your DORA program? Contact us - we’ll help identify gaps and plan remediation actions.

Learn key terms related to this article in our cybersecurity glossary:

Ransomware — Ransomware is a type of malicious software (malware) that blocks access to a…
Security Operations Center (SOC) — Security Operations Center (SOC) is a central location where a team of security…
SOC as a Service — SOC as a Service (Security Operations Center as a Service), also known as…
Cybersecurity — Cybersecurity is a collection of techniques, processes, and practices used to…
Cybersecurity Incident Management — Cybersecurity incident management is the process of identifying, analyzing,…

Learn More

Explore related articles in our knowledge base:

Explore Our Services

Need cybersecurity support? Check out:

DORA Compliance Audit - DORA regulation preparation
Incident Response - rapid response to security incidents