Skip to content
Knowledge base Updated: February 5, 2026

DORA vs. the FSA's Recommendation D: How do past implementations help with compliance with the new regulation?

The financial sector has been living under regulatory pressure from the FSA for years. The implementation of Recommendation D and the IT Guidelines was a huge effort. Will this work be in vain in the face of DORA? On the contrary. It's a solid foundation, but DORA raises the bar much higher, especia

For years, the Polish financial sector has been operating in an environment of high regulatory maturity. The Financial Supervisory Commission’s (FSC) IT guidelines and Recommendation D for banks have been the backbone around which security and technology risk management systems have been built over the years. The implementation of these frameworks was a huge, multi-year organizational and financial effort for many institutions, which significantly raised the level of cyber resilience. Today, with the European-wide DORA (Digital Operational Resilience Act) Regulation coming into force, many leaders are asking themselves: will all this work have been in vain?

The answer is: absolutely not. Existing implementations that comply with the FSC guidelines are extremely valuable assets and a solid foundation on which DORA compliance can and should be built. Many key areas, such as the need for a risk management framework, business continuity plans or incident handling procedures, are common to both regimes. However, DORA goes much further in several key aspects, raising the bar and introducing entirely new, more stringent responsibilities. Understanding where the synergies lie, and where there are new gaps to be filled, is a key task for every financial institution in Poland today.

Shortcuts

What has been the regulatory landscape for IT in the Polish financial sector so far (Recommendation D, FSA Guidelines)?

Over the years, the main guideposts for technology and security management in the Polish financial sector have been documents issued by the Financial Supervision Commission. For banks, the key document was Recommendation D, which dealt with the management of information technology areas and the security of the ICT environment. For other entities, such as insurance companies and investment firms, the FSC issued analogous Guidelines on the management of IT and security areas.

These documents, although soft law in nature, were in practice treated as mandatory by the market and supervisor. They introduced a culture of technology risk management into the financial sector, forced boards to pay attention to IT issues, and defined requirements in areas such as business continuity, systems security and incident management. However, they were national documents, and their detail and interpretation could vary.

📚 Read the complete guide: SOC: Security Operations Center - what it is, how it works, how to choose

What is the DORA regulation and what is its overarching purpose in relation to national guidelines?

The DORA (Digital Operational Resilience Act) regulation is a piece of European Union legislation that applies directly and in the same way in all member countries. Its overarching goal is to harmonize and unify digital operational resilience requirements across the European financial sector.

Unlike national recommendations, DORA has the rank of a regulation, which means that its legal force is much stronger. DORA does not completely replace the FSC guidelines, but becomes an overarching framework for them. This means that wherever DORA introduces more stringent or new requirements, they become binding on Polish institutions.

DORA’s main goal is to ensure that the entire European financial system, as a network of interconnected vessels, can survive and function even in the face of a major cross-border cyber attack or ICT failure.

In what areas does the FSC’s implementation to date provide a solid foundation for DORA compliance?

The good news for Polish financial institutions is that years of work to implement the FSC guidelines have not been in vain. Many fundamental concepts are common to both legal regimes.

Organizations that have reliably implemented Recommendation D or the IT Guidelines already have a solid foundation in areas such as:

  • Overall risk management framework: Have policies, procedures and organizational structures in place to manage IT risk.

  • Incident Management: Have basic procedures for identifying, classifying and handling incidents.

  • Business Continuity: Have and test business continuity (BCP) and disaster recovery (DR) plans.

  • Systems security: Implement fundamental technical security such as access control, hardening and network protection.

These existing processes and mechanisms do not need to be built from scratch. They are an excellent starting point, but need to be reviewed, expanded and adapted to the more detailed and rigorous requirements of DORA.

How is DORA revolutionizing third-party (ICT vendor) risk management requirements?

This is one area where DORA goes much further than the FSC’s existing guidelines. The regulation introduces an entire, dedicated chapter on managing risk from third-party ICT service providers.

While the FSC’s guidelines treated the topic more generally, DORA imposes very specific and detailed obligations on financial institutions, including:

  • Have a strategy in place to address risks associated with ICT providers.

  • Maintain a detailed record of information on all vendor contracts, with particular emphasis on those that support critical or essential functions.

  • Conduct in-depth risk assessment (due diligence) before entering into any new contract with an ICT provider.

  • Introducing a series of mandatory, detailed clauses in contracts regarding security, audit rights, data localization and exit strategies, among others.

  • Oversight of the entire sub-supplier chain (so-called “fourth-party risk”).

Moreover, DORA introduces a globally unique mechanism for direct European oversight of critical ICT providers (e.g., major cloud providers).

Comparison of key areas: FSC guidelines vs DORA

