Incident Commander Assignment Governance requires that organisations predefine incident command roles and decision rights for serious AI agent failures before those failures occur. When a material AI agent incident occurs, the response requires coordination across multiple functions: technology (to diagnose and contain), risk (to assess exposure), legal (to evaluate regulatory notification obligations), communications (to manage stakeholder messaging), and operations (to implement fallback procedures). Without a predefined incident command structure, this coordination happens ad-hoc — individuals self-organise, decision authority is unclear, conflicting directions are given, and critical actions are delayed while people negotiate who is in charge. AG-267 requires that the incident command structure, decision rights, communication protocols, and handover procedures are defined, documented, communicated, and tested before an incident occurs.
Scenario A — Leaderless Incident Response: A bank's AI trading agent begins executing trades that systematically favour one counterparty — a pattern consistent with either a model error or a potential market manipulation scenario. The on-call operator (AG-263) detects the anomaly and escalates to Level 2 (AG-261). Three people join the call: the Head of Technology, the Head of Trading Risk, and the Chief Compliance Officer. Each has a different priority. Technology wants to preserve the agent's state for diagnosis. Trading Risk wants to kill the agent immediately to prevent further exposure. Compliance wants to assess whether regulatory notification is required before taking any action that might be seen as "destroying evidence." For 45 minutes, the three argue about the correct course of action while the agent continues trading. No one has predefined authority to make the decision. Eventually, the CEO is called and directs the kill, but by that time the agent has executed an additional 340 trades, and the total exposure from the anomalous period is £7.1 million.
What went wrong: No incident commander was designated. Three senior people with legitimate but conflicting priorities had no framework for resolving the conflict quickly. The 45-minute delay occurred not because anyone was wrong, but because no one was authorised to make a binding decision that overruled the others. Consequence: £7.1 million in potentially problematic trades, FCA investigation, mandatory independent review of incident response procedures, personal accountability review for the three senior individuals under SM&CR.
Scenario B — Effective Incident Command: A payment processor's AI reconciliation agent begins generating mismatches between its internal records and the correspondent bank's records. The on-call operator detects the anomaly and escalates to Level 2. The predefined incident command structure activates: the Operations Director assumes the Incident Commander role (predefined for reconciliation incidents), the Technology Lead assumes the Technical Lead role (responsible for diagnosis and containment), and the Compliance Officer assumes the Regulatory Liaison role (responsible for assessing notification obligations). The Incident Commander makes the binding decision: pause the agent, switch to manual reconciliation, preserve the agent's state for diagnosis. The Technical Lead executes the containment. The Regulatory Liaison begins the notification assessment in parallel. Total time from detection to containment: 22 minutes. The predefined roles meant that no time was spent debating who was in charge or what the priorities should be — the roles and decision rights were established before the incident.
What went right: Incident command roles were predefined with clear decision rights. The Incident Commander had binding authority. Each role knew their responsibilities. No time was wasted on authority negotiation.
Scenario C — Incident Command Handover During Extended Incident: A logistics company's AI route-optimisation agent experiences a sustained failure lasting 36 hours. The initial Incident Commander (the Operations Director) manages the first 12 hours but needs to hand over due to fatigue. The predefined incident command handover protocol activates: the incoming Incident Commander (the Deputy Operations Director) receives a structured briefing covering current status, actions taken, outstanding decisions, and open actions. The handover takes 30 minutes and is documented. The incoming Commander resumes command with full situational awareness. Over the 36-hour period, command is handed over twice more, each time following the same protocol. At no point does the incident lack a designated commander.
What went right: The incident command framework included handover procedures for extended incidents. Commanders were designated for multiple shifts. The handover protocol preserved situational awareness across transitions.
Scope: This dimension applies to all material AI agent incidents — defined as incidents that trigger Level 2 or Level 3 escalation (AG-261), involve potential regulatory notification, cause or risk causing financial loss exceeding £50,000, affect personal data of more than 100 data subjects, or involve potential safety risk. The scope covers the full incident lifecycle: detection, triage, containment, diagnosis, remediation, recovery, and post-incident review. For each phase, named roles with defined decision rights must be specified. The scope extends to cross-functional coordination: AI agent incidents typically require involvement from technology, risk, legal, compliance, communications, and operations, and the incident command structure must integrate all relevant functions. The scope also covers extended incidents: when an incident lasts beyond a single work shift, the command structure must support handover to maintain continuous leadership.
4.1. A conforming system MUST define an incident command structure for AI agent incidents, specifying at minimum: Incident Commander (with binding decision authority), Technical Lead (responsible for diagnosis and containment), Regulatory Liaison (responsible for notification assessment), and Communications Lead (responsible for stakeholder messaging).
4.2. A conforming system MUST predefine which named roles or individuals assume incident command for different categories of AI agent incident (operational, security, safety, regulatory), published and accessible to all potential incident participants.
4.3. A conforming system MUST grant the Incident Commander binding decision authority — the Commander's decisions on containment, escalation, and resource allocation SHALL override other participants' preferences during the active incident, subject to post-incident review.
4.4. A conforming system MUST define incident command handover procedures for incidents lasting beyond a single work shift (8 hours), including structured briefing requirements, documentation of current status and outstanding actions, and formal transfer of command authority.
4.5. A conforming system MUST require a documented post-incident review for every incident that triggered the incident command structure, conducted within 10 business days and including: timeline, root cause, response effectiveness, command structure effectiveness, and improvement actions.
4.6. A conforming system MUST test the incident command structure through simulated exercises at least annually, verifying that designated commanders can assume command, coordinate cross-functional response, and make binding decisions within defined timeframes.
4.7. A conforming system SHOULD define severity levels for AI agent incidents with corresponding incident command resource requirements (e.g., Severity 1 requires full command structure activation; Severity 3 requires Technical Lead only).
4.8. A conforming system SHOULD maintain an incident command toolkit — pre-configured communication channels, war-room access, documentation templates, and stakeholder contact lists — accessible to the Incident Commander at all times.
4.9. A conforming system MAY integrate AI agent incident command with the organisation's existing major-incident management framework, adapting the generic framework with AI-specific roles and decision criteria.
Incident command is a well-established discipline in emergency services, aviation, military operations, and IT major-incident management. The principle is simple: when multiple people must coordinate under time pressure, a predefined command structure with clear authority produces faster, more effective responses than ad-hoc self-organisation. This principle applies directly to AI agent incidents.
AI agent incidents present unique challenges that make incident command particularly important. First, AI agent failures can be technically opaque — the root cause may not be immediately apparent, requiring coordination between multiple technical specialists. Second, AI agent incidents often have regulatory dimensions — requiring real-time assessment of notification obligations while technical containment is ongoing. Third, AI agent incidents can involve conflicting priorities — technology wants to diagnose (which may require leaving the agent running), risk wants to contain (which may require stopping the agent), and compliance wants to preserve evidence (which may conflict with both). The Incident Commander's role is to resolve these conflicts quickly, making binding decisions that allow the response to proceed.
The binding authority requirement (4.3) is the critical element. Without binding authority, the Incident Commander is a coordinator, not a commander. In the Scenario A example, three senior people debated for 45 minutes because none had the authority to overrule the others. If any one of them had been designated as Incident Commander with binding authority, the decision would have been made in minutes. The post-incident review can assess whether the decision was correct — during the incident, the priority is making a decision and acting on it.
The handover requirement (4.4) addresses a practical gap: AI agent incidents can last hours or days, far exceeding a single person's effective decision-making window. Fatigue degrades judgment, and an Incident Commander making poor decisions after 16 hours of continuous command is more dangerous than a fresh Commander who needs 30 minutes to come up to speed. The handover protocol ensures that command transitions are structured rather than chaotic.
The incident command structure should be simple, practised, and integrated with existing organisational incident management frameworks.
Recommended patterns:
Each commander should have a designated deputy who assumes command if the primary is unavailable.
Anti-patterns to avoid:
Financial Services. Major-incident management for AI agents should align with the firm's existing major-incident management framework (typically required by DORA Article 17 and FCA operational resilience requirements). The incident command structure should integrate with the firm's existing Severity 1/2/3 classification and the corresponding management response. Under SM&CR, the Incident Commander may need to be a Certified Person or Senior Manager, depending on the severity and decision authority involved.
Healthcare. Clinical AI agent incidents must integrate with existing clinical incident management (Serious Incident Framework in the NHS). The Incident Commander for clinical AI incidents should be a clinician with appropriate authority — a technology leader may manage the technical response, but clinical decisions must be made by clinicians. The post-incident review should follow the clinical Root Cause Analysis (RCA) methodology.
Critical Infrastructure. Safety-critical AI agent incidents must integrate with existing emergency response frameworks (Control of Major Accident Hazards — COMAH, IEC 62443 incident response). The Incident Commander must have authority over safety functions, including the ability to invoke emergency shutdown procedures and notify emergency services. Real-time regulatory notification may be required (e.g., HSE notification for safety incidents).
Basic Implementation — An incident command structure is defined with named roles and decision rights. Incident Commanders are designated for different incident categories. The structure has been communicated to all potential incident participants. At least one simulated exercise has been conducted. Post-incident reviews are conducted for major incidents.
Intermediate Implementation — Incident command is integrated with the organisation's existing major-incident management framework. War-room activation occurs within 15 minutes. Handover procedures are defined and tested for extended incidents. Post-incident reviews are conducted for all incidents that trigger the command structure, within 10 business days. Improvement actions are tracked to closure. Annual simulated exercises include cross-functional participation.
Advanced Implementation — All intermediate capabilities plus: incident command response times are measured and trended (time from detection to command activation, time from command activation to containment). Simulated exercises include realistic scenarios with ambiguous information, conflicting priorities, and time pressure. Cross-entity incident command (AG-266) is tested for shared-control arrangements. The organisation can demonstrate that incident command is exercised effectively under adverse conditions, including simultaneous incidents, unavailable primary commanders, and extended duration.
Required artefacts:
Retention requirements:
Access requirements:
Testing AG-267 compliance requires verifying both the framework completeness and the operational readiness of the incident command structure.
Test 8.1: Framework Completeness
Test 8.2: Commander Activation Speed
Test 8.3: Binding Authority Exercise
Test 8.4: Cross-Functional Coordination
Test 8.5: Handover Effectiveness
Test 8.6: Post-Incident Review Timeliness
Test 8.7: Annual Exercise Evidence
| Regulation | Provision | Relationship Type |
|---|---|---|
| EU AI Act | Article 9 (Risk Management System) | Supports compliance |
| EU AI Act | Article 62 (Reporting of Serious Incidents) | Direct requirement |
| FCA SYSC | 3.2.6R (Responsibility for Compliance) | Supports compliance |
| DORA | Article 17 (ICT-Related Incident Management Process) | Direct requirement |
| DORA | Article 19 (Reporting of Major ICT-Related Incidents) | Supports compliance |
| NIST AI RMF | MANAGE 4.1 (Post-Deployment Monitoring) | Supports compliance |
| ISO 42001 | Clause 10.2 (Nonconformity and Corrective Action) | Supports compliance |
| NIS2 Directive | Article 23 (Incident Handling and Reporting) | Direct requirement |
| IEC 62443 | SR 6.1 (Audit Log Accessibility), SR 6.2 (Continuous Monitoring) | Supports compliance |
Article 62 requires providers and deployers to report serious incidents involving high-risk AI systems. Effective reporting requires effective incident management — knowing what happened, what was done, and what the impact was. AG-267's incident command structure ensures that incident information is collected in real time (through the incident log), decisions are documented (through command authority records), and a comprehensive account can be compiled (through the post-incident review).
Article 17 requires financial entities to establish an ICT-related incident management process, including defined roles, responsibilities, and escalation procedures. AG-267 directly implements this requirement for AI agent incidents, providing the command structure, decision rights, and coordination framework that Article 17 requires.
Article 23 requires essential and important entities to handle incidents and report significant incidents to authorities. AG-267's incident command structure provides the organisational framework for handling AI agent incidents and preparing regulatory notifications.
| Field | Value |
|---|---|
| Severity Rating | High |
| Blast Radius | Incident-specific but compounding with response delay |
Consequence chain: Without predefined incident command, AI agent incident response is characterised by delay, conflict, and fragmentation. Multiple functions respond independently with conflicting priorities. Decision authority is unclear, leading to extended debates while the agent continues operating. Critical actions (containment, regulatory notification, stakeholder communication) are delayed or omitted because no one is clearly responsible for them. The consequence is proportional to the response delay: an AI agent incident that could have been contained in 22 minutes (with effective command) may instead run for 3+ hours (without command). During those additional hours, governed exposure accumulates, affected individuals increase, regulatory notification deadlines approach or pass, and the organisation's ability to demonstrate competent governance degrades. The post-incident regulatory investigation will examine not just what happened but how the organisation responded — and a disorganised, leaderless response is itself a governance finding that compounds the underlying incident.
Cross-references: This dimension builds upon AG-261 (Escalation Authority Governance) which defines the graduated escalation levels that trigger incident command activation; AG-262 (Kill Authority Designation Governance) which must be integrated into the command structure; AG-263 (On-Call Responsibility Governance) which ensures that incident command can be activated outside office hours; AG-264 (Successor and Coverage Planning Governance) which ensures command handover is possible during extended incidents; AG-266 (Joint-Venture and Shared-Control Governance) which extends incident command to cross-entity scenarios; AG-268 (Whistleblower and Speak-Up Governance) which provides an additional channel for reporting incidents that may not trigger normal detection; and AG-019 (Human Escalation & Override Triggers) which defines the conditions that may initiate the escalation leading to command activation.