As impacted organizations start to look at DORA compliance, Michael Bratton considers its scope, highlights provisions that align to other regulations, and outlines areas that may help practitioners seeking to build cohesive resilience programs and frameworks that encompass multiple risk disciplines.
The Digital Operational Resilience Act (DORA) establishes a framework and regulatory guidance for organizations to manage and address ICT and cyber related risks and threats. DORA entered into force on 16th January 2023. With an implementation period of two years, financial entities will be expected to be compliant with the regulation by 17th January 2025 and is applicable to financial entities and service providers in the EU and their ICT providers. DORA is unique in that it not only applies to financial institutions directly but also to the ICT providers that provide critical services to the financial sector.
DORA requirements are expansive, spanning 50+ articles. While DORA’s focus is aimed at digital and cyber resilience, there are numerous integration points with other risk disciplines, such as crisis management, operational risk, business continuity, and operational resilience.
As a resilience practitioner, I couldn’t help but wonder how much of what is in DORA runs parallel to other regulations and where it might help or hurt to support organizations that are already working to align and mature operational resilience and business continuity programs. This article will explore the basics of DORA, highlight provisions that align to other regulations, and ultimately, outline areas that may provide additional weight or guidance to practitioners seeking to build cohesive resilience programs and frameworks that encompass multiple risk disciplines.
What’s in DORA?
The regulation outlines five key requirements providing direction on:
- Information and Communication Technology (ICT) risk management
- Reporting of major ICT-related incidents to the competent authorities by financial entities
- Digital operational resilience testing
- Information and intelligence sharing in relation to cyber threats and vulnerabilities
- Measures for the sound management of ICT third-party risk by financial entities.
While seemingly straightforward, DORA’s mandate is broad, covering those ICT resources supporting critical or important functions which are defined as “a function whose disruption would materially impair the financial performance of a financial entity, or the soundness or continuity of its services and activities or whose discontinued, defective or failed performance would materially impair the continuing compliance of a financial entity with the conditions and obligations of its authorization, or with its other obligations under applicable financial services legislation.” Better stated, any ICT resources that, if disrupted, affected the financial performance of the entity, safety and soundness of the entity, or those services that are obligated to other firms, customers, or regulators would be in scope. This is somewhat broader than definitions of important/critical business services seen in other operational resilience regulations but unsurprising given that DORA refers to important functions (not services).
Who must comply with DORA?
The Regulation provides a lengthy list of sectors of which most would be similar to other financial sector regulations. T hese include: credit institutions, payment institutions, electronic money institutions, investment firms, crypto-asset service providers, central securities depositories, central counterparties, trading venues, trade repositories, managers of alternative investment funds, management companies, data reporting service providers, insurance and reinsurance undertakings, insurance intermediaries, institutions for occupational retirement pensions, credit rating agencies, statutory auditors and audit firms, administrators of critical benchmarks, crowdfunding service providers, securitization repositories, and ICT third-party service providers.
The interesting thing to note here is the requirement that ICT third-party service providers are included in the regulation, meaning that those IT/ICT firms providing services to those in the financial sector will now be required to align to the same regulations that financial institutions are beholden to. For continuity and resilience professionals, this provides some additional leverage where it has been somewhat challenging to enlist compliance with ICT third parties, unless requirements were explicitly stated in contracts.
Where does DORA intersect with other resilience-related regulations?
Different regulations covering similar risk-related activities can be difficult to navigate, but in DORA’s case, many provisions are aligned to either existing best practices or regulation. While DORA has numerous examples of requirements that cater to managing technology-related risk, for purposes of this article, I want to highlight those operational resilience and continuity-related requirements that create a need for those practitioners working on DORA to coordinate with existing continuity and resilience efforts.
Business continuity policy
DORA stipulates that as part of the ICT framework, organizations will also need to establish a comprehensive ICT business continuity policy. The regulation notes that this is designed to allow organizations to build on existing best practices; however, the requirement also requires that there is significant consideration given to business continuity and IT disaster recovery plans, particularly in response to a cyber attack. Adapting technology loss scenarios used for planning while simultaneously considering how a cyber attack could alter response and recovery can help practitioners prepare for cyber events more holistically.
Technology recovery
While more so around technology risk, some of DORA’s requirements documented in Article 11 (Backup policies and recovery methods) are worth being aware of for practitioners. DORA highlights the need for financial entities or their ICT providers to maintain at least one secondary processing site with resourcing commensurate with business need. DORA also outlines requirements for a secondary site which include the secondary site being:
- Geographically separated so that it has a distinct risk profile,
- Capable of ensuring continuity of critical services identically to the primary site (or at least in line with RTO/RPO requirements)
- Available to the staff for access.
Lessons learned
DORA outlines the need that the results and lessons learned from ICT tests, disruptions, and cyber events should be made available to counterparts and regulators and should also feed back into the overall risk management framework. By forcing post-test/incident reviews and postmortems, this creates a situation where practitioners can use the resulting information to help drive other requirements, such as identifying plausible scenarios, looking at what worst case scenarios could have been (to help set impact tolerances), and identifying alignment to RTO/RPO. All of this information can assist continuity and resilience practitioners with BC and op res initiatives to create holistic risk management approaches.
Crisis management and communications planning
Similar to requirements set by the CBI, DORA has specific provisions around maintaining the ability to perform crisis communications when faced with significant disruption. DORA highlights that communication plans consider both technical and non-technical staff and identify public spokespersons. Additionally in Article 10, DORA mandates that entities “have a crisis management function” to coordinate activities. This further codifies many best practices that many organizations have in place to maintain a command-and-control structure during a disruption that isn’t solely staffed with technical expertise.
Testing and exercising
DORA provides numerous examples of the types of testing that are applicable for ICT testing, such as vulnerability assessments, open-source analyses, network security assessments, gap analyses, physical security reviews, questionnaires and scanning solutions, code reviews, scenario-based tests, compatibility testing, end-to-end testing, or penetration testing. Many of these test types could also be used in conjunction with operational resilience requirements, such as conducting end-to-end and scenario-based testing. These types of tests could be layered in resilience stress testing plans and used to substantiate that an organization could remain within stated impact tolerances.
Third-party risk management
One of the unique aspects of DORA is some of the detail it provides on relationships with ICT providers. For example, DORA outlines steps that organizations will need to take prior to engaging in a relationship with an ICT third-party, such as determining if the provider will support critical/important functions and if the third-party could aggravate concentration risk. This provides the opportunity for collaboration with continuity and resilience teams who could assist by leveraging the results of a business impact analysis or end-to-end mapping to determine the potential criticality of a third-party. Additionally, there are requirements around the ability to exit a given contract in certain circumstances and pressure put on ICT providers to retain the same level of security for a financial institution. I believe these requirements will benefit risk practitioners who often have the unenviable task of identifying a third-party or concentration risk but lack the authority to enforce or keep the business from entering certain relationships.
A few final thoughts
While DORA may seem like yet another cyber regulation, it also provides benefit for business continuity and resilience practitioners, particularly for those practitioners working in organizations that may have struggled with technology risk being siloed. In many ways, DORA forces organizations to look at technology risk in new ways, leveraging and building off other risk disciplines where possible, whether its business continuity, operational resilience and risk, or third-party risk management. This article has only focused on those parts of DORA that provide a direct intersection with business continuity and operational resilience regulations and initiatives, but DORA also includes numerous requirements around incident management, sharing of information, and more clarity around technical testing, particularly for larger institutions. Building comprehensive and holistic risk management programs that leverage the strengths of different disciplines can help improve the overall resilience of your organization and the financial sector.
The author
Michael Bratton is Principal Consultant at Riskonnect.
link
