DORA for DevOps and Jira Admins: How to Prepare Your Business for the Digital Operational Resilience Act

Last Updated on February 12, 2025

Given the reality of today’s cybersecurity, it is of utmost importance to have frameworks and regulations. These help both the customers and the organizations to stay protected against the cyber threats that are around us. On 17th January 2025, the Digital Operational Resilience Act (DORA), formally known as Regulation (EU) 2022/2554, came into full effect.

This regulation was adopted by the European Union as a way of ensuring the resilience of the financial sector’s information and communication technology (ICT). Even though DORA is not legally binding for everyone, it is mandatory for financial organizations that operate in the European Union. These include banks, investment firms, insurance companies, and many others. In terms of DevOps, paying attention to this is crucial as it guarantees data security, infrastructure robustness, and compliance with industry regulations, especially for financial services institutions.

What is DORA?

The DORA regulation is essentially a compilation of guidelines that establishes technical standards, to improve the operational resilience of financial institutions and ICT service providers against threats. As the European Council stated, this new regulation will most likely replace several ICT risk management frameworks, to unify the approach for mitigating ICT risks related to the EU financial sector. The regulation mandates that organizations must implement systems and policies to withstand, recover from, and adapt to cyber threats and any operational disruptions. This helps to guarantee business continuity, even in the face of security issues. DORA also mandates that Critical ICT Third-Party service providers (CTPPs) should also adhere to these standards and that it will be monitored and reviewed by one of the following three European Supervisory Authorities (ESAs):

• The European Banking Authority (EBA)
• The European Insurance and Occupational Pensions Authority (EIOPA)
• The European Securities and Markets Authority (ESMA)

While compliance with DORA may seem like a difficult task, it is a necessity. By complying, you ensure data security according to the regulatory technical standards, and as a consequence, this is great for the organization’s reputation. Therefore, it isn’t so bad after all, it is beneficial for everyone (except cyber criminals). 

Why do we need DORA?

The short answer… Security. In reality, the global growth of cybercrime has been so significant that the authorities had to address the issue. The research shows that on average there are 97 cybercrime victims every hour (or every 37 seconds!). Of course, we cannot just get rid of cybercrime, however, frameworks such as DORA help to mitigate ICT risks and reduce the impact of these threats. 

DORA pillars of compliance

DORA actually outlines 5 pillars that are required to be compliant with this regulation. They essentially guide organizations to achieve compliance with this framework. 

ICT Risk Management: 

Financial institutions must develop and implement an ICT risk management framework that supports business continuity, includes disaster recovery strategies, and has communication plans. Being able to recover data during any security event is a critical factor here as it guarantees your organization remains operational, minimizing downtime, and your data is secured and available. Keep in mind there is a strict expectation of uninterrupted business operations.

Now, the stakeholders must do the following. First, set the degree of risk and impact tolerance for any ICT disturbances, you can use the RTO & RPO metrics to help you. A business continuity plan should be developed, approved, and enforced. Then, implement a complete disaster recovery plan that will cover all your data, and allow you to flexibly restore anything when needed. Also, make sure all your assets have specified security controls. 

ICT Incident Reporting: 

Guidelines introduced with the DORA regulation will aim to create a more streamlined reporting channel to be able to report significant ICT incidents. This consolidates the current multiple reporting obligations into one, more effective system. The Digital Operational Resilience Act (DORA) also aims to reduce the number of reporting trigger events – and then standardize reporting templates. This is important as it is a step towards a unified EU hub for reporting events rather than being dependent on many different National Competent Authorities (NCAs). All reports of major ICT-related incidents affecting financial entities will be gathered and analyzed to outline any common vulnerability trends. This should improve ICT resilience and security. It’s important to note that financial entities must submit a root cause report no longer than one month after the incident took place. 

Digital Operational Resilience Testing: 

Another key aspect is that organizations in the financial sector should regularly undergo digital operations resilience testing carried out by independent parties, either external or internal. These tests will include various resilience tests, including vulnerability assessments, penetration testing, and performance testing, to guarantee operational security, as outlined in Article 24, 25. As for critical infrastructure, apps, and ICT services that support necessary operations have to be assessed for vulnerabilities before any deployments. This actually has the potential to cut the costs of staying compliant and reduce the complexity of it. 

Information and Intelligence Sharing: 

It is outlined in Article 23 that Digital Operational Resilience Act (DORA) allows for threat intelligence sharing – information exchange regarding significant cyber threats within trusted financial firms. Sharing such information is great for raising awareness and building a network of trust and cooperation among stakeholders. 

ICT Third-Party Risk Management: 

