Edward Roozenburg: Key risk management issues to consider when implementing DORA

December 31, 2024

This column was originally written in Dutch. This is an English translation.

By Edward Roozenburg, Risk Management Consultant at Probability & Partners

On 17 January, all financial institutions must comply with the European regulation requiring financial institutions to be digitally resilient: the Digital Operational Resilience Act (DORA). Meanwhile, the financial institutions I work for have scheduled extra board meetings to adopt the latest changes to policy documents in time. This also provides work for the key risk management officer who provides the documents with a risk opinion. He also uses this moment to ask other questions about the implementation.

 
Process issues

First, the key risk management function holder can pay attention to the process followed to become DORA compliant. The right process does not guarantee a proper implementation, but it does facilitate a sound implementation. Here are some things about the process that the key risk management function holder can ask questions about:

1) Gap analysis
Has a gap analysis been carried out? Was this done using the DORA articles in the main text as well as the underlying elaborations in RTS/ITSs? And were the right people involved in this? The people involved should at least be those responsible for risk management, outsourcing, information security including ICT incident handling and business continuity.

2) Closing the gap
Have action plans been drawn up to close identified gaps? And have these actually been implemented?

3) Assurance
What assurance is there showing that the implementation has actually been completed? Has the controller been involved in implementing the action plans? Or has another second-line function (e.g. Compliance) looked in and helped interpret the legal text? Have reports been prepared by independents?

And what assurance has been set up for the future? To remain compliant, periodic things like risk assessments on key ICT suppliers and identification of any new threats should be carried out. Is periodic and independent testing and reporting to the board on whether these control measures are properly implemented?

4) Open gaps
Which components have not yet been fully implemented? And has their risk been determined? Both for information security and compliance risk play a role in this.

5) Training
Have training programmes been developed and implemented to train board and staff on DORA and its requirements? The board is also expected to have sufficient knowledge to assess risks to digital operational resilience.

 
Content issues

In addition to process issues, the key risk management officer can also pay attention to various substantive issues that actually strengthen digital resilience. These measures are included in policy documents that were probably already in place but revised for DORA. Below are some key (revised) documents for DORA and things the key function holder can look out for in his opinion in doing so. There are, of course, endless substantive issues to pay attention to. The following is intended only as an anthology.

1) Risk management policies/Risk management policies
Generally, financial institutions adopt a generic risk management policy for identifying, analysing, assessing and controlling strategic, operational, financial and compliance risks. The same approach is also used for ICT risks. The key function holder can validate whether this approach is indeed used in managing ICT risks, question whether this approach is adequate in practice and assess whether the policy states sufficiently clearly that it also applies to ICT risks.

2) Information register
The information register contains an overview of all suppliers providing information assets to the financial institution with the classification of whether the asset contributes to any of the institution's critical or important processes. If an information asset indeed contributes to a critical or important process, it is also mandatory for this asset to map any subcontracts. Because of this extra work, there is therefore some incentive for the implementing organisation to keep the set of critical or important processes as limited as possible. The key risk management officer can ask about the rationale used to designate certain processes as critical or important and assess this rationale.

3) Incident management
Incident management describes the procedures for detecting, reporting and resolving ICT-related incidents. It should describe how incidents are detected, how they are classified, how and when they should be reported (internally and externally) and how incidents should be recovered. There should also be a periodic review of whether there are connections between incidents that indicate larger threats, or whether certain incidents have occurred more than once. The key risk management officer can assess whether these issues are included in the policy.

4) Business continuity plan/policy
The continuity plan describes the measures taken to ensure continuity of critical services in case of disruptions. The key function holder can assess whether there are clear procedures for restoring normal operations after a disruption. It is also important that matters have been established about testing the recovery measures. This requires examining whether the measures that should take effect in the event of a disaster can actually be implemented. As this directly contributes to the digital operational resilience of the financial institution, it is good if the key function holder risk management reviews whether arrangements have indeed been made about testing.

5) Outsourcing policy
The outsourcing policy describes the procedures for selecting, monitoring and evaluating external service providers. DORA highlights dependence on a single supplier as a key risk in outsourcing. This should be avoided. An incident at such a key supplier, would then have major consequences. Thus, DORA emphasises the presence of a multi-vendor strategy as an important element to reduce dependence on a single supplier and highlights concentration risk analysis. The key function holder can assess whether these points are sufficiently secured with the implementation of the outsourcing policy. For example, is this included in the risk analysis to be done for each supplier?

 
Conclusion

The implementation of DORA brings challenges for boards and key function holders of risk management. The key function holder risk management plays a useful role in this process. By paying attention to both process-related and substantive issues, the key function holder can contribute to the successful implementation of DORA and thereby protect the interests of participants and the resilience of the organisation. Board members can build on the key function holder's judgement. But even with the above list of focal points in hand, it remains difficult to assess whether there is sufficient assurance. After all, board members and key function holders are not cybersecurity specialists. They are expert at using their own judgement and calling in specialists when necessary. They cannot know everything about ICT controls. They will therefore have to rely on the information provided to them by an internal but independent ICT risk management expert, the CISO. In this respect, the independent CISO in a reviewing role is also essential for a good and balanced implementation of DORA within the risk appetite of an organisation, such as a pension fund.