The DORA Regulation: What a Financial Entity Actually Has to Do

What DORA is

DORA is Regulation (EU) 2022/2554 of the European Parliament and of the Council of 14 December 2022 on digital operational resilience for the financial sector. The name stands for Digital Operational Resilience Act. It has applied since 17 January 2025.

The premise is straightforward. Finance runs on IT systems and on the suppliers of those systems, so digital resilience stops being an IT department concern and becomes part of financial stability. DORA puts responsibility for it on the management body, which in practice means the board.

The regulation applies directly, but national law still has a job to do: name the supervisor and set the penalties. In Poland that came with the act of 25 June 2025 on digital operational resilience of the financial sector, published on 6 August and in force from 7 August 2025. It is what gives the KNF the concrete inspection and sanctioning powers described below.

Who it covers

The scope is broad and covers essentially the whole supervised financial market. In Poland the supervisor is the KNF. The rules apply to, among others:

• banks and credit institutions
• investment firms and brokerage houses
• insurance and reinsurance undertakings
• payment institutions and e-money institutions
• fund managers and pension funds
• crypto-asset service providers
• third-party ICT providers serving any of the above

That last entry catches people out. DORA reaches beyond the financial sector into the technology suppliers that serve it. If your company provides software or services to banks, the service-level and audit requirements will arrive through contracts whether or not you are a supervised entity yourself.

The five pillars

The requirements are usually grouped into five areas. The split is useful for planning, because each pillar needs different skills.

1. ICT risk management

You need a documented risk management framework: identifying assets and dependencies, protection, detection, response and recovery. Responsibility sits with the management body and cannot be delegated to a supplier. The board is also expected to keep its own knowledge of ICT risk current.

2. Incident reporting

You need a process for detecting, classifying and reporting ICT-related incidents. Classification criteria come from Delegated Regulation (EU) 2024/1772, reporting content and deadlines from Delegated Regulation (EU) 2025/301, and the forms themselves from Implementing Regulation (EU) 2025/302. Deadlines are below.

3. Digital resilience testing

A testing programme is required, covering vulnerability scanning, security testing and scenario-based assessment. Significant entities additionally run threat-led penetration testing, or TLPT, on a three-year cycle. This is the area we cover through security assessments and pen testing.

4. Third-party risk

You need a register of ICT supplier contracts, kept on the templates in Implementing Regulation (EU) 2024/2956, due diligence before signing, and contractual terms on service levels, audit rights, incident notification and exit strategies. Providers designated as critical fall under oversight at European level: the ESAs published the first list on 18 November 2025, covering 19 providers from cloud hyperscalers to telecoms operators. The registers submitted by financial entities are exactly what the criticality assessment was built on.

5. Information sharing

This pillar is voluntary. DORA encourages participation in threat intelligence sharing arrangements between financial entities, subject to data protection and competition rules.

Major incident reporting deadlines

This is the most common question, so here it is concretely. There are three reports, but the clock starts earlier, when you classify the incident as major:

Four hours reads reasonably on paper and very differently at 2am on a Sunday. The hard part in practice is not the form, it is establishing within that window whether the incident even meets the major threshold. Without round-the-clock detection, for example through SOC-as-a-Service, that clock starts running before anyone has noticed the event.

What the single entry point would change

On 19 November 2025 the European Commission proposed the Digital Omnibus package, which includes a single entry point for incident reporting operated by ENISA. One notification would eventually satisfy obligations under DORA, NIS2, the GDPR, the eIDAS Regulation, the CER Directive and the Cyber Resilience Act at once. For a financial entity that files with the KNF through SOID and then separately with the data protection authority over the same event, that is a real simplification.

It is a long way off, though. The AI part of the package was split out and adopted as Regulation (EU) 2026/1744, while the part covering the GDPR, NIS2 and DORA is still in negotiation. The entry point itself is due to go live 18 months after the rules enter into force, extendable by another six months. Until then the existing channels apply and the deadlines in Regulation 2022/2554 stand unchanged. Design your 2026 and 2027 reporting process as though the single entry point did not exist.

What supervisors expect

Poland's KNF runs a dedicated DORA section and, more usefully day to day, operates two separate reporting systems. Confusing them costs hours precisely when there are none to spare:

