The DORA Regulation (Digital Operational Resilience Act) has been in force for more than fourteen months — and a significant part of the Polish financial sector still treats it as a distant problem. Meanwhile, the European supervisory authorities have already completed their work on the regulatory technical standards (RTS), the Polish Financial Supervision Authority (KNF) is stepping up its inspection activity, and the first wave of major ICT incident reports is reaching supervisors in a new, harmonised format.
This guide sets out DORA's requirements in a way that supports concrete action — without unnecessary legal jargon, but with the precision a regulation of this weight demands.
What DORA is and why it changes the approach to ICT risk
Regulation (EU) 2022/2554 of the European Parliament and of the Council of 14 December 2022 — DORA for short — is the first regulation in the history of the European Union to govern the digital operational resilience of the financial sector comprehensively. Not a directive requiring transposition, but a regulation applying directly in all Member States since 17 January 2025.
Until now, the digital resilience of financial institutions was regulated piecemeal: EBA guidelines on ICT risk management, KNF recommendations (Recommendation D in particular) and EIOPA outsourcing requirements for the insurance sector. DORA replaces that patchwork with a single framework covering banks, insurers, investment funds, payment institutions, crypto-asset service providers and — importantly — critical ICT service providers to the financial sector.
The difference between DORA and earlier rules is fundamental: DORA does not stop at requiring "appropriate measures". It defines specific processes, reporting deadlines, testing methods and a framework for supervising third-party providers. This is a shift from general principles to detailed operational requirements.
Who DORA applies to — the full list of entities
DORA's scope is broader than many market participants assumed. The Regulation covers twenty-one categories of financial entity:
Entities covered by DORA
Credit institutions (banks), payment institutions, electronic money institutions, investment firms, crypto-asset service providers, central securities depositories, central counterparties (CCPs), trading venues, trade repositories, alternative investment fund managers (AIFMs), UCITS management companies, insurance and reinsurance undertakings, insurance and reinsurance intermediaries, institutions for occupational retirement provision, credit rating agencies, benchmark administrators, crowdfunding service providers, securitisation special purpose entities and — the key category — critical ICT third-party service providers (CTPPs).
The proportionality criterion
Unlike NIS-2, DORA does not apply a simple size criterion (50 employees / EUR 10 million turnover). Instead it introduces a proportionality principle: the extent of the requirements depends on the entity's size, risk profile, and the nature and complexity of the services it provides. Financial microenterprises are subject to a simplified ICT risk management regime, but they are not exempt from incident reporting obligations.
The five pillars of DORA — the architecture of digital resilience
DORA rests on five interlocking pillars. Each translates into concrete obligations that financial institutions must implement and maintain.
Pillar 1: ICT risk management (Articles 5–16)
The foundation of the whole structure. A financial institution must have a comprehensive ICT risk management framework covering: a digital operational resilience strategy approved by the management body, policies and procedures for protecting information assets and ICT assets, mechanisms for detecting anomalies and incidents, response and recovery plans for disruptions, and crisis communication programmes.
The management body — the management board and the supervisory board — bears ultimate responsibility for ICT risk management. This is not a formality: Article 5(2) DORA states unambiguously that members of the management body must have sufficient knowledge and skills to understand and assess ICT risk and its impact on the entity's operations. The obligation includes regular training, tailored to the entity's ICT risk.
Pillar 2: ICT incident management and reporting (Articles 17–23)
DORA introduces a harmonised incident management and reporting process which, in Polish conditions, means reporting major ICT incidents to the Polish Financial Supervision Authority:
Initial notification — within 4 hours of classifying an incident as major (and no later than 24 hours from detection). This is the shortest reporting deadline in any European cybersecurity regulation — by comparison, NIS-2 allows 24 hours and GDPR 72 hours.
Intermediate report — within 72 hours of the initial notification. It contains an update on the incident's status, a preliminary impact assessment and the remedial measures taken.
Final report — within 1 month of the initial notification. A full root cause analysis, a detailed description of the impact on operations and customers, and the corrective measures taken and planned.
An incident is classified as major on the basis of criteria set out in the RTS — among them the number of customers affected, the duration of the disruption, the geographical spread, and the impact on data and financial transactions.
Pillar 3: Digital operational resilience testing (Articles 24–27)
DORA requires regular testing of ICT systems — but distinguishes two levels of testing:
Basic testing — mandatory for all entities. It covers: vulnerability assessments, network security testing, gap analysis of software, source code reviews (where feasible), performance testing and penetration testing.
Advanced threat-led penetration testing (TLPT) — mandatory only for entities identified by the supervisory authorities on the basis of their risk profile. TLPT is testing modelled on real-world threats, conducted in line with the TIBER-EU framework. It is carried out every three years by independent testers holding the relevant certifications. This is the highest level of testing the Regulation provides for — and the most expensive.
The key principle: testing must be carried out by independent parties — internal or external, but free from conflicts of interest. For TLPT, an external tester is required.
Pillar 4: ICT third-party risk management (Articles 28–44)
This is the pillar that has generated the most market debate. DORA requires financial institutions to manage risks associated with external ICT service providers comprehensively:
Register of contracts: every institution must keep and maintain an up-to-date register of all contracts with ICT providers, split between services supporting critical functions and the rest.
Pre-contractual risk assessment: before entrusting a critical function to an external provider, the institution must assess concentration risk (whether it is becoming too dependent on a single provider), substitutability (whether the provider can be replaced without disruption) and the location of data processing.
Contractual clauses: DORA requires specific provisions in contracts with ICT providers — among them audit and inspection rights, an obligation to report incidents, termination conditions and an exit strategy. These are not "nice to haves" — the absence of a required clause is a breach of the Regulation.
The CTPP oversight framework: DORA's most innovative element. Critical ICT third-party service providers (for example, large cloud firms serving many financial institutions) are subject to direct oversight by the European Supervisory Authorities (ESAs). This is the first time non-financial entities have been placed under financial supervision — solely because of the systemic risk their failure could cause.
Pillar 5: Information sharing on threats (Article 45)
The fifth pillar encourages — though it does not strictly require — participation in threat intelligence sharing arrangements. Financial institutions may exchange information with one another on the tactics, techniques and procedures (TTPs) used by attackers, indicators of compromise (IoCs) and information on vulnerabilities.
In practice this means the option of creating or joining sector information-sharing groups, similar to the ISACs (Information Sharing and Analysis Centers) operating in the United States. In Poland, that role may be played by the Cybersecurity Forum at Związek Banków Polskich (the Polish Bank Association).
DORA and NIS-2 — the key differences
The relationship between DORA and NIS-2 is one of the most common sources of confusion among financial institutions. Let us set it out precisely.
DORA is sector-specific legislation (lex specialis) in relation to the NIS-2 Directive. Article 4 of the DORA Regulation states unambiguously that where DORA conflicts with national rules transposing NIS-2, DORA prevails. In practice this means:
Incident reporting: a financial institution reports ICT incidents to KNF under the DORA schedule (4h/72h/1 month), not to a CSIRT under the NIS-2 schedule (24h/72h/30 days). One reporting channel, one supervisory authority.
Testing: the institution applies DORA's testing framework (including TLPT), not NIS-2's general security testing requirements.
Third-party management: DORA's requirements for ICT providers are far more detailed than those in NIS-2 — and it is DORA that binds the financial sector.
Note: DORA does not remove the obligation to register in the list of essential or important entities under the amended act on the national cybersecurity system. If a financial institution meets the NIS-2 criteria for essential entities, it must register — but for operational requirements it applies DORA.
For the full picture of obligations on the Polish side, see our guide to NIS-2 and the KSC Act.
Penalties and sanctions — the cost of non-compliance
DORA does not itself set fine amounts — it delegates that to national regulators. In Poland, the supervisory authority for most financial entities is the Polish Financial Supervision Authority, which has a wide arsenal of sanctions available under the Act on Financial Market Supervision and the sectoral statutes.
In practice, sanctions may include: orders to cease the infringement, a temporary ban on holding management functions, financial penalties — whose upper limit depends on the sector (for banks it follows from the Banking Law Act, for investment firms from the Act on Trading in Financial Instruments) — and public disclosure of the infringement and the sanction imposed.
Importantly, DORA requires Member States to ensure that penalties are "effective, proportionate and dissuasive". Given KNF's practice to date — it does not shy away from imposing substantial financial penalties — financial institutions should treat DORA compliance with the utmost seriousness.
Regulatory technical standards — the details that matter
The European Supervisory Authorities (EBA, EIOPA and ESMA) have developed a package of regulatory technical standards (RTS) and implementing technical standards (ITS) that give detail to DORA's requirements:
RTS on ICT risk management — detailed requirements on ICT security policies, identity and access management, change management, ICT business continuity management, data encryption and network security.
RTS on the classification of ICT incidents — criteria for classifying major ICT incidents and significant cyber threats, materiality thresholds (number of customers, duration, impact on transactions) and the reporting format.
RTS on TLPT — requirements for testers, the scope of testing, how results are reported and the role of the threat intelligence team.
RTS on ICT providers — the elements of the register of information on provider contracts, criteria for identifying critical providers and the scope of reporting on subcontracting.
All the RTS and ITS entered into force alongside DORA or during the first months of 2025. Institutions that implemented DORA "at a general level" now face the task of aligning with the detailed requirements of the technical standards.
DORA and ISO 27001 — how much you already have and how much you still need
A financial institution with a certified ISMS in place under ISO 27001:2022 has a solid starting point — but not full DORA compliance. Here is the coverage map:
What ISO 27001 covers: risk management (clause 6.1 plus Annex A), incident management (A.5.24–5.28), business continuity management (A.5.29–5.30), supplier security (A.5.19–5.23), access control and cryptography (A.8) and network security (A.8.20–8.22).
What ISO 27001 does not cover: incident reporting under the DORA schedule (4h/72h/1 month) in the required format, the register of ICT provider contracts in the format required by the RTS, threat-led penetration testing (TLPT), the specific requirements on exit strategies for provider contracts, and the oversight framework for critical ICT providers (CTPPs) — although that is the supervisor's obligation, the institution must cooperate with it.
We estimate that ISO 27001 covers 60–70% of DORA's requirements in the area of ICT risk management. The remaining 30–40% consists of requirements specific to the financial sector that cannot be met with general information security controls.
If you are only just starting to build your system, the place to begin is our guide to implementing ISO 27001.
How to prepare — an action plan for 2026
DORA has applied since 17 January 2025. If your institution has not yet reached full compliance, every month of delay increases both regulatory and operational risk. We suggest a three-step approach:
Step 1: Gap analysis
Compare the current state against DORA's requirements and the relevant RTS and ITS. This covers: a review of the ICT risk management framework, an assessment of incident reporting capability (can the institution meet the 4-hour requirement?), an inventory of ICT provider contracts, a review of the security testing programme, and an assessment of how ready the documentation is for a KNF inspection.
Step 2: Priority implementation
On the basis of the gap analysis, implement the missing elements in order of priority. The highest priority goes to: the incident reporting process (because a 4-hour deadline leaves no room for improvisation), the register of ICT provider contracts (because KNF may ask for it at any moment) and the ICT risk management framework approved by the management board (because it is the foundation on which everything else rests).
Step 3: Testing and improvement
Carry out penetration testing and business continuity testing, verify the incident reporting procedures through simulation, review the contractual clauses with critical providers, and hold a management review involving the management body. For institutions designated for TLPT, plan and budget for advanced testing (cost: from several hundred thousand zloty upwards).
Frequently asked questions about DORA
Does DORA apply to small cooperative banks?
Yes. DORA covers all credit institutions, regardless of size. Cooperative banks are, however, subject to the proportionality principle — the extent of the requirements is adjusted to their risk profile, the scale of their business and the complexity of their services. In practice this means a simplified ICT risk management framework, but full incident reporting obligations.
Does DORA apply to fintechs and payment service providers?
Yes. Payment institutions, electronic money institutions and crypto-asset service providers licensed under MiCA are subject to DORA on the same footing as banks. For many fintechs that have until now operated under a relatively light regulatory regime, DORA represents a fundamental change.
Does my IT company, which serves banks, fall under DORA?
If your company is a critical ICT service provider to financial institutions, then potentially yes. The European supervisory authorities identify critical providers (CTPPs) on the basis of criteria set out in DORA (Article 31) — among them the systemic importance of the services, the degree of concentration and substitutability. CTPPs are subject to direct oversight by the ESAs. Regardless of CTPP status, your financial clients will require you to meet the contractual clauses arising from DORA — the domino effect through the supply chain.
How does DORA incident reporting differ from GDPR?
DORA and GDPR are two separate reporting regimes. DORA requires every major ICT incident to be reported to KNF, whether or not it concerns personal data. GDPR requires a personal data breach to be reported to the President of UODO — but only where the incident involves personal data. As for deadlines: DORA allows 4 hours for the initial notification, GDPR 72 hours. A ransomware attack on a banking system that disrupts services and encrypts customer data falls under both regimes at once — separate notifications to KNF and to the President of UODO.
Does holding an ISO 27001 certificate exempt me from DORA?
No. ISO 27001 is not a substitute for DORA. It is, however, a solid foundation — an institution with an ISO 27001-compliant ISMS in place has 60–70% of DORA's ICT risk management requirements covered. The remaining requirements (reporting on the 4-hour schedule, the provider register, TLPT and contractual clauses) call for additional work.
What is TLPT and does my institution have to carry it out?
TLPT (threat-led penetration testing) is an advanced form of security testing based on real threat scenarios and conducted in line with the TIBER-EU framework. It is mandatory only for entities designated by the supervisory authority — typically large banks, insurers and financial market infrastructure. TLPT usually costs several hundred thousand zloty and takes 3–6 months to complete. Smaller institutions carry out "ordinary" penetration tests, which also satisfies DORA's requirements.
What is the status of DORA implementation in Poland as at March 2026?
DORA has applied directly since 17 January 2025 and requires no transposition. KNF has published guidance on ICT incident reporting and is consulting the sector on identifying entities subject to TLPT. Work is also under way to align national sectoral legislation (the Banking Law Act, the Act on Trading in Financial Instruments) with DORA's requirements on sanctions.
How Fib.Code can help with DORA
For more than six years the Fib.Code team has supported organisations in implementing information security management systems — including financial sector institutions that must meet DORA, NIS-2 and GDPR requirements simultaneously. We have delivered over 500 projects covering ISO 27001 implementations, security audits, the design of incident management processes and the outsourcing of security functions.
As part of our DORA compliance implementation for the financial sector we offer: gap analysis — an assessment of compliance with the Regulation and with the RTS and ITS technical standards; implementation or extension of the ICT risk management framework; design of an incident reporting process on the 4h/72h/1 month schedule; an inventory and review of ICT provider contracts against the required clauses; penetration testing and vulnerability analysis; training on ICT risk for the management board and senior management; and ongoing support as an external adviser on digital operational resilience.
Every project starts with a conversation, not with a proposal. We would be glad to talk about what DORA means specifically for your institution.
Book a free consultation: l.grabowski@fibcode.com | fibcode.com
This article reflects the state of the law as at 14 March 2026. The DORA Regulation (EU) 2022/2554 has applied directly since 17 January 2025.
