3 DORA Implementation Steps for CISOs

06 3 DORA Implementation Steps For CISOs

You have until January 17th, 2025, to finish your DORA implementation process. In this short guide, we give you a high-level overview of the most likely DORA implementation challenges you will face - and how to get ahead of them.

1 - Understand Your DORA Implementation Resource Requirements

Not only does DORA impact a vast number of financial services businesses, including some of the world's biggest banks and the continent's smallest fintechs, but its five pillars also touch on almost every aspect of your company's operations.

This broadness means that everything from core financial services infrastructure and the transaction systems for inter-banking to online banking and customer portals will need to be assessed against DORA's requirements and brought into line.

There is no single technological solution or set of processes that will help you become compliant with DORA.

Like any other regulation, the act's relative broadness means that the core resource you need for DORA implementation is people. You need a pool of human hours available to implement the security controls, contractual changes, and reporting procedures that DORA will require from you.

Your exact DORA implementation human resource costs will depend on how much change is needed following your gap analysis. From there, you can determine how many human hours of work will be required to address any gaps/shortcomings you have and figure out whether you can fill this requirement with your existing security/IT teams or if you'll require additional resources.

If you're already complying with regulations like the EBA Guidelines on outsourcing arrangements and the Bank of England's SS2/21 Outsourcing and third-party risk management, your resource requirements will likely be lower.

Our DORA implementation resource recommendations:


2 - Focus On Initial Reporting Capability

For smaller financial services companies, reporting major cyber incidents in a very short space of time will likely be a big operational shift.

DORA has three levels of major incident reporting requirements:

The initial report will need to include information like the description of the incident, member states and other financial entities or third parties impacted or potentially impacted by the incident, the origin of the incident (if available), the number of clients impacted, data losses, how critical the services impacted are, and whether the incident is recurring.

Knowing all this and communicating it to a competent authority within 24 hours will likely be a tall order for many organisations. It will mean being able to tie together data around cyber incidents such as cloud data breaches about what kind of data and systems were impacted and how the attack chain happened.

A key challenge here is understanding at a granular level what data/systems create risk in what context. For example, a cloud database of client names will present risk at a different level if it is exposed alongside their date of birth and tax identification numbers.

Building the capability to understand and report on risks quickly might mean moving beyond siloed security controls towards security tool consolidation.

Our DORA implementation reporting recommendations:

3 - Think About Third Party Continuity

What would happen to your clients’ data and your business services if your number one provider stopped functioning for whatever reason?

Being compliant with DORA's third-party risk aspects has several parts. One that a lot of organisations will likely struggle with is the need to ensure the continuity of critical services.

The DORA regulation states that "Financial entities shall put in place exit strategies to take into account risks that may emerge at the level of ICT third-party service provider, in particular a possible failure of the latter, a deterioration of the quality of the functions provided, any business disruption due to inappropriate or failed provision of services or material risk arising in relation to the appropriate and continuous deployment of the function."

What DORA tries to do here is ensure that the security of data that a third-party provider is holding will not be compromised. Even if you need to break a deal with a provider urgently, you need to be able to get all your data.

In all contracts with third parties, you will need a clause that allows you to break the deal without impacting client data.

For every critical ICT service you contract, you will need a backup infrastructure/way to continue business and agreements with secondary providers to enable you to cut a third party off.

This means that although you might be reliant on large cloud service providers, under DORA, you will also need to have a secondary backup plan for cloud infrastructure in place. You will need to either have provisions in place with third parties who provide the same services or a justification to make an exception.

You will also need to make sure, through your contracts, that your critical service providers follow a business continuity plan. For example, if a data centre goes out, you will need a redundant centre.

Our DORA implementation third-party guidelines:


Getting Help With DORA Implementation

If you need help planning your DORA implementation process, SECFORCE offers an end-to-end DORA consultancy service.

We can guide you through DORA’s five pillars, conduct a thorough gap analysis and walk you through the best-fit solutions for your firm.

You may also be interested in...

CBEST Implementation Guide 2024 Update
March 20, 2024

CBEST Implementation Guide: What’s New In 2024

A refresher on the overall CBEST process and a quick summary of the updates for 2024.

See more
Visual DORA vs NIS2
May 29, 2024

Don't Sleep On DORA vs NIS2

Our high level digest on two of the most important security legislative instruments in history.

See more