How can organisations measure whether development and security are actually aligned?

Why This Matters for Security Teams

Alignment between development and security is not a cultural slogan. It is a measurable operating condition that affects release reliability, vulnerability exposure, and how quickly teams can respond to risk. If the metric set rewards ticket closure or policy completion, teams can appear busy while still shipping recurring exceptions, late findings, and fragile compensating controls. Security leaders should focus on whether both functions are improving the same delivery outcomes, not whether they are simply attending the same meetings.

Good measurement also needs to reflect control effectiveness, not only process volume. NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it separates the existence of a control from the evidence that it is operating as intended. That distinction matters when security reviews are routinely bypassed late in delivery, or when developers are forced into manual workarounds that reintroduce risk later. In practice, many security teams discover misalignment only after repeated release delays, not through any intentional measurement model.

How It Works in Practice

Measuring alignment works best when the organisation defines a small set of shared indicators that reflect both speed and risk reduction. The goal is to show whether secure delivery is becoming easier over time, not whether every team is generating more activity. Security and engineering should agree on what “good” looks like for intake, review, remediation, and exception handling before the numbers are collected.

Useful indicators usually fall into four groups:

• Delivery friction: time from security finding to remediation, or time from build completion to security approval.
• Quality of outcomes: number of late-cycle findings, escaped defects, and repeat issues across releases.
• Exception health: volume of risk acceptances, how often they recur, and whether compensating controls actually reduce exposure.
• Operational consistency: whether policy-as-code, CI/CD checks, and review gates are applied predictably across teams.

That measurement model should be tied to threat context. If the product handles sensitive data or high-value transactions, the alignment question is not just whether controls exist, but whether they reduce attack paths that matter. Guidance from CISA Secure by Design reinforces this by treating secure outcomes as an engineering responsibility, not a downstream review step. For teams building cloud or software-heavy environments, OWASP DevSecOps Guideline is also useful for turning review points into repeatable delivery controls.

Practically, the best signal is trend direction over several releases, because one-off improvements can hide unstable processes. Mature teams compare the same metrics by product line, repo, or release train so that a high-performing group does not mask a weaker one. These controls tend to break down when development work is highly outsourced and security lacks visibility into backlog prioritisation, because the metric owner cannot verify whether exceptions are truly being removed.

Common Variations and Edge Cases

Tighter measurement often increases reporting overhead, requiring organisations to balance visibility against the time developers spend on evidence collection. That tradeoff is real, especially when teams are already overloaded with tooling, dashboards, and audit requests. The answer is not to measure everything, but to choose a few indicators that directly reflect shared outcomes and can be trusted by both sides.

There is no universal standard for this yet. Some organisations lean heavily on lead time to remediation, while others care more about the proportion of findings that reappear after a fix. Both can be valid, but they answer different questions. A fast fix rate may still hide brittle code if the same weakness returns in each sprint. A low recurrence rate may still mask poor responsiveness if exceptions linger too long before closure.

Edge cases matter. In highly regulated environments, alignment can be strong even when release velocity slows, if the slowdown reflects deliberate control hardening rather than avoidable friction. In product teams with strong platform engineering, security may be embedded so deeply that separate “security metrics” become less meaningful than pipeline health and control coverage. For identity-heavy systems, recurring access exceptions can be a strong indicator of poor alignment between engineering, IAM, and PAM governance, because teams are treating privilege as a release obstacle instead of a design constraint. The main test is whether security work is reducing rework over time, or merely shifting it to a later stage.

Related resources from NHI Mgmt Group

• How should security teams measure whether authentication controls are actually working?
• How should security teams measure whether DLP monitoring is actually working?
• How should organisations measure whether identity governance is actually working?
• How can organisations tell whether their AI security model is actually working?