What DORA Means for Security and Risk Teams in 2026

Key Takeaways

• Board members are personally liable for ICT resilience: The EU DORA regulation places accountability at the executive level, with incident reporting timelines measured in hours.
• Delivery speed metrics don’t satisfy regulators: Traditional DevOps benchmarks miss security debt, application risk, and unsafe change propagation.
• Compliance works best when it’s built into the pipeline: Teams that embed risk context and material change detection into their delivery process generate regulatory evidence as a byproduct of how they ship.

Most engineering leaders hear “DORA” and think deployment frequency and lead time, but the EU’s Digital Operational Resilience Act (DORA) carries far higher stakes than a DevOps scorecard.

The EU DORA regulation (Regulation (EU) 2022/2554) took effect in January 2025. It requires financial entities to prove they can withstand and recover from ICT disruptions. In it, board members are personally liable, reporting timelines are measured in hours, and third-party providers fall under the same accountability umbrella.

For security and risk teams, this changes the operating model. Speed metrics alone no longer signal engineering health. Regulators want to see resilience, including asset inventories, incident detection capabilities, tested recovery plans, and full supply chain visibility. Teams that treat compliance as a one-time audit are already behind.

Under EU DORA, resilience is measured across five structured pillars. Explore how traditional software delivery performance metrics miss critical signals and how security and risk leaders adapt accordingly.

What DORA Measures Beyond DevOps Performance

Let’s start by establishing there are two DORAs in the industry, and the naming convention causes real confusion.

The first is DevOps Research and Assessment (DORA), a set of DORA metrics that measure engineering maturity, including: 

• Deployment frequency
• Lead time for changes 
• Change failure rate
• Failed deployment recovery time

Teams use these to benchmark how fast and how reliably they ship code.

The second is the EU regulations, a legally binding regulation that evaluates whether financial entities can survive operational disruption and prove it to regulators.

While they share an acronym, they share almost nothing else in common.

The EU regulation requires demonstrating asset inventory completeness, incident detection and classification capabilities, tested recovery processes with defined time objectives, documented third-party risk management, and supply chain transparency down to the component level.

A team can score “Elite” on every DevOps DORA KPI and still be dangerously exposed under the EU regulation. High deployment frequency tells you nothing about whether those deployments carry unpatched vulnerabilities, bypass security controls, or introduce ungoverned third-party dependencies.

That’s because the EU regulation forces a harder question: are the changes you’re shipping actually safe?

The 5 Pillars of DORA

The EU DORA framework is built on five pillars. Together, they define what regulators expect from financial entities when it comes to ICT resilience. Each one carries specific obligations that touch security, risk, and engineering teams directly.

Pillar 1: ICT Risk Management

The regulation puts ICT risk management at the board level. Under Article 5, senior leadership is personally liable for overseeing the framework. 

Entities must maintain a detailed inventory of all ICT assets, map dependencies across systems, and identify critical functions whose failure could threaten business viability. 

The framework requires annual review and immediate updates after major incidents.

Pillar 2: Incident Reporting

DORA harmonizes incident reporting across the EU with strict timelines.

Initial notification must happen within four hours of classification. An intermediate report follows within 72 hours. A final report with root cause analysis is due within one month. 

The regulation also introduces “significant cyber threats” as a reportable category, covering threats that haven’t materialized yet.

Pillar 3: Digital Operational Resilience Testing

All financial entities must run annual testing programs on critical systems, including vulnerability assessments, open-source code analysis, and scenario-based simulations. 

Significant institutions face a higher bar: Threat-Led Penetration Testing (TLPT), conducted by independent external testers following real-world attack scenarios.

Pillar 4: Third-Party Risk Management

Financial entities are legally liable for the resilience of their outsourced services under Article 28. The regulation requires a “Register of Information” cataloging all third-party contractual arrangements. 

It also pushes organizations toward maintaining Software Bills of Materials (SBOMs) for full supply chain transparency.

Pillar 5: Intelligence Sharing

The fifth pillar encourages financial entities to share threat intelligence and Indicators of Compromise (IoCs) within trusted communities. 

The goal is reducing mean time to detect (MTTD) and time to remediate across the sector, building collective defense against systemic attacks.

The Security Blind Spot in Traditional DORA Metrics

DevOps DORA software metrics were designed to measure delivery performance. They do that well. What they don’t measure is whether the code being delivered is safe.

A team shipping multiple deployments per day with a low change failure rate looks healthy on paper. But those deployments might carry unpatched vulnerabilities, expose sensitive data through new APIs, or introduce ungoverned dependencies. The metrics won’t flag any of it.

There’s also a gaming problem. Developers can inflate deployment frequency by splitting a single feature into micro-deployments. The numbers go up, but actual resilience doesn’t.

Under EU DORA, regulators care about the integrity of what’s being shipped. That means engineering teams need qualitative signals alongside their velocity metrics, including:

• Vulnerability age: How long known vulnerabilities remain unpatched in production. Long-lived vulnerabilities are security debt that compounds over time.
• Reachability: Whether a vulnerability is actually exposed to the internet or sits in a critical data path. Not every CVE is a real risk.
• Blast radius: The potential impact if a specific component or service fails. A vulnerability in an internal logging tool is different from one in a payment processing API.

These are the DORA KPIs that connect delivery performance to operational resilience, and the ones regulators increasingly expect to see evidence of.

Related Content: What is Application Vulnerability Correlation

DORA Compliance vs. Engineering Health

“DORA compliant” is not a status you achieve and move on from. The regulation requires continuous, demonstrable resilience. An annual audit pass is the floor, not the finish line.

