DORA’s First Year: From Paper To Practice

"Help, the website portal has been down for four hours already!"

For many organisations, including asset or fund managers, this is unfortunately not a theoretical scenario. It is a realistic incident that impacts participants and clients, entails reputational risks and triggers a notification obligation towards the supervisory authority. One year after the entry into force of DORA, the key question therefore arises: are we compliant, or are we truly ‘in control’? 

From implementation to permanent in-control 

On 17 January 2025, the Digital Operational Resilience Act (DORA) entered into force, by various underlying Regulatory Technical Standards (RTS) throughout 2025. Many financial institutions used this periodto implement these requirements. By now, policies and procedures are largely in place and compliant – but is that sufficient? 

Supervisory authorities are clearly shifting their focus from “is it designed?” to “does it actually work?”. This is evident in licence applications and  assessments of board members. DORA itself also places strong emphasis on execution, for example through requirements for ongoing due diligence, periodic ICT risk assessments and structured testing programmes. 

The implementation phase is therefore largely behind us. What follows is a shift from paper to practice – not only for the business (first line), but also for the second line (compliance and risk). 

How does structural control work in practice? 

An example from the DORA pillar ICT Risk Management: 

In the figure above, the left-hand column shows a DORA requirement from the ICT Risk Framework. This framework defines, among other things, the risk taxonomy used, impact and likelihood definitions and the organisation’s risk appetite. Based on this framework, the risk assessment is performed. 

However, the risk assessment is not an end point. It leads to a concrete outcome: does the identified risk fall within or outside the organisation’s risk appetite? As the management body is ultimately responsible for the organisation as a whole, it must be informed of these risks. DORA also requires that risks outside the risk appetite are formally accepted by the management body. The minutes of the management meeting in which this acceptance takes place then serve as evidence of operating effectiveness. 

Being compliant means being able to demonstrate that the formal requirements of DORA are met. Policy documents and procedures, such as an information security policy and an incident management procedure,  form the foundation of controlled operations. For many organisations, these requirements are relatively new. 

DORA compliant 

Being compliant means being able to demonstrate that the formal requirements of DORA are met. Policy documents and procedures, such as an information security policy and an incident management procedure,  form the foundation of controlled operations. For many organisations, these requirements are relatively new. 

After the first year of DORA, the next question arises: not only whether policies and procedures are in place, but whether they are actually followed and whether risks are identified and managed in a timely manner. This is also the core objective of DORA, which explicitly emphasises monitoring and testing. Think of structural service level management of ICT service providers and the execution of the Digital Operational Resilience testing programme. 

The challenge therefore shifts from documentation to execution. Where the implementation of DORA largely consisted of drafting documentation, the current phase requires the structural execution, monitoring and testing of those measures. In practice, we observe that after the first DORA year, this remains an area of attention for many organisations. The key question often remains: if we comply with DORA requirements, how do we ensure that we remain continuously ‘in control’? 

Risk & Control Framework as a foundation 

Legislation is generally risk-based and DORA is no exception. The rule-based requirements within DORA can essentially be seen as mitigating measures for identified risks or specific threats. A clear example is access and authorisation management. 

Depending on the application, it is appropriate for employees to have different rights to view, amend or delete data. For instance, multiple employees may need access to client or participant data, while only a limited number should be authorised to make changes. The same applies to financial processes such as booking and approving invoices, where it is undesirable for all actions to be performed by the same individuals. 

Underlying  examples would be that of confidentiality, integrity and fraud risks. Authorisations should therefore be based on principles such as need-to-know, need-to-use and least privilege (Commission Delegated Regulation (EU) 2024/1774, Article 21(a) and (b), RTS ICT Risk Management). In this context, DORA requirements function as mitigating controls derived from the risk assessment. 

NOREA, the Dutch professional body for IT auditors, has also recognised this and, through its DORA working group, developed a ‘DORA in Control’ framework. This Excel-based framework translates DORA requirements into controls and measures maturity levels through dashboards and visualisations. 

It should be noted that this framework has been designed for all types of DORA in-scope regulated entities, large and small. In practice, however, it primarily fits larger organisations. Smaller organisations in particular face challenges in designing and measuring both the existence and effectiveness of controls, mainly due to limited capacity and expertise. In our client engagements, we see a strong demand for a pragmatic translation of DORA requirements into workable controls linked to actual risks. 

ICT Risk Management as a Service – ICT-RaaS in short 

A robust, organisation-specific and pragmatic ICT Risk & Control Framework is essential not only for compliance, but also to ensure that DORA truly lives within the organisation. Only when stakeholders understand why certain procedures exist will they actually follow them. This does, however, require ICT expertise, continuity and independence to be embedded within the financial institution. 

For many organisations, employing a full-time specialist to perform monitoring and testing activities is neither proportionate nor commercially viable. For organisations seeking a more flexible second-line solution, ICT Risk Management as a Service (ICT-RaaS) can offer an effective alternative. 

Within the ICT-RaaS model of Projective Group, professionals operate in the second line to maintain the Risk & Control Framework, test the effectiveness of DORA controls and periodically provide insight into compliance levels, DORA maturity and the effectiveness of risk management. Together with the organisation, a realistic annual plan is established, defining which controls and DORA requirements are tested and when. 

This approach not only ensures compliance with formal requirements, but also builds confidence that measures actually work in practice  

IT Compliance

Enabling compliance, building resilience

For more information about ICT-RaaS and how it can be implemented for your organisation based on a Risk & Control Framework, please contact us via dora@projectivegroup.com or reach out to one of our IT Compliance professionals.