The time is fast approaching when almost all authorised financial organisations will need to comply with the Digital Operational Resilience Act (DORA). DORA is the first European regulation to set out concrete requirements in the field of ICT. As a Regulation, DORA has direct effect in each Member State, without the need for transposition into national law. We are getting more and more questions from our customers about DORA:
- When should we start implementing DORA?
- What are the exact requirements?
- Are we perhaps already compliant in some areas?
- How do I apply proportionality (read: ‘what exactly do I have to do to be compliant’)?
In our previous articles, we outlined the requirements of DORA in addition to the timeline. In a subsequent series of in-depth articles, we will explain DORA at a topic level, making it clearer what is required to be compliant with DORA and, of course, to manage ICT risks so that your organisation is sufficiently ‘digitally operationally resilient’.
In this article, we look specifically at the requirements in Articles 5 to 15, or ‘Chapter II: ICT Risk Management’. Time to explore!
Organisation & Governance
In DORA, managing risks and threats to digital operational resilience is key. Not surprisingly, DORA begins with several requirements related to ICT risk management.
The essence of Chapter II is that ICT risk management must be demonstrably organised and established. The legislator therefore starts with the mandatory internal governance and control framework (Art. 5(1)). What exactly this is or should be is not further specified in DORA. In our experience, the governance framework is a documented or formalised description of responsibilities and activities, including the monitoring of implementation. In simple terms, who is ultimately responsible for ICT risk management? Who does what work and who checks the quality of the work?
Control Framework
An important building block for good ICT risk management is to have a “control framework that ensures effective and prudent management of ICT risks”. In other words, a control framework that shows what risks the organisation faces, what level of risk is acceptable, what mitigation measures are in place and how the effectiveness of the measures is determined.
An important building block for good ICT risk management is to have a ‘control framework that ensures effective and prudent management of ICT risks’.
Fortunately, DORA provides a lot of guidance on how to set up the various frameworks. For example, organisations could include these requirements in a governance document (which may already exist). If this does not already exist, a specific IT governance policy can also be drawn up. Ultimately, it is less important in which document the frameworks are set out, as long as they are formalised, approved by a board or management and known throughout the organisation.
Governance Framework
For the governance framework, DORA already provides some guidance in Article 5(2), which may be so obvious as to be overlooked. For example, that ultimate responsibility for ICT risk management lies with the board. This will often be the board of directors or senior management. The same article lists several other matters for which the management body is responsible (Art. 5(2)(a) to (i)), namely setting and implementing policy, describing ICT roles and responsibilities, defining the strategy for digital business resilience, and approving audit plans. All these elements therefore need to be clearly defined, for example in a governance document or AO/IC description. This may seem obvious, but it is important that it is done. After all, a clear statement of roles and responsibilities is fundamental to establishing and maintaining adequate risk management.
Training requirements
Since the managing body has all these duties and responsibilities, it is logical that it should have adequate knowledge and skills in the area of ICT risks. Regular participation in specific training (commensurate with the risk to be managed) is therefore a requirement in Art. 5(4). This does not mean, however, that directors are expected to have detailed technical knowledge.
In our view, it is unrealistic for a director to know in technical detail, for example, how a ransomware attack works. However, it is important for boards and directors to know exactly what a ransomware attack is, how an attack can take place, what factors are involved, what the possible consequences are and what mitigation measures exist to reduce the likelihood and mitigate the impact. Indeed, this is the only way a director can provide adequate guidance and manage the risks.
ICT Risk Management Framework
After Art. 5 sets out how and by whom the ICT risk management process should be managed, DORA continues with the ICT risk management framework itself. Art. 6 can be seen as the basic design of the ICT Risk Management process. This article describes how the process should be embedded in the organisation and what the framework should consist of. According to paragraph 2 of Art. 6, the ICT risk management framework shall at least consist of strategies, policies, procedures and ICT protocols and ICT risk protection tools (detailed in Article 7).
The aim of the ICT risk management framework is to minimise the impact of ICT risks.
The aim of the ICT risk management framework (and therefore of the underlying elements from the previous enumeration) is to minimise the impact of ICT risks. So somewhere it will be necessary to identify and record what is an acceptable minimum for the organisation. In risk management terminology, this is called ‘risk tolerance’. The combination of the ICT risk management framework and up-to-date information on ICT risks may be required by the regulator. In this case, we expect the regulator to ask for documents related to the establishment of ICT risk management, e.g. an ICT risk charter, but most importantly an up-to-date risk analysis.
Three line model
Within the ICT risk management framework, the ‘business’, or first line, is responsible for ICT risks and providing up-to-date status on them. However, the second line, the control function, is often responsible for managing and monitoring ICT risks. This is to avoid potential conflicts of interest between a business and a control function. This is exactly what Art. 6(4) wants to see reflected within an organisation: how is an appropriate separation and independence of the ICT risk management functions, control functions and internal audit functions established? Reference is made to the ‘three lines of defence’ model, now also known as the ‘three-line model’.
Once an organisation has established an ICT risk management framework, it should also be reviewed annually. Art. 6(5) also requires an assessment to be carried out after
- the occurrence of serious ICT-related incidents
- monitoring instructions; or
- the conclusions of relevant test or audit reports.
Note that a record of this evaluation is also part of the information that the regulator can request!
As described in the previous section, the conclusions of audit reports may identify areas for improvement in the ICT risk management framework. Therefore, a formal follow-up process should be established (paragraph 7). The periodicity of internal audits (paragraph 6) is not prescribed, other than that they should be regular and in accordance with the audit plan.
Digital Business Resilience Strategy
Art. 8(6) describes that the ICT risk management framework shall include a strategy that explains
- how the ICT risk management framework will be implemented; and
- the methods and objectives used to manage ICT risks.
Of course, the subsequent sub-paragraphs (a) to (h) provide more interpretation. For example, the strategy should describe:
- How the ICT risk management framework supports the business strategy and objectives;
- That a risk tolerance level has been set that is consistent with the organisation’s risk appetite;
- Clear information security objectives, including key performance indicators and key risk metrics;
- An explanation of the ICT reference architecture and any changes required to meet specific business objectives (further elaborated in Article 8);
- mechanisms to detect, mitigate the impact of and protect against ICT related incidents (further elaborated in Art. 9 and 10); and
- a description of the current state of digital operational resilience, based on the number of reported serious ICT-related incidents and the effectiveness of preventive measures;
- Conducting digital operational resilience tests as described in Chapter IV of the DORA;
- a communication strategy in the event of ICT-related incidents, if these are to be disclosed in accordance with Art. 14 (further elaboration in Art. 14).
In order to comply with this article, this digital operational resilience strategy should be developed as part of the ICT risk management framework. For our clients, we summarise the mandatory elements of Articles 5 and 6 in a document we call the ICT Risk Charter. Here we also reflect paragraph 9 of Article 6 on the ICT multi-vendor strategy, where significant dependencies on third party ICT service providers are addressed.
Want to know more?
Chapter II of DORA continues with various prerequisites for an effectively designed ICT risk management framework. These prerequisites will be discussed in more detail in a later article. Want to make sure you never miss one of our articles? Make sure to follow us on LinkedIn!
Do you have questions about DORA or need help preparing for the entry into force? Our consultants are here to help. Do not hesitate to get in touch.
About Projective Group
Established in 2006, Projective Group is a leading Financial Services change specialist. With deep expertise across practices in Data, Payments, Transformation and Risk & Compliance.
We are recognised within the industry as a complete solutions provider, partnering with clients in Financial Services to provide resolutions that are both holistic and pragmatic. We have evolved to become a trusted partner for companies that want to thrive and prosper in an ever-changing Financial Services landscape.
