Accountability should sit with both security and engineering leadership, because usable application security depends on process, tooling, and workflow design. Security teams define risk policy and prioritisation, while engineering leaders ensure the controls fit delivery practices. If the workflow is too cumbersome, adoption drops and the organisation loses both speed and assurance.
Why Accountability Cannot Sit in One Team
Usable application security is not just a policy question, it is a delivery question. Security can define what must be protected, but engineering decides whether the control fits the way code is built, reviewed, tested, and released. When accountability is split badly, teams either over-engineer controls that developers bypass or simplify so much that real risk goes unaddressed. NIST’s control guidance is useful here because it treats security as a managed set of responsibilities, not an isolated function.
In practice, many organisations discover the ownership gap only after developers start working around the control rather than through it.
How Shared Ownership Works in Practice
The most workable model is shared accountability with clear boundaries. Security leadership should own the risk standard: what classes of findings matter, which exceptions are acceptable, and how the organisation measures exposure. Engineering leadership should own the developer experience: where checks appear in the pipeline, how noisy the tooling is, and whether the workflow adds friction that slows delivery without reducing risk.
That split matters because application security fails when it is treated as either a compliance overlay or a tooling problem. If security writes requirements without understanding delivery reality, the result is often a control that is technically sound but operationally ignored. If engineering optimises only for speed, security checks become fragmented, inconsistently applied, or postponed until after release. The practical answer is to make both sides accountable for the same outcome, but for different parts of it.
A useful operating pattern is:
- Security defines the minimum acceptable control intent and exception thresholds.
- Engineering designs the workflow so those controls can run inside normal developer activity.
- Product or platform teams validate whether the workflow is actually usable at scale.
- Leadership tracks whether the control is improving assurance without creating avoidable delay.
The supplied NIST guidance on controls supports this shared-responsibility approach by emphasising that effective safeguards must be implemented, maintained, and governed as part of normal operating practice rather than as a one-off policy statement.
Where this guidance breaks down is when accountability exists only on paper and neither team is measured on whether developers can actually use the security process.
When Usability Becomes a Governance Problem
Tighter application security often increases process overhead, so organisations have to balance stronger assurance against developer friction. That tradeoff becomes especially visible when teams are handling fast release cycles, multiple repositories, or inconsistent tooling across products. In those environments, a security gate that works for one team can become unmanageable for another if the workflow is not standardised or the exceptions process is unclear.
There is also a genuine consensus issue in the industry: some organisations place primary accountability in central security, while others make engineering the owner and security the policy authority. The better model depends on maturity, but the common failure is the same. If the accountable owner cannot change the workflow, they cannot make it usable. If they can change the workflow but do not understand the risk, they may remove the very control the organisation needs.
Another edge case appears in platform-heavy organisations. When shared CI/CD, internal developer portals, or guardrail tooling is owned centrally, the practical accountability may sit with a platform engineering function even though security still owns the risk criteria. In those cases, the question is less “who approves the policy?” and more “who is responsible for making the control usable in the path developers actually follow?” That distinction is often what determines whether adoption is high or merely mandated.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 6 — Access Control Management | Usable security depends on access and workflow controls developers can follow. |
| 16 — Application Software Security | The topic is directly about making application security workable within software delivery. | |
| Recommendation — Align access controls with developer workflows so protection is enforced without routine bypasses. Build application security checks into the delivery pipeline so they are usable at the point developers work. | ||
| NIST CSF 2.0 | GV.OV-01 — Organisational Risk Management Strategy | Accountability here is a governance question about who owns risk decisions and delivery fit. |
| PR.AT-01 — Awareness and Training | Developer adoption depends on security being understandable and usable in practice. | |
| Recommendation — Assign governance ownership for security usability and measure whether controls reduce risk without blocking delivery. Design developer-facing security processes so teams can use them consistently without relying on workaround training. | ||
Practitioner Guidance
What to prioritise: Put accountability on the team that can change the developer workflow, not just the team that can write the policy. Security should own the risk decision, but engineering or platform ownership should cover usability, integration, and day-to-day fit.
What to verify: Confirm that the accountable team can answer three questions without deferring elsewhere: where the control lives, how developers encounter it, and how exceptions are handled. If those answers are vague, ownership is not operationally real.
Common mistake: Treating “security owns security” as sufficient. That usually produces controls that are formally approved but practically bypassed, because no delivery owner is responsible for reducing friction or improving the path to compliance.
Practitioner takeaway: Usable application security is accountable only when the owner is close enough to the development workflow to change behaviour, while security leadership remains accountable for the risk boundary.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
