Risk Management: Are You Ready for DORA?

[#1]

The Digital Operational Resilience Act (DORA) is a EU regulation that entered into force on 16 January 2023 and will apply as of 17 January 2025. Are you ready?

What is DORA?

The Digital Operational Resilience Act (DORA) is an EU regulation designed to strengthen the digital resilience of the financial sector. Enacted in 2022, DORA sets uniform standards for managing Information and Communication Technology (ICT) risks across financial institutions. It requires firms to adopt robust measures to detect, mitigate, and recover from ICT incidents, ensuring that operations remain functional during disruptions like cyberattacks. DORA also consolidates existing regulations into a cohesive framework, mandating regular ICT risk assessments, incident reporting, and resilience testing. A key aspect is the regulation of third-party ICT providers, like cloud services, to ensure their compliance with resilience standards. DORA aims to safeguard the stability of the EU’s financial system by addressing growing risks from increased digital interconnectivity, enhancing operational resilience across all financial institutions and their digital partners.

Why is DORA Being Implemented?

DORA addresses the financial sector’s growing reliance on digital infrastructure, which makes it more vulnerable to cyber threats and ICT disruptions. With financial services increasingly interconnected, an ICT failure in one institution can spread rapidly, destabilizing entire markets. DORA aims to prevent these risks by ensuring financial entities have strong digital resilience systems. It also harmonizes ICT risk regulations across EU member states, eliminating inconsistencies in national rules that previously complicated compliance for cross-border institutions. Another reason for DORA’s implementation is the rise of third-party ICT providers, like cloud services, which introduce new risks. DORA’s oversight framework ensures that these critical providers meet the same standards as financial entities, safeguarding the entire financial ecosystem.

Who is Affected by DORA?

DORA applies to a wide range of financial entities, including banks, insurance companies, investment firms, and payment service providers. Approximately 22,000 financial institutions in the EU are affected. Critical ICT third-party service providers, such as cloud and data service providers, are also within its scope. These third-party providers must adhere to the same stringent standards for operational resilience, ensuring they can support financial institutions securely. While larger firms face more comprehensive requirements, small and micro-enterprises are subject to a simplified version of the regulation. DORA is designed to cover the entire financial ecosystem, ensuring that all players, large or small, contribute to the sector’s digital resilience.

What are My Obligations Under DORA?

Under DORA, financial entities must implement strong ICT risk management frameworks, regularly assess and test their resilience, and promptly report major ICT incidents to the relevant authorities. They are required to have policies in place for detecting, managing, and recovering from ICT-related disruptions. Third-party ICT service providers, especially those deemed critical, must also comply with these standards, ensuring they can support their financial clients securely. Financial institutions must oversee their third-party providers, ensuring they meet all DORA obligations. Smaller firms may have fewer obligations but still need to maintain basic resilience standards. The goal is for all entities, regardless of size, to be prepared to handle ICT incidents and maintain continuous operations.

What Happens if I Ignore DORA?

Failure to comply with DORA can lead to significant consequences for financial institutions and third-party ICT service providers. Regulatory authorities have the power to impose substantial fines and penalties, depending on the severity of non-compliance. Additionally, non-compliance could lead to increased regulatory scrutiny, audits, and corrective measures, which can be both costly and time-consuming for an organization.

Beyond financial penalties, non-compliance with DORA exposes an organization to increased risks, such as cyberattacks, operational disruptions, and damage to its reputation. Since DORA aims to enhance the digital resilience of the financial sector, any failure to comply with its standards can result in vulnerabilities that threaten not only individual institutions but also the broader financial system.

In extreme cases, systemic failures in digital resilience may lead to loss of customer trust, legal liabilities, and disruptions in the provision of essential financial services, amplifying the risks to the entire sector

How Can Risk Register Help Me with DORA?

Risk Register by ProjectBalm can significantly streamline your compliance with DORA by providing an integrated platform for managing digital operational risks. DORA mandates that financial entities implement robust ICT risk management frameworks. Risk Register helps meet this requirements by allowing you to systematically identify, assess, and manage risks within your organization, all while integrating directly into your existing Jira environment.

With Risk Register, you can easily set up a centralized repository for tracking all identified risks, including those related to ICT vulnerabilities. The platform enables you to categorize risks, assign responsibilities, and track mitigation efforts, ensuring your organization stays compliant with DORA's stringent requirements. Additionally, Risk Register supports advanced reporting features, including real-time dashboards, which help in tracking the progress of risk mitigation and reporting incidents efficiently.

By using Risk Register, your organization can enhance its digital resilience, meet DORA’s compliance standards, and ensure that operational disruptions are minimized and effectively managed.

Risk Register Set Up

The following guide shows you how to set up Risk Register to help you comply with DORA.

Step 1: Set Up Risk Models

Risk models enable you to assess the risks within your organization. These models will reflect your organization's risk tolerance levels and help you make informed decisions about priority and treatment. Below are the steps to set up risk models in Risk Register by ProjectBalm:

Full explanations of the following screens, including screenshots, can be found here.

1. Access Risk Models:

   • Navigate to the Risk Register settings in Jira.

   • Select "Risk models" from the settings menu.

2. Create or Edit Risk Models:

   • Click on "Add a risk model" to create a new model or select an existing model to edit.

   • Define the risk model name and associate it with relevant projects.

3. Set Impact and Probability Levels:

   • Customize the impact and probability levels to align with your organization's risk criteria.

4. Configure the Risk Matrix:

   • Use the risk matrix to map out the risk levels resulting from different combinations of impact and probability.

   • Ensure the matrix accurately reflects your organization's risk tolerance by adjusting the cells to represent appropriate risk levels (e.g., Low, Medium, High, Critical).

5. Define Risk Criteria:

   • Establish clear criteria for evaluating risks. This includes thresholds for acceptable risk levels and guidelines for prioritizing risks based on their severity. Record these in the descriptions of the impact and probability levels.

Step 2: Create Projects to Capture Risk Information

Having set up your risk models, you must create projects in Jira to capture risk information. There are two approaches to this, which can co-exist:

1. Utilize Existing Jira Projects:

   • For project-based risks, you can use the existing Jira projects to capture risks related to those projects.

   • If required, integrate risk management into the project's workflow to ensure risks are identified and managed throughout the project lifecycle.

2. Organizational Risk Register:

   • You can also create a dedicated Jira project to contain risks. 

   • This is often the preferred approach for organizational or enterprise risk management, but is also sometimes done for project-based risks.

Step 3: Set Up Issue Types to Capture Risk Information

Your organization must decide which issue type will hold risk information. While it’s possible to use any existing issue type, including existing ones such as “Task,” organizations most often choose to set up a dedicated risk issue type:

Create a Risk Issue Type:

• Set up a new issue type in Jira called "Risk."

• Set this as your primary risk type. This ensures that essential risk information such as impact, probability, and level will appear on the issue. 

• Add fields for additional risk information you wish to include, such as description, assignee, priority, and so on.

Step 4: Define Project Access in Jira

Defining appropriate access levels is crucial for ensuring that only authorized personnel can view and manage risk information. This ensures the integrity and security of your risk management processes. This document provides detailed information about permissions in Risk Register by ProjectBalm. Below is a summary of the key information:

Role-Based Access Control:

1. Global Administrator:

   • View and change application settings.

   • Add and change risk models.

   • Delete risk registers.

   • View and change risk register settings.

2. Jira Administrator:

   • Create new projects and new risk registers based on those projects.

   • Assign global and project-specific roles and permissions.

3. Project Administrator:

   • Create project-based risk registers if they have the necessary permissions.

   • View the list of risk registers for their projects.

   • Add, change, and remove risk assessments on issues.

4. Risk Owners and Team Members:

   • Edit issues (project permission) to add, change, and remove risk assessments.

   • View risk register settings if they have the appropriate permissions.

Specific Permissions Required:

1. Creating Risk Registers:

   • Project-Based Risk Register: Requires 'Create risk registers' permission and either Global Administrator, Project Administrator, or 'Browse projects' permission.

   • Filter-Based Risk Register: Requires 'Create risk registers' permission and access to the specified filter.

2. Viewing Risk Registers:

   • Risk registers will appear in the list if the user has the following permissions:

     • Project-Based Risk Registers: Global Administrator, Project Administrator, or 'Browse projects' permission.

     • Filter-Based Risk Registers: Permission to view the specified filter.

3. Modifying Risk Registers:

   • To change risk register settings, users must be a Global Administrator or Risk Register Administrator.

   • Note: Settings for multi-project risk registers cannot be changed.

4. Adding and Changing Risk Assessments:

   • Users need 'Edit issues' project permission to add, change, or remove risk assessments on issues.

Step 5: Create Risk Registers within the Projects

A risk register is a collection of risks that you can view. A risk register can be based on a project, in which case the register contains all of the risks in that project. However, it is also possible to create registers based on a filter. This is most commonly done in order to provide a multi-project view of the risks. Instructions for creating a risk register can be found here.

---

Download Risk Register by ProjectBalm Today!

---

Risk Management Process

The following general risk management process is compatible with the principles required by DORA:

Each step will be explained below, along with the implementation using Jira and Risk Register by ProjectBalm.

Risk Identification

The goal of risk identification is to recognize and describe risks that might help or hinder an organization in achieving its objectives.

Risk identification should take into account a variety of factors, including both tangible and intangible sources of risk, causes, events, vulnerabilities, capabilities, and changes in the external/internal context. It is also important to consider indicators of emerging risks, the nature and value of resources, and the potential impact on objectives. Additionally, the limitations of knowledge and the reliability of information, time-related factors, and biases, assumptions, and beliefs of those involved should be taken into account. Classic risk identification techniques can be found here.

Risk identification should be an ongoing process and integrated into the organization’s strategic and operational activities.

In project risk management, risk identification tends to happen at key stages such as during the project initiation phase, when developing project plans, at major milestones, and whenever there are significant changes to the project scope, resources, or environment. Regular risk reviews and updates are also conducted throughout the project lifecycle to capture new risks and reassess existing ones as the project evolves.

In organizational risk management, risk identification typically occurs during strategic planning sessions, annual reviews, and when there are changes in the external or internal business environment. This includes during mergers and acquisitions, entering new markets, launching new products or services, and changes in regulatory landscapes. 

Configuration in Risk Register:

• Create a Risk Issue: Create a Jira issue to represent the risk in the appropriate project. As mentioned above, this would most likely use a risk issue type.

• Risk Register Views: Utilize the risk register table and matrix views to track all identified risks.

Risk Analysis and Evaluation

Risk analysis involves a detailed consideration of the identified risk, including uncertainties, sources, relevant events, controls, impacts, and probabilities. The goal is to record all of this information in the risk issue, especially the impact and probability. 

Risk evaluation takes all of this information and assigns a risk level according to predetermined criteria. In Risk Register by ProjectBalm, the risk level is automatically calculated using the defined risk model, and so the analysis and evaluation steps have been combined in this guide. 

Configuration in Risk Register:

• Risk Assessment: Use the risk assessment panel to record probability and impact data for each identified risk..

• Risk Visualization: Use the risk matrix to visualize risks based on their assessed levels, providing a clear picture of their potential impact and likelihood.

Risk Treatment

The risk treatment process involves selecting and implementing measures to address risks identified during the risk assessment phase. Best practice requires this to be an iterative process of formulating risk treatment options, implementing risk treatment, assessing the effectiveness of the treatment, and deciding whether the remaining risk is acceptable. If the remaining risk is not acceptable, further treatment is required. 

Typical risk treatments include: 

• Avoiding the risk.

• Reducing the probability of the risk through mitigation.

• Reducing the impact of the risk through mitigation.

• Transferring the risk to another entity.

• Accepting the risk.

Risk treatment should be guided by the organization’s risk management policy, which should outline the criteria for selecting risk treatment options, the approach to implementing treatment plans, and the process for monitoring and reviewing the effectiveness of the treatments. The policy should ensure that risk treatment decisions are aligned with the organization’s objectives and risk appetite.

Treatment plans can be complex, with multiple steps that must be planned, implemented, and tracked. More information on risk treatment can be found here.

Configuration in Risk Register:

• Risk Treatment Plans:

  • Create Jira issues for each risk treatment plan. Use of the “Task” issue type is common, but some organizations choose to create a specific “Treatment” issue type. 

  • Document the selected treatment options, including the rationale for selection, and expected benefits.

  • Create detailed action plans within Jira issues, assigning tasks, setting deadlines, and specifying required resources.

  • Link the treatment plans to the relevant risk. 

• Monitoring and Review:

  • Use the risk register table to track the progress of risk treatment plans.

  • Regularly update the status of risk treatments and assess their effectiveness.

• Residual Risk Assessment:

  • Evaluate the remaining risk after treatment has been applied.

  • Document whether the residual risk is acceptable.

  • If further treatment is needed, create and link a new treatment plan.

Recording and Reporting

The purpose of recording and reporting is to communicate risk management activities and outcomes throughout the organization, facilitating transparency, accountability, and informed decision-making. Proper documentation and communication ensure that all stakeholders are aware of the risks, the decisions made to address them, and the outcomes of those actions.

Best practice emphasizes that all aspects of the risk management process should be recorded and reported appropriately to ensure clarity, consistency, and alignment with organizational objectives. This includes documenting all risk analysis, decisions, reasons for decisions, treatments, outcomes, and any other relevant information.

Risk Recording

Recording involves documenting all stages of the risk management process, from risk identification to treatment and monitoring. Accurate records are vital for auditing purposes, continual improvement, and compliance with internal and external requirements.

Configuration in Risk Register:

The recording of information in Risk Register has been fully described in the process steps above, but following is a summary:

• Risk Register Entries: Ensure that each identified risk is recorded in the Risk Register with detailed information, including risk description, sources, potential impact, probability, and assigned risk owners. 

• Risk Assessments: Document risk assessments, including inherent and residual risk levels, in the Risk Register, using the risk assessment panel within Jira to record probability, impact, and risk level.

• Treatment Plans: Record the details of risk treatments, including the selected options, implementation plans, and assigned responsibilities. Treatment plans should be linked to the corresponding risks within the Risk Register.

• Change Logs: Utilize Jira's history logs and the custom risk history to track changes to risk assessments, treatments, and decisions. This ensures a transparent audit trail, which is crucial for accountability and continuous improvement.

Risk Reporting 

Reporting is the process of communicating risk management information to relevant stakeholders. Effective reporting ensures that decision-makers have the information they need to manage risks effectively and that all stakeholders are informed about the risk landscape and the measures being taken to address risks. 

Configuration in Risk Register:

• Dashboard Reports: Set up dashboards in Jira to provide real-time visualizations of risk data. Dashboards can include risk matrices, treatment status, risk level aggregations, and more, allowing stakeholders to monitor risks actively. 

• Automated Emails: Use Jira automation to automatically notify stakeholders about report availability. These emails can be scheduled, and contain links to either your dashboards or the risk register table and matrix views. 

• Confluence Reports: You can display risk information in Confluence using Smart Links in conjunction with Jira dashboards. 

• Export to CSV/Excel: You can use Jira search to locate the required risk records then export them to a CSV or Excel file, including whichever columns you wish.

• Export to Word/PDF: Once you have embedded a risk dashboard in Confluence, as described above, you can easily export that report to a PDF or Word file.

Monitoring and Review

The goal of monitoring and review is to ensure and enhance the quality and effectiveness of the process implementation and outcomes. Continuous monitoring and regular review of the risk management process and its results should be an intentional component of the risk management framework, with clearly assigned responsibilities. 

Continuous monitoring involves the ongoing observation of how the risk management process is functioning. This includes assessing whether the process is being followed correctly, identifying any deviations from the established procedures, and ensuring that the process remains aligned with the organization’s strategic objectives.

Regular reviews involve periodic assessments of the risk management process to evaluate its effectiveness and identify opportunities for improvement. These reviews should examine the overall process design, the quality of its implementation, and the outcomes it produces.

Configuration in Jira:

• Process Dashboards: Utilize Jira dashboards to monitor the health and effectiveness of the risk management process itself. Dashboards can display metrics such as the issue completion rate, created vs resolved, and time in status, providing a clear view of how well the process is being executed.

• Review Schedules: Establish regular schedules for reviewing the risk management process. These reviews should involve key stakeholders and focus on assessing whether the process is meeting its objectives and producing the desired outcomes.

• Audit Logs: Use Jira’s history logs and the risk history logs to audit the execution of the risk management process, including compliance with established procedures, timelines, and responsibilities. This helps to ensure that the process is being followed as intended and provides a basis for identifying areas for improvement.

Monitoring and review are essential for driving continuous improvement in the risk management process. By regularly evaluating the process, organizations can identify inefficiencies, gaps, and opportunities to enhance the process, ensuring it remains effective and aligned with evolving organizational needs.

---

Download Risk Register by ProjectBalm Today!

---