Meet us at Cisco Live Las Vegas 2024
Home
>
Blog
>
DORA requires proving operational resilience in your network
| | |

DORA requires proving operational resilience in your network

4 minute read
Home
>
Blog
>
DORA requires proving operational resilience in your network
Updated: April 3, 2024
March 25, 2024
Updated: April 3, 2024
4 mins

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:

  1. Information and Communication Technology (ICT) risk management
  2. ICT-related incident management, classification, and reporting
  3. Digital operations resilience testing
  4. ICT third-party risk
  5. Information Sharing

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.

1. The network in the spotlight; renewed focus, but also scrutiny

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.

tom wilson KvvAkN ZKEM unsplash

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...

2. Proving compliance is as important as being compliant

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:

  • WIthin Pillar 1, ICT Risk Management: Mapping configuration of information assets and ICT assets and the links and interdependencies between the different information assets and ICT assets. (DORA Article 8).
  • Within Pillar 3, Testing: Internal validation methodologies to ascertain that all identified weaknesses, deficiencies or gaps are fully addressed. (DORA Article 24)
  • Also Within Pillar 3, Testing: Conduct network security assessments (DORA Article 25)

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...

3. Network Data will (necessarily) become very interesting to non-experts

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.

Non-experts need key network information to ensure DORA compliance.

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.

Conclusion

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.

DORA requires proving operational resilience in your network

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:

  1. Information and Communication Technology (ICT) risk management
  2. ICT-related incident management, classification, and reporting
  3. Digital operations resilience testing
  4. ICT third-party risk
  5. Information Sharing

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.

1. The network in the spotlight; renewed focus, but also scrutiny

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.

tom wilson KvvAkN ZKEM unsplash

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...

2. Proving compliance is as important as being compliant

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:

  • WIthin Pillar 1, ICT Risk Management: Mapping configuration of information assets and ICT assets and the links and interdependencies between the different information assets and ICT assets. (DORA Article 8).
  • Within Pillar 3, Testing: Internal validation methodologies to ascertain that all identified weaknesses, deficiencies or gaps are fully addressed. (DORA Article 24)
  • Also Within Pillar 3, Testing: Conduct network security assessments (DORA Article 25)

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...

3. Network Data will (necessarily) become very interesting to non-experts

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.

Non-experts need key network information to ensure DORA compliance.

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.

Conclusion

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.

SHARE
Demo

Try out the platform

Test out IP Fabric’s automated network assurance platform yourself and be inspired by the endless possibilities.

What would this change for your network teams?
Start live demo
 
 
 
 
 
We're Hiring!
Join the Team and be part of the Future of Network Automation
Available Positions
98 North Washington Street
Suite 407
Boston, MA 02114
United States
This is a block of text. Double-click this text to edit it.
Phone : +1 617-821-3639
IP Fabric s.r.o.
Kateřinská 466/40
Praha 2 - Nové Město, 120 00
Czech Republic
This is a block of text. Double-click this text to edit it.
Phone : +420 720 022 997
IP Fabric UK Limited
Gateley Legal, 1 Paternoster Square, London,
England EC4M 7DX
This is a block of text. Double-click this text to edit it.
Phone : +420 720 022 997
IP Fabric, Inc. © 2024 All Rights Reserved