Focusing only on DORA metrics can push teams to optimize throughput while ignoring whether code is adequately protected. That creates pressure to ship faster, which can reduce attention to testing, remediation, and security review. Over time, the result is more bugs and vulnerabilities reaching later stages of the pipeline, where fixes are more expensive and operational disruption is harder to avoid.
Why DORA Metrics Alone Can Distort Secure Delivery Priorities
DORA metrics are useful for understanding delivery performance, but they only describe speed and stability outcomes, not whether the software being released is secure. If teams treat them as the only success measure, they can optimise for release frequency and lead time while underweighting threat modelling, code review depth, dependency checking, and vulnerability remediation. That creates a governance gap: the organisation may appear operationally efficient while latent security defects continue to move through the pipeline.
That gap matters because delivery optimisation changes behaviour. Engineers and managers respond to what is measured, so a narrow scorecard can make security work feel optional, delayed, or invisible. The result is not just more defects in code, but weaker assurance that changes are safe to deploy and supportable when incidents occur. NIST Cybersecurity Framework 2.0 is useful here because it frames outcomes across governance, identify, protect, detect, respond, and recover, rather than treating throughput as the only success condition. In practice, many security teams discover this misalignment only after release pressure has already normalised shallow review and deferred fixes.
How Security Weakness Emerges in a Metrics-Only Delivery Model
Focusing only on DORA metrics usually changes the sequence of decisions inside the delivery process. Teams begin asking which activity helps a release move faster, not which activity reduces the chance of shipping unsafe code. That can lead to fewer security checkpoints, shorter review windows, and a bias toward passing work downstream rather than fixing it early. The problem is not that DORA metrics are bad. The problem is that they are incomplete when used as the sole management signal.
In practice, a secure delivery model needs both flow metrics and assurance signals. Flow metrics show whether work moves efficiently. Security signals show whether the work is trustworthy enough to release. Those signals can include vulnerability backlog age, dependency risk, policy exceptions, code review coverage, test depth, and the percentage of changes that fail security validation before production. When these are absent, teams may still improve throughput while quietly increasing the cost of remediation and the probability of post-release exposure.
This is especially important where software changes affect identity handling, secrets, privilege paths, or externally exposed APIs, because a fast release can amplify the blast radius of a simple mistake. DORA metrics do not show whether a change introduced insecure authentication logic, weakened access control, or failed to update a vulnerable library. A framework such as EU Digital Operational Resilience Act (DORA) is relevant here because it emphasises resilience and controlled delivery in regulated environments, not delivery speed alone. Where security review is treated as a bottleneck rather than a control, the guidance breaks down under release pressure and exception handling becomes the default.
- Measure delivery performance and security assurance together, so one set of numbers does not crowd out the other.
- Use early-stage checks to catch unsafe changes before they become expensive production fixes.
- Track whether vulnerabilities are being reduced or merely moved later in the pipeline.
When Fast Delivery Is Compatible With Stronger Security, and When It Is Not
Tighter measurement often improves visibility, but it also increases the risk that teams optimise the visible metric rather than the underlying outcome, so organisations must balance speed against assurance. The common mistake is to assume that high deployment frequency automatically implies maturity; in reality, it can just as easily reflect a process that is very efficient at shipping unresolved risk.
The acceptable variation is context-dependent. For low-risk changes, automation can safely reduce friction if guardrails are strong and exceptions are rare. For higher-risk services, regulated environments, or changes that touch authentication, authorisation, or sensitive data paths, the same shortcut becomes much harder to justify. Guidance-vs-consensus matters here: there is broad agreement that DORA metrics are valuable, but no consensus that they should be the principal measure of engineering success. Security teams should treat that disagreement as a signal to preserve independent assurance metrics rather than collapsing everything into one score.
DORA and resilience expectations are most useful when they prompt teams to ask what delivery speed is buying, what it is hiding, and where the release process needs explicit safety gates. The limit of this approach is clear: once a team cannot show that fast delivery is still producing safe changes, the metric has stopped being a management aid and started becoming a source of blind spots.
Risk and Threat Considerations
Using DORA metrics as the primary success measure creates a material operational and security risk: organisations can improve delivery velocity while degrading the controls that keep vulnerable code, insecure dependencies, and weak access handling out of production. The exposure is governance-driven as much as technical, because the metric can reward speed even when the underlying change set is becoming harder to secure.
Failure mechanism: When management attention centres on lead time, deployment frequency, and change-failure rate alone, teams have an incentive to shorten review cycles, defer remediation, and treat security validation as optional or late-stage. That pattern allows recognised failure modes such as insufficient code review, incomplete testing, unpatched dependencies, and bypassed approval steps to accumulate until they appear in production.
Impact: The likely consequence is a larger pool of reachable vulnerabilities, greater rework cost, higher incident likelihood, and more disruptive emergency fixes after release. In environments with privileged access paths or sensitive data flows, the same pressure can also make containment and rollback more difficult because the organisation has prioritised throughput over assurance.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and NIST IR 8596 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC-01 — Organisational Context | Delivery metrics should reflect security outcomes, not throughput alone. |
| GV.RM-01 — Risk Management Strategy | Narrow metric focus can distort risk acceptance in software delivery. | |
| PR.IP-03 — Configuration Change Control Processes | Fast delivery can erode change controls if speed becomes the only target. | |
| Recommendation — Align delivery KPIs with security outcomes and governance context. Embed security risk tolerance into release-performance decisions. Keep change control gates intact when optimising deployment speed. | ||
| CIS Controls v8 | CIS 16 — Application Software Security | The question is about delivery practices that can weaken application security. |
| CIS 7 — Continuous Vulnerability Management | Speed-only metrics can leave vulnerabilities to accumulate unseen. | |
| CIS 4 — Secure Configuration of Enterprise Assets and Software | Release pressure can encourage insecure configuration shortcuts. | |
| Recommendation — Require secure SDLC checks before promoting code to production. Track vulnerability remediation alongside delivery throughput. Validate secure baseline settings before and after release. | ||
| NIST IR 8596 | IR-4 — Incident Handling | Weaker assurance increases the chance of incidents needing response. |
| Recommendation — Use incident trends to test whether delivery speed is creating exposure. | ||
| MITRE ATT&CK | T1190 — Exploit Public-Facing Application | Unsafe releases can expose exploitable application weaknesses. |
| Recommendation — Hunt for public-facing weaknesses introduced by rushed releases. | ||
Practitioner Guidance
What to prioritise: Treat DORA metrics as one management lens, not the delivery objective. Pair them with security assurance indicators that show whether faster delivery is still producing acceptable risk decisions and whether the pipeline is actually reducing unresolved exposure.
Decision rule: If a team can improve DORA performance only by reducing security review depth, delaying remediation, or tolerating repeated policy exceptions, the metric set is mis-specified and should be corrected before it drives more release decisions.
What to verify: Verify that changes moving quickly through the pipeline are still subject to meaningful controls at the points where defects become most expensive to fix, especially around authentication, access control, and dependency management.
Practitioner takeaway: Delivery speed is valuable only when the organisation can prove that speed is not being bought by quietly transferring security risk downstream.
Related resources from NHI Mgmt Group
- Why do abandoned GitHub Actions increase operational and security risk in software delivery?
- How should security teams reduce risk in software delivery pipelines with NHI controls?
- How should security teams govern software supply chain risk in application delivery?
- Why do data silos increase compliance and breach risk in software delivery?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