• Major ICT incidents and significant cyber threats go through the DORA Incident Handling System (SOID) at csirt.knf.gov.pl
• If SOID is unavailable, the report goes to incydenty.dora@knf.gov.pl on the form KNF publishes
• All other DORA reporting, including the ICT supplier contract register, goes through the DORA Reporting System (SSD) at crp.knf.gov.pl
• The full set is expected: initial notification, intermediate report and final report
• The contract register is submitted on a recurring cycle, with each round's deadline announced separately in the DORA news section
• Interpretation questions go to konsultacje.dora@knf.gov.pl
• Smaller entities may use a simplified ICT risk management framework, which does not exempt them from incident reporting

Penalties

This is where the wrong numbers circulate, so take it in order. DORA itself sets no amounts for financial entities: Article 50 requires Member States to provide penalties that are effective, proportionate and dissuasive, and leaves the figures to them. In Poland they sit in Article 18zm of the financial market supervision act, inserted by the act of 25 June 2025: the KNF can impose up to PLN 20,869,500, or up to 10% of the revenue shown in the last approved annual accounts, or up to twice the benefit obtained, and up to PLN 3,042,410 on a board member responsible for the breach.

The supplier side works differently. A critical ICT third-party provider falls under European oversight, and under Article 35(6) the Lead Overseer can impose periodic penalty payments of up to 1% of average daily worldwide turnover in the preceding business year, charged daily for up to six months. It is not a one-off sum, and it has nothing to do with the 5 million euro figure that circulates in industry decks.

In practice a different consequence usually bites harder: supervisory decisions restricting activity or requiring termination of a supplier contract. A fine happens once. Unwinding a core banking contract is a project measured in quarters.

Where to start

If implementation is behind, the order of the work matters more than the pace. The steps below are in the order that returns the most for the least effort, with the function that usually runs each one:

1. Week 1Procurement and IT
   Close out the ICT contract register

   Inspections usually start here, because the register is the only document that shows an entity's dependencies as a whole. Regulation 2024/2956 dictates the fields, and the register goes to the KNF through the DORA Reporting System on a recurring basis. It is also the data the European Supervisory Authorities use to decide which providers are critical.

2. Weeks 1–2Board and CISO
   Name the person who classifies an incident

   The four-hour clock starts at classification, so the name and the deputy have to be settled before the incident, not during it. Settle who decides at 2am on a Saturday and who signs the notification in SOID.

3. Weeks 2–4Legal
   Review contracts with key suppliers

   Four things to check: service levels, audit rights, incident notification duties and the exit strategy. Renegotiation takes months, so start with the contracts behind critical functions rather than the ones that happen to expire first.

4. Quarter 1Security
   Get detection running around the clock

   Without it the deadlines stay theoretical, because an incident noticed on Monday morning fits none of them. If your own team does not work 24/7, SOC-as-a-Service covers it. Extend the monitoring to credentials exposed in infostealer logs as well, since that exposure is ICT risk in the sense of Article 8.

5. Quarters 1–2Security and the board
   Plan the testing programme, and TLPT for significant entities

   The programme covers vulnerability scanning, penetration testing and scenario-based assessments. Advanced TLPT runs on a three-year cycle, needs an external provider and has to be agreed with the supervisor, so the lead time is measured in quarters rather than weeks.

6. OngoingBoard
   Keep ICT risk knowledge current at board level

   The regulation puts this obligation on the management body directly, and it cannot be delegated to a supplier or to the IT department. Where that capability is missing, a virtual CISO closes the gap faster than a year-long recruitment.

DORA and NIS2

Both deal with digital resilience and are often confused. The distinction is simple: DORA is sector-specific law for finance and takes precedence over NIS2 where the two overlap. A financial entity therefore applies DORA rather than NIS2, though groups with activity outside the financial sector can end up under both regimes at once.

Mixing them up has a concrete cost. The 2% of worldwide turnover or 10 million euro ceiling for essential entities comes from NIS2, not DORA. That number keeps turning up in DORA material where it simply does not apply, and it produces risk assessments built on the wrong base. The clocks differ too: NIS2 allows 24 hours for an early warning from becoming aware of an incident, DORA 4 hours from classification. Where a group also operates outside finance, that second track runs off the Polish Cybersecurity Act — who it covers and on what deadlines is in our separate piece on NIS2 and the Cybersecurity Act.

Frequently asked questions

Conclusion

DORA introduces no technical requirement any security team would find unfamiliar. What is new is that it assigns those requirements to named people, sets deadlines measured in hours, and attaches penalties. The biggest gaps we see are not technical. They are about who makes the classification call at 2am on a Saturday.

The four-hour clock starts when you classify the incident. The catch is that somebody has to notice it first.