What D.O.R.A means for your security team

From January 2025, all UK financial organisations that do business in the EU must comply with the new Digital Operational Resilience Act (DORA). In all honesty, it’s a new regulation that forces organisations to do many things that they should have been doing for years. Most financial organisations will breeze through requirements such as red team assessments, business continuity policies and disaster recovery plans because they are already complete. Indeed, many DORA requirements are covered by other regulations, making it a relatively low bar to step over.  

That’s not to say that DORA is meaningless. Not at all. It’s a useful addition to the regulatory landscape. First and foremost, it is a simple, common sense backstop regulation that enforces best practice without being overly prescriptive. Like the GDPR, it rarely cites specific tools/products, but instead focuses on outcomes and best practice. This is beneficial in such a fast-moving sector, as cybersecurity regulations can quickly become outdated or useless if they get too bogged down in the minutia. In my opinion, I also think that DORA does a fantastic job of outlining all the ways that a good Security Operations Centre (SOC) should work. It doesn’t tell companies that they need a dedicated SOC or a specific SEIM, SASE or EDR product. It outlines requirements that can be met in several ways, and many organisations will outsource a lot of them to their SOC team. If you read between the lines, DORA is telling organisations to get a SOC, and get their SOC up to scratch.  

The SOC plays an important role in meeting the broader aims of the act (operational resiliency), as well as many of the specifics requirements/articles contained therein. There are several articles contained in the final text that read like SOC best practice guidelines, or outline areas that distinguish good SOCs from bad ones. 

Article 9, Protection and prevention – There are several lines in article 9 that highlight the importance of the ongoing protection and prevention capabilities offered by a good SOC, which don’t directly compel organisations to build a SOC team. For instance 

“continuously monitor and control the security and functioning of ICT systems and tools”  

“maintain high standards of availability, authenticity, integrity and confidentiality of data.” 

“ensure that data is protected from risks arising from data management, including poor administration, processing-related risks and human error.” 

Article 10, Detection – DORA states that Financial entities must be able to “monitor user activity”, “promptly detect anomalous activities” as well as identify “ICT-related incidents” and “potential material single points of failure”. Furthermore, they need must be able to “enable multiple layers of control” and “trigger and initiate ICT-related incident response processes”.  

Whether an organisation has its own in-house team or is outsourcing its SOC requirements to a third party, these are exactly the kind of detection activities that organisations  would expect from a good SOC. The best SOCs are not like a help desk responding to alerts. They engage in threat hunting, they proactively search for anomalies, and they stitch together data from all remote endpoints, the network and the cloud.  

Article 11, Response and recovery – The various “arrangements, plans, procedures and mechanisms”outlined in this article include: 

“ensure continuity of critical functions”

“quickly, appropriately and effectively resolve ICT-related incidents”

“limit damage and prioritise the resumption of activities and recovery actions”

“activate dedicated plans that enable containment measures, processes and technologies”

“set out communication and crisis management actions 

“ensure that updated information is transmitted to all relevant internal staff and external stakeholders”

Again, I struggle to understand how an organisation could hope to comply with this section without a dedicated SOC team. The SOC team should be central to any organisation’s response and recovery process, even if it also involves the introduction of additional digital forensics and incident response services. You need a team on the ground who knows the full intricacies of the IT estate before the breach, as well as external IR teams. 

Article 7, ICT systems, protocols and tools – This section speaks to a major challenge facing security teams and traditional first generation SOCs. An organisation’s IT estate and technology requirements can change fast, and so does their security ecosystem.  Due to sprawling IT estates and the growing number of alerts generated by organisations’ many security tools, security teams must ingest and analyse huge volumes of information. Under DORA, companies must be “equipped with sufficient capacity to accurately process the data necessary for the performance of activities and the timely provision of services, and to deal with peak orders, message or transaction volumes, as needed, including where new technology is introduced;  

This underscores the need to stay on top of IT sprawl and appoint security resources that can scale with demand / potential threats. Unfortunately, some SOCs will purposely limit the amount of data they ingest, potentially missing important alerts, or charge high fees to ingest more data. These are important considerations for the security and finance teams alike.  

Getting ready for DORA

As stated in the introduction, DORA is not prescriptive, and it does not tell financial organisations to get a SOC. However, it’s clear from a lot of the key articles and the language therein that building a SOC team or outsourcing a third party SOC would go a long long way to ensuring compliance. If you read between the lines, you could argue that DORA essentially makes having a good SOC mandatory.  

As we look ahead to Jan 2025, I think all financial organisations will either be finding a new SOC, or finetuning their current processes.