DORA for the Financial Sector — Practical Implementation Step by Step (2026)

DORA entered into force on 17 January 2025. I speak every day with CEOs of cooperative banks, fintechs, insurers and investment firms in Poland. After a year of the regulation being in force, in 70% of conversations I still hear the same thing: “We know we have to, we have part of the things, but we don’t know how to tie it all together.” This article is for boards and people responsible for compliance who need a concrete action plan — not yet another academic presentation about the five pillars.

At nFlo, we have been supporting financial entities in DORA implementations since the publication of the first RTS (Regulatory Technical Standards) in Q2 2024. We have completed 30+ DORA readiness audits and we are running 8 active implementations. What I write here is a distillation of these experiences — what really works, where companies stumble, how much it costs and what KNF expects.

TL;DR — DORA in 60 seconds for the board

• What it is: Digital Operational Resilience Act, EU regulation 2022/2554, in force since 17 January 2025, directly (without transposition into national law).
• Who it covers: practically all financial entities (banks, insurers, fintechs, TFI, brokerage houses, CASP) plus critical ICT providers for this sector (subject to separate ESA oversight).
• 5 pillars: ICT risk management, incident reporting (4h for major incidents), digital operational resilience testing (including TLPT once every 3 years), third-party risk management, information sharing.
• Penalties: up to 10% of annual turnover, plus personal liability of board members up to 1% of turnover.
• Practical truth: most firms think they are compliant because they have ISO 27001 + BCP. That covers 60–70% of DORA. The rest (TLPT, third-party SLA, incident reporting to KNF) needs to be built separately.

Where DORA came from and why it is different from earlier regulations

The first thing that surprises firms: DORA did not appear “out of thin air”. It emerged in response to specific, documented events that demonstrated that the EU financial sector was unprepared for serious ICT incidents.

In the years 2018–2022 we had a series of incidents in the EU that hit financial stability: the TSB Bank outage (2018, customers without access to accounts for weeks, FCA fine of GBP 48M), the ransomware attack on Banco BCR in Costa Rica (2020, impact on European fintechs through providers), the Kaseya VSA attack (2021, more than 1500 firms affected, including European cooperative banks), and finally the compromise of Microsoft Exchange (HAFNIUM, 2021). The common conclusion of regulators was: existing regulations (PSD2 for payments, MiFID II for markets, local EBA guidelines) do not systemically cover cyber resilience.

DORA is a regulation (not a directive like NIS2), which means two key practical effects:

1. Direct applicability — it does not require transposition into Polish law. It applies directly, just like, for example, GDPR. If KNF in Poland issues guidelines, they are clarifications of DORA, not modifications of it.
2. Lex specialis for the financial sector — DORA excludes the application of NIS2 for financial entities. A bank that until now analysed whether it should classify itself as an “essential entity” in NIS2 now has a clear situation: it applies DORA.

The second thing that surprises: DORA introduces oversight of critical ICT providers. For the first time in EU history a financial regulator (ESA — EBA, ESMA, EIOPA) has powers directly over a cloud provider (e.g. AWS, Microsoft Azure, Google Cloud), if that provider supports critical services for the financial sector. This changes the balance of power on the market — large cloud providers can no longer use standard SaaS contracts for banking.

DORA’s 5 pillars — what they actually mean in practice

Pillar 1: ICT Risk Management Framework

This is the foundation and the first area where firms most often think “we have it” — because they have ISO 27001 or some security policies. DORA, however, requires specific elements that ISO 27001 does not directly enforce:

• Digital resilience strategy approved by the board — not a security policy, but a strategy. It must have business objectives (RTO, RPO at the level of business services), development directions, budget allocation. Annual updates are required.
• Classification of critical business functions and the ICT systems supporting them — a formal map linking “business service” (e.g. executing a transfer) with “ICT systems” (core banking, domestic payment system, card system). This is crucial because everything else (BCP, incident response, testing) follows from this classification.
• Board responsibility — DORA explicitly states that the board bears ultimate responsibility for ICT risk management. It cannot be delegated to the CIO or CISO. In practice, KNF expects minutes from board meetings where ICT risk is discussed once a quarter.
• BCP and DRP tested regularly — at least once a year for critical systems, scenarios covering cyber attacks (not only hardware failures).

The most common gap we see in audits: firms have policies but they don’t have operational evidence (board minutes, DR test reports, evidence that the classification is being updated). KNF in the first inspections (Q1-Q2 2026) focused precisely on evidence, not on the documents themselves.

Pillar 2: ICT Incident Reporting

This is the pillar that makes the biggest operational impression because it introduces hard deadlines towards the regulator:

