The Impending DORA Regulations Increase Operational Resilience Requirements Globally

Are you ready? Do you know what “ready” means?

The Digital Operational Resilience Act (DORA) is a critical piece of legislation passed by the European Union aimed at enhancing the digital operational resilience of financial entities. This regulation addresses the growing reliance on information and communication technology (ICT) and associated risks. It focuses on ensuring that the financial sector can withstand, respond to, and recover from, all types of ICT-related disruptions and threats.

Like the GDPR before it, DORA is not restricted to companies based in the EU. If your organization is a service provider to a financial entity that does business in the EU, you will most likely be impacted.

Under DORA, third-party service providers must adhere to stringent requirements to ensure the resilience of their services. Service quality requirements are particularly notable as they extend beyond traditional security and privacy issues. They encompass a broader range of operational and systemic risks, emphasizing the need for thorough risk management practices. Article 10: Governance of ICT Third-Party Risk requirements includes:

• General Obligations

  • Financial entities must ensure that their ICT third-party service providers are reliable and capable of maintaining the required level of operational resilience. This is notable as it explicitly extends beyond security and privacy requirements and implies additional controls, expenses, and regulatory obligations for both financial entities and third-party service providers.

  • Entities are required to manage and mitigate ICT third-party risks effectively, ensuring that their providers adhere to standards that uphold the security and operational resilience of the financial sector. This is analogous to the shared obligations of data owner and operator defined in the GDPR and other regulations. Financial entities cannot pass the liability on to their providers.

• Contractual Provisions

  • Key contractual clauses should cover service level agreements (SLAs), data protection measures, and incident management processes. SLAs and incident management processes must now include non-privacy and non-security considerations as well.

  • Contracts should also stipulate the right of the financial entities to conduct audits and access information necessary to assess compliance. Every additional audit and access obligation brings additional expense and its own risk. These are prime opportunities for automation and integration.

• Risk Management Requirements

  • Financial entities need to conduct thorough risk assessments to identify and address potential risks associated with ICT third-party services. Including additional non-security and non-privacy requirements.

  • This involves regular monitoring and evaluation of the performance and risk profile of the third-party providers. Including those additional non-security and non-privacy requirements.

• Reporting and Oversight Expectations

  • ICT third-party service providers must report significant incidents and changes that could impact the operational resilience of the financial entities they serve. The definition of “significant” is based upon operational risk framework rather than classic software bug classification and will require additional analysis and automation.

  • Financial entities should maintain effective oversight mechanisms, in addition to the contractual provisions, to ensure that third-party providers comply with DORA's requirements. Another important target for automation and ITSM and ITOM integration.

We are so conditioned to focus on security and privacy issues that there is a risk of developing tunnel vision and excluding non-security related defects that can also trigger outages and major disruptions. Here are some examples tied to their relevant articles.

• Race Conditions (Article 11(2)(b)): Race conditions in job scheduling software could delay or skip critical batch processes, impacting service delivery.

• Performance Testing Defects (Article 25): Defects in performance testing tools could generate excessive load, causing unintended service disruptions during testing.

• Data Processing Defects (Article 30(2)(e)): Defects in data processing could lead to incorrect data transformations, resulting in inaccurate reporting and decision-making.

• Compatibility Issues (Article 33(3)(f)): Compatibility issues between software and new operating system versions could cause unexpected behavior or system crashes during upgrades.

These are just a few examples to illustrate the wide range of issues that go beyond traditional security and privacy concerns, demanding a broader appreciation of operational resilience and compliance.

One of the many advantages of using third-party service providers is that their products and services are hardened by a much larger community of users and most critical issues are quickly identified by others. Providers publish known defects to minimize their impact on their userbase and, when combined with a service like BugZero, this same data can be leveraged to efficiently and effectively meet DORA’s operational resilience requirements as well.

Here is an expanded view on the examples cited above:

Non-Compliance Scenario

An ICT third-party service provider publishes a bug report disclosing a compatibility issue between their software and a new operating system version, which could cause unexpected behavior or system crashes during a planned upgrade, compromising the financial entity's ability to ensure the availability of ICT services.

Risk Mitigation

The monitoring system detects the compatibility bug report and the risk assessment engine evaluates its potential impact on the institution's planned system upgrades. The workflow system notifies the IT change management team and triggers a process to test the upgrade process in a controlled environment, identify and mitigate any compatibility issues, and coordinate with the third-party provider for a software update or workaround.

Non-Compliance Scenario

An ICT third-party service provider publishes a bug report revealing a race condition in their job scheduling software that could cause critical batch processes to be delayed or skipped, impacting the timely delivery of services and breaching the requirement for effective ICT response and recovery plans.

Risk Mitigation

The monitoring system identifies the race condition bug report and the risk assessment engine determines its potential impact on the entity's critical batch processes. The workflow system alerts the IT operations team and triggers a process to assess the affected job schedules, implement monitoring and alerts for delayed or skipped jobs, and work with the third-party provider to patch the race condition and ensure the reliability of the job scheduling process.

Non-Compliance Scenario

A bug report from a third-party performance testing tool indicates a defect that could cause the tool to generate excessive load on the tested systems, potentially leading to unintended service disruptions during testing and non-compliance with testing requirements.

Risk Mitigation

The monitoring system captures the performance testing tool bug report and the risk assessment tool analyzes its potential impact on the stability and availability of tested systems. The workflow system alerts the testing team and initiates a process to review and adjust the testing methodology, implement safeguards to prevent overload conditions, and collaborate with the third-party provider to resolve the defect in the testing tool.

Non-Compliance Scenario

A bug report from a third-party data processing service reveals a defect that could cause incorrect data transformations or aggregations, leading to inaccurate reporting and decision-making, and breaching the requirement for effective monitoring of ICT third-party risk.

Risk Mitigation

The monitoring system identifies the data processing bug report and the risk assessment tool determines its potential impact on data accuracy and integrity. The workflow system alerts the data governance team and initiates a process to validate the affected data sets, assess the impact on downstream processes, and engage with the third-party provider to resolve the defect and re-process the affected data.

By leveraging BugZero's capabilities, financial entities and their third-party providers can stay ahead of potential compliance issues, maintain operational resilience, and ensure the continuous delivery of critical services. This proactive approach aligns with DORA's requirements and helps mitigate a broad spectrum of risks, thereby enhancing the overall stability of the financial ecosystem.