DORA mapping requirements (Dora Article 8: Identification) are an area of interpretation for firms wishing to follow a proportionate approach to DORA implementation. There is perceived latitude in the wording of Regulatory Technical Standards and the regulation to create debate for some firms around DORA's mapping requirements.
Regulatory expectations
There are three clauses in the Regulation (2022/2554) and a published response in the RTS regarding mapping. The clauses cover function, resource, and process mapping.
The clauses are:
Article 8(1): "As part of the ICT risk management framework referred to in Article 6(1), financial entities shall identify, classify and adequately document all ICT supported business functions, roles and responsibilities, the information assets and ICT assets supporting those functions, and their roles and dependencies in relation to ICT risk.”
Article 8(4): "Financial entities shall identify all information assets and ICT assets, including those on remote sites, network resources and hardware equipment, and shall map those considered critical. They shall map the configuration of the information assets and ICT assets and the links and interdependencies between the different information assets and ICT assets."
Article 8(5): "Financial entities shall identify and document all processes that are dependent on ICT third-party service providers and shall identify interconnections with ICT third-party service providers that provide services that support critical or important functions."
Clauses 8(1) and 8(5) clearly outline the requirement to map all in-house and third-party ICT assets, and clause 8(4) articulates the requirement to identify all assets, then further map the configuration of hardware and networks for those assets which support critical or important functions.
To borrow more wording, this time from page 106 the ICT Risk Framework Regulatory Technical Standards (JC_2023_86), "This comprehensive approach ensures that no potential vulnerabilities are overlooked ..."
All the above points to a very high bar in terms of European Supervisory Authorities (ESAs) expectations around the depth and detail of mapping required for in-scope firms.
However, on page 126 of the ICT Risk Framework Regulatory Technical Standards (JC_2023_86), there is also a response regarding proportionality which has given some firms pause for thought.
"Regarding concerns about high costs for smaller entities, these should be addressed by following the proportionality principle...the risk management framework is designed to be abstract yet aligned with DORA. The draft RTS offers flexibility for entities to stick to their existing models ensuring compliance across different risk management frameworks based on different international standards."
The response infers some flexibility, based on proportionality, for firms wishing to follow their own approach to the ICT Risk Management framework and by extension the mapping methodology employed within that framework.
In the next breath, there is a word of warning however, as the ESAs point out that "focusing only on the risk management of ICT systems supporting critical or important functions could leave ICT systems not supporting critical or important functions exposed, potentially affecting the one supporting critical or important functions due to their interconnectedness. This broad risk management approach aligns with regulatory principles like DORA, emphasizing holistic digital operational resilience."
In short, this response implies that given the interconnectedness of all ICT assets, a firm who only maps critical assets will leave themselves open to ICT risk through unknown vulnerabilities in non-critical assets.
In practice
In terms of practical application, we've heard from firms who have approached DORA mapping and interpretations of proportionality from different angles.
The one constant is that all firms will decide to map functions, functional processes, and associated ICT assets.
Bottom-up
Some have chosen to apply a bottom-up approach, using Article 8(1) as the cornerstone of their mapping, sometimes leveraging Business Continuity and IT Disaster Recovery programmes to develop a complete list of ICT Assets. Again, leveraging BCM and ITDR capability, these assets have then been classified as critical and non-critical. Those that fall into the critical camp and then mapped in granular detail to help firms visualise the importance and interdependencies of these assets on the organisation.
Top-down
Some have chosen a top-down approach, starting with the identification of Critical or Important Functions (CIFs).
Following CIF identification, rather than mapping all ICT assets, those firms have mapped only ICT assets supporting delivery of those Critical or Important Functions. The intention with these firms would be to undertake this level of mapping as a first iteration, focusing only on what's critical, and then maturing the mapping over time to include all ICT assets.
This may be considered a risk as we are unsure how regulatory oversight will be applied by ESAs following January 2025, however firms adopting the top-down approach may argue that in the early days of regulatory oversight, for all but the most systemic firms, we are more likely to see strong sector-wide guidance and feedback rather than direct action at a firm level.
Leveraging Operational Resilience
Finally, there are those firms who have not yet started with DORA mapping. These firms are hoping to leverage the mapping they've carried out as part of the operational resilience regime.
However, whereas the mapping requirements for operational resilience only require firms to map to a level of granularity where vulnerabilites are identified, DORA is far more detailed, which will force firms to go further with their mapping.
In our experience, a majority of firms have only mapped as far as the application layer and some have included End User Applications (EUCs), however many firms have not mapped the infrastructure layer (networks, servers, databases). This presents a potential resilience vulnerability for firms which should be addressed as part of operational resilience maturity and must be addressed as part of a DORA mapping programme.
Conclusion
Firms have interpreted the DORA mapping requirements and proportionality questions in different ways. As we’ve discussed, some will spread the heavy lifting over the course of several programme iterations and other firms will decide that identifying vulnerabilities is the cornerstone of a robust DORA implementation and focus their early programme efforts on mapping.
Whichever way firms choose to tackle DORA mapping, it's clear that the intended outcome from the European Supervisory Authorities is to ensure firms and the market is aware of all potential ICT vulnerabilities.
This again links back to the importance of developing a DORA strategy early on which will ensure firms and their senior managers understand how digitally resilient they want to be and the detailed steps to achieve those objectives.