Regulatory areaKNF IT Guidelines / Recommendation DDORA Regulation
Third party risk managementGeneral requirements, focused on outsourcing.Very detailed and prescriptive requirements for all ICT suppliers, mandatory contract clauses, oversight of critical suppliers.
Security testingRequire regular penetration testing.Requiring a comprehensive annual testing program. For the largest entities, mandatory advanced TLPT testing every 3 years.
Incident managementDuty to report to the FSC and the FSC CSIRT.Harmonized, multi-stage (24h/72h) system for reporting serious incidents to competent authorities.
Management responsibilityOverall responsibility for oversight of the IT area.Direct, personal and ultimate responsibility for ICT risk management. Mandatory training for board members.

How does the approach to incident classification and reporting differ between DORA and the FSC guidelines?

DORA aims to create a single, pan-European system for reporting major incidents to enable regulators to quickly assess their potential cross-border impact. To this end, it is introducing a harmonized classification and reporting process.

Financial institutions will have to classify all ICT incidents based on uniform criteria defined in the regulation, which take into account the number of affected users, duration, geographic scope and data impact, among other things.

In the event of ** a “major incident,”** DORA imposes a very rigorous, multi-step process for reporting it to the relevant supervisory authority:

  • Initial notification: within 24 hours of the incident being classified as serious.

  • Intermediate report: within 72 hours.

  • Final report: within one month.

This harmonized and demanding calendar aims to ensure that information about potentially systemic risks reaches supervisors across the EU in a timely and consistent manner.

How does DORA raise the profile and direct board responsibility for digital resilience?

One of the most important changes that DORA introduces is that it places ultimate and direct responsibility for managing digital operational resilience on the shoulders of a financial institution’ s governing body (board).

This is no longer a task that can be fully delegated to the IT director or CISO. Under DORA, the board must:

  • Define, approve, oversee and be responsible for the implementation of the ICT risk management framework.

  • Determine ICT risk tolerance.

  • Actively oversee contracts with external ICT providers.

  • Undergo specialized training on a regular basis (at least once a year) to maintain and expand their knowledge of ICT risks and their impact on operations.

This personal responsibility, coupled with the threat of severe penalties, makes cyber security and digital resilience one of the key topics at every board meeting at a financial institution.

How does nFlo support financial institutions in making a smooth transition from the FSC regime to full DORA compliance?

At nFlo, we have unique competencies that allow us to effectively support financial sector institutions in this complex regulatory transition. We understand both the existing realities and requirements of the FSA, as well as the new, broader obligations under DORA.

Our key service is a comprehensive gap analysis (Gap Analysis) between the current state of implementation of the FSA IT Guidelines and the full spectrum of DORA requirements. We map your existing processes, policies and safeguards to the new requirements, precisely identifying areas that need to be expanded, modified or built from scratch. The result is a prioritized roadmap that allows you to effectively plan your adaptation activities.

We actively support in filling identified gaps. We help expand the ICT risk management framework, with a particular focus on third-party risks, assisting in the creation of vendor assessment processes and the preparation of appropriate contractual clauses. Our elite Red Team is ready to perform advanced threat-based penetration testing (TLPT) in accordance with the TIBER-EU framework. As part of vCISO’s services, we also support boards in understanding and implementing their new direct responsibilities, helping to build an effective reporting and oversight system for digital operational resilience.

What transfers and what does not

An institution that implemented Recommendation D enters DORA with genuine assets, but the transfer is uneven. The governance layer carries over well: the technology risk management framework, business continuity plans, incident handling procedures, documented roles and responsibilities. Much of this evidence can be presented largely as it stands, once the terminology is aligned with the regulation.

Two things do not transfer, and they generate most of the new work. The first is the register of contractual arrangements with ICT third-party providers in the form DORA requires — the earlier regime expected supplier risk management, but not this register. The second is testing: DORA mandates a programme with defined frequency and, for financial entities identified by the competent authority, TLPT, which the national guidelines never contemplated. Establishing what already exists and what is missing is the scope of a DORA readiness and compliance audit.

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

  • 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…
  • Backup — Backup, also known as a backup copy or safety copy, is the process of creating…
  • Network Security — Network security is a set of practices, technologies, and strategies aimed at…
  • Cybersecurity — Cybersecurity is a collection of techniques, processes, and practices used to…

Learn More

Explore related articles in our knowledge base:


Explore Our Services

Need cybersecurity support? Check out:


Cybersecurity for Your Industry

Learn more about cybersecurity in your industry:


Share:

Talk to an expert

Have questions about this topic? Get in touch with our specialist.

Sales Representative
Grzegorz Gnych

Grzegorz Gnych

Sales Representative

Response within 24 hours
Free consultation
Individual approach

Providing your phone number will speed up contact.

Want to Reduce IT Risk and Costs?

Book a free consultation - we respond within 24h

Response in 24h Free quote No obligations