How should organisations decide whether appsec, IAM, or platform teams own a control failure?

Why This Matters for Security Teams

Ownership disputes around control failures are rarely about labels. They are about which team can actually change the trust decision that failed. When an access problem surfaces in an application, the symptom may be visible to appsec, but the root cause may sit in IAM policy, a platform identity boundary, or the lifecycle of a secret. That is why the right model is shared accountability, not blame assignment after the fact.

This matters because control failures are often discovered late, after misuse has already occurred. NIST Cybersecurity Framework 2.0 frames governance as a cross-functional responsibility, not a siloed technical task, and NHI guidance from NHI Management Group reinforces that secrets, identities, and authorisation failures tend to span multiple domains. In practice, many security teams discover the real owner only after a leaked token, mis-scoped role, or broken signing workflow has already been exploited.

One useful reminder comes from the NHIMG analysis of The State of Secrets in AppSec, which shows how long leaked secrets can persist before remediation becomes effective. That is not just an appsec problem or just an IAM problem. It is a trust boundary problem that needs the right team to own the fix.

How It Works in Practice

A practical ownership model starts by asking where the trust decision is made and who can change it safely. If the control failure is about authentication, token issuance, signing, conditional access, or privilege scoping, IAM or platform engineering usually owns the mechanism. If the failure is about insecure use of credentials in code, poor secret handling, or missing guardrails in an application flow, appsec usually owns the application-side remediation. If the failure is about how the runtime environment exposes identity, workload metadata, or policy enforcement, platform teams often own the enforcement layer.

That mapping works best when organisations separate three layers:

• Identity issuance and lifecycle, including credentials, keys, certificates, and workload identities.
• Policy definition and authorisation, including role design, exceptions, and conditional access.
• Secure consumption, including application code, integrations, and runtime behaviour.

For example, a leaked API key may be discovered in source control, but the real issue might be that platform teams allowed a long-lived secret where a short-lived workload identity should have been used. Likewise, if a service account has excessive permissions, appsec may identify the exploit path while IAM owns the role model and platform owns the deployment pattern. NIST CSF 2.0 supports this kind of coordinated governance, while the NHIMG research on LLMjacking: How Attackers Hijack AI Using Compromised NHIs shows how quickly exposed credentials become an operational risk once an identity is live in the wild.

Best practice is to define a control owner, a remediation owner, and an accountable risk owner. That avoids the common failure mode where each team fixes only the part they can see. These controls tend to break down when shared services expose multiple identity paths at once, because no single team can prove end-to-end trust without joint change control.

Common Variations and Edge Cases

Tighter ownership rules often improve accountability but increase coordination overhead, requiring organisations to balance fast remediation against clear decision rights. That tradeoff becomes visible in hybrid environments, legacy stacks, and multi-cloud platforms where identity, secrets, and application code are managed by different teams.

There is no universal standard for this yet, so the decision should be driven by the control layer rather than a fixed RACI template. If the failure is in configuration drift, platform ownership may dominate. If the failure is in secret creation, rotation, or revocation, identity governance may own the remediation. If the failure is in insecure implementation or unsafe developer workflow, appsec may own the code fix even when IAM supplies the underlying token model.

Edge cases usually appear when the symptom is security-relevant but the cause is outside the first responder’s scope. A team may see a breach alert in an app, while the real defect is an over-privileged role or a misconfigured CI/CD identity. In those cases, the fastest path is a shared ticket with explicit handoff criteria, not a debate about organisational boundaries. NHIMG’s Azure Key Vault privilege escalation exposure research illustrates how quickly control failures cross team lines when identity and platform decisions intersect.

Where organisations get into trouble is when ownership is assigned by asset type instead of trust function. That works on paper, but in live incidents it leaves the root cause in place while each team assumes someone else has already fixed it.

Related resources from NHI Mgmt Group

• How do IAM teams decide whether an AI security assistant needs its own access controls?
• How can IAM teams decide whether an ITSM tool supports governance?
• How do IAM and compliance teams decide whether to buy point tools or broader governance platforms?
• How do organisations decide whether to replace an identity platform or keep extending it?