The DORA Quest: Beware of Vendors with Magic Beans

Originally published by Own Company.

Written by Matthew O'Neill, Field CTO, Own Company.

You can't escape the sheer volume of vendors sharing information about the Digital Operational Resilience Act (DORA) and how buying their tooling will make you compliant, which we all know is nonsense. DORA is upon us, and crafting the right outcome will require new processes and focus.

Amongst the endless press releases and whitepapers, here are two of my unanswered questions:

"Will DORA be an excuse to raise prices?" and, more intriguingly, "Do Tech Firms working under the oversight of Financial Services (FS) regulators have any idea what is about to happen?".

Let's jump in.

The primary purpose of DORA is to improve the stability of Financial Services across Europe and beyond. This regulation is now live across Europe; it cannot be watered down by local implementation—it's a uniform law, with teeth.

The regulation formalises the disciplines for digital operational risk management and has been live since January 2023. Enforcement by the regulators (Competent Authorities) commences on January 17th, 2025.

There are five focus areas, and depending on where you are starting from, some may be a much bigger deal than others. The regulation covers Critical and Important services. However, what makes up these designations is also subject to some discussion. For now, the focus five are risk management, incident management, resilience testing, third-party risk management, and intelligence information sharing.

ICT Risk Management

Financial services firms are well versed in Risk Management, from 3LOD models to understanding and mitigating Operational Risk. The legislation adds more specific obligations for Digital Operational Resilience risks. Overall, FS firms will mostly have this covered and feel this is an evolutionary tweak, not a revolutionary overhaul, assuming they can produce enough documentary evidence.

For ICT Third-Party Providers, increased use of Risk Management language in sales conversations and at regular service reviews will be necessary while avoiding the urge to say, "Buy this; we will make you compliant."

ICT Related Incidents

Incident management, and particularly incident management reporting, is now more prescriptive with DORA. There is less room for ambiguity in reporting, more deadlines, and a precise timetable for notifying of the incident, providing an after-the-event report and a remediation plan for any shortcomings identified. As a result of these reports, both individually and collectively, there will be increased scrutiny, trending, scorecards, and further action from the regulators. The timelines and the depth of detail required will require direct action from both FS firms and their partners.

FS firms and ICT Third-Party Providers will be under increased pressure to provide timely updates, potentially to multiple customers, during service-impacting incidents.

Digital Operational Resilience Testing

‍Resilience testing is going to be a big deal. It is no longer acceptable to rely on paper-based desktop exercises to demonstrate the resilience of Critical and Important services; equally, it won't be acceptable to perform a controlled shut-down to flush transaction logs and caches so that the standby version can take up 'in a known good state'.

Instead, risk-based testing will need to be performed regularly against each of these services, independently, in a form that demonstrates the robustness and security of the application and platform. The results then need to be available for regulatory scrutiny. There is likely to be some interpretation of how big this will be.

However, it is prudent to consider this to be the complete end-to-end service test of every moving part and every likely failure scenario. FS firms and third parties already know some of the services they will need to shore up, but others will come out as part of the testing. Analysis and remediation plans should be in progress now to share with the regulators to limit future impact or sanction.

Simple things like having transaction logs and backups separate from production databases and services are still 'out there'. I encourage everyone to seek out the uncomfortable truths now and start the remediation rather than let independent auditors and regulators find out following an avoidable failure. I have performed this exercise a few times, and it is truly amazing the things that come to light that someone in the team knew about but did not feel protected enough to bring truth to power.

ICT Third-Party Risk Management

Third-party risk management and the review/update of contractual terms are going to cause a great deal of work. There is likely to be a big difference between what the FS entity and the contracted party understand today. Ultimately, the responsibility will lie with the FS firm to ensure that the contractual terms cover all subcontractors, including full audit rights and data access rights over all data domiciled wherever it might be as part of that service.

Now for the crunch: The FS entity must ensure that its third parties and all subcontracted parties understand that they are hosting Critical or Important services and the potential impact of service degradation, breach, or loss.

