Decision Rights, Change Authority and the Incident Commander

On a bad night an operations organisation takes decisions that no runbook takes for it: whether to declare an incident, who commands it, whether to stop an agent, whether to approve a change that has had no review, whether to move traffic to another site, whether to restore over data that exists, whether to break a freeze. This chapter concerns O2 Diagnose, where the incident is declared and commanded, O3 Change, where change authority decides what may enter production and on what evidence, and O4 Restore, where failover, restore and the stop of an agent are decided. Its subject is who holds each decision, who deputises, how quickly the holder must answer, what evidence the holder needs and what record the decision leaves, written as a requirement into a delegation profile that a policy decision point outside the agents can read.

The chapter builds on conclusions of the earlier volumes. Decisions are tiered and routed to the lowest tier that can take them with evidence, and the tier policy is data that changes by pull request (AI Governance, Chapter 13, F17); forums decide what pipelines cannot (F18); stop decisions are named in advance (F19) (296, Nordqvist, 2026). Decision rights to stop, pause, deny or reverse are assigned before the crisis to holders who can act within the time the threat allows, and the right to stop must be cheaper to exercise than the right to continue (AI Threat, Chapter 30, F63) (299, Nordqvist, 2026). The transformed team is an artefact with a delegation profile per function and action class, in which the lowest ceiling governs and an unlisted action is undelegated (AI Blue, Chapter 4, F93); accountability does not pass to a tool (F100); and a decision right has a holder, two deputies, a response time, an evidence standard and a record (AI Blue, Chapter 18, F107) (302, Nordqvist, 2026). AI Purple, Chapter 20, added a decision-rights file of ten decisions, the rule that position governs, and risk acceptance routed by severity with an expiry (F134). This chapter applies that method to operations, beside the observer principle of Chapters 4 and 17.

Figure 22.1: Decision rights across the operations loop: named holders, a policy decision point that reads the delegation profile, a stop right outside the platform and an independent probe.

Decision rights as requirements

A decision right is the authority to take a defined decision and to be obeyed. Weill and Ross organised their study of information technology governance around decision rights, the question of who holds the authority to decide what (277, Weill & Ross, 2004). Operations has always had such rights in practice and has seldom written them down. Written down, a right becomes testable, and the test is the point. An incident that takes forty minutes to find a person who may authorise a failover has lost the forty minutes whether or not the failover was the right decision.

Six fields

Each right in this book has six fields.

1. Holder. A role, filled from a rota by a named person on the day. A right held by a person and not a role lapses when the person is on leave.
2. Deputy and second deputy. Two further roles, each qualified to decide, with the rule for when they take over. A right with no deputy is a wish; it fails when the holder is asleep, travelling or the subject of the incident.
3. Response time. The time within which the holder, or failing that a deputy, must answer, set from the shortest clock that the decision feeds.
4. Evidence standard. What the holder must have seen before deciding, as a list that can be checked afterwards: a probe result, the status of a claim in the resilience register, the change record.
5. Record. Where the decision is written, by whom and within what time. A decision with no record cannot be reviewed, taught or shown to a supervisor.
6. Ceiling for AI. The highest degree of delegation an AI system may hold in relation to the decision, from Level 0 Advisory to Level 3 Bounded, with the statement that Level 4 Autonomous is never used where the prohibitions of Chapter 4 apply.

What is new for operations is the source of the response time and the reach of the ceiling. Response times derive from clocks that law and contract impose and from the page target of the service. NIS 2 Article 23(4) requires an early warning within 24 hours of becoming aware of a significant incident, and the incident clocks of Chapter 14 run from awareness and from classification, so the person who classifies must be reachable early in the incident, not late (3, European Union, 2022). The Google SRE book gives 5 minutes as a typical response target for user-facing or otherwise highly time-critical services (118, Spadaccini, 2016), which is also the 5-minute acknowledgement target for a Tier 1 page at Hansa Mutual. The ceiling for AI follows from the action classes of Chapter 4, because every decision in this chapter either authorises an action of one of the eleven classes or concerns the observation or the stop path.

Why the law asks for them

The instruments do not use the phrase decision right, and they ask for it. DORA Article 5(2)(c) requires the management body of a financial entity to set clear roles and responsibilities for all ICT-related functions and to establish governance arrangements that ensure timely communication, cooperation and coordination among them. Article 17(3)(c) requires the incident management process to assign the roles and responsibilities that need to be activated for different incident types and scenarios, and Article 17(3)(e) requires that at least major incidents are reported to senior management and the management body (2, European Union, 2022). The delegated regulation on ICT risk management repeats the point at the level of operations: Article 23(1) requires clear roles and responsibilities to detect and respond to incidents and anomalous activities, and Article 26(1) requires response and recovery plans to specify the conditions prompting their activation or deactivation and the conditions for declaring successful execution, with roles and responsibilities clearly specified. Article 26(2)(e) lists among the scenarios the non-availability of a critical number of the staff in charge of continuity, which is the case that a second deputy exists to cover (8, European Commission, 2024).

NIS 2 Article 20(1) requires the management bodies of essential and important entities to approve the cybersecurity risk-management measures, to oversee their implementation and to be capable of being held liable, without prejudice to national law on the liability of public institutions and officials (3, European Union, 2022). The allocation of who may stop, fail over or accept risk is a measure of the kind the article means, so it falls under the management body's approval. The AI Act adds a requirement that bears on the human side of every AI-assisted decision. A deployer of a high-risk AI system must assign human oversight to natural persons who have the necessary competence, training and authority, as well as the necessary support (Article 26(2)), and the system must be provided so that those persons can decide not to use it, or to disregard, override or reverse its output, and can intervene or interrupt it through a stop button or similar procedure that brings it to a halt in a safe state (Article 14(4)(d) and (e)) (1, European Union, 2024). The articles concern high-risk AI systems and not every operations agent; the design requirement transfers, because an overseer without the authority to override is not an overseer.

