Security Strategy & DORA
Since the EU imposed the Digital
Operational Resilience Act (DORA) on financial institutions, I have come across
very different ways they go to deal with this January 2025 spell... In my mind,
DORA has always been an outsider.
It pretends to be a security standard that the financial world is requested to hold on to. But unlike ISO 2700x or NIST, DORA is
a) legally binding and enforceable by a governmental organization, b) considerably less detailed/prescriptive.
Let’s talk the legal element here. Is it really going to have a positive effect on the security posture of the EU’s financial sector? Senior management of financial institutions see their playground through one lens – and that’s the bottom line.
The experience has already sufficiently taught them that if they’re not well protected against cyber threats, they will likely end up in red. If they treat their bottom line responsibly, they have already implemented one of the most common security standards such as ISO and/or NIST (most often I see ISO aligned to NIST) and they take care that the next audit re-confirms their security posture.
Now DORA has jumped in and organizations have been forced to set aside budgets for the sole purpose of trying to interpret the very broad DORA legal text, identifying possible gaps in their security controls (dependent on that interpretation), and, most importantly, figuring out how to best present their existing security policies and controls to the Regulator so that they get the final stamp of compliance.
This is why for many organizations, DORA is just an expensive burden that needs to be synchronized with the organization’s existing security strategy, policies, and controls (as well as compensating controls). In cases where the organization does not have a required policy or specific security control in place yet, often when their ISO 2700x certification is (not yet) in the initial stages, a real battle starts.
First of all – a million $ question needs to be answered: to what extent does this and that requirement need to be met? Where is the thin red (non-)compliance line? And truly, even a small shift to the left or right in the level of that meeting-the-requirement effort can make a multi-million $ difference in the organization’s budget.
A qualitative and quantitative risk analysis may give us just a very rough estimate of where that red line might stand. At the same time, no one is willing to be held accountable for answering the question what the minimum viable product is. DORA legal text itself does not even display any ambition to answer that. The RTS/ITS may have had that ambition - at least us, hands-on people, do seek support in that document as a last resort, usually without the desired result. And despite the EBA’s public hearings and open-door feedback approach, the RTS/ITS won’t fulfill that mission.
As a matter of fact, ISO and NIST security standards are detailed and structured enough and do not require any more specification. I value ISO specifically for using the nuance between “should” and “shall” to say clearly what’s a must-have and what’s a nice-to-have. My bottom line is that from financial, strategic, and technical perspective, it would have been wiser for the EU to oblige the financial sector to obtain the ISO 2700x certification by that January 2025 deadline, rather than create an own standard that lacks any history, industry experience, and the important thing called “custom” in legal world that could make interpretation and definition of minimum viable product easier.
Therefore, the most reasonable security strategy currently is to continue efforts to become/keep compliant with the ISO 2700x standard, allocate budget to work on and maintain a good ISMS, and only thirdly, set out on the road of ISO-DORA alignment in the sense of using the ISO compliance evidence as DORA compliance evidence to the maximum possible extent. Challenge me if you have a different strategy in your pocket that you believe could result in a better security posture with the same (or smaller) budget. Diana Prusova
It pretends to be a security standard that the financial world is requested to hold on to. But unlike ISO 2700x or NIST, DORA is
a) legally binding and enforceable by a governmental organization, b) considerably less detailed/prescriptive.
Let’s talk the legal element here. Is it really going to have a positive effect on the security posture of the EU’s financial sector? Senior management of financial institutions see their playground through one lens – and that’s the bottom line.
The experience has already sufficiently taught them that if they’re not well protected against cyber threats, they will likely end up in red. If they treat their bottom line responsibly, they have already implemented one of the most common security standards such as ISO and/or NIST (most often I see ISO aligned to NIST) and they take care that the next audit re-confirms their security posture.
Now DORA has jumped in and organizations have been forced to set aside budgets for the sole purpose of trying to interpret the very broad DORA legal text, identifying possible gaps in their security controls (dependent on that interpretation), and, most importantly, figuring out how to best present their existing security policies and controls to the Regulator so that they get the final stamp of compliance.
This is why for many organizations, DORA is just an expensive burden that needs to be synchronized with the organization’s existing security strategy, policies, and controls (as well as compensating controls). In cases where the organization does not have a required policy or specific security control in place yet, often when their ISO 2700x certification is (not yet) in the initial stages, a real battle starts.
First of all – a million $ question needs to be answered: to what extent does this and that requirement need to be met? Where is the thin red (non-)compliance line? And truly, even a small shift to the left or right in the level of that meeting-the-requirement effort can make a multi-million $ difference in the organization’s budget.
A qualitative and quantitative risk analysis may give us just a very rough estimate of where that red line might stand. At the same time, no one is willing to be held accountable for answering the question what the minimum viable product is. DORA legal text itself does not even display any ambition to answer that. The RTS/ITS may have had that ambition - at least us, hands-on people, do seek support in that document as a last resort, usually without the desired result. And despite the EBA’s public hearings and open-door feedback approach, the RTS/ITS won’t fulfill that mission.
As a matter of fact, ISO and NIST security standards are detailed and structured enough and do not require any more specification. I value ISO specifically for using the nuance between “should” and “shall” to say clearly what’s a must-have and what’s a nice-to-have. My bottom line is that from financial, strategic, and technical perspective, it would have been wiser for the EU to oblige the financial sector to obtain the ISO 2700x certification by that January 2025 deadline, rather than create an own standard that lacks any history, industry experience, and the important thing called “custom” in legal world that could make interpretation and definition of minimum viable product easier.
Therefore, the most reasonable security strategy currently is to continue efforts to become/keep compliant with the ISO 2700x standard, allocate budget to work on and maintain a good ISMS, and only thirdly, set out on the road of ISO-DORA alignment in the sense of using the ISO compliance evidence as DORA compliance evidence to the maximum possible extent. Challenge me if you have a different strategy in your pocket that you believe could result in a better security posture with the same (or smaller) budget. Diana Prusova