Rekomendacja D KNF, Rekomendacja D-SKOK, komunikat chmurowy oraz wytyczne dla ubezpieczycieli i TFI zostały uchylone (m.in. 17 stycznia 2025 r.). Krajowe soft law It has been replaced by binding EU law—the DORA Regulation, which now serves as the primary reference point for banks and financial institutions.
Below, we discuss key operational changes and ways to reconcile the new requirements with the technology backlog.
What happened – the repeal of Recommendation D
By Resolution No. 6/2025, the Polish Financial Supervision Authority (KNF) repealed Recommendation D (issued by Resolution No. 7/2013) with effect from 17 January 2025, i.e. the date on which DORA came into force. On the same day, related guidelines for other types of entities and a notice concerning cloud computing were also withdrawn. The reason is clear: DORA is generally applicable law, whereas the recommendation was a piece of so-called ‘soft law’. Maintaining both simultaneously would have created interpretative uncertainties and a double regulatory burden. It is worth noting that Poland has also adopted a national act implementing DORA, signed by the President on 31 July 2025.
Does that mean the requirements have been scrapped? Quite the opposite
This is the most common misunderstanding. The substance of Recommendation D – IT governance, ICT environment security, risk management, and control over end-user software (such as spreadsheets and databases created by non-programmers) – has not disappeared. It has been incorporated and expanded upon by the ICT risk management framework in DORA. The nature of the requirements has changed, not their direction. And that nature has become more demanding.
What does DORA actually change compared to Recommendation D?
In practice, these differences boil down to three key points. First and foremost, it is a question of the legal status of the provisions themselves. As a result, ‘soft law’ guidelines become a binding legal obligation. Furthermore, non-compliance is punishable by fines of up to 2 per cent of annual turnover.
Another issue is the significantly broader scope of requirements. DORA introduces mandatory digital resilience tests, including the TLPT. Furthermore, it imposes an obligation to maintain a register of ICT suppliers and to provide structured reporting.
The final difference, in turn, is the complete uniformity of the law. DORA applies directly throughout the European Union. It therefore harmonises the rules across existing national legislation.
Where legacy code becomes a problem
The implication is the same as throughout DORA. An undocumented system in Delphi, VB6 or legacy Java EE makes it difficult to demonstrate risk management, carry out testing and provide the documentation that regulators now strictly require. Recommendation D also required documentation and control over the environment, but as ‘soft law’ it was enforced more leniently. DORA leaves no room here for the ‘the system works, so it’s fine’ approach: you must prove that it is managed and resilient.
How to prepare
The good news is that you’re not starting from scratch. Much of the work done under Recommendation D—policies, documentation, risk management—is still valuable and mainly requires mapping to DORA requirements. A sensible approach is to conduct a gap analysis between your current compliance status and DORA, fill in the missing elements, and restore visibility where it’s lacking. We provide support in this area through IT consulting and IT architecture audits. We use S*.doc to reconstruct documentation for legacy systems—ensuring that DORA compliance can be reliably demonstrated, even for legacy stacks.
