Bona Iqiniso Rationale 

DORA categorization (DORA blocks) – rationale

1. Background

The Digital Operational Resilience Act (DORA) is a proposed legislation by the European Union (EU) aimed at ensuring the operational resilience of the financial sector in the digital age. DORA intends to address the increasing dependence of financial institutions on digital technologies and the potential risks associated with cyber threats, IT failures, and other operational disruptions. The act aims to establish a comprehensive framework for the management of digital risks, requiring financial firms to implement robust cybersecurity measures, enhance their incident response capabilities, and conduct regular testing and assessment of their operational resilience. DORA also extends the regulatory scope to include third-party service providers and critical infrastructures, ensuring a holistic approach to safeguarding the stability and integrity of the financial system. By promoting a strong operational resilience culture and providing a clear regulatory framework, DORA aims to enhance the trust and confidence of consumers and investors in the digital financial services sector.

2. Problem

Euroclear has 10 workstreams to address compliance to DORA. This also means there may be a certain overlap/dependency between these workstreams.

For Workstream 5: Software testing & disaster recovery, the team needs to define ‘categories (DORA blocks)’ that will help to address the above dependencies.

All DORA compliance issues need to be categorized according to these DORA blocks.

3. Solution

Define DORA blocks to categorize areas of compliance within DORA

4. Advantages

  • Identify major compliance areas with other dependencies
  • Communication with the other workstreams improved
  • Project definition may be helped by knowing the areas (dependencies) to focus on

5. Disadvantages

  • Another classification: Although important, there are also other forms of classification (see other rationales)
  • Other dependencies: Besides the other workstreams there are other divisions/teams that are involved in solving DORA compliance issues
  • The focus should be on solving compliance issues and only in a secondary way on the dependencies.

6. Conclusion

Dependencies should not be the main focus, but also shouldn’t be forgotten or neglected.

The following main ‘DORA blocks’ should be defined:

  • Functional & non-functional testing
  • Security testing
  • Third-party testing
  • Business continuity and disaster recovery testing

A fifth candidate would be ‘risk management‘, but lowering risk is a core part of DORA and is involved in all regulations and therefore also in all compliance issues.

A sixth candidate would be ‘asset management‘, but DORA is very clear that it is only concerned about critical and important assets/resources.

For Workstream 5 (Software testing and disaster recovery) this drills down to the application of risk-based testing for all critical and important assets/resources. Risk is a general DORA concern and asset management is restricted to critical and important assets. For these reasons, it makes no sense to consider them as DORA blocks.