As outlined in Articles 28 to 44, organizations in the financial sector must properly manage risks related to third-party ICT providers. Bear in mind that Cloud Service Providers (CSPs) also have to stay compliant with these regulations if they are deemed to be ‘critical’. Contracts signed with ICT service providers must cover aspects such as data protection, audits, and incident management and then map all third-party dependencies. CSPs that are critical will be monitored by ESA via inspections. Non-compliance can lead to a fine of 1% of daily global turnover.

This will not replace the current GDPR regulations – but rather complement it. Moreover, financial organizations will have to share responsibility with third-party providers. Therefore it is essential to enforce ICT risk management programs in order to address any vulnerabilities. 

How does DORA impact DevOps?

When it comes to DevOps, the Digital Operational Resilience Act (DORA) also applies and you will be required to adhere to strict requirements of these regulations. This exemplifies a shift towards better security and means that DORA compliance will have to be integrated into workflows, pipelines, and risk management strategies. All of the 5 pillars along with the full documentation should be evaluated and adopted by DevOps organizations that provide services to financial institutions (third-party risks). 

Compliance with DORA for DevOps 

Since DevOps companies are usually services, those who provide services to institutions in the financial sector are considered a third-party risk as outlined in Articles 28 to 44 of DORA official documentation. What is more, DevOps teams often rely on third-party tools. The “sub-tier” third-party tools used by DevOps teams (that work for or provide a service to financial institutions) must adhere to frameworks that the primary ICT service providers set out. In order to be compliant with DORA you should fully address the guidelines, therefore there are several aspects that need to be considered.

How to simplify DORA compliance?

In order to guarantee compliance with the Digital Operational Resilience Act (DORA) it is advisable to do a gap analysis. This way you pinpoint all the potential security holes and compliance gaps across your ICT systems and processes. After, you will need to address the identified gaps. Create a roadmap that will include your identified actions on a yearly timeline and base it on action priority and achievability. This is a great practice because once you spot all the gaps, you have a clear overview of what has to be done to achieve DORA compliance.

Then, you should check if you’ll be classified as ‘critical.’ Measure and evaluate all the characteristics that define criticality and see if they apply to your organization, as outlined in Article 31 of DORA documentation. Moreover, companies in the financial industry have an obligation to evaluate which of the third-party providers will be deemed critical. All critical third-party providers should plan how they intend to retain compliance. 

Next, it is crucial to note that all organizations operating in the financial sector that are not currently implementing TLPT have to find independent providers to cover this service, as it is described in the Article 26 of DORA.

💡 TLPT is a controlled & authorized attempt by ethical hackers to compromise a company’s systems & general cyber resilience using the tactics, techniques, and procedures of real-life threat actors, in the form of a simulation.

The article 17, also outlines that there must be a response and recovery strategy in place. This includes practices that help with ICT risk management as well as procedures that guarantee that services will become operational and secure in a timely manner, as DORA documentation states. This would include comprehensive monitoring and reporting abilities as well as automated backups along with a disaster recovery strategy. Bear in mind all ICT-related incidents must be reported properly to senior management and explain the impact, response as well as plans to implement as a result of such a security event. 

Shift left security 

If you haven’t already done so, DORA is another push towards the shift left approach. Now, more than ever, DevOps teams should aim to switch to DevSecOps and apply appropriate measures. This strategy calls for testing and quality evaluations much earlier in the software development process. So, you should make sure to implement automated security testing and compliance checks into your CI/CD pipelines. In the traditional model, testing occurs at the end, and the shift left approach introduces collaboration between testing, security, and development teams right from the beginning. Now, when you move the security-related tasks to the start of the pipeline, issues and bugs can be identified and addressed at a stage where the impact on the final product is not so huge. 

To guarantee compliance with DORA and successfully shift security left, there are a couple of points that must be covered: 

• comprehensive monitoring & reporting capabilities
• regular audits 
• risk assessments and management 
• incident response tactics
• complete backup and DR solution
• secure the use of third-party tools by DevOps teams 

Jira and DORA compliance

There are two sides of how Jira ties into the Digital Operational Resilience Act (DORA) compliance. Many DevOps organizations actually rely on Jira for project management, therefore it is critical to secure your Jira instances in accordance with DORA regulations. The other aspect is the fact that Jira can actually be helpful in simplifying compliance efforts. Since Jira is used to track and manage projects, you can leverage it to clearly and transparently work towards compliance. This could be helpful in setting out tasks for individuals or teams that must be completed and then the progress can be easily tracked. You can have a clearer overview of your compliance efforts by creating a roadmap in Jira. This way you make sure all processes are covered and deadlines are met.

Moreover, you could actually track any ICT-related incidents using Jira and record them there. Simply log an incident and document the measures taken to recover. A huge aspect of Jira is the simplicity it brings to collaborating with other teams and overall communication. All teams whether it is security, management, or R&D, can easily track and collaborate on tasks related to DORA compliance, as they are in one single place. 