The regulation applies a proportionality principle. A global investment bank faces different expectations than a small crowdfunding platform. But no entity is exempt from the core requirements. Every financial entity must establish impact tolerance levels for ICT disruptions, maintain documented recovery objectives, and prove that processes exist for managing risk.

The gap shows up when teams treat metrics as proof of health without examining what’s behind them. A clean change failure rate means nothing if the changes being shipped carry unpatched vulnerabilities or bypass security controls. Low lead time is meaningless if there’s no audit trail connecting a code change to its approval, testing, and deployment.

Where the Regulation Meets the Pipeline

Articles 9 and 17 make this concrete:

• Article 9 (Change Management): Every code change must be recorded, tested, assessed, approved, and verified through documented policies. This puts traceability requirements directly into the deployment workflow.
• Article 17 (Incident Management): Entities must implement early warning indicators and prompt detection mechanisms for anomalous activity. This pushes monitoring and alerting standards into daily operations.

Engineering health under DORA means your delivery process produces safe, traceable, recoverable changes by default.

How Engineering Teams Use DORA Metrics Without Gaming the System

Metrics improve what they measure. The problem is when teams optimize for the number instead of the outcome. Deployment frequency goes up, but the deployments aren’t meaningful. Lead time drops, but code review gets skipped.

The EU DORA regulation provides a forcing function here. When regulators require audit trails, tested recovery plans, and documented change management, gaming the metrics becomes a liability.

Process Alignment

• Automated audit trails: Signed commits and policy-as-code let teams maintain deployment velocity while satisfying the traceability requirements of Article 9.
• Separation of duties: The regulation requires independence between change approval and implementation. High-maturity teams automate this through approval workflows and role-based access controls.
• Sprint-level review: Pair quantitative DORA metrics with qualitative checks in every retrospective. Track not just how fast you’re shipping, but how safely.

Ownership Clarity

Every risk, every component, and every remediation path needs a responsible owner. The regulation demands this at the board level through Pillar 1. Engineering teams need it at the repo level.

When ownership is clear and processes are automated, compliance becomes a byproduct of how you already work. Day-to-day engineering improvements directly strengthen the evidence you present during annual regulatory review.

Extending DORA with Risk and Context Signals

Meeting EU DORA requirements means connecting delivery performance to actual risk. Most security tooling doesn’t do this well. SAST, DAST, and SCA tools generate findings in isolation, without the architectural context needed to determine what actually matters.

Application Security Posture Management (ASPM) platforms close this gap by correlating findings across the stack with real-time visibility into your software architecture. For teams operating under the DORA framework, three capabilities matter most:

• Material change detection: Automatically identifying architectural shifts that trigger compliance reviews under Articles 9 and 17, so compliance stays continuous without adding manual gates.
• Code-to-runtime context: Linking code-level findings to runtime exposure. A vulnerability in a deployed, internet-facing service with PII access is a different priority than one in an internal staging tool.
• Toxic combination identification: Flagging scenarios where individually minor risks combine into critical exposure, like an unauthenticated API handling sensitive data on a public-facing service.

The evolution of AppSec in the AI era is pushing teams toward this model. When risk context is embedded into the development process, compliance becomes a continuous outcome of how you build, not a quarterly exercise that slows everything down.

Build Compliance into How You Ship Code

The EU DORA regulation raises the bar for what “healthy engineering” looks like in financial services. Delivery speed still matters, but regulators now expect proof that speed comes with resilience: asset visibility, incident readiness, tested recovery, supply chain accountability, and continuous risk management.

The teams that will operate well under this regulation are the ones that stop treating compliance as a separate workstream. When material change detection, risk-based prioritization, and code-to-runtime context are built into the development process, compliance evidence generates itself. Security debt gets managed in real time. And regulatory reviews become a confirmation of what you’re already doing, not a scramble to produce documentation.

Apiiro gives security and risk teams the architectural visibility and risk context needed to align engineering velocity with EU DORA requirements. From automated material change detection to full software architecture mapping, it connects delivery performance to the resilience outcomes regulators expect.

See how Apiiro works

FAQs

Are DORA metrics required for regulatory compliance?

DevOps DORA metrics like Deployment Frequency and Lead Time are not named in the EU regulation. But they serve as practical evidence for compliance. Article 9 requires documented change management audit trails, and Article 17 requires demonstrable recovery capabilities. Teams use engineering metrics as early indicators that their systems can deliver the safe, stable changes the regulation demands.

Can small engineering teams use DORA metrics effectively?

Yes. The regulation applies a proportionality principle, offering a simplified ICT risk management framework for smaller entities. Small teams should focus on automating baseline measurements like system uptime and incident classification. Compliance for smaller firms is about proving that a defined process exists for managing risks and incidents, not replicating the infrastructure of a global bank.

How do DORA metrics apply to security incidents?

Under the EU regulation, mean time to detect becomes a critical compliance metric. The four-hour reporting window for major incidents requires near-instant detection and automated classification workflows. High change failure rates are often flagged by regulators as evidence of quality control gaps in the deployment pipeline, which can trigger more frequent audits.

What tools are commonly used to track DORA metrics?

Organizations typically use a layered approach. ASPM tools track material changes and risk propagation at the code level. GRC platforms manage policy registries and third-party risk assessments. Observability platforms and incident management tools handle the stability and recovery metrics required under Pillar 2’s reporting mandates.

How often should DORA metrics be reviewed?

The regulation mandates an annual review of the ICT risk management framework, with immediate updates required after major incidents or significant infrastructure changes. From an engineering perspective, teams should review delivery and security metrics every sprint. This creates a continuous compliance loop where day-to-day improvements directly strengthen annual regulatory evidence.