Historically, FS firms have been selective about the information they share with third parties, citing security exposure, data protection, and commercial risks. Their obligations now go beyond a simple service-level agreement.

Once the third party or their subcontracted parties understand their service or component is part of a Critical or Important service under the terms of the DORA regulations, I anticipate they will want to charge more to cover the increased measures and risks, they now understand from running this service, not least because all parties will have responsibilities of their own.

Information Sharing

Intelligence information sharing on emerging cyber threats is undoubtedly helpful in improving cyber resilience for all. While this is currently considered voluntary, it will be interesting to see whether financial services entities will be coaxed into providing meaningful information in a timely manner. My prediction is that this will become more mandated than voluntary over time.

Beyond the five pillars, there is more.

Oversight of Critical ICT Third-Party Providers

DORA recognises that not all third-party providers are created equal. Some are so critical that they require direct oversight from Europe's FS Regulators. Inclusion in this group will be assessed through the dimension and nature of the financial sector's reliance on the ICT third-party provider through quantitative and qualitative criteria to determine criticality. The list of who is and who is not is still under development. Still, it's easy to guess some of the most prominent players included here.

And here are other areas that are going to get very interesting:

1. There will be an increasing awareness of the concentration risk posed by dependence on certain Critical ICT Third-Party Providers; regulators will challenge the FS entities to demonstrate they have considered alternatives and, on a service-by-service basis, have proved that they can switch suppliers in a timely manner without impacting customer service.

2. Do tech firms (and other ICT Third Party Providers) have the specialist experience required to work directly with Financial Services Regulators, especially when understanding where failure to meet the demands or timelines of the regulator can result in a significant penalty?

3. Will FS entities update their RFPs in the future to only accept bids from Critical ICT Third-Party Providers to improve their risk posture and, therefore, exclude non-critical providers? Will ICT third-party Providers opt into the Oversight Framework voluntarily to be included in these RFPs?

4. Will subcontractors to Critical ICT Third-Party Providers be automatically designated as Critical, and how does that work for the FS entity?

Regulatory Risk Appetite does not typically exist outside of America, the home to many of the biggest Tech firms. Determining which regulations to comply with based on the size or nature of the potential penalty will not work when dealing with European FS Regulators. If you have worked in FS and had to work directly with regulators, you will know that there could be a world of pain coming from this new regulatory oversight.

Final Thoughts

Operational Resilience will improve as we move away from paper-based testing to regular threat-led testing.

Beware of the magic beans, anyone who tells you that buying their software or service can give you a one-and-done for DORA compliance; sure, they can get you moving, but compliance will be tested on an ongoing basis and often because of other failings. DORA will require a lot of work and culture shift(s) across FS entities and their ICT partners; if you have not already started, start now.

It is essential to have far more transparency, communication, and openness between the buy and sell sides. There will be justifiable nervousness that this will lead to higher prices and more significant exposure to leverage conversations as part of contractual renewals across the whole service (contracted and subcontracted parties).

It is also a big deal as this will give regulators far more information about which parties are providing critical services and pose a concentration risk to the financial services industry across Europe. The list of Critical ICT Third Party Providers is not yet known, and it will be a surprise just how big that list will be.

Regulators do accept cloud operating models despite buy-side rhetoric. However, the concentration risk evidence will lead to further regulation of the transferability of data and services between cloud providers.

So, what can you do besides buckle up and hope for a good ride?

1. Make sure you understand your risk profile, especially around your Critical and Important services and the general services that make everything else work.

2. Determine who can help you mitigate or manage these risks in a methodical and meaningful way.

3. Consider who can help you understand, categorise, manage, back up, and recover your Critical and Important data (including metadata), bearing in mind the SaaS world in which we now operate in.

4. Think whether it would be good if you could prove the integrity of your backup without having to gamble on the integrity of a complete system restore.

5. Consider more than just customer systems within your Critical and Important list. I would argue that your IT Service Management Platform should make the list, as without this, you would struggle to recover your other customer-facing services.