• Early notification: 4 hours from detection of a major incident.
• Intermediate report: 72 hours from the beginning of the incident.
• Final report: 1 month after closure.

What does “major incident” mean? DORA defines it through threshold criteria — among others, the number of affected clients, the value of transactions, the length of the outage, reputational impact, impact on other entities (contagion). Full classification in Commission Delegated Regulation (EU) 2024/1772.

Operationally: 4 hours is very little. If an incident occurs on Friday at 18:00 and your team is “8/5” — you will not make it. This requires:

1. 24/7 monitoring (MDR or own SOC) with a team authorised to take classification decisions.
2. Pre-authorised escalation matrix — who, to whom, in what mode, with what mandate. There is no time to wake up the CEO and board to approve sending a form to KNF.
3. Ready report templates — EBA/ESMA forms are detailed, filling them under time pressure is realistic only if we have templates and a trained person.
4. Incident reporting drill once every six months — simulation of a major incident, full cycle, measuring response time.

At nFlo we see that firms often have technology (EDR/XDR) but they don’t have a reporting process. This is the gap that is cheapest to close (a few weeks of work + one drill).

Pillar 3: Digital Operational Resilience Testing

The testing pillar consists of two levels:

Level 1 — mandatory tests for everyone:

• Vulnerability assessments — at least once a year.
• Open-source analysis — if you use open source in critical systems (and you do).
• Network security assessments — tests of network infrastructure.
• Source code reviews — for custom-developed software.
• Scenario-based testing — simulations of incidents (cyber attack, provider outage, human error).
• Performance testing, end-to-end testing.

Level 2 — TLPT (Threat-Led Penetration Testing) — mandatory for selected entities (usually larger banks, insurers, capital market infrastructure) once every 3 years:

TLPT is not a standard pentest. These are simulated APT (advanced persistent threat) attacks carried out by certified teams (Red Team), in production (not in a test environment), using real Threat Intelligence on specific groups attacking the financial sector. Methodology: TIBER-EU (Threat Intelligence-Based Ethical Red-teaming) — EBA issued guidelines (regulatorily TLPT must be aligned with TIBER-EU).

Practically:

• Cost of TLPT: PLN 200–400k per cycle (3-year interval).
• Duration: 6–9 months (3 phases: threat intelligence → red team → purple team / reporting).
• Requires board engagement — TLPT is “white-box” only for a narrow group (CISO + 2-3 people), the rest of the IT team does not know about the tests (testing reaction “as if real”).

In Poland, there are about 12–15 certified TLPT providers compliant with TIBER-EU (the market is growing strongly, KNF maintains a list). At nFlo we do not directly provide TLPT (conflict of interest with the MDR we provide), but we cooperate with 3 certified partners and coordinate the whole process for clients.

Pillar 4: ICT Third-Party Risk Management

This is the pillar that most changes the daily life of firms, because it touches all contracts with ICT providers — from large cloud providers to providers of niche applications.

DORA requirements in brief:

• Register of information on contracts — full map of all ICT providers, classification of criticality, exposure to risk, country/jurisdiction, sub-outsourcing chains.
• Pre-contract due diligence — assessment of the provider before signing a contract (security posture, financial stability, compliance, dependencies).
• DORA-compliant contractual clauses — DORA precisely lists what must be in a contract with a critical ICT provider: SLA, audit rights, exit clauses, sub-outsourcing rules, security obligations.
• Concentration risk assessment — if all critical systems are hosted in one AWS cloud in one region, you have concentration risk and you must have a diversification or exit plan.
• Exit strategies — for each critical provider a realistic migration plan, if the provider goes down / is switched off / breaches the contract. The plan must be tested.

The hardest thing in practice: renegotiation of existing contracts. Standard T&Cs of cloud providers (pre-DORA) did not contain clauses required by DORA. Most banks in 2025–2026 spent months negotiating with AWS, Microsoft, Google on contract addenda (Financial Services Addendum, FSA). For smaller providers it is necessary to renegotiate directly. Some refuse — then the financial entity must consider changing the provider.

Pillar 5: Information and Intelligence Sharing

Pillar 5 is voluntary but recommended. DORA creates a legal framework for the exchange of threat information between financial entities (e.g. through ISACs — Information Sharing and Analysis Centers). In Poland we have FinCERT at ZBP (Polish Bank Association) and several sector initiatives.

Most conversations with boards skip this pillar — and wrongly so, because active participation in an ISAC gives 2 specific benefits: (1) early detection of campaigns attacking the sector (if they attack someone else the day before you, you have IOCs), (2) the regulator sees activity as an element of “operational resilience culture” and treats it more leniently in inspections.