Secure your Jira projects

Another thing is securing your Jira projects. As you may know, oftentimes many individuals and teams collaborate in Jira. Therefore, it is necessary to pay attention to access control and management. Make sure that you cover and implement: 

• Role Based Access Controls (RBAC) 
• The principle of the least privilege 
• Multi-factor authentication (MFA) 
• Single Sign-On (SSO) 
• Regular reviews of granted access 
• Revoke unnecessary or old permissions 

Moreover, it is important to keep your data encrypted and avoid sharing sensitive information in easily accessible places. Also, pay attention to audit logs, these can help to track any changes and access permissions in Jira. Moreover, logs can help you spot any suspicious activity such as unauthorized access – and then address it in no time. 

Keep your Jira data backed up with possibilities of flexible restoration and recovery of all relevant data. For instance, if a Jira issue was deleted a long time ago and turned out to be useful, you should have the option of restoring it from any point in time whenever you need to – that is if you have unlimited retention from your backup vendor. 

What are the risks of non-compliance?

By not complying with the requirements of DORA you essentially jeopardize data security, end up with damage to reputation as well as customer trust, and unfortunately, may end up having to pay fines. The official documentation for the Digital Operational Resilience Act (DORA) gives insight into how non-compliance will be penalized. What is more, as outlined in Articles 50, 51, and 52, DORA actually gives authorities the power to verify compliance, and therefore allows for:

• accessing all of your relevant data 
• on-site inspections 
• imposing corrective orders 

The official DORA documentation states that penalties or relevant remedial actions will vary depending on the impact as well as the duration of a breach. As outlined in Article 50, penalties can be in the form of a fine, public notice, or corrective orders to stop violations (even potential ones) and non-compliant practices. 

Authorities get to analyze if any violations were intentional or simply negligent. An organization’s financial strength, history of breaches, level of friendly cooperation as well as any losses caused as a result of non-compliant practices will all be considered penalized accordingly. These are outlined in Article 51, and describe how the powers issued to the authorities can be exercised. 

Automate security processes

To guarantee DORA compliance, it is advisable to automate key processes using dedicated solutions for better efficiency and security. For example, time spent on manual backups makes individuals leave their primary tasks and does not guarantee security as a process, and actually poses a risk of human error. Therefore, it is a good practice to securely automate processes such as scanning, testing, backups, monitoring & reporting. 

Testing

As Articles 24, 25, and 26 outline, financial organizations must undergo a range of assessments and tests. These should include: scenario-based testing, vulnerability assessments, and penetration testing, to guarantee that ICT systems are robust and reliable. Testing must take place regularly in order to verify if systems can handle a potential severe operational disruption and guarantee business continuity. Introducing automated testing into your organization can save time and money but most importantly it will support compliance efforts and provide security. 

Backup, restore and recovery capabilities

To elevate your data protection you should implement a backup and disaster recovery solution. DORA actually mandates in Article 12, that all entities within the financial sector (along with their critical third-party providers), must implement and document reliable backup, restore and recovery procedures to achieve compliance. 

Source: DORA documentation 

There are reliable backup solutions providing security and supporting compliance of financial organizations. Verify that the vendor you opt for covers all of the required data. Make sure that you get the following capabilities to ensure data recoverability and compliance: 

• Point-in-time restore
• Granular restore
• Cross-over restore
• Full data recovery

A crucial aspect is to find a vendor to keep your data secure while automatically supporting your compliance with capabilities such as automated monthly and daily reports, audits, SLAs, and technical abilities that align with DORA requirements. These should include adherence to the 3-2-1 backup rule, unlimited retention, and flexible backup policies to protect your critical assets.

Source: DORA documentation 

Reporting 

Another key data protection aspect is monitoring and reporting. This actually gives you insights to processes taking place and allows you to react quickly if any issues arise. Implementing monitoring tools can prove beneficial as it eliminates the need for human oversight and simplifies the reporting process. This ties into Article 17 of DORA, as all ICT-related incidents in financial firms must be properly reported since it is a compliance requirement.

Conclusion

Now that DORA has come into full effect, as of January 17th 2025, it is not only a trust guarantee for clients and a boost to organizations’ security but also a legal requirement. Financial entities must adhere to the pillars outlined by the Digital Operational Resilience Act in order to meet requirements set out by the framework. Remember to follow industry best practices such as regular testing and having robust backup and disaster recovery solutions, as suggested by DORA, to mitigate risks and stay compliant.

[FREE TRIAL] Ensure compliant DevOps backup and recovery with a 14-day trial 🚀

[CUSTOM DEMO] Let’s talk about how backup & DR software for DevOps can help you mitigate the risks