The EU’s Digital Operational Resilience Act (DORA) will change how financial services test their security 

The EU’s Digital Operational Resilience Act (DORA) will change how financial services test their security 

Gareth Challonder, Security Subject Matter Expert at Spirent, takes us through the EU’s Digital Operational Resilience Act (DORA) and how the act will change the way financial services test their security and much more. 

Gareth Challonder, Security Subject Matter Expert at Spirent

By January, the Digital Operations Resilience Act (DORA) will come into force. Enacted by the European Commission, DORA aims to reinforce the cyber-resilience of financial institutions as a key part of European society. Their reasoning is that a failure in the security of these institutions may result in far ranging effects on other parts of society, specifically private and institutional account holders: They don’t want a cyberattack in the right place to cause serious and outsized economic damage.  

For DORA, cyber-resilience = economic resilience 

For that reason, DORA takes aim at financial institutions as potential points of failure in national economies. In fact, the DORA text states ‘the high level of interconnectedness across financial entities, financial markets and financial market infrastructures, and particularly the interdependencies of their ICT systems, could constitute a systemic vulnerability because localised cyber-incidents could quickly spread from any of the approximately 22,000 Union financial entities to the entire financial system, unhindered by geographical boundaries.’ 

The text later adds that serious ICT breaches could ‘smooth the way for the propagation of localised vulnerabilities across the financial transmission channels and potentially trigger adverse consequences for the stability of the Union’s financial system, such as generating liquidity runs and an overall loss of confidence and trust in financial markets.’ 

With that end in mind, DORA will make financial services engage in regular operational resilience testing which will include the examination of ICT systems, policies and procedures to evaluate their preparedness in case of an attack or incident. That will likely involve vulnerability assessments and penetration testing alongside other forms of testing. Certain institutions of sufficient size and importance may even be subject to nationally supervised Threat Led Penetration Tests (TLPT). 

Under its auspices, financial institutions will have to conduct regular testing of their IT risk management frameworks to test how effectively they can detect, respond to and protect against threats, and then how well they can recover. These tests will have to be risk-based thus focusing on the risks specific to the organisation doing the testing, improving their practices according to new threats and vulnerabilities. 

That testing will need to cover the most critical component, assets and systems – including everything from internal systems to third party providers – a given organisation possesses and validates that organisation’s ability to recover from an incident and ensure business continuity in the event of a disruption.  

On top of that, it all has to be documented, and the results of testing exercises have to be held onto to identify areas which can be improved and hopefully, the results of that improvement with each subsequent effort. This is partly to create a feedback loop and basis on which to continuously assess and improve upon test results and update response plans accordingly.  

One more compliance obligation 

Financial Services are one of the most regulated sectors around. DORA adds one more regime to comply with. From that point of view, it’s important to not just think about how DORA compliance will affect the sector individually, but as part of a larger body of regulation.  

The complexity of compliance in financial services is a dense thing. Given the international nature of finance, many financial services companies often find themselves having to comply with multiple different statutes in multiple different territories, across sectoral, government and private sectors. Given that a transaction or data handling procedure may start in one part of the world, retrieve data in another and then return to its location of origin, in doing so it may cross in and out of multiple territorially located regulatory regimes and sectoral compliance obligations, DORA included. Violation of any one of these will likely come with some form of penalty – financial or otherwise.  

It’s a startling amount of complexity that financial services have to deal with. That headache-inducing workload obviously falls upon stressed and overworked compliance departments who not only have to ensure compliance over a mountain of metrics but clearly document how they’re doing so. Many are even attempting to do so using largely manual processes and while that’s a herculean effort – against a backdrop of mounting regulatory complexity – no longer viable.  

Away from manual reactivity and towards pro-active automated compliance 

DORA and other regulations will actually require a wholesale change in the way we look at testing. Many financial services currently approach security testing as a reactive, periodic and check-box activity. That is the first thing that will have to change if we want to tackle DORA compliance. Instead, in the constantly evolving and complexifying landscapes of modern IT, testing will have to become a pro-active, continuous and automated task. This will effectively allow financial services sectors to continuously understand if they remain in compliance and how they fall out of it, while accommodating the constant change inherent in modern IT networks. Furthermore – and this is key – it will provide clear documentation that a particular network is taking the necessary steps to comply – not just that it is testing regularly but that its results are aligning to expected compliance goals.  

Some may try to do this manually. They will fail. To keep up with the shifting sands of threats, compliance obligations and technological evolution – this process must be as continuous and quick as the pace of change. Automated testing will bridge the critical gap between test and expedited automated remediation.