Exploring EU DORA in the context of broad cyber resilience

What is the origin of DORA and are there any other mandates in Europe that are comparable?

Following the financial crisis of 2008, the EU sprang into action to strengthen financial resilience by managing systemic risks with capital buffers and rating agencies oversight.

With the debilitating impact of cyber-attacks on banks as well as the increasing outages and disruptions caused by ICT incidents, the European competent authorities have come to a consensus: Cyber threats are a systemic risk on par with the financial stability risks from 2008.

As a result the EU Digital Operational Resilience Act (DORA) was drafted to set “…uniform requirements for the security of network and information systems of companies and organisations operating in the financial sector as well as critical third-parties.”[1]; Perhaps drawing on the regulatory response from 2008 that lead to the oversight of rating agencies, critical third-parties are coming under the oversight of the European Supervisory Authorities as well.

Fittingly, operational resilience of the financial system is a pan-European concern, so there are similar mandates in Switzerland and the UK like the Basel Committee Principles for Operational Resilience and the PRA Policy Statement on Operational Resilience.

The operational resilience mandates in Europe all build on existing outsourcing, business continuity, and risk management guidelines, but put more regulatory rigor behind it by setting and enforcing new baselines. An example of a prescriptive approach to setting risk management baselines is the already lapsed PRA deadline in the UK, which requires that firms identify important business services and set impact tolerances by March 2022[2]

What is the relationship between DORA and Open Banking? 

At first glance, DORA and Open Banking/PSD2 don’t have an immediately apparent relationship. One regulation deals with operational resilience of the financial system through ICT vendor risk management, and the other with banks extending financial services through regulated third-parties via open APIs, giving their clients more agency over their financial data in the process.

However, when one looks at the third-parties in question of both regulations, Critical Third-Party Providers (CTPP) in DORA and Third-Party-Providers (TPP) in PSD2, and how the competent authorities expect financial institutions to treat them, a relationship materialises.

On one hand PSD2 generally expects banks to remove barriers to TPPs getting integrated into the solutions eco-systems that clients can access via banks, while DORA calls for a guarded risk-based approach to integrating CTPPs into the banking ICT infrastructure.

Consequently, there is a tension between the regulations due to their simultaneously open and circumspect treatment of third-parties.

An example of third-parties cited in both regulations that exemplifies the delicate balancing of DORA and PSD2 requirements are Payment Services Providers (PSPs). PSPs are “considered to be ICT third–party service providers”[3] in DORA and fall under the stringent risk management requirements of the act. Consequently, the increased ICT risk vetting might delay onboarding into the open banking solution network and conflict with one of the aims of PSD2: timely and frictionless access to third-party solutions for bank clients.

What does DORA compliance look like? How does this compare to broad cyber resilience?

Some of the key elements of a GRC programme in support of DORA compliance are:

• Adequate ICT risk management frameworks
• Internal and external incident reporting processes
• Comprehensive business continuity measures
• Sound ICT third-party risk monitoring & dependency mapping

DORA focuses on ICT risk from ICT vendors, so the points above are useful baselines for managing and achieving cyber resilience.

However, ICT risks can emanate from vendors that are not ICT vendors and/or those that aren’t deemed to be Critical Third-Party Providers (CTPP)- in other words cyber threat vectors go beyond CTPPs and ICT vendors.

A prime example of the expanded threat vector are Account Information Service Providers (AISPs). Similar to PSPs, AISPs are cited both in DORA and PSD2. DORA references their incident reporting responsibilities while in PSD2 they are cited as Third-Party Providers (TPPs) that access banking infrastructures via APIs.

Despite the inherently sensitive customer information handled by AISPs-account information – and the impact of data breaches on customers and the bank’s bottom line, they are not explicitly cited as CTPPs in DORA.

It follows that PSPs will undergo the vetting and approval process by the competent authorities to become a TPP and further measures under DORA due to their CTPP status. Other TPPs like AISPs on the other hand are unlikely to be subjected to the additional risk management layer if one only follows the letter of DORA.

Since the spirit of DORA is improving the operational resilience of the financial system, a broad cyber resilience approach would be to widen the risk lens beyond CTPPs and consider the threat of cyber incidents more broadly. DORA compliance is a good baseline for cyber resilience, but should not be regarded as cyber resilience itself.

How does GRC technology impact DORA adherence?

GRC platforms like SAI360 are the connecting tissue between disjointed processes that typically happen in systems that are not linked. Once a unified platform is the connection point for aggregating GRC data, DORA adherence is eased. This happens among others through automated risk & control management, digitised business continuity programmes, and responsive incident reporting workflows which eliminate the otherwise manual and duplicated efforts associated with risk frameworks.

Crucially, a joined-up approach facilitates the collaboration of stakeholders from different departments, enabling a fuller view of the risk dimensions of CTPPs for instance i.e. IT Departments assess ICT risks of a PSP in line with DORA during the onboarding process, then pass the data on to the Compliance Functions via the GRC platform.

Exchanging data between departments on a unified platform gives organisations a holistic risk view that builds on preceding assessments; Here the compliance department can now move on to assessing sanction risk exposure and continuous transaction monitoring to address vendor lifecycle risks in their domain (i.e. PSD2, AML, PCI DSS etc.), informed by the risk management groundwork of colleagues.

Therefore, data exchange and coordinated risk assessments drastically reduce administrative touchpoints and avoid ICT assessments that other departments might have already conducted in a different context.

Ultimately, the Regtech applications of GRC technology also ease the administrative burden on ICT vendors during DORA compliance processes, since duplicate assessments can be avoided by design as outlined in the onboarding example earlier.

[1] www.consilium.europa.eu/en/press/press-releases/2022/11/28/digital-finance-council-adopts-digital-operational-resilience-act/

[2] www.bankofengland.co.uk/-/media/boe/files/prudential-regulation/supervisory-statement/2021/ss121-march-22.pdf

[3] www.europarl.europa.eu/doceo/document/TA-9-2022-0381_EN.html