What DORA requires from software engineering and platform teams
The Digital Operational Resilience Act, or DORA, is an EU regulation for financial entities. It entered into full application on January 17, 2025, and is designed to make financial organizations more able to withstand, respond to, and recover from ICT disruptions such as cyberattacks and system failures.
For software engineering and platform teams, DORA compliance is not only a risk, audit, or legal requirement. It changes how engineering teams need to think about digital operational resilience: secure development, software quality, dependency visibility, vulnerability management, testing, release governance, and incident follow-up all become part of the resilience picture.
DORA covers ICT risk management, ICT-related incident handling, digital operational resilience testing, ICT third-party risk management, information sharing, and oversight of critical ICT third-party providers. In practical engineering terms, this means teams need to show that software risk is identified, reduced, tested, monitored, and improved over time.
DORA-level software security should focus on preventing software-originated operational disruption, not just responding after an incident has already affected critical services.
How ICT risk, testing, and resilience expectations translate to engineering
DORA digital operational resilience expectations put more emphasis on prevention, continuity, and recoverability than traditional compliance programs. Software teams need to reduce the likelihood that insecure code, vulnerable dependencies, exposed secrets, misconfigured infrastructure, or untested changes become operational incidents.
That makes DORA secure development a workflow issue. Teams need engineering practices that support:
- Clear ownership of application and platform risk.
- Visibility into software assets, services, dependencies, and critical systems.
- Secure coding and configuration checks before release.
- Continuous testing of code, infrastructure, and dependencies.
- Evidence that risks were reviewed, fixed, accepted, or escalated.
- Faster investigation and corrective action after software-related incidents.
- Continuous improvement based on findings from testing, incidents, and remediation.
DORA penetration testing also sits within this broader testing expectation. DORA includes both basic and advanced digital operational resilience testing, including threat-led penetration testing for relevant entities. For engineering teams, penetration testing should not be the first time security weaknesses are discovered. The stronger operating model is to identify common code, dependency, and configuration issues earlier, then use penetration testing to validate resilience against realistic threat scenarios.
Industry discussion around DORA reflects this shift. Financial institutions have moved from preparation into integration, with strong emphasis on ICT risk management frameworks, incident response, threat-led penetration testing, and third-party risk oversight. Research into secure software engineering in financial services also shows a persistent gap between security specialists and development teams, reinforcing the need for developer-friendly security controls inside the SDLC.
How do you operationalize DORA compliance in a CI/CD pipeline?
DORA compliance software programs need controls that work inside delivery, not around it. A policy that lives outside the development workflow is hard to enforce consistently and hard to evidence later.
A DORA-aligned DevSecOps process should include:
- Security and quality checks in pull requests and CI pipelines.
- Automated controls that stop high-risk changes before release.
- Dependency scanning and software composition analysis.
- Secrets detection before credentials reach production.
- Infrastructure as Code checks for risky cloud or deployment configurations.
- Vulnerability triage with ownership, severity, reachability, and remediation status.
- Integration with issue tracking so fixes are visible and assigned.
- Release evidence that shows what was checked, what passed, and what remains open.
- Post-incident review that links operational issues back to code, configuration, dependency, or process improvements.
This approach supports DORA ICT risk management by turning risk controls into repeatable engineering activity. It also helps reduce friction for developers. Research has found that developers cannot be expected to become security experts overnight and that security tools need to fit development workflows to be adopted effectively.
For platform teams, the same logic applies to infrastructure and shared services. DORA resilience depends on the quality of deployment pipelines, IaC, secrets handling, service dependencies, monitoring, and rollback paths. The closer these checks are to everyday delivery, the easier it becomes to keep operational resilience current as systems change.
Does DORA require SBOMs for ICT risk management?
DORA does not introduce SBOM requirements in the same direct way as the Cyber Resilience Act. For DORA, SBOMs are best understood as an enabling control for ICT asset visibility, third-party risk management, software supply chain transparency, and vulnerability response.
That still makes the use of SBOM relevant to engineering teams. If a critical service depends on vulnerable open source components, transitive libraries, or third-party packages, teams need a reliable way to answer:
- Which applications include the affected component?
- Which versions are deployed?
- Is the vulnerable code reachable?
- Is the component part of a critical or important function?
- Is there a fixed version or mitigation?
- Who owns remediation?
- What evidence shows the risk was addressed?
DORA vulnerability management is closely tied to operational resilience because exploitable vulnerabilities can become service disruption, data integrity issues, incident reporting events, or third-party risk findings. Vulnerability response practitioners continue to report challenges around prioritization, false positives, tool output volume, and the need for both product context and security expertise to assess risk correctly.
SBOMs and software composition analysis help teams move from reactive searching to structured visibility. They support dependency inventory, vulnerability prioritization, third-party review, and faster impact assessment when a new vulnerability is disclosed. For DORA, that visibility matters because ICT third-party risk management is one of the regulation’s core areas.
How does SonarQube support DORA compliance for software teams?
SonarQube, in combination with SonarQube Advanced Security, supports DORA-aligned delivery by bringing application security, code quality, dependency risk, SBOM, and remediation controls into everyday software development.
It supports resilience testing and continuous improvement by acting as a continuous verification layer for code. Analysis on branches and pull requests, dependency risk review, secrets detection, IaC analysis, imported external findings, and remediation tracking help teams identify weaknesses early and drive corrective action before changes progress through the delivery pipeline.
It helps teams strengthen software governance with portfolio views, quality gate statuses, and security reporting. Management and engineering leaders get clearer oversight of application quality, security, and release readiness across projects, supporting more consistent control of the software delivery landscape.
It helps operationalize ICT risk management by embedding code quality and security policies directly into delivery. Automated code review, quality gates, and issue workflows help teams apply standards consistently, monitor adherence over time, and improve based on analysis and remediation.
It supports identification, protection, and prevention by giving teams visibility into third-party libraries and transitive dependencies, detecting vulnerabilities, exposed secrets, insecure data flows, and risky Infrastructure as Code configurations before release. SBOM generation also strengthens inventory, documentation, and downstream review for the application stack.
It supports software-related incident follow-up by helping teams trace issues back to specific code locations, understand execution flows, document issue decisions, and push findings to Jira. This helps connect incident investigation with root-cause analysis and corrective action.
By integrating code analysis, dependency risk review, SBOM generation, quality gates, remediation tracking, and security reporting into the SDLC, SonarQube helps teams turn DORA readiness into an in-workflow development practice.