DORA implementation roadmap — 90 days from zero to compliance

Realistically, a full DORA implementation from zero takes 6–12 months. But in 90 days you can bring a firm to a “passable” state, in which we have a plan, key gaps addressed, and we are able to respond to a regulator during an inspection. Here is the roadmap:

Days 1–14: Readiness audit and gap analysis

• Kickoff meeting with the board — alignment on scope, deadlines, budget, decision-making authority.
• Inventory of existing artefacts: policies, certifications (ISO 27001, ISO 22301), results of internal/external audits, BCP reports, provider registers, incident response documentation.
• Gap analysis against the 5 DORA pillars — checklist of 150+ questions, each item with status (compliant / partial / gap), priority (P1 P2 P3), estimation of cost/time to close.
• Output of day 14: gap analysis report for the board, draft roadmap for 90/180/365 days.

Days 15–45: Quick wins and foundations

• Pillar 2 — Incident Reporting: build escalation matrix, ready EBA/ESMA report templates, organise the first drill (simulation of a major incident).
• Pillar 1 — Risk Management: update the ICT risk policy to DORA-specific requirements, formalise the classification of critical business functions, establish quarterly board review.
• Pillar 4 — Third-Party: begin inventory of ICT providers (if no register exists yet). Classification of criticality. Identification of concentration risk.
• MDR/SOC 24/7 — if you don’t have one, launch it on an urgent basis (4-week go-live with an MDR partner, e.g. nFlo). Without 24/7 monitoring there is no chance to meet the 4h incident reporting deadline.

Days 46–75: TLPT, third-party negotiation, deeper testing

• Pillar 3 — Testing: plan TLPT (if applicable), select a provider (TIBER-EU certified). Carry out vulnerability assessment + scenario-based testing for critical systems.
• Pillar 4 — Negotiation: start talks with the TOP 5 critical ICT providers on DORA-compliant clauses. Cloud providers (AWS/Azure/GCP) have ready FSAs, sign them. Smaller providers — individual negotiations, partly forced by contract changes.
• Pillar 1 — BCP: full DR test for critical systems (if not done in the last 12 months). The scenario includes a cyber attack (e.g. ransomware), not only a hardware failure.

Days 76–90: Drill, documentation, readiness for inspection

• Full-scope incident drill — simulation of a major incident, the whole cycle measured: detection → triage → escalation → reporting to KNF → containment → recovery → lessons learned. If the reporting time is >4h, we identify the bottleneck and fix it.
• Operational documentation — runbooks, procedures, ARTPC (Application/Resource/Threat/Protection/Control matrix), evidence pack for the regulator (folders with evidence that each DORA requirement is met + operational evidence, not just policy).
• Training for management — 4-hour workshop for the board: what are their personal obligations under DORA, what does incident escalation look like, what do they sign (quarterly reports), what questions to ask the CISO each quarter.
• Day 90 deliverable: status report for the board — what is done, what is partial, what is outstanding, what further 90-day plan.

The most common mistakes in DORA implementations that we see

From 30+ readiness audits in Poland in 2025–2026, we have a list of recurring mistakes. I list them because it is easier to avoid them than to fix them:

1. “We have ISO 27001, so we are DORA-ready” — ISO 27001:2022 covers ~60–70% of DORA. The remaining 30–40% are specific, measurable requirements (4h incident reporting, TLPT, third-party SLA, classification per business service) that ISO does not enforce.

2. Outdated ICT provider register — firms have a register “from the last audit 18 months ago”. In the meantime there have been 20+ new SaaS integrations, nobody knows who connected what. The first KNF inspection will trip up on this.

3. No 24/7 monitoring and incident response capability — they think that the SLA with the hosting provider is enough. It is not enough. DORA requires the financial entity to have its own detection + response capabilities (or a contracted MDR with a specific SLA).

4. Inconsistent contractual clauses — different ICT providers have different clauses, no standard in the organisation. DORA requires consistency.

5. No operational evidence — there are policies, but no evidence of execution. The policy says “quarterly board review” — there are no minutes. The policy says “DR test once a year” — the last one was 2 years ago.

6. Concentration risk ignored — everything in AWS Frankfurt, one region. DORA requires assessment of concentration risk and a mitigation plan. KNF is particularly sensitive to this.

7. TLPT outsourced to a non-TIBER-EU certified partner — TLPT must be TIBER-EU compliant. A standard pentest, even well executed, does not meet the DORA requirement.

