Subscribe to the Non-Human & AI Identity Journal

Who is accountable when cyber crisis decisions stall across teams?

Accountability sits with the leaders and governance owners who were supposed to define decision rights, priorities, and escalation before the incident. If those elements were never agreed, the gap is organisational rather than individual. Frameworks for resilience and incident governance expect that accountability is established in advance.

Why This Matters for Security Teams

When cyber crisis decisions stall, the immediate issue is rarely just speed. The deeper problem is that no one has been given the authority to decide, and no one has been told how far their remit extends when business continuity is under pressure. For NHI-heavy environments, that creates a second-order risk: teams cannot safely pause, rotate, revoke, or reissue access for service accounts, API keys, and automations without a clear owner. NHIMG research shows that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which is why response governance must include machine identities, not only human escalation paths. See The 52 NHI breaches Report and Ultimate Guide to NHIs — Why NHI Security Matters Now for the underlying exposure patterns. Guidance from CISA cyber threat advisories reinforces that incident roles, escalation paths, and pre-authorised actions should be defined before an event begins. In practice, many security teams encounter this failure only after a credential compromise has already spread across systems, rather than through intentional crisis design.

How It Works in Practice

Accountability in a stalled crisis should sit with the executives and governance owners who approved the operating model, plus the incident commander empowered to execute it. That means the question is not “who is to blame?” but “who had decision rights for containment, restoration, and communications?” In mature environments, those rights are documented in incident playbooks, mapped to business services, and tied to specific authority to suspend integrations, rotate secrets, and override normal approval chains.

A practical model usually includes:

  • a named executive owner for business risk acceptance,
  • a technical incident lead for containment actions,
  • a service owner for affected systems and identities, and
  • a governance function that validates whether the response matched policy.

For identity-heavy incidents, the response must also cover NHI controls. If a service account or API key is implicated, teams should know who can revoke it, who can reissue it, and who approves any temporary exception. NHIMG highlights that only 20% of organisations have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, which makes crisis execution fragile. See Top 10 NHI Issues and Ultimate Guide to NHIs — Key Challenges and Risks for the governance gaps that commonly delay action. For modern response design, current guidance also favours Zero Trust-style verification and rapid revocation over trust in legacy perimeter assumptions, which aligns with MITRE ATLAS adversarial AI threat matrix when automation or AI-driven workflows are involved. These controls tend to break down in federated enterprises where business units, cloud teams, and SaaS owners all believe someone else owns the final containment decision.

Common Variations and Edge Cases

Tighter crisis authority often increases operational friction, requiring organisations to balance faster containment against the risk of overreach or service interruption. That tradeoff is especially visible in regulated environments, outsourced operations, and shared platform teams, where one team can trigger impact across many business units. Current guidance suggests this should be managed through pre-approved playbooks rather than ad hoc debate, but there is no universal standard for every governance model yet.

A common edge case is when the incident affects autonomous systems, job runners, or AI agents that hold tool access and can continue acting while humans deliberate. In that situation, the accountable party must still be the human governance owner, but the operational response should prioritise workload identity, short-lived credentials, and immediate containment of the agent’s permissions. OWASP NHI Top 10 is useful here because it frames identity risk in agentic environments where access is executed by software rather than people. For broader AI governance, Anthropic — first AI-orchestrated cyber espionage campaign report shows why autonomous behaviour can outpace manual approval chains. The practical rule is simple: if the team cannot say who can stop the automation, it has not defined accountability well enough for crisis conditions.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
NIST CSF 2.0 GV.RM-1 Governance and risk ownership are central when crisis decisions stall.
NIST AI RMF GOVERN AI governance covers accountability for autonomous or semi-autonomous actions.
OWASP Agentic AI Top 10 A2 Agentic systems need explicit control over tool use and runtime authority.

Assign named risk owners who can make and document containment decisions during incidents.