Who should be accountable for business application security findings?

Accountability should sit with both the business owner and the identity governance function. The business owner defines acceptable access and approval risk, while IAM or IGA teams enforce the control model, maintain evidence, and escalate unresolved conflicts. Without shared accountability, application risk is pushed between teams and left unowned.

Why This Matters for Security Teams

Business application security findings are not just technical issues. They represent decisions about who may approve access, accept risk, and fund remediation. If accountability is unclear, findings linger in ticket queues while application owners assume IAM will fix them and IAM assumes the business will decide. That gap is especially dangerous for secrets, service accounts, and other NHIs, where control failures are often invisible until misuse occurs.

Current guidance from the NIST Cybersecurity Framework 2.0 is clear that governance, risk ownership, and control execution need separate but connected responsibilities. NHIMG research shows why this matters operationally: in The State of Non-Human Identity Security, only 1.5 out of 10 organisations are highly confident in securing NHIs, and 45% cite weak credential rotation as a leading cause of NHI-related attacks. Those findings are not abstract; they point to a recurring ownership problem.

In practice, many security teams encounter unresolved access findings only after a leaked credential, over-privileged account, or failed review has already created an incident.

How It Works in Practice

The cleanest operating model is shared accountability with different duties. The business owner is accountable for the risk decision: whether the access, entitlement, exception, or compensating control is acceptable for the application and its data. The IAM or IGA function is accountable for the control design, evidence, workflow enforcement, and escalation when the business does not respond. That split prevents findings from being “owned by everyone,” which usually means owned by no one.

For business application findings, mature programs usually assign three things at the same time:

• Risk ownership to the application or data owner, who approves exceptions and residual risk.
• Control ownership to IAM, IGA, or PAM teams, who implement recertification, least privilege, and entitlement hygiene.
• Escalation authority to security governance, which forces closure when findings exceed risk tolerance.

That structure works best when findings are tied to a concrete asset, such as a privileged role, a service account, or an OAuth connection. NHIMG’s Ultimate Guide to NHIs — Key Research and Survey Results highlights the visibility gap that makes this necessary, especially where third-party access and non-human identities are involved. In those cases, the business owner must answer whether the connection still serves a legitimate purpose, while the identity team confirms that the grant is time-bound, logged, and reviewed.

For evidence, teams should capture who accepted the risk, what control was missing, what compensating control exists, and when the finding will be revalidated. Best practice is evolving toward policy-as-code and workflow automation, but there is no universal standard for this yet. These controls tend to break down when application ownership is split across business units, because approval authority and technical remediation responsibility get separated without a clear escalation path.

Common Variations and Edge Cases

Tighter accountability often increases process overhead, requiring organisations to balance faster remediation against more formal approval and evidence capture. That tradeoff matters most when the application is customer-facing, regulated, or deeply integrated with NHIs and machine-to-machine access.

There are a few common exceptions. If the finding is purely technical, such as an expired certificate renewal workflow or a broken entitlement sync, IAM or the platform owner may be the primary remediation owner. If the finding changes business risk, such as approval of privileged access, data exposure, or exception to segregation of duties, the business owner must retain accountability. For cross-functional issues, current guidance suggests using a risk committee or control board to resolve disputes rather than letting tickets cycle indefinitely.

For teams formalising this model, the safest rule is simple: the business decides whether the risk is acceptable, while identity governance decides whether the control is enforced and evidenced. That is the practical line between ownership and execution. The OWASP Agentic Applications Top 10 underscores how quickly automated systems can amplify weak approvals, especially when access decisions are reused at scale.

Related resources from NHI Mgmt Group

• How should security teams make NHI best practices usable across the business?
• Who is accountable when identity security controls fail across IAM, PAM, and NHI programmes?
• Who is accountable when a broken application control affects financial reporting?
• Who is accountable when SAP SoD findings are not remediated?