8. No board training — the board does not know it has personal responsibility. First KNF inspection, question to the CFO “when did the board last review ICT risk?” — and there is no answer.

9. No incident reporting drill — the EBA form filled in for the first time only during a real incident — a guarantee that we will not make it in 4h.

10. Cloud exit strategies only on paper — there is a plan “migration to another cloud in 6 months”, but it has never been tested. KNF increasingly asks about the realism of the exit strategy.

What it actually costs — cases from the Polish market

For the board the most important question is: how much budget to plan. Below are three examples (generalised, based on our projects):

Case A: Cooperative bank (60 people, 1 branch, several thousand retail clients)

• Starting point: ISO 27001 implemented in 2020, no SOC, policies partially updated, single core banking provider (critical concentration risk), no TLPT (not mandatory for cooperative banks <X PLN bn in assets).
• Implementation: 4 months, PLN 350k CAPEX (gap closure, documentation, MDR setup), PLN 280k OPEX annually (MDR with partner, internal audits).
• Does not cover: TLPT (not mandatory), second cloud provider (we considered concentration risk as acceptable with an exit plan).

Case B: Fintech payment institution (130 people, B2C clients, payment processing)

• Starting point: ISO 27001 + SOC 2 Type II, own security team of 4 people (8/5), AWS multi-region, no third-party risk register, no DORA-compliant contracts.
• Implementation: 7 months, PLN 1.1M CAPEX (TLPT first cycle PLN 280k, contract renegotiation, gap closure, MDR upgrade to 24/7), PLN 650k OPEX annually (MDR 24/7, threat intel, audits).
• Covers: TLPT (mandatory due to scale), full third-party DORA-compliance, advanced incident drill programme.

Case C: Mid-size commercial bank (1200 people, corporate + retail clients)

• Starting point: mature security programme, own SOC 8/5 + MDR partner, vendors >300, complex core banking landscape (legacy + hybrid cloud).
• Implementation: 11 months, PLN 6.5M CAPEX (TLPT, deep third-party remediation, core banking gap closure, regulatory project management), PLN 2.2M OPEX annually (MDR upgrade, threat intel subscriptions, continuous audits).
• Specifics: focus on third-party (>300 providers to reorganise) and exit strategies for 8 critical cloud services.

What to do from Monday — 5 concrete steps

If this article reached you and you still don’t have full DORA compliance, here is what to do in the first week:

1. 4-hour audit with a partner experienced in DORA (e.g. nFlo) — rigid methodology, output: gap analysis with priorities and budget estimation.
2. Convene the board — a dedicated meeting devoted to DORA, presentation of the gap analysis, decision on budget and timeline.
3. Appoint a DORA Lead — one person responsible for coordination (usually the CISO or Compliance Officer), with mandate and budget.
4. Quick win — incident reporting drill — the first one within 30 days. Do not wait for full readiness. Run a drill even with flaws — and learn from it.
5. Engage MDR/SOC 24/7 — if you don’t have one, start talks. Full deployment 4–8 weeks. This is the singular bottleneck — without 24/7 monitoring there is no DORA compliance.

DORA requires in art. 26–27 so-called TLPT (Threat-Led Penetration Testing) — at least once every 3 years. The most effective way to deliver this is through penetration testing carried out in a model close to real attacker scenarios (TIBER-EU). In parallel, for entities without a dedicated in-house CISO, the vCISO model allows continuity of the oversight role and accountability for DORA in communication with the regulator. DORA is also strongly correlated with NIS2 requirements — many controls (governance, incident reporting, third-party risk) are shared, so it is worth implementing them in a single stream.

At nFlo we run DORA gap analyses in 2 weeks and full implementations in 4–9 months depending on scale. If you are planning this in 2026, contact us or check our SOC 24/7 service, which is the foundation of DORA compliance in the areas of detection, incident response and reporting.

Related nFlo services

• SOC 24/7 — 24/7 monitoring + incident response with SLA <15 min, foundation of DORA compliance
• Security audits — DORA gap analysis, ISO 27001 / 22301, NIS2 readiness
• Penetration testing — TLPT aligned with DORA art. 26–27 (required every 3 years)
• vCISO — DORA oversight function for entities without in-house CISO
• NIS2 compliance — shared DORA+NIS2 controls (governance, incident reporting, third-party risk)
• Incident Response — 24/7 retainer, drill programme, DORA-compliant reporting

Related articles from the knowledge base

• XDR vs EDR vs MDR — complete comparison 2026
• ISO 27001 vs 22301 — complete guide
• ISO 27001 standard — requirements and benefits of implementation
• ICT supply chain security — vendor audit NIS2