I remember a conversation with the Compliance Manager at a regional cooperative bank — let’s call him Tom — from a few months back. He sat across from me with a stack of documents and said plainly: “Przemek, we have NIS2, we have KRI, we have KNF Recommendations D and U, and now DORA on top of it all. By the time we finish implementing one, there will be another letter of the alphabet.” I understood him perfectly. Regulatory fatigue in the financial sector today is very real. But DORA is not “another letter” — it is a systemic, sector-wide transformation in the approach to digital resilience, one that cannot be treated like yet another checklist audit.
The DORA Regulation (Digital Operational Resilience Act, EU Regulation 2022/2554) entered into force on 17 January 2025, following a two-year preparatory period. Unlike directives such as NIS2, DORA is a regulation — it applies directly, without the need for transposition into national law. This means uniform standards across all 27 EU member states, which for cross-border institutions is both an advantage and a challenge. An advantage, because the rules are consistent. A challenge, because there is no room for national “softening interpretations.”
This article is a practical guide for CISOs, Compliance Managers, CTOs, and boards of financial institutions. No legal jargon — just concrete operational specifics.
What is DORA and why does it change the approach to cybersecurity in finance?
The financial sector has long been subject to numerous IT security regulations — KNF recommendations, PCI DSS standards, Basel III operational risk requirements, and more recently NIS2. However, each of these regulations addressed only a particular slice of reality. DORA is the first regulation that approaches digital resilience holistically and dedicates itself exclusively to the financial sector.
The key difference from earlier approaches lies in the fact that DORA does not ask “do you have security controls?” but rather “are you resilient to disruptions?” This is a fundamental philosophical shift. Cybersecurity for years focused on prevention — building defensive walls. DORA assumes that incidents and disruptions are inevitable, and requires institutions to be able to withstand them, limit their impact, and quickly return to normal operations. This is the approach industry experts call “assume breach” — assume you will be attacked.
The second dimension of change concerns the ICT supply chain. Before DORA, many financial institutions treated external technology providers as “IT helpers.” DORA explicitly calls them risk providers and imposes on financial institutions the obligation to manage that risk with the same diligence applied to credit or market risk. If your critical cloud provider goes down for two hours, that is your problem — not theirs.
The third change concerns the requirements on management boards. DORA, like NIS2, shifts responsibility for digital resilience from the IT level to the level of senior management. The board must approve the digital resilience strategy, understand the risks, and maintain documented evidence of its involvement. Ignorance is no longer any excuse.
📚 Read the complete guide: NIS2: Complete guide to the NIS2 Directive — obligations, penalties, deadlines
📚 Read the complete guide: DORA: DORA - rozporządzenie o cyfrowej odporności operacyjnej dla sektora finansowego
Which entities are subject to DORA — banks, insurers, investment firms, fintechs?
The personal scope of DORA is very broad and precisely defined in Article 2 of the regulation. It covers 21 categories of financial entities. In practice, this means DORA applies to virtually the entire regulated financial sector in the EU.
Banks and credit institutions — all are subject to DORA without exception, regardless of size. The same applies to payment institutions, including those handling mobile payments, electronic money institutions, investment firms, asset managers (UCITS, AIF), central counterparties (CCPs), trade repositories, crypto-asset service providers (CASPs), insurance and reinsurance undertakings, insurance intermediaries (with certain exceptions), and credit rating agencies.
Fintechs deserve particular attention. If a fintech company holds a regulatory licence — as a payment institution, CASP provider, or investment firm — it is subject to DORA in full. Many financial startups are surprised to learn that their “small payment application” is subject to the same requirements as a large retail bank. DORA provides no exemptions based on size — only for certain categories does it apply the proportionality principle.
The proportionality principle (Article 4 of DORA) allows entities to apply a simplified ICT risk management framework if they meet the criteria of a microenterprise or small enterprise. However, even then all five pillars of DORA remain applicable — proportionality relates only to the manner of implementation, not exemption from the obligation.
External ICT third-party service providers (TPSPs) are not directly subject to DORA, but are indirectly regulated through the obligations of financial institutions towards them. For the largest cloud and infrastructure providers (so-called Critical Third-Party Providers, or CTPPs), the European supervisory authorities (EBA, ESMA, EIOPA) exercise direct oversight — which is unprecedented in the history of EU financial regulation.
What are DORA’s requirements for ICT risk management?
ICT Risk Management — the first and foundational pillar of DORA — is described in detail in Articles 5–16 of the regulation. It forms the core of the entire requirements architecture and is a prerequisite for meeting the remaining requirements.
DORA requires financial institutions to maintain comprehensive, documented, and regularly updated ICT risk management frameworks. These frameworks must cover identification, protection, detection, response, and recovery (reflecting an approach similar to the NIST CSF framework). The key word is “maintain” — DORA is not satisfied with a one-time preparation of documentation; it requires a continuous process.
Specific requirements cover several areas. First, ICT asset identification and classification — the institution must maintain a detailed register of all ICT systems, indicating which ones support critical or important functions. This is not an inventory for IT — it is a risk management tool. Second, protection and prevention — implementing appropriate security policies, privileged access management (PAM), data encryption, vulnerability and patch management, and continuous monitoring. Third, detection — implementing mechanisms to enable rapid identification of anomalies and incidents, which in practice means the need to have a SIEM-class system or a SOC.
A critical and often undervalued element is the requirement for an ICT Business Continuity Plan. DORA requires that this plan not only be developed but also regularly tested. The institution must demonstrate that it knows how to operate in emergency mode — from the decision-making procedure to the specific configurations of backup systems.
The board has direct obligations here. It must approve the digital resilience strategy, regularly review response and recovery plans, and document its involvement. In practice, this means at least quarterly board reports on the status of ICT risks and progress in implementation.
It is worth emphasising that DORA distinguishes critical systems from others. Systems supporting critical or important functions (e.g. transactional systems, core banking, policy management systems) are subject to significantly stricter requirements than auxiliary systems (e.g. HR systems). This hierarchisation is both a regulatory requirement and a practical approach to the rational management of security resources.
How does DORA regulate incident management — classification and reporting?
Management of ICT-related incidents — the second pillar of DORA, regulated in Articles 17–23 of the regulation — presents one of the most important operational requirements that in many institutions demands a thorough overhaul of processes.
DORA requires the implementation of an ICT incident classification process that distinguishes ordinary incidents from major ICT-related incidents and — a new concept in regulation — major cyber threats. Classification is not left to the discretion of the institution — the delegated regulation (RTS) specifies the criteria: number of affected clients, transaction value, duration of unavailability, geographical scope, criticality of affected services.
The reporting timelines for major ICT incidents to the competent supervisory authority (in Poland: the KNF) are strict and three-tiered. The Initial Notification must be submitted within 4 hours of classifying the incident as major, but no later than 24 hours after detection. The Intermediate Report must be submitted within 72 hours of the initial notification, with updated data and a preliminary assessment of causes. The Final Report must be submitted within one month of closing the incident, containing a root cause analysis and lessons learned.
These timelines will be familiar to those acquainted with GDPR (72 hours to notify the supervisory authority) and NIS2. DORA tightens them in the first phase (4 hours!) while simultaneously requiring deeper analysis at the final report stage. This means an institution must have an effective incident triage process — the ability to quickly assess whether an incident qualifies as “major” and to initiate the reporting procedure.
In practice, with our clients from the banking sector, we see two most common problems. The first is the absence of clear classification criteria — when an incident occurs, nobody knows whether it is already a “major” case or still a “normal” one. The second is the lack of a ready-made template and process for reporting to the regulator — in a stressful situation, with the clock ticking, the organisation has no time to create documents from scratch.
A new element is the obligation to report major cyber threats. Institutions that identify a threat with the potential to cause a major incident (e.g. a phishing campaign targeting their systems, exploitation of a vulnerability in a critical system) may — though are not required to — voluntarily notify the competent supervisory authority. This is an element of building situational awareness at the regulatory level.
What are digital resilience tests (TLPT) and who must conduct them?
Threat-Led Penetration Testing (TLPT) is the third pillar of DORA and simultaneously the most operationally challenging to implement. Articles 24–27 of the regulation govern the rules for conducting these tests in detail, and the accompanying delegated regulations (RTS, TIBER-EU guidelines) provide the methodological framework.
TLPT are not ordinary penetration tests. They are advanced, scenario-based tests conducted by certified external testers (so-called red teams), simulating real, advanced targeted attacks (APTs — Advanced Persistent Threats). Attack scenarios are developed on the basis of current threat intelligence specific to the given institution. The tests cover production systems — not test environments — which increases their realism and, at the same time, the operational risk.
The obligation to conduct TLPT applies to institutions recognised as “systemically important” entities — that is, those whose disruption could threaten the stability of the entire financial system. In practice, this means the largest banks, key market infrastructures, and selected institutions designated by the competent supervisory authority. Smaller institutions are not required to conduct TLPT, but may do so voluntarily.
For institutions subject to the TLPT obligation, tests must be conducted at least once every three years. They require the involvement of three parties: the institution itself (blue team, process management), an external tester (red team, certified under DORA/TIBER-EU), and the competent supervisory authority, which oversees the entire process and validates the results.
A key innovation in DORA is the possibility of mutual recognition of TLPT results across jurisdictions. If a holding bank conducts a DORA-compliant TLPT test in one EU country, the results may be recognised by the supervisory authority in another country without requiring the full test to be repeated. This is a significant advantage for cross-border institutions.
Even for institutions not subject to the TLPT obligation, DORA requires regular digital resilience testing (Article 25). These may include: internal penetration tests, vulnerability-based tests, performance tests, ICT business continuity plan tests, or disaster recovery tests. The institution must develop a testing programme — approved by the board — and execute it systematically, documenting results and lessons learned.
One of our clients, a regional investment fund management company managing a multi-billion portfolio, conducted a disaster recovery test for the very first time in its history — as part of the preparations for DORA. The result? The actual recovery time was over three times longer than the documentation assumed. Without the test, this gap would never have come to light — until a real incident occurred.
How does DORA affect ICT third-party risk management?
Management of external ICT third-party risk (Third-Party Risk Management, TPRM) — the fourth pillar of DORA — is the area that in many financial institutions requires the most fundamental changes. Articles 28–44 regulate this area with unprecedented detail.
The starting point is the requirement to maintain an ICT Third-Party Register. This register must document all external ICT services, with particular emphasis on those supporting critical or important functions. The information in the register includes: provider details, data location, service description, contract dates, indication of whether the service supports a critical function, and information about sub-contractors.
DORA introduces the concept of third-party concentration risk — a situation where an institution or the entire sector is excessively dependent on a single provider or group of related providers. Supervisory authorities will analyse these dependencies at the sector level. The practical implication for institutions is: maintain an exit strategy for each critical provider. The question “what will we do if this provider goes bankrupt or terminates the contract?” must have a concrete answer.
The contractual requirements for ICT providers supporting critical or important functions are precisely defined in Article 30 of DORA. Contracts must include: a description of services and service levels (SLA), the institution’s right to audit the provider or to use the results of third-party audits, information security requirements, the provider’s obligation to report incidents, sub-contracting regulations, contract termination conditions, and a transition plan (exit plan).
For many financial institutions, renegotiating contracts with ICT providers in line with DORA requirements is a massive project in itself. Many contracts with large cloud providers (AWS, Azure, Google Cloud) or banking software vendors were established before DORA entered into force and do not contain the required clauses. The good news is that large cloud providers are actively adjusting their standard contractual terms to meet DORA requirements and are providing compliance documentation that facilitates this process.
The European Supervisory Authorities (EBA, ESMA, EIOPA) have drawn from DORA the obligation to exercise direct supervision over critical external ICT providers (CTPPs — Critical Third-Party Providers). The list of CTPP entities is established centrally at EU level. For providers placed on this list — which concerns the largest cloud providers and critical infrastructure providers — direct inspections are foreseen, along with the possibility of imposing fines of up to 1% of average daily global turnover for each day of violation. This is an unprecedented supervisory tool.
How to prepare a training programme compliant with DORA?
Awareness and competence in digital resilience form the fifth, often underestimated pillar of DORA. Article 13 and the recitals of the regulation explicitly state that a financial institution must provide training for employees and — particularly importantly — for members of the management board.
DORA explicitly requires that management bodies undergo regular training in ICT digital resilience. This training must be documented. The absence of documentation is itself a violation of the requirements. The content of training for the board should cover: understanding the cyber threat landscape specific to the financial sector, familiarity with DORA requirements and the board’s role in fulfilling them, the ability to evaluate incident reports and resilience test results, and decision-making regarding the prioritisation of ICT risks.
For operational employees, the training programme should be differentiated according to role. IT and security staff need advanced technical training (SIEM operations, incident response procedures, secure configuration principles). Front-line employees (customer service, banking operations) need training in recognising threats (phishing, social engineering) and incident escalation procedures. Risk managers and compliance staff need knowledge of the specific regulatory requirements of DORA, incident classification, and reporting obligations.
The training programme must be a living document, updated in response to changes in the threat landscape. If new phishing campaigns targeting the banking sector emerge, the organisation must have a mechanism for rapidly communicating that knowledge to employees. An annual “online course” ticked off in an HR system does not meet DORA’s requirements for maintaining up-to-date knowledge.
It is worth noting that DORA does not define in detail the form of training. Options include: traditional classroom training, e-learning platforms, phishing simulations, tabletop exercises for the board, and regular security awareness briefings. What matters is that they are effective — and the institution should be able to demonstrate the measurement of effectiveness (simulation results, knowledge tests, behavioural changes) to the regulator.
Our recommendation for financial institutions: build the training programme as a system, not as a project. Implementing training once and forgetting about it is a trap. DORA requires continuity — and it is precisely the continuity of training, documented and verifiable, that the regulator will examine during inspections.
How does DORA interact with NIS2, ISO 27001, and KNF guidelines?
One of the questions most frequently asked during workshops with financial institutions is: “Since we already have NIS2, ISO 27001, and KNF guidelines, how much that is genuinely new does DORA actually add?” The answer is complex and requires precise mapping.
DORA vs NIS2: The DORA Regulation constitutes lex specialis in relation to the NIS2 Directive for the financial sector. This means that financial institutions subject to DORA simultaneously fulfil NIS2 requirements in the area of network and information systems security — they do not need to “double report” the same incidents to different authorities. Coordination between financial supervisory authorities (KNF) and authorities competent for NIS2 (sectoral CSIRTs, national authorities) is regulated at the European level.
DORA vs ISO 27001: ISO 27001 is a voluntary information security management standard that an institution may implement in many ways. DORA is a mandatory regulation with precise requirements. The good news is that many ISO 27001 controls (particularly from Annex A) cover DORA requirements. However, DORA goes further in areas that ISO 27001 does not regulate to the same degree — for example TLPT, contractual requirements for ICT providers, and the incident register with mandatory reporting timelines. For institutions holding ISO 27001 certification, the starting point for a DORA gap analysis should be precise mapping of coverage and identification of gaps.
DORA vs KNF guidelines (Recommendation D, Recommendation U): KNF guidelines on ICT risk management (Recommendation D for banks, Recommendation U for insurers) were, before DORA, the most important reference point for Polish financial institutions. DORA takes precedence as an EU legislative act, but the KNF may issue additional guidelines supplementing DORA for the specifics of the Polish market. In practice, institutions that have robustly implemented Recommendation D have a solid foundation for DORA — but are not automatically compliant. In particular, the areas of TLPT, TPRM (third-party risk management), and the precise incident reporting requirements demand additional work.
The approach we recommend at nFlo is based on one integrated compliance architecture, rather than siloed “DORA”, “NIS2”, “ISO 27001” projects. Our mapping framework makes it possible to identify controls that are common, controls specific to each regulation, and to build them on top of the existing compliance infrastructure. The result: instead of three separate implementation programmes — one integrated management system.
What does the DORA implementation roadmap look like?
The table below presents a strategic DORA implementation path based on three phases. Since DORA has been in force since 17 January 2025, financial institutions that have not yet completed implementation should treat this roadmap as a catch-up plan with immediate priority on the areas most exposed to regulatory risk.
| Phase | Time horizon | Key actions | Result / Deliverable | Owner |
|---|---|---|---|---|
| 1. DIAGNOSIS | Weeks 1–6 | DORA gap analysis vs current state: ICT risk management, incident processes, supplier registers, contractual documentation | Gap report with prioritisation and budget estimate | CISO / Compliance |
| 1. DIAGNOSIS | Weeks 1–6 | Identification of critical systems and important ICT functions; build/verify ICT asset register | Certified ICT asset register | CTO / Architecture |
| 2. FOUNDATIONS | Months 2–5 | Update ICT risk management policies and procedures; implement/update ICT business continuity framework (BCP/DRP) | Board-approved DORA-compliant policies | CISO + Board |
| 2. FOUNDATIONS | Months 2–5 | Implement ICT incident classification and reporting process; prepare report templates for the supervisory authority; integrate with SOC | Activated IR process with DORA timers | SOC / CISO |
| 2. FOUNDATIONS | Months 3–6 | Review and update contracts with key ICT providers; build ICT Third-Party Register; assess provider risk | DORA-compliant contracts + provider register | Procurement / Legal |
| 3. RESILIENCE | Months 5–9 | Develop and execute digital resilience testing programme; initial BCP/DRP tests; assess TLPT readiness | Test report with results and remediation plan | CISO / Red team |
| 3. RESILIENCE | Months 5–9 | Implement DORA training programme for board and employees; document training | Training certificates/confirmations + ongoing training plan | HR / CISO |
| 3. RESILIENCE | Months 7–12 | Implement exit strategy for critical ICT providers; concentration risk — analysis and mitigation | Documented exit plans for top-5 critical providers | CTO / Procurement |
| CONTINUITY | Ongoing process | Regular ICT framework reviews, cyclical resilience tests, monitoring of regulatory changes (RTS, ITS), board reporting | Evidence of ongoing compliance for supervisory authority | CISO + Board |
Institutions at an earlier stage of implementation should immediately focus on the “DIAGNOSIS” and “FOUNDATIONS” phases — particularly on the incident reporting process, which is the area with the fastest regulatory clock (4 hours for the initial notification). The absence of an effective reporting process at the time an incident occurs constitutes a direct DORA violation, regardless of the status of the remaining requirements.
How does nFlo support financial institutions in preparing for DORA?
I have been working with the financial sector for several years and I can clearly see that implementing DORA is not a project an institution can carry out on its own, overnight, relying solely on internal resources. It requires a combination of regulatory, technical, and organisational competencies that are rarely available in one place.
nFlo supports financial institutions in the area of DORA as an end-to-end partner — from diagnosis through implementation to maintaining ongoing compliance. We have served over 200 clients, completed over 500 projects in the area of cybersecurity and compliance, and 98% of our clients choose to continue cooperation after the first project. Our SOC response time is less than 15 minutes — which is particularly relevant in the context of DORA’s stringent reporting deadlines.
Our offering for the financial sector includes specific services tailored to DORA requirements. DORA Gap Analysis — a comprehensive audit of the institution’s current state against all five pillars of DORA, concluding with a detailed report with gap prioritisation and an implementation roadmap. DORA ICT Risk Framework — assistance in building or updating the ICT risk management framework, creating policies, procedures, and registers compliant with the requirements of the regulation and accompanying RTS. IR Process Support — designing the incident classification and reporting process, preparing report templates for the supervisory authority, integration with an existing SOC or building SOC processes from scratch.
In the area of third-party risk management we offer TPRM Assessment — a review of contracts with key ICT providers against Article 30 DORA requirements, building a provider register, concentration risk assessment, and assistance with contract renegotiation. We also conduct digital resilience testing — from penetration tests through BCP/DRP tests to advanced scenario-based red team exercises, with documentation meeting DORA requirements. We complement this with DORA training — tailored to the role (board, CISO, operational employees) and documented in a way that enables compliance to be demonstrated to the regulator.
Our work does not end at “implementation” — because DORA requires continuity, not one-off actions. We offer managed compliance support models, where nFlo acts as an external CISO or compliance advisor, monitoring regulatory changes (new RTS, ITS, EBA/ESMA/EIOPA guidelines), updating documentation, and supporting preparation for KNF inspections.
If you are a Compliance Manager, CISO, or member of the board of a financial institution and have doubts about exactly where your organisation stands in relation to DORA requirements — call us. The first 90-minute diagnostic meeting is free of charge. From experience, I know that ninety minutes of honest conversation brings more clarity than a month of reading regulatory documents.
Related concepts
Explore related articles in our knowledge base:
- Complete guide to the NIS2 Directive — obligations, penalties, deadlines
- How to conduct a KSC NIS2 readiness audit? A practical guide for CISOs
- ICT third-party risk management — supply chain audit compliant with NIS2
- Compliance automation: How RidgeBot® supports ISO 27001 and NIS2 requirements
- Board liability for cybersecurity under NIS2
Learn more
- Anatomy of a cyberattack on banking — from phishing to advanced frauds
- PCI DSS security — how to protect payment card data
- SOC in every office — demystifying KRI and NIS2 requirements
Check our services
Do you need support with DORA implementation or compliance more broadly? Check out:
- NIS2/DORA Compliance — regulatory compliance for the financial sector
- Security audits — comprehensive assessment of the ICT security posture
- SOC as a Service — 24/7 security monitoring meeting DORA requirements
FAQ — frequently asked questions about DORA
Does DORA also apply to small financial institutions and fintechs without their own IT department?
Yes, DORA applies to all financial institutions listed in Article 2 of the regulation, regardless of size. However, the proportionality principle (Article 4) allows microenterprises and small entities to apply a simplified ICT risk management framework. The simplification relates to the form and level of detail of documentation, not the obligation itself to have ICT risk management processes, incident response, and ICT system security in place. A fintech that has no IT department is not exempt from DORA — it must, however, document how it manages the ICT risk of its external providers.
What are the penalties for non-compliance with DORA?
DORA does not directly specify the monetary amount of penalties for financial institutions — it leaves this to the competent national supervisory authorities (in Poland: the KNF). The KNF, acting on the basis of both DORA and national financial supervision law, may apply the full range of supervisory measures: from recommendations and orders, through the imposition of financial penalties (whose upper limit is determined by national supervisory law), up to the withdrawal of a licence or suspension of operations. For critical external ICT providers (CTPPs), fines may amount to up to 1% of average daily global turnover for each day of violation, for a maximum of 6 months.
When must I conduct the first DORA-compliant TLPT?
The TLPT obligation applies only to institutions designated by the competent supervisory authority as “systemically important.” If the KNF designates your institution as required to conduct TLPT, you will be given a specific deadline for conducting the first test. Tests must take place at least once every three years. If you have not been designated, TLPT is voluntary — but DORA still requires regular digital resilience testing in other forms (penetration tests, BCP/DRP tests). It is advisable to verify your institution’s TLPT status with the KNF.
How does DORA affect contracts with cloud providers (AWS, Azure, Google Cloud)?
DORA requires that contracts with ICT providers supporting critical or important functions contain specific clauses (Article 30). In the case of large cloud providers, two approaches are possible: negotiating standard security agreements (BAA, DPA) to meet DORA requirements, or using dedicated compliance documents that providers such as Microsoft (Azure) and Amazon (AWS) have specifically prepared for DORA. Best practice is to gather all compliance documents from the provider, map them against Article 30 DORA requirements, and document any gaps. If a provider does not cover a particular requirement, the institution must compensate for this with compensating controls on its own side.
Does a financial institution need to hire a new CISO for DORA purposes?
DORA does not require the appointment of a CISO by name, but it imposes obligations that in practice require an equivalent function — a person or unit responsible for ICT risk management, oversight of the resilience testing programme, coordination of incident reporting, and communication with the supervisory authority. Smaller institutions may outsource this function externally (vCISO model). What matters is that regardless of the organisational model, the person or entity fulfilling this role has the appropriate competencies, resources, and management mandate to act effectively.
Sources
- Regulation (EU) 2022/2554 of the European Parliament and of the Council of 14 December 2022 on digital operational resilience for the financial sector (DORA) — Official Journal of the EU L 333/1
- European Banking Authority (EBA) — guidelines and technical standards for DORA: eba.europa.eu
- European Securities and Markets Authority (ESMA) — DORA documentation: esma.europa.eu
- European Insurance and Occupational Pensions Authority (EIOPA) — DORA materials: eiopa.europa.eu
- Polish Financial Supervision Authority (KNF) — communications on DORA implementation in Poland: knf.gov.pl
- TIBER-EU Framework (European Central Bank) — threat-led penetration testing methodology: ecb.europa.eu
- KNF Recommendation D on the management of information technology and ICT security environment in banks — KNF 2013/updated