These readings are organisational and architectural implications, not legal advice. They tell an organisation that a supervisor will ask who holds the right, who stands in and what the record shows.

Position governs

Four rules about the position of the decider recur. They come from AI Purple, Chapter 20, and are restated for operations.

• The authoriser does not run. A person who approves a Level 2 action does not also execute it. The operations lead or the runbook runner executes, and the commander watches the independent probe.
• The requester does not approve. The approver of a change is never its requester or its author, whether the author is a person or an agent, in line with the independence of approving and requesting functions that Article 17(1)(b) of the delegated regulation requires of financial entities (8, European Commission, 2024).
• The acceptor neither authors nor closes. The person who accepts a residual risk did not write the change or the runbook that created it, and does not close the finding that the acceptance opened.
• A conflicted holder passes the decision. A commander who approved the change now under suspicion hands that decision to a deputy and says so in the record. The rule is a courtesy to the holder, who is spared the pressure of judging their own work.

The incident commander

Operations borrowed the incident commander from emergency management, and the sources agree on the shape of the role even where they differ in detail. The Google SRE book states that, de facto, the commander holds all positions that they have not delegated, that the commander's most important responsibility is to keep a living incident document, and that the post must be clearly handed off (132, Stribblehill, 2017). The workbook's chapter on incident response organises the roles in a hierarchy in which the commander leads and the operations lead and the communications lead report to the commander, advises declaring incidents early and often, and lets the commander either hand off command and take the operations role or assign the operations role to someone else (133, Mace et al., 2018). PagerDuty's published response guide describes the commander as the final decision maker for the incident, the highest-ranking individual on the call whatever their day-to-day rank, who notes objections and decides, who does not perform the technical work, and whose deputy must be as qualified as the commander. The guide adds the rule for the executive who disagrees: the commander asks whether the executive wishes to take command and, if so, performs a formal handover (275, PagerDuty, 2026). The U.S. National Incident Management System, from which the structure descends, states the underlying principles: command is clearly established at the start, transfer of command includes a briefing, each individual reports to one supervisor (unity of command), and one supervisor to five subordinates is a guideline for span of control and not a rule (276, Federal Emergency Management Agency & U.S. Department of Homeland Security, 2017).

What the commander decides

The commander's authority is broad and bounded. Within an incident the commander decides the class and severity, who holds the operations and communications roles, which hypotheses are worked first, whether to approve an emergency change, whether to authorise a failover and when to declare the service restored. Four things lie outside it. The legal classification of the incident, whether it meets the definition of a serious incident, a major ICT-related incident or a personal data breach, belongs to the people designated for it (Chapter 14). A restore over existing data needs the service owner as well, a freeze is broken with a second holder, and a risk acceptance beyond the incident is routed to the person the profile names. And any decision about a named person's access to work is outside every operations decision right in this book, because it is a management function (Chapter 4).

The commander's authority is pre-assigned, which is what makes the PagerDuty rule usable. A junior commander who tells a head of department to stop interrupting is exercising a right that the management body granted in the profile, and the profile says so in terms. Without the written grant the commander has to argue the point during the incident.

Commander and agent operator

Two roles often sit in one person. At Hansa Mutual the commander of the Polish night rota is also the agent operator of the IT-operations agent for the night window (Chapter 21). The profile resolves the position conflict by rule. The stop right is held in both capacities and costs nothing to exercise. The commander approves the agent's Level 2 actions and does not execute them, and the independent probe, not the commander's reading of the agent's report, confirms the effect. If the incident concerns the agent itself, the commander hands command to a deputy and acts as agent operator only.

Handover and deputies

A handover is a decision with a record: the outgoing commander briefs the incoming one, the briefing is written into the incident record, and the incoming commander confirms and the time is logged. Fatigue is one of the reasons the PagerDuty guide gives for a transfer, and in Europe the rule on daily rest, a minimum of 11 consecutive hours per 24-hour period under the Working Time Directive (18, European Union, 2003), applies to the commander as to anyone, so a long incident passes through a handover whether or not the commander wishes it (Chapter 25). The arrival of a more senior person does not change the commander unless the commander hands over, which protects the person in the role.

A deputy is an incident commander in every respect. The second deputy at night is a more senior person, normally the head of the function, and a profile is defective when its second deputy cannot be woken. The escalation is mechanical: if the commander does not acknowledge within the response time the page goes to the deputy, and if the deputy does not, to the second deputy. A drill that silences the primary page and measures the time to the first acknowledged command is the test, run in the cycle of the stop drill.

With and without the assistant

The incident assistant of Chapter 7 changes the work around the commander and not the commander's rights. The decision stages of Parasuraman, Sheridan and Wickens, information acquisition, information analysis, decision and action selection, and action implementation, give the vocabulary: automation can operate at each stage at its own level, and selection is the stage where it is most dangerous to let it take over (223, Parasuraman et al., 2000). The profile keeps the assistant in the first two stages. It retrieves, correlates changes and ranks hypotheses at Level 1 Assisted; it drafts internal updates and files the candidate record and the declaration at Level 2 Supervised, so that the commander has approved before the declaration takes effect; and its ceiling for external communication is Level 0 Advisory. It never classifies the incident, because classification feeds the reporting clocks and the legal consequence belongs to a person.

