DORA and the code you ship: what financial entities need to prove

The Digital Operational Resilience Act (DORA) has applied across the European Union since January 17, 2025. For ICT risk, compliance, and security teams, it raises a practical question every time software goes to production: what can we demonstrate about the code we just shipped?

This page walks through the DORA provisions that apply to software delivery, the records that answer them, and how those records come together for a single release. 

What is considered to be DORA-relevant software development evidence?

DORA asks financial entities to show that their testing, change management, and vulnerability management controls are in place and working. For software, that proof comes from records such as test and analysis results, change approvals, vulnerability remediation records, dependency inventories, and documented exceptions.

Each record carries the most weight when it is tied to a specific release. When it names the commit, build, and deployment it covers, a reviewer can check it directly against what went into production.

Which financial entities are in scope for DORA?

Article 2(1) of DORA lists 20 types of financial entity in scope. They include credit institutions, payment and electronic money institutions, investment firms, crypto-asset service providers, central counterparties and central securities depositories, trading venues, fund managers, insurance and reinsurance undertakings, insurance intermediaries, occupational pension funds, credit rating agencies, and crowdfunding service providers. Some smaller entities, such as small and non-interconnected investment firms, apply a simplified ICT risk management framework under Article 16.

Article 2(1) also names ICT third-party service providers, in connection with the EU oversight framework for providers designated as critical (Chapter V, Section II). Other providers are covered through the contractual terms financial entities must agree with them (Article 30).

This guide is written for the financial entity: the teams that must evidence their own software delivery controls, including for software built in house.

Why does DORA require release-specific evidence?

Incident reporting is where evidence gets tested under pressure. Under Commission Delegated Regulation (EU) 2025/301, the general time limits for a major ICT-related incident are:

• Initial notification: within four hours of classifying the incident as major, and no later than 24 hours after becoming aware of it.
• Intermediate report: within 72 hours of the initial notification.
• Final report: within one month of the intermediate report or the latest updated intermediate report.

Within those windows, the questions come quickly. Which releases contain the affected component? When did they ship? Who approved them? When the evidence was assembled at release time, those answers are a lookup instead of an investigation.

The same discipline pays off before anything goes wrong. Issues caught in a pull request cost less to fix than issues found in production, and the record of each fix becomes part of the evidence.

What are DORA's software development requirements?

Auditors need documented controls and evidence that those controls operated. For software delivery, the most specific requirements sit in Commission Delegated Regulation (EU) 2024/1774, the regulatory technical standards on the ICT risk management framework.

Your release, testing, and change management processes supply the remaining records, such as dynamic test results and production change approvals. Together they form one evidence trail for each release.

What evidence does a DORA-compliant software release require?

Individual records become evidence when they connect. Give each one the same release identifier, and an auditor or your incident team can follow a release from commit to production.

Centrally governed standards and release controls

Evidence for one release carries more weight when it shows the standard that release was held to. Defining your rules and release conditions centrally, and applying them the same way across every in-scope project, shows how the process itself is governed.

Release records

A release record ties a deployment to the commits, build, and version it contains. It is the anchor for everything else, because it turns "the code" into "the code that shipped on this date."

Analysis results

Code analysis and security results show what was checked, what was found, and what was fixed before release. The quality gate outcome shows whether the release met the standard you set.

Approvals

Pull request reviews and merge decisions show who reviewed and merged each change. Your change management system records the production approval and the separation between approver and implementer.

Dependency inventories and SBOMs

An SBOM lists the open source and third-party components, versions, and licenses in a release. When a new vulnerability is published, it lets you answer "are we running the affected version?" in minutes.

Documented exceptions

When a finding is accepted for a later release, an exception records the finding, the risk decision, who made it, and when it will be reviewed. A documented, accepted risk is a control doing its job.

What goes into a DORA release evidence pack?

Picture a release of a payments service, payments-api 4.12.0, built as #2318 from commit a3f9c21 and deployed on March 4. Its evidence pack looks like this:

