Operational Resilience now mandated for EU Financial Institutions
The safety and resilience of financial and credit institutions will soon be enforced by the Digital Operational Resilience Act and applicable to any of the relevant institutions doing business in the European Union.
With the deadline less than a year away (enforcement begins on 17th January 2025), enterprises need a clear path to compliance that they can implement and maintain.
DORA outlines five critical areas where organizations must adhere to technical specifications:
The overarching goal is to maintain the resilience of the financial system as a whole, minimizing disruption, and downtime, and ensuring business continuity.
What does this mean for the IT network, in the context of large enterprises? Here's three things to keep in mind as you prepare for DORA.
This regulation will bring renewed focus to identifying and classifying your critical business functions. In DORA, with respect to the financial industry, these are defined as areas where "the disruption of which would materially impair the financial performance of a financial entity, or the soundness or continuity of its services and activities, or the discontinued, defective or failed performance of that function would materially impair the continuing compliance of a financial entity." (DORA Article 3).
Ultimately, a key goal of DORA is business continuity. While it may seem very clear to network operators how critical continued network services are to the health and success of the business, in the context of a large organization, business leaders may not understand just how reliant their business is on the operational resilience of the network. A network compliance issue can be the first domino in costly, reputation-damaging business interruptions.
They don't know the scale of change (planned, and unplanned) network operators are managing day to day; they don't understand the complexity of dealing with different technologies and vendors, to satisfy ever-changing business operations; they don't understand that securing a network against a growing threat landscape is a continuous activity.
That said, as DORA compliance escalates to top priority - there are, after all, criminal penalties for non-compliance (DORA Article 52) - the network will take the spotlight as key to understand, visualize, and report on.
This fresh attention to what might have been previously relegated to "plumbing" or a cost center in the minds of leadership will unlock resources network engineers have been desperately needing for years, but also scrutiny. And let's be clear, the first question will be "Where's your network documentation?"
This leads us to point 2...
The regulations put forth in DORA make it clear that it's not enough to assume compliance - financial entities have a burden of proof, and must (both internally, and externally) continuously validate their compliance.
Exactly what this proof will look like might differ by organization (there is also a proportionality principle to note within DORA), but it includes, for example:
All this proof must be reported in the manner, and through the mechanisms specific in Pillar 2 - ICT-related incident management, classification, and reporting - and the Regulatory Technical Standards that will specify the harmonization and centralization of DORA compliance reporting.
That said, the appointed overseers and responsible parties might not be networking experts, so raw network data won't be of much use. Which brings us to point 3...
A lot of DORA is principles-based; not necessarily specifying exact policies or technologies to implement, but more so about having the right people, planning, and frameworks in place to provide continuous oversight.
It's key to note that there's a lot that must be communicated to business leaders, clients, and stakeholders in the event of an ICT-related incident, for example "to relevant senior management and inform the management body of at least major ICT-related incidents, explaining the impact, response and additional controls to be established as a result" and to "clients about the major ICT-related incident and about the measures that have been taken to mitigate the adverse effects of such incident" (Article 17).
It's easy to imagine, then, in the event of a network-based ICT-related incident, that there is specific and complicated network information that must be made available and consumable for the above-mentioned parties.
These are just three threads to pull at as DORA crystallizes into clear specifications for financial entities and the IT networks that underpin them. As the scramble to assure and prove compliance starts, we'll keep an eye on the challenges and themes emerging for network teams.
For now, the best way to prepare is to ensure that your team has a comprehensive and accurate network understanding; an accurate inventory; clear and complete documentation; a mechanism to visualize the network and its interconnections and dependencies; and a realistic and feasible way to keep this all up-to-date and therefore, useful.
For more information on IP Fabric's network assurance platform, reach out to the team or try our self-guided online demo.
Operational Resilience now mandated for EU Financial Institutions
The safety and resilience of financial and credit institutions will soon be enforced by the Digital Operational Resilience Act and applicable to any of the relevant institutions doing business in the European Union.
With the deadline less than a year away (enforcement begins on 17th January 2025), enterprises need a clear path to compliance that they can implement and maintain.
DORA outlines five critical areas where organizations must adhere to technical specifications:
The overarching goal is to maintain the resilience of the financial system as a whole, minimizing disruption, and downtime, and ensuring business continuity.
What does this mean for the IT network, in the context of large enterprises? Here's three things to keep in mind as you prepare for DORA.
This regulation will bring renewed focus to identifying and classifying your critical business functions. In DORA, with respect to the financial industry, these are defined as areas where "the disruption of which would materially impair the financial performance of a financial entity, or the soundness or continuity of its services and activities, or the discontinued, defective or failed performance of that function would materially impair the continuing compliance of a financial entity." (DORA Article 3).
Ultimately, a key goal of DORA is business continuity. While it may seem very clear to network operators how critical continued network services are to the health and success of the business, in the context of a large organization, business leaders may not understand just how reliant their business is on the operational resilience of the network. A network compliance issue can be the first domino in costly, reputation-damaging business interruptions.
They don't know the scale of change (planned, and unplanned) network operators are managing day to day; they don't understand the complexity of dealing with different technologies and vendors, to satisfy ever-changing business operations; they don't understand that securing a network against a growing threat landscape is a continuous activity.
That said, as DORA compliance escalates to top priority - there are, after all, criminal penalties for non-compliance (DORA Article 52) - the network will take the spotlight as key to understand, visualize, and report on.
This fresh attention to what might have been previously relegated to "plumbing" or a cost center in the minds of leadership will unlock resources network engineers have been desperately needing for years, but also scrutiny. And let's be clear, the first question will be "Where's your network documentation?"
This leads us to point 2...
The regulations put forth in DORA make it clear that it's not enough to assume compliance - financial entities have a burden of proof, and must (both internally, and externally) continuously validate their compliance.
Exactly what this proof will look like might differ by organization (there is also a proportionality principle to note within DORA), but it includes, for example:
All this proof must be reported in the manner, and through the mechanisms specific in Pillar 2 - ICT-related incident management, classification, and reporting - and the Regulatory Technical Standards that will specify the harmonization and centralization of DORA compliance reporting.
That said, the appointed overseers and responsible parties might not be networking experts, so raw network data won't be of much use. Which brings us to point 3...
A lot of DORA is principles-based; not necessarily specifying exact policies or technologies to implement, but more so about having the right people, planning, and frameworks in place to provide continuous oversight.
It's key to note that there's a lot that must be communicated to business leaders, clients, and stakeholders in the event of an ICT-related incident, for example "to relevant senior management and inform the management body of at least major ICT-related incidents, explaining the impact, response and additional controls to be established as a result" and to "clients about the major ICT-related incident and about the measures that have been taken to mitigate the adverse effects of such incident" (Article 17).
It's easy to imagine, then, in the event of a network-based ICT-related incident, that there is specific and complicated network information that must be made available and consumable for the above-mentioned parties.
These are just three threads to pull at as DORA crystallizes into clear specifications for financial entities and the IT networks that underpin them. As the scramble to assure and prove compliance starts, we'll keep an eye on the challenges and themes emerging for network teams.
For now, the best way to prepare is to ensure that your team has a comprehensive and accurate network understanding; an accurate inventory; clear and complete documentation; a mechanism to visualize the network and its interconnections and dependencies; and a realistic and feasible way to keep this all up-to-date and therefore, useful.
For more information on IP Fabric's network assurance platform, reach out to the team or try our self-guided online demo.
