DORA: your questions, answered

It’s not surprising that you have questions about the Digital Operational Resilience Act (DORA). It’s the EU’s most expansive digital risk regulation and the expectations on your firm are huge. You need to enhance your technology and cyber resilience, improve your risk and controls framework, and put information communication technology (ICT) risks high on the agenda of your board and executive committees. With a tall list of actions, where do you even begin? 

To help, we’ve pulled together 10 of the most frequently asked questions by our clients to give you the answers you need.  

What’s the definition of ICT according to the European Banking Authority (EBA); many references are to IT systems but how broad should we apply DORA? 

If we look at the text verbatim, an ICT asset is a software or hardware asset in the network and information systems used by the financial entity. Put simply, all ICT systems that you use fall within DORA’s scope. You should approach each system with a risk-based approach, prioritising controls and monitoring those systems which are most critical or highest risk. 

Who’s responsible for ICT risk management activities under DORA? 

ICT risk management responsibilities tend to span the CIO, CTO, and COO with CISO input too. The second line of defence is also important in establishing a framework that’s effectively integrated with enterprise risk management structures. It should also provide appropriate review and robust challenge. 

How can we effectively manage risks associated with ICT systems that may lack modern security features? 

Generally, there are five actions that we’d recommend: 

1. Develop an inventory of ICT systems that support your firm’s critical or important functions (CIFs).
2. Create criteria for assessing potential risks if your legacy ICT systems fail and what it means for your CIFs. 
3. Understand the likelihood of those risks and take a risk-based approach to mitigating risks across your legacy estate. 
4. Control and monitor risks and establish additional protective measures where possible and reviewing mechanisms to monitor vulnerabilities and threats. 
5. If the risks associated with legacy systems can’t be mitigated, then consider whether a replacement is needed. 

What are the testing capability enhancements required by DORA? 

You need to have a comprehensive testing framework. We think this should cover: 

• Regular and thorough testing of ICT systems to identify vulnerabilities, ensure robustness, and verify the effectiveness of security controls. 
• Scenario-based testing, including extreme but plausible events to guarantee systems can handle unexpected disruptions. 
• Advanced threat-led penetration testing, including engaging in red-team exercises that simulate sophisticated cyberattacks to really test the resilience of your systems and identify weakness. 
• Incident respond testing to measure the effectiveness of response plans through regular drills and tabletop exercises. 
• Testing third-party systems and making sure your providers also rigorously test their ICT systems and processes to ensure your entire supply chain is resilient—especially where they support CIFs. 

What level of oversight is expected of sub-contractor relationships? 

Essentially, the more oversight, the better. You need to understand the impact of sub-contractor failure on the provision of ICT services supporting critical or important functions (CIFs). You need to be comfortable with the due diligence process the third-party performs over the sub-contractor relationship and the regularity of the risk assessments performed. And you also need to ensure you’re sufficiently notified in advance of material changes to sub-contracting arrangements and risk assess any changes to material sub-contracting arrangements, which should be subject to approval / non-objection. 

How are firms integrating third-party risk management (TPRM) effectively into enterprise risk management frameworks (ERMF)? 

TPRM needs to be integrated into your ERMF when you identify risks and when you require any new or adapted controls during your DORA implementation. As you probably already know, identifying and mapping CIFs is anchored to ICT risk ownership in the first line of defence. But your second line also needs sufficient expertise to discharge their responsibilities effectively. We’ve seen scenarios where specialist cyber risks skills are needed to complement existing capabilities in the risk function. 

What’s the potential impact of an organisation using the services of a firm in scope of Article 33 (ie increased costs being passed on)? 

The provisions of Article 33 fall on ICT suppliers, so the chance of significant costs being passed onto individual service users during implementation is unlikely. Service providers may need to increase their compliance and risk management resources, so we way see an incremental increase in critical software costs in the medium to long term. But this will depend on the maturity of rules, procedures, and mechanisms for IT risk that the service provider is responsible for. 

Do we need an exit plan for each ICT service provider that supports a critical function? 

Yes, you need a documented exit plan for each of your ICT third-party services providers supporting a CIF. We’ve seen a lot of firms failing to adequately define the service description and key dependencies on the third-party. It’s really important that you don’t overlook this step, and an information register can be a useful tool in tackling this area. 

You should define the periodicity of the review and testing of exit plans, and this should be outlined in a policy. In some cases, it might even be beneficial to combine exit testing with testing other contingency plans to avoid duplication. 

DORA talks about including contractual agreements around exit plans but what does that mean and what should we include in contracts? 

You should consider exit planning throughout the entire third-party lifecycle to mitigate risks and ensure a seamless service transition. You should address it during supplier due diligence before contracting is even considered. You should assess alternative service providers, the impact of service disruption, and the risks of such disruption. During the contracting of supplier for critical services, you should include clear clauses defined for the provider in case of disruption, clear terms of contract termination, and supplier obligations in the event of an exit. These types of clauses aim to ensure your critical services aren’t disrupted and you’re protecting against bad outcomes. 

Is there alignment between DORA requirements on ICT third-party providers and the proposed UK Critical Third-Party (CTP) regime? 

The short answer is yes. Both CTP and DORA stem from concerns financial institutions have become highly dependent on third-party providers to such a degree that should those third parties face disruption, it could have adverse outcomes for customers and the stability of financial markets. Given this common concern, there’s naturally overlap in regulatory requirements between the UK and EU’s approach. Both focus on improving the risk management and governance of third parties that provide critical systems or services. And there’s a strong correlation between several themes, which could provide synergies for firms addressing both regulations.  

Got more questions and need answers fast?

Getting your head around regulation isn’t always easy—especially when it’s as expansive as DORA. But our team of operational resilience and regulatory compliance experts are on hand to help.  

We don’t believe in one-size-fits-all solutions. We help you focus on the right details—whether that’s simplifying your network of third-party dependencies, fine-tuning your ICT risk frameworks, or developing your testing capability. We act as an extension to your team embedding resilience at the core of your organisation to protect your biggest assets. And when we leave our capabilities stay because we upskill your people to build sustainable solutions faster, keeping you ready for the next wave of risk and regulation. 

Get in touch to find out more