Three months later, a vulnerability is published in a widely used library. The incident team opens the SBOM for 4.12.0, confirms whether the affected version shipped, and already has the approval and exception trail for the report.

Keep the pack with the release

Export the records at release time and store them together under the release identifier, in line with your retention policy. The pack then stays complete and easy to find for as long as a regulator, auditor, or incident team may need it.

Why does AI-generated code need the same verification?

AI-powered development increases how much code reaches review and how fast it arrives. What you need to demonstrate stays the same. DORA's testing, change, and vulnerability requirements apply to every change, whoever or whatever wrote it.

AI code can pass a functional test and still import a vulnerable library, pin an outdated version, or break a standard your organization has committed to. Coding agents add dependencies as readily as engineers do, which brings them straight into the scope of library tracking.

The answer is standardization. When the same set of standards and controls applies to every change and the result is recorded per release, your evidence holds regardless of how the code was written.

How does SonarQube support DORA compliance?

SonarQube is the independent code verification layer for the code you ship. It analyzes every change, whether an engineer or an agent wrote it, and records the results in a form your compliance and legal teams can map to DORA obligations. Because verification runs inside the development workflow, the evidence builds up as your teams ship.

Put it into practice

• Analyze every change. Run analysis on all supported, in-scope code in your CI pipeline and on pull requests.
• Define your standards. Use quality profiles to set the security, reliability, and maintainability rules applied to each project.
• Enforce them at merge and release. Use quality gates to set the conditions every pull request and release must meet. Set as required checks, they stop non-conforming changes from progressing.
• Extend verification to dependencies. SonarQube Advanced Security adds Advanced SAST, software composition analysis (SCA), dependency risk analysis, and SBOM export.
• Keep an inventory for every release. Review dependencies, export SBOMs, and store them with the matching application and release records.
• Document every dependency decision. Review and assign dependency risks, update their status, record treatment decisions, and track remediation.
• Add deeper reviews. Schedule SonarQube Hunter Agent reviews to find broken access control, business logic vulnerabilities, and authentication and session management flaws, complementing rule-based analysis.
• Bring in findings from other tools. Import results from the other security tools in your testing workflow through SARIF.
• Fix findings faster. Use the SonarQube Remediation Agent to help your teams address eligible findings.
• Retain the record. Keep issue history, quality gate results, security reports, dependency records, SBOMs, and audit logs as code-level inputs to ICT risk assessments and control reviews.
• Cover agentic workflows. Use Sonar Vortex to apply the same standards and checks inside agentic coding workflows.

How SonarQube maps to DORA

Article numbers below refer to the regulation itself, Regulation (EU) 2022/2554.

Evidence readiness checklist

Here’s an example of a good starting point for a software-level DORA evidence checklist:

• [ ] The release record: version, build, commit, and deployment date
• [ ] Test results for that build, including dynamic testing
• [ ] The set of rules and release controls applied to the release, confirmed as the centrally approved versions used across in-scope projects, with their change history
• [ ] Code analysis results and the quality gate status for the released commit
• [ ] An SBOM for the release, with dependency vulnerabilities and their status
• [ ] Pull request reviews and merge records for every change in the release
• [ ] The production change approval, showing separation between approver and implementer
• [ ] Documented exceptions, each with an owner, rationale, and review date
• [ ] Confirmation that the same release controls applied to AI-generated changes
• [ ] All of the above stored together under the release identifier
• [ ] A named owner for each item

If any item takes more than a day to find, start there.

Next steps

• How SonarQube enables DORA compliance for financial institutions: blog post mapping SonarQube capabilities to DORA's pillars.
• SonarQube Advanced Security: product page covering SCA, Advanced SAST, and SBOM export.
• Get started with SonarQube Advanced Security: documentation for setting up dependency analysis.
• Reviewing and fixing dependency risks: how to triage and prioritize dependency findings.