Three design choices keep the contribution from becoming the decision. The ranking is released after the commander and the operations lead have each recorded a hypothesis, or ten minutes after declaration (Chapter 7). A decision in the classes that change production needs a second hypothesis and one refuting observation from a source the assistant did not select. And a seeded-incident catch rate below 0.8 lowers the ranking ceiling to Level 0 until a person has reviewed why. Parasuraman and Manzey's review traced complacency and bias to the attention of people working with automated aids (218, Parasuraman & Manzey, 2010); the design assumes that an exhausted commander at 03:00 will lean on a ranked list, and makes the lean visible and testable.

Two commanders

Operations incidents and security incidents overlap: a failing authentication service is an outage until the evidence says otherwise, and the security operations function of AI Blue then has its own commander, with its own rights over containment of the adversary. The book's rule, in the spirit of the unified command of NIMS, in which participating organisations jointly set objectives and keep their own authority (276, Federal Emergency Management Agency & U.S. Department of Homeland Security, 2017), is that each commander keeps the decisions of their own function and the two agree the objectives in the incident record. Where the objectives conflict, usually restoration against preservation of evidence, the decision goes to the pair the profile names, normally the head of operations and the CISO or their deputies, and the record states who decided and why.

Change authority

Change authority is the set of decision rights over what enters production. The traditional form is the change advisory board, a standing meeting that reads change requests. The evidence on that form is mixed in a specific way. The DevOps Research and Assessment programme reports that its research found no evidence to support the hypothesis that a more formal, external review process lowers change fail rates, links heavyweight approvals to slower delivery and larger batches, finds change approval best implemented through peer review during development supported by automation, and keeps a role for a central board in notification, coordination and trade-offs that need sign-off at a higher level (139, Google Cloud, n.d.). The finding concerns approval by a body distant from the change. It does not say that approval is unnecessary, and the regulation for financial entities requires approval that is independent of request and implementation (8, European Commission, 2024). A peer in another team is independent in that sense, and a distant board need not be.

Chapter 8 defined the classes of change and left the decision rights to this chapter. They are as follows.

Standard change: approved once, as a class. The change authority approves a class, a catalogued kind of change with eligibility, limits, a verification, a tested rollback, a budget consequence and an expiry of twelve months, and the pipeline's policy gate approves each instance. The decision right that matters is the right to create, suspend and withdraw a class. At Hansa Mutual the head of Group Site Reliability and Incident Management holds it, with the head of operational resilience reading every class that touches a critical or important function; a rise in level for a class that an agent releases at Level 3 Bounded goes to the group AI governance board (Chapter 16). At Nordvik Region the Head of IT and Digitalisation holds it, advised by the CISO's delegate and the platform lead, and no class exists yet.

Normal change: approved by a peer and a gate. A reviewer who is neither requester nor drafter approves, and the policy checks of Chapter 8 compute the class from the diff and deny a lower declared class. A Tier 1 service adds a second reviewer from another team. The decision is a field of the change record CHG-*, with the policy results and the rollback plan. The owner of an agent that drafts or requests a change is the requester for the independence rule.

Exception: the authority forum. The board survives as a small forum for the first change of a new kind, a change whose blast radius exceeds the budget of Chapter 9, a change to a protected path such as policy, a mandate or an observer manifest, a freeze exception that is not an emergency, and the approval of new classes. It meets when there is something to decide, and its decisions are records. It reads the exceptions and the statistics of the classes, not every change.

Emergency change: declared by a person, approved by the commander. The delegated regulation requires procedures and tools to manage emergency changes with adequate safeguards and procedures to document, re-evaluate, assess and approve them after implementation (Article 17(1)(f) and (g)) (8, European Commission, 2024). The book adds three conditions. A person declares the emergency; an agent may draft the change at Level 2 Supervised or below and never chooses the class. The approver is the commander or a deputy, never the requester. And the record is completed within five working days, the period Chapter 8 sets for adopting or reverting emergency drift.

The Knight Capital order of the U.S. Securities and Exchange Commission shows what the absence of such rights looks like. It records that on 1 August 2012 the firm had no supervisory procedures to guide its personnel when significant issues developed, relied primarily on its technology team to address the problem in a live trading environment, and in one attempt uninstalled the new code from the seven servers where it had been deployed correctly, which worsened the problem; the firm accumulated an unintended multi-billion dollar portfolio in about forty-five minutes and lost more than USD 460 million (80, U.S. Securities and Exchange Commission, 2013). The order is a finding about a market access rule, and the book draws one observation from it: an action taken in an incident is a change, and a change without a named approver, a stated rollback and a halt condition can enlarge the incident.

Break a freeze

A freeze is a decision by people who know what else is happening. Breaking one is a decision of the same kind, and it needs two holders (Chapter 9). At Hansa Mutual they are the commander and the head of Group Site Reliability and Incident Management or a deputy; at Nordvik Region the duty manager and the Head of IT and Digitalisation. The exception states why the change cannot wait, uses the smallest ring and the strictest stop conditions, and is reviewed afterwards. An agent never holds the right and never breaks a freeze on a critical function at any level.

Failover and stop

Failover

A failover moves service to another site, region or provider. It reverses at cost and time, can strand writes and is rarely rehearsed. The ceiling for an agent is Level 2 Supervised in general and Level 1 Assisted across providers for a critical function (Chapter 4), and the profile of the IT-operations agent keeps it at Level 1 for the claims core. The decision belongs to the commander, with the evidence standard drawn from the resilience register of Chapter 19: the commander reads the status of the failover claim, and the profile says what the status permits.

Register status of the failover claim	Commander decides alone	Concurrence needed	Record
Verified	Yes	None	Decision log
Expired or implemented but unverified	Yes, with the status stated	Head of SRE or deputy, by telephone	Decision log and a time-boxed acceptance that ends with the incident
Failed, asserted or untested	Only where harm is imminent	Standing acceptance by the service owner's superior, with expiry	Decision log, acceptance reference and a post-incident review item

The table is the book's design. It does not forbid a failover on a failed claim, because a service that is down while a failover is possible has a worse expected outcome than a failover of unknown quality; it makes the unknown visible. The standing acceptance in the last row is recorded before the incident, in the risk acceptance file below, so that nobody is woken at three in the morning to accept a risk that everyone already knows about.

Failback is a separate decision with its own record, held by the commander with the service owner, because returning traffic to a repaired primary has its own risks. A staged return is the default for a large service. Meta's report on its outage of October 2021 describes why: the engineers did not flip services back on all at once, because a sudden reversal of the dip in power consumption could put electrical systems and caches at risk, and the loss of normal remote access meant engineers had to go to the data centres, where secure access protocols took extra time (79, Janardhan, 2021). Each stage has its own halt condition, and the holder for the first stage is not automatically the holder for the second.

Restore over existing data

A restore over existing data cannot be undone for what it overwrites. The ladder of Chapter 14 places it at the top, with the commander and the service owner as holders and Level 1 Assisted as the ceiling for the agent. The decision follows a restore into a separate target and a comparison, and a named person executes. Level 4 Autonomous is never used, and the evidence standard names the comparison.

The stop right

The stop right differs from every other right in this chapter. Any holder may exercise it, it needs no approval and no prior justification, and it costs the organisation and not the individual if the stop proves unnecessary (AI Blue, Chapter 18, F107). The reasoning is that the right to stop must be cheaper to exercise than the right to continue, since an operator who has to justify a stop will hesitate for the length of the justification. A stop in good faith is recorded as an exercise of the right and never as a failure of the operator.

Chapter 16 fixed the rule for the holders: for every action class the manifest answers who can stop the agent, and the answer is a list of roles that includes at least one reachable out of hours without approval. The halves are tested separately. Reachable out of hours means a role with a 24-hour rota, not a person who might answer the telephone. Without approval means that the holder acts first and informs afterwards, and that the mechanism accepts the action without asking the agent, the agent platform or the ticketing system. The agent owner alone fails the rule, because the owner may be unreachable. The mechanism sits outside the platform on which the agent runs, as the third test of the observer principle requires (Chapter 17): revocation of the agent's workload identity at the identity provider, and a disabled trigger at the network edge. The pipeline kill switch and the freeze flag follow the same rule.

Restart is a separate decision: the agent owner restarts, at a lower level than before, after reading the incident record. Hansa Mutual's profile lists three stop holders, the incident commander, the agent operator and the platform engineer on call, and its drill of 2028-10-24 stopped the IT-operations agent in 4 minutes 10 seconds against a target of 5 (SPT-HM-ITOPS-2028-Q4-01), where the first drill of the series had taken 17 minutes (STOP-HM-ITOPS-2027-Q1-01). The profile carries the date of the last drill and expires the claim at 90 days.

A short check makes the rule enforceable in the repository. It fails a build when a Tier 1 right has fewer than two deputies, when the stop right needs approval or has no role reachable out of hours, or when a record or an evidence standard is missing.

import sys
import yaml

REQUIRED = ("holder", "deputies", "respond_minutes", "evidence", "record")


def check(profile: dict) -> list[str]:
    errors = []
    rota = profile.get("rota", {})
    for name, right in profile["decision_rights"].items():
        if name == "D3_stop":
            continue
        holder = right.get("holder") or right.get("holders")
        missing = [f for f in REQUIRED[1:] if not right.get(f)]
        if not holder or missing:
            errors.append(f"{name}: missing holder or {missing}")
        if len(right.get("deputies", [])) < 2:
            errors.append(f"{name}: fewer than two deputies")
    stop = profile["decision_rights"]["D3_stop"]
    if stop.get("approval") != "none":
        errors.append("D3_stop: approval must be none")
    if not any(rota.get(r) == "24x7" for r in stop["holders"]):
        errors.append("D3_stop: no holder reachable out of hours")
    if "agent-owner" in stop["holders"] and len(stop["holders"]) == 1:
        errors.append("D3_stop: the agent owner alone is not a stop path")
    if stop.get("mechanism_runs_on") in (None, "agent_platform"):
        errors.append("D3_stop: mechanism must run outside the agent platform")
    if stop.get("last_drill_age_days", 999) > 90:
        errors.append("D3_stop: drill older than 90 days")
    return errors


if __name__ == "__main__":
    problems = check(yaml.safe_load(open(sys.argv[1])))
    print("\n".join(problems) or "decision rights: ok")
    sys.exit(1 if problems else 0)

Risk acceptance

Some risks are accepted before an incident and some during one, and both need a named person and an end date. AI Purple, Chapter 20, set the rule that risk acceptance is routed by severity, with a reason, a compensating control and an expiry (F134). In operations the commonest acceptances are these: running a Tier 1 service whose recoverability claim has failed or expired, which is the situation in which both organisations begin the book; operating an agent at Level 3 Bounded while its evidence has aged; running with an observer that depends on a shared failure domain, recorded as an accepted shared dependency (Chapter 17); and deferring a change that a problem record requires.

The routing follows the severity of the service and the size of the residual risk. The service owner accepts what stays inside the service level objective and error budget of a Tier 2 or Tier 3 service. The head of operations, or at Nordvik Region the Head of IT and Digitalisation, accepts for a Tier 1 service. The management body accepts what exceeds the tolerance it has itself set: for a financial entity DORA Article 5(2)(d) assigns the ICT risk tolerance to the management body and Article 5(2)(a) places the ultimate responsibility on it (2, European Union, 2022); for a public authority the equivalent is the regional executive committee or the body that national transposition of NIS 2 names under Article 20 (3, European Union, 2022). The book's defaults for expiry are 90 days for a standing acceptance on a Tier 1 service, 180 days for Tier 2 and Tier 3, never later than the evidence it concerns, and the end of the incident for an acceptance made within one. Each acceptance names a compensating control, such as a manual fallback or a shorter drill interval, and the register shows it beside the claim, so that a board reading "recoverable for 9 of 31 claims" also reads how many of the other 22 stand under an acceptance and until when.

Two things are not accepted at all. A prohibition of Chapter 4 is not a risk to be weighed: no acceptance permits Level 4 Autonomous for an irreversible action on production data, outside an authorised window or freeze on a critical function, on the observation or the stop path, or on a named person's access to work. And no acceptance covers a decision that belongs to a statute: a person cannot accept on behalf of the organisation that a reporting clock will not be met.

Delegation profiles and the register

A delegation profile DLG-* states, for one agent and one service, what the agent may do (Chapter 4). A decision-rights file DRF-* states, for one organisation and one tier of service, who may decide what. In this chapter the two meet in one file for the incident command position, because the assistant's ceilings and the humans' rights refer to the same decisions and are reviewed together. The delegation register lists every profile in force, its levels per action class and the sum of what the organisation has delegated, so that a supervisor can read the total and not only the parts (AI Blue, Chapter 4, F93). The reversibility test applies: for each delegation there is a statement of how it is undone and how quickly, and a lowering takes effect when anyone with the stop right decides it, while a rise needs the named authority, a decision record and the evidence.

Worked example: delegation profile DLG-HM-OPS-02

The profile below is illustrative and fictional. It completes the fragment that Chapter 7 used for the incident record INC-HM-2028-0871: the ceilings and display policy of the incident assistant HM-OPS-002 are those of the fragment, and the decision rights of the humans around it are added. It is in force from 2028-11-14 under AIDR-0972, which answers the commission of AIDR-0950 for the incident command position.

delegation_profile: DLG-HM-OPS-02
version: 1.0.0
status: active
effective: 2028-11-14
decision_record: AIDR-0972
owner: Tobias Richter            # head of Group Site Reliability and Incident Management
second_line_reader: head-of-operational-resilience
scope: {services: [SVC-HM-001, SVC-HM-002, SVC-HM-004, SVC-HM-006], tier: 1, cif: true}
rota: {incident-commander: 24x7, agent-operator: 24x7, platform-engineer-on-call: 24x7,
       head-of-sre: business-hours-and-escalation}
assistant:
  id: HM-OPS-002                 # AIDR-0951
  ceilings: {retrieve: 1, correlate_changes: 1, rank_hypotheses: 1, draft_internal_update: 2,
             open_candidate_incident: 2, declare_incident: 2, external_communication: 0}
  display_policy: {ranking_release: {after_human_hypotheses: 2, or_minutes_from_declaration: 10},
                   min_candidates: 3}
  gate: {action_classes_requiring_second_hypothesis: [reconfigure, deploy, roll_back, fail_over,
         delete, restore_over_existing], evidence_source_must_differ_from_assistant: true}
  stop_rule: {seeded_catch_rate_below: 0.8, on_breach: {rank_hypotheses: 0}}
decision_rights:
  D1_declare_classify: {holder: incident-commander, deputies: [ic-hamburg-standby, head-of-sre],
    respond_minutes: 10, evidence: [slo_burn_or_customer_impact, second_team_or_unsolved_60min],
    record: incident.decisions, ai_ceiling: "Level 2 files after approval; never classifies"}
  D2_command_handover: {holder: outgoing-commander, deputies: [incoming-commander, head-of-sre],
    respond_minutes: 10, evidence: [written_briefing], record: incident.timeline, ai_ceiling: "Level 1 drafts"}
  D3_stop: {holders: [incident-commander, agent-operator, platform-engineer-on-call], approval: none,
    respond_minutes: 5, mechanism: [revoke_identity_at_idp, disable_trigger_at_edge],
    mechanism_runs_on: outside_agent_platform, last_drill_age_days: 15, restart: agent-owner-at-lower-level}
  D4_emergency_change: {holder: incident-commander, deputies: [ic-hamburg-standby, head-of-sre],
    respond_minutes: 10, evidence: [second_hypothesis, rollback_plan, change_record],
    record: CHG, approver_never: requester, ai_ceiling: "Level 2 drafts; emergency declared by a person"}
  D5_failover: {holder: incident-commander, deputies: [ic-hamburg-standby, head-of-sre],
    respond_minutes: 10, evidence: [claim_status_from_register, probe_of_target], record: incident.decisions,
    concurrence_if_claim_not_verified: head-of-sre-or-deputy, ai_ceiling: "Level 1"}
  D6_restore_overwrite: {holders: [incident-commander, service-owner], deputies: [head-of-sre, cro-delegate],
    respond_minutes: 15, evidence: [restore_to_separate_target_compared], record: CHG, ai_ceiling: "Level 1; Level 4 never"}
  D7_break_freeze: {holders: [incident-commander, head-of-sre], deputies: [ic-hamburg-standby, group-cio-delegate],
    respond_minutes: 15, evidence: [why_it_cannot_wait, smallest_ring], record: FRZ-exception, ai_ceiling: "Level 0; never an agent"}
  D8_classify_for_reporting: {holder: head-of-operational-resilience-or-deputy, deputies: [dpo-delegate, legal-duty-officer],
    respond_minutes: 30, evidence: [clock_sheet], record: incident.clocks, ai_ceiling: "Level 1 drafts the clock sheet"}
  D9_external_communication: {holder: communications-lead, deputies: [incident-commander, head-of-sre],
    respond_minutes: 30, evidence: [commander_approval], record: incident.timeline, ai_ceiling: "Level 1 drafts; a person sends"}
  D10_declare_recovery: {holder: incident-commander, deputies: [ic-hamburg-standby, head-of-sre],
    respond_minutes: 10, evidence: [independent_probe_pass, reconciliation], record: incident.decisions, ai_ceiling: "Level 0"}
employee_representation: "KBV-IT-2024-OPS-01 rotas and rest; -02 measures at team level, minimum group 5"
review: {every_days: 90, next: 2029-02-12, also_after: any_major_incident}

The file is read by the policy decision point for the assistant's ceilings and by the checker above for the decision rights. At night the first deputy is the Hamburg standby commander and the second is the head of the function. The commander of the Polish night rota, Ewa Kowalczyk, answers within 10 minutes for declaration, takes the stop right in two capacities as commander and agent operator, and hands any decision about the agent itself to the deputy.

Practical guide: building a decision-right matrix for the first ten decisions of a bad night

Purpose. Produce, for one tier of services, a decision-rights file in which each of the first ten decisions of a serious incident has a holder, two deputies, a response time, an evidence standard, a record and a ceiling for AI, and in which the stop right is shown to work out of hours.

Roles. The head of operations or head of site reliability engineering, who owns the file; the incident commanders of the rota; the service owners; the head of operational resilience or the CIO's delegate; the CISO's delegate; the data protection officer for the classification right; and employee representatives for response times and rotas.

Steps.

1. Replay the last three Tier 1 incidents from their records. List every decision taken, by whom, and how long it took to find that person. Nordvik Region's failover after the storage controller failure of 2027-02-18 took 3 hours 40 minutes against a 2-hour objective (INC-NR-2027-0034); the record does not say how much of that was waiting for a decision, and the replay is how the Region finds out.
2. Fix the list. The ten decisions are declare and classify; take or hand over command; stop an agent or hold a pipeline; approve an emergency change or rollback; authorise failover; authorise restore over existing data; break a freeze; classify for reporting; communicate externally; declare recovery and close. Add what the replay found and drop nothing without a reason.
3. Name each holder as a role with a rota and two deputies, the second of whom can be woken. Check that no holder is also the requester, author or closer of the thing decided.
4. Derive each response time from the shortest clock the decision feeds: the page target (5 minutes to acknowledge for Tier 1 at Hansa Mutual, 15 at Nordvik Region), the target for the stop right (5 minutes for an agent with write access to production) and the clock sheet of Chapter 14 for classification. Adapt to the contract and the works agreement.
5. Write the evidence standard as a list a reviewer can check afterwards, and tie failover and restore to the status of the claim in the resilience register.
6. Set the ceiling for AI per decision from the action classes of Chapter 4, and write the Level 4 prohibitions as refusals at the policy decision point.
7. Test the stop right. Confirm a 24-hour holder and no approval, run the stop drill with the platform degraded, and run the escalation drill by silencing the primary page. Record both times.
8. Put the file in version control, run the checker in the pipeline, and have the management body or its delegate approve it.
9. Agree response times, rotas and the decision log with employee representatives before use, and report measures for teams and services, never by named person.
10. Review every 90 days and after every major incident. A lowering takes effect at once; a rise needs the named authority and a decision record.

Definition of done. The file is in version control with a named owner and an approving authority; the checker passes; each of the ten decisions has a holder, two deputies, a response time, an evidence standard and a record; the stop drill and the escalation drill are on record with dates and measured times; the representatives' agreement is referenced; and the first review date is set.

Evidence for supervisors

A supervisor who asks who may do what in an incident should receive five things: the profile in version control with its history; the decision log of a sample of incidents, showing for each decision the holder, time, profile and evidence, and listing as exceptions the decisions taken by someone other than the listed holder; the drill records for the stop right and the escalation chain; the register view with the acceptances beside the claims; and the record of AI contributions in the incident, marked by kind and outcome (Chapter 7). DORA Article 11(8) requires readily accessible records of the activities before and during disruption events, and Article 5(2)(i) requires reporting channels through which the management body is informed of at least major incidents and the response and recovery measures (2, European Union, 2022). The decision log gives those articles content for the commander's decisions. Responsibility does not pass to a tool: a log in which the assistant appears as decider, without a delegation that names who delegated it, is defective (AI Blue, Chapter 4, F100).

Outlook, labelled

That named roles, a management body that approves them and records of what was decided are required of financial entities by DORA and of essential and important entities by NIS 2 is observable from the instruments cited. That the incident commander role, with a written handover, a living record and unity of command, is established practice is observable from the practitioner documentation and from NIMS. That supervisors will ask for delegation profiles and decision logs as evidence of who could act is expected, because the requirements on roles, testing and records are in force and agent-assisted operations raise the question of what an agent was allowed to do. That an AI system will hold incident command without a person's decision is speculation; no source cited here supports it, and the design rules of this book exclude it for decisions with irreversible effects.

Across the degrees of delegation

The table sets the ten decisions against the degrees of delegation. The mode describes how the AI is deployed and whose identity it uses; the level describes who decides each action. Every decision has a named human holder, and the table gives the highest level at which an AI system may contribute and what the contribution is. A contribution at Level 3 Bounded needs a catalogued runbook, a mandate enforced by a policy decision point outside the agent and a stop path outside the system it stops.

Decision	Holder	Highest level for AI	What the AI does
D1 Declare and classify	Incident commander	Level 2 Supervised	Drafts the candidate and files the declaration after approval; never classifies
D2 Take or hand over command	Outgoing and incoming commander	Level 1 Assisted	Drafts the briefing from the record
D3 Stop an agent or hold a pipeline	Any listed holder, no approval	Level 3 Bounded	Mandate circuit breakers stop the agent and page a person; a person decides any restart
D4 Approve an emergency change	Incident commander, never the requester	Level 2 Supervised	Drafts the change; a person declares the emergency and approves
D5 Authorise failover	Incident commander, with concurrence by claim status	Level 1 Assisted	Prepares and checks the target; a person decides and executes
D6 Restore over existing data	Commander and service owner	Level 1 Assisted	Restores into a separate target and reports the comparison; Level 4 never
D7 Break a freeze	Commander and head of SRE	Level 0 Advisory	Reads and flags the conflict; never an agent
D8 Classify for reporting	Designated person	Level 1 Assisted	Drafts the clock sheet and notification text
D9 Communicate externally	Communications lead	Level 1 Assisted	Drafts; a person sends
D10 Declare recovery and close	Incident commander	Level 0 Advisory	Reports probe results; an independent probe and a person confirm

Level 4 Autonomous is never used for an irreversible action on production data, for an action outside an authorised change window or freeze on a critical function, for an action that disables the observation or the stop path itself, or for an action that decides about a named person's access to work.

Nordvik Region and Hansa Mutual

Nordvik Region has no Mode 5 agent and a small team in which the same few people hold most rights. Its decision-rights file DRF-NR-001 (illustrative) makes a duty manager the incident commander from the rota of four, of whom Oskar Berg is one, with the next duty manager as first deputy and the platform lead, Maja Lindqvist, as second. The Tier 1 page target is 15 minutes, so the first deputy is paged at 15 minutes and the second at 30. The stop right for every agent, including NR-OPS-003 under AIDR-0916, is held by the duty manager, the platform lead and the platform engineer on call without approval; the regional director holds it as a backstop for any agent, to be informed afterwards, and the duty manager is the holder reachable out of hours because the director is not on a rota. SamDrift's network operations centre pages the on-call and does not hold the stop. The weakness is that the portal's failover claim has failed (RST-NR-2027-002, 5 hours 20 minutes against 2 hours) and no re-test has run, so the Head of IT and Digitalisation, Henrik Dahl, records a standing acceptance before any incident, with an expiry, and the duty manager may attempt a failover of SVC-NR-002 with the platform lead's concurrence without waking anyone to accept the risk.

decision_rights_file: DRF-NR-001      # illustrative
version: 0.9.0
decision_record: AIDR-0922            # 2028-11-28
owner: Henrik Dahl
incident_commander: {holder: duty-manager, deputies: [next-duty-manager, platform-lead],
                     page_ack_minutes: 15, deputy_paged_after_minutes: [15, 30]}
stop: {holders: [duty-manager, platform-lead, platform-engineer-on-call],
       backstop: regional-director, approval: none, out_of_hours: duty-manager,
       mechanism: revoke-at-token-service, mechanism_runs_on: outside_agent_platform}
change_authority: {standard_classes: none_yet, normal: peer-and-gate, exception_forum: on_demand,
                   emergency_approver: duty-manager, emergency_review_working_days: 5}
break_freeze: [duty-manager, head-of-it-and-digitalisation]
risk_acceptances:
  - id: DRF-NR-001/RA-01
    claim: "SVC-NR-002 failover to SamDrift site"      # RST-NR-2027-002 failed
    accepted_by: Henrik Dahl
    permits: "duty manager may attempt failover with platform lead concurrence"
    compensating_control: "manual fallback for fee payments; re-test before the tax season"
    expires: 2029-03-31              # or at the first passing re-test

Hansa Mutual has the larger team and the agent, and writes its rights into DLG-HM-OPS-02. It names an incident commander with two deputies and a 10-minute response time for the decisions of the incident, inside the 5-minute acknowledgement target of a Tier 1 page. The 12-person rota across Hamburg and the Polish service centre, with the UK entity's late shift, gives each role a holder at every hour, and the night commander, Ewa Kowalczyk, is also the agent operator of HM-OPS-001, which the profile resolves by the rules above. Rollback stays at Level 2 and failover at Level 1 in DLG-HM-OPS-001, and DLG-HM-OPS-02 states who decides when the agent proposes either. DORA Article 5(2)(c) makes the allocation of roles a duty of the management body, and the head of operational resilience reads the profile as the second line. The operations annex (KBV-IT-2024-OPS-01 and -02) governs rota and rest and keeps the decision log's measures at team level with a minimum group of five. The two organisations differ in depth and not in kind: Nordvik has fewer holders and leans on a standing acceptance, and Hansa has more holders and leans on a policy decision point that reads the file.

Summary

This chapter concerned O2 Diagnose, O3 Change and O4 Restore, and the decisions that connect them when a service is failing. A decision right is a requirement with a holder, two deputies, a response time, an evidence standard, a record and a ceiling for AI. DORA Articles 5 and 17, the delegated regulation on ICT risk management, NIS 2 Article 20 and the AI Act's Articles 14 and 26 ask for the same content in other words: clear roles, activation conditions, a trained and empowered overseer and a management body that approves the allocation. Four rules about position keep the holders honest.

The incident commander holds the incident by a written, pre-assigned authority, hands over by a recorded briefing and has deputies who are as qualified. An assistant works at the stages of information and analysis, files what the commander approves, and never classifies or speaks externally. Change authority replaces the weekly board with class approval, peer and gate for normal change, a small forum for exceptions and an emergency right whose approver is never the requester. Failover is decided by the commander with a concurrence that depends on the status of the claim in the register, a restore over existing data needs the service owner as well, and the stop right is held by roles that include one reachable out of hours without approval, through a mechanism outside the platform, drilled within 90 days. Risk is accepted by named people with a compensating control and an expiry, and no prohibition of Chapter 4 is a risk to accept. The delegation profile, the decision-rights file, the decision log and the drill records are what a supervisor reads.

Nordvik Region closes its gaps with a short file and a standing acceptance, and Hansa Mutual with a profile that its policy decision point enforces. Chapter 23 turns to the regulatory instruments as a constraint on the whole loop, and Chapter 25 returns to the people who hold these rights: their rotas, their rest and their protection.

Sources

1. European Parliament and Council of the European Union. Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). Official Journal of the European Union, 12 July 2024. Articles 14(4) and 26(2). (1, European Union, 2024)
2. European Parliament and Council of the European Union. Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). Official Journal of the European Union, 27 December 2022. Articles 5, 11 and 17. (2, European Union, 2022)
3. European Parliament and Council of the European Union. Directive (EU) 2022/2555 on measures for a high common level of cybersecurity across the Union (NIS 2 Directive). Official Journal of the European Union, 27 December 2022. Articles 20 and 23. (3, European Union, 2022)
4. Parasuraman, R. & Manzey, D. H. (2010). Complacency and Bias in Human Use of Automation: An Attentional Integration. Human Factors 52(3), 381-410. (218, Parasuraman & Manzey, 2010)
5. Nordqvist, G. (2026). AI Governance: Governing Artificial Intelligence in European Enterprises and Public Authorities. The Transformed Architecture, Book 2. (296, Nordqvist, 2026)
6. Nordqvist, G. (2026). AI Threat: Are the Dystopias Coming True? Evidence, Risk and Response for European Enterprises and Public Authorities. The Transformed Architecture, Book 5. (299, Nordqvist, 2026)
7. Nordqvist, G. (2026). AI Blue: How Artificial Intelligence Transforms the Blue Team in European Enterprises and Public Authorities. The Transformed Architecture, Book 8. (302, Nordqvist, 2026)
8. Parasuraman, R., Sheridan, T. B. & Wickens, C. D. (2000). A model for types and levels of human interaction with automation. IEEE Transactions on Systems, Man, and Cybernetics, Part A 30(3), 286-297. (223, Parasuraman et al., 2000)
9. Spadaccini, A. (2016). Being On-Call. In Beyer, B. et al. (eds), Site Reliability Engineering. O'Reilly Media. (118, Spadaccini, 2016)
10. Stribblehill, A. (2017). Managing Incidents. In Beyer, B. et al. (eds), Site Reliability Engineering. Google and O'Reilly Media. (132, Stribblehill, 2017)
11. Mace, J., Oertel, J., Thorne, S. & Chakrabarti, A. (2018). Incident Response. Chapter 9 of The Site Reliability Workbook. Google and O'Reilly Media. (133, Mace et al., 2018)
12. Google Cloud. Capabilities: Streamlining change approval. DevOps Research and Assessment programme. (139, Google Cloud, n.d.)
13. U.S. Securities and Exchange Commission (2013). In the Matter of Knight Capital Americas LLC. Release No. 34-70694, 16 October 2013. (80, U.S. Securities and Exchange Commission, 2013)
14. Janardhan, S. (2021). More details about the October 4 outage. Meta Engineering, 5 October 2021. (79, Janardhan, 2021)
15. European Commission. Commission Delegated Regulation (EU) 2024/1774 supplementing Regulation (EU) 2022/2554 with regard to regulatory technical standards specifying ICT risk management tools, methods, processes, and policies. Official Journal of the European Union, 25 June 2024. Articles 17, 23 and 26. (8, European Commission, 2024)
16. PagerDuty, Inc. (2026). Incident Commander. PagerDuty Docs, Incident Response guide. (275, PagerDuty, 2026)
17. Federal Emergency Management Agency (2017). National Incident Management System, third edition, October 2017. (276, Federal Emergency Management Agency & U.S. Department of Homeland Security, 2017)
18. Weill, P. & Ross, J. W. (2004). IT Governance: How Top Performers Manage IT Decision Rights for Superior Results. Harvard Business School Press. (277, Weill & Ross, 2004)
19. European Parliament and Council of the European Union. Directive 2003/88/EC concerning certain aspects of the organisation of working time. Official Journal of the European Union L 299, 18 November 2003. Article 3. (18, European Union, 2003)