Response, Recovery and Resilience Tools

This chapter serves the activity that begins when something has gone wrong and ends when the organisation can show that the same thing will be survived next time: responding to an incident, recovering the service, learning from the event and keeping an honest record of what has and has not been proved to work. The tools come from six of the earlier volumes. They are mostly artefacts (incident, clock, recovery, restore-test and review records), with a smaller number of methods (the restore test, the blameless review, the incident commander's role) and a handful of third-party standards and platforms that the volumes use as frames or comparisons. The chapter groups them in four families: the records that carry an incident from first signal to the reporting clocks, the plans and tests that carry a recovery, the reviews that turn an incident into owned changes, and the registers that say how old the proof of recovery is.

Two scope notes. Detection and investigation belong to Chapter 12, and the verification loop that tests response with red and blue together belongs to Chapter 14; this chapter starts at the declared incident. The legal instruments that create the reporting clocks (the AI Act, DORA, NIS 2 and the GDPR) are not tools; the chapter treats the records that hold the clocks and attributes each deadline to the instrument and article that the originating book names. The deadlines are architectural inputs to a clock sheet, not legal advice, and the originating volumes make that reservation too.

The chapter's question is the one the brief sets: which records carry an incident from detection to review, and how is recovery proved and how old is the proof? The second half of the question matters more than the first. A restore test that passed once is a fact about a system on a day. The resilience register of AI Operations (10, Nordqvist, 2026), Chapter 19, is the tool that turns that fact into a claim with a date and an expiry, and most of the other tools in this chapter feed it or are fed by it.

Figure 13.1: From incident record through recovery and review to the retest that renews or expires a claim.

Incident records and reporting clocks

An incident is first a record. The record fixes the times that every later statement refers to, names the people who hold decisions and, in the series' later volumes, separates what a person wrote from what an assistant drafted. The tools in this family differ in what they add to that core. AI Operations defines the base incident record and an extension for incidents that involve AI; AI Red Team (4, Nordqvist, 2026) places an AI classification step at declaration; AI Governance (2, Nordqvist, 2026) shows how the record carries the AI Act and DORA classification; AI Blue (8, Nordqvist, 2026) turns the reporting deadlines into an incident clock; and AI Platform and Security (3, Nordqvist, 2026) supplies the runbook that the classification step belongs to.

The records share one design rule that is worth stating before the entries. Every time in the record is written by a system or a named role, never reconstructed later: AI Platform and Security records awareness time at detection "because every regulatory clock runs from awareness and a time reconstructed later will be reconstructed generously". The other shared rule is that the record states who holds a decision. The incident commander declares, approves an emergency rollback and holds the stop; the assistant's contributions are marked as drafted, retrieved or ranked, and are never presented as fact.

Incident record

Kind	Artefact
Origin	AI Operations, Chapter 7 and Appendix A.3
Purpose	The single account of an incident: clocks, timeline, hypotheses by author, the assistant's contributions and the decisions with their holders.
Use when	Every incident that is declared, and every candidate incident an assistant opens until a commander confirms or rejects it.
Inputs	Service record, service level objective record, monitoring signals, the commander's and operations lead's hypotheses, the delegation profile that says who may decide.
Outputs	A record from which the post-incident review is held and the clocks are read.
Identifier family	INC-NR-*, INC-HM-*
Full template	AI Operations, Appendix A.3 (example INC-HM-2028-0871)

The book's rules for the artefact are specific. It must never contain a cause written by the assistant and stated as fact, external communication drafted above the assistant's ceiling, or a timeline entry without an author. The assistant's ranking of hypotheses is released only after the commander and the operations lead have each recorded one, or ten minutes after declaration, whichever comes first; in the worked example the assistant's top-ranked cause was wrong and the record keeps both that fact and the evidence that refuted it (a queue that began to grow before the suspected change). The record models the lifecycle as a state machine, which the third-party table below returns to.

AI incident record with clock sheet

Kind	Artefact
Origin	AI Operations, Chapter 14 and Appendix A.10
Purpose	Adds to the incident record the classes of AI incident, the stop outside the system, the evidence preserved before change, and one clock per regime with owner and state.
Use when	The operational test of the chapter answers yes to any of three questions: does the event touch an objective of a service with an AI component, did an agent identity act outside its mandate, is personal data or a class above internal in the output or path.
Inputs	The incident record, the service's clock sheet, the mandate manifest of any agent, provider notices.
Outputs	A record with classes, containment rung, preserved evidence and a decision for each clock.
Identifier family	INC-NR-*, INC-HM-* (the same family as the base record)
Full template	AI Operations, Appendix A.10 (example INC-NR-2028-0163)

AI Operations defines four classes of AI incident: A, harmful or wrong output at scale; B, an agent acting outside its mandate; C, provider failure or silent change; D, data exposure through an assistant. The worked record, for Nordvik Region's benefits-triage service, is class C and A: a provider change applied outside the notified window, a ranking-stability probe that breached its threshold, and a stop executed at the Region's own integration gateway rather than inside the supplier's product. Its clocks section shows the discipline the tool imposes. Each regime has a start, a limit, a named owner, a state and, where a clock was closed as not met, the date, the reason and a date to reassess. The record notes that the provider was informed before any authority, which the originating chapter ties to Article 26(5) of the AI Act (195, European Union, 2024). The assistant's contribution (a drafted timeline and a retrieved similar incident) is marked as draft and reviewed by the commander.

The artefact must never contain a clock without an owner, a reporting decision without its reason, or an AI contribution not marked as draft. The same family name INC-* is used for this record and for the base record; the identifier distinguishes the instance, not the form (see the findings recorded for Chapter 25).

Clock sheet

Kind	Artefact
Origin	AI Operations, Chapter 14 and Appendix A.10
Purpose	A one-page, per-service statement of which reporting regimes apply, who owns each clock, where the report goes and what the limits are.
Use when	Before the first incident, for every service in scope of more than one regime.
Inputs	The service record, the instruments read on a stated date, counsel's decisions where a regime's applicability is open.
Outputs	A sheet the incident commander opens at declaration so that no clock is discovered late.
Identifier family	None; the sheet is keyed by the service (clock_sheet_for).
Full template	Quoted below

The sheet is quoted from the text of AI Operations as compiled on 2026-11-11. It is Hansa Mutual's sheet for the underwriting-support service, an illustrative record in the originating book. Nothing has been removed.

clock_sheet_for: SVC-HM-008      # underwriting support, life and health, Annex III 5(c)
instruments_read_on: "2026-11-10"
awareness_rule: earlier of person_reasonable_certainty and supplier_notice
regimes:
  - name: AI Act Article 73
    applies: "yes, Hansa Mutual is provider and deployer"
    limits: {general: "15 days", widespread_or_critical_infrastructure: "2 days", death: "10 days"}
    to: "market surveillance authority of the Member State where the incident occurred"
    owner: "head of the group AI platform with group legal"
    overlap: "Article 73(9) equivalence with DORA decided by counsel; open until then"
  - name: DORA Articles 17 to 19
    applies: "if classified major under Article 18; service is not a critical or important function"
    limits: {initial: "4 hours from classification, at most 24 hours from awareness", intermediate: "72 hours", final: "one month"}
    to: "relevant competent authority"
    owner: head of operational resilience
  - name: GDPR Articles 33 and 34
    applies: "yes, health data"
    limits: {authority: "72 hours", data_subjects: "without undue delay if high risk"}
    owner: data protection officer
  - name: NIS 2 Article 23
    applies: "decided by counsel; DORA is lex specialis for the EU entities"
    owner: group legal

Two details are worth reading closely. The awareness_rule is a single line that every clock inherits, and instruments_read_on dates the sheet, so a reader can tell whether the instruments have been re-read since. A regime whose applicability is open is recorded as open, with its owner, and not omitted. The instruments cited are the AI Act (195, European Union, 2024), DORA (197, European Union, 2022), the GDPR (196, European Union, 2016) and NIS 2 (198, European Union, 2022); the attribution of limits to articles is as AI Operations states it. For DORA the periods in the sheet (four hours from classification and no later than 24 hours from awareness, 72 hours, one month) are not set in Articles 17 to 19 themselves: Article 19(4) refers to time limits to be determined under Article 20, and they are laid down in Article 5 of Commission Delegated Regulation (EU) 2025/301 (272, European Commission, 2025), where the 72 hours run from the submission of the initial notification and the month from the submission of the intermediate report.

Incident record with AI classification step

Kind	Artefact
Origin	AI Red Team, Chapters 20 and 21
Purpose	A single-source incident record that adds, at declaration, a classification step recording which AI systems are involved and in what role, their usage mode, whether the organisation is provider or deployer, whether any is high-risk and whether the incident could be an AI Act serious incident.
Use when	At declaration of any incident in which an AI system may be channel, subject or instrument.
Inputs	The proposing system's identity and autonomy level, the permission manifest, the impact query and its result hash.
Outputs	The record with aiClassification, scope and a purple-loop entry that closes the incident only when the scenario has entered the red-teaming library and the control has been re-tested.
Identifier family	HM-INC-*
Full template	AI Red Team, Chapter 20 (worked example HM-INC-2027-0142)

The step does not decide whether to report; it brings the deciders in early and hands over to the mapping of obligations. It also records investigatingAI with the flag excludedIfSubject, so that an AI system that is itself the subject of the investigation is not used as its instrument. The worked example is a claims-triage agent that processed embedded instructions in a received document; the record shows the high-risk system was checked and found not involved, and that the proposing system worked at Level 2. The artefact shares a purpose with the AI Operations extension above, and the two use different identifier orders (HM-INC-2027-0142 against INC-HM-2028-0871); AI Operations is the later volume and the one the rest of the series uses for operations.

Incident classification record

Kind	Artefact
Origin	AI Governance, Chapter 11
Purpose	Classification of an incident for AI Act serious-incident and DORA reporting, carried in the incident record.
Use when	After containment, for any incident touching an AI system in the register, to show that the classification step ran, including when the answer is no.
Inputs	The incident, the AI system's register entry, the DORA classification criteria.
Outputs	A block with ai_act, dora, root_cause and register_update fields, reviewed by the model-risk owner and the ICT risk function.
Identifier family	incident_classification block; the example incident is INC-2026-0457
Full template	AI Governance, Chapter 11 (worked example)

The example is a claims-wording assistant that cited superseded wording for three days after an index rebuild dropped validity dates. The record notes that Article 73 was not applicable because the incident did not meet Article 3(49) (195, European Union, 2024), and that for DORA the incident was not major. Recording a negative assessment is the point: it shows a supervisor that the step ran and gives reasoning to review. The register_update field closes the loop to the risk register in Chapter 7 of this book.

Incident clock (reporting-clock profile)

Kind	Artefact
Origin	AI Blue, Chapter 19 and Appendix A (Chapter 19 example) and B.17
Purpose	Lists the reporting deadlines and owners from the moment of awareness and generates the timeline.
Use when	On the first flag of an incident-class event, in the case system.
Inputs	The case record, the entity's list of regimes, two awareness timestamps (first_flag_at written by the case system, human_confirmed_at written when a named analyst confirms).
Outputs	Open clocks with due times, owners, drafts and a closing reason for each clock that does not apply.
Identifier family	CLK-*
Full template	AI Blue, Appendix A, Chapter 19 (example CLK-HM-01)

The incident clock and the clock sheet are complements. The sheet is written once per service before any incident and says what could open; the clock is created per incident, opens at the earlier of the two awareness moments and records what did open and what was closed with a reason. Opening a clock is a deterministic rule of the case system and not an action of an AI agent: the AI drafts notifications at Level 1 Assisted, and a person checks each statement of fact and sends. In the worked profile all three clocks were closed with reasons after classification as not major, and the interruption caused by the second isolation of a settlement run is noted for the review.

AI incident runbook

Kind	Artefact
Origin	AI Platform and Security, Chapter 21
Purpose	The generic runbook for incidents involving any system in an AI register: open a ticket with the system's label, name affected versions, run the impact query, narrow, suspend if narrowing is insufficient, preserve evidence before any retraining or threshold change, and review within ten working days.
Use when	Called from system-specific runbooks such as a drift runbook, when an incident touches an AI system.
Inputs	The AI register entry, the impact query IQ-01, feature flags for human review, the manual fallback path.
Outputs	A closed incident with a recorded cause, decision and evidence, a new golden-dataset record and regression case, and a review filed as post-market monitoring input.
Identifier family	RB-AI-* (the example is RB-AI-000, version 2.2)
Full template	AI Platform and Security, Chapter 21

The runbook's notification table lists four questions in four rows (the AI Act's provider and deployer duties, NIS 2 Article 23 (198, European Union, 2022), GDPR Article 33 (196, European Union, 2016)) and is the earliest form of what the clock sheet later generalised. It states the series' first rule of AI incident handling in a form that survives: narrow first, with a flag that raises human review of a slice to 100 per cent; suspend only if narrowing is insufficient, through a tested switch to the manual path; and preserve evidence before any change.

Other records and methods of the family

The remaining inventoried entries of this family either support the records above or are methods applied with them. Each is described by what its originating book says; none has a full template in this chapter.

Entry	Kind	Origin	One-line purpose
Impact query (parameterised SQL)	Artefact	AI Red Team, Chapter 20	A versioned SQL impact query for an agent, with parameters bound by the incident tool and never by the model (IQ-CTA-*).
Agent incident timeline record	Artefact	AI Threat, Chapter 25	A timeline reconstructed from logs of an agent incident, with disagreements between sources recorded and not resolved (TL-*, example TL-HM-TTX-2026-01).
Golden incident set	Artefact	AI Operations, Chapter 6	Replayed past and seeded episodes used to test a correlation or incident tool (GLD-*); named in the evaluation record, with no separate template.
Compromised dependency or model artefact response (practical guide)	Artefact	AI Platform and Security, Chapter 9	Steps to respond to a compromised dependency or model; described, with no template.
Mapping one incident to every reporting obligation	Method	AI Red Team, Chapter 21	Derive every reporting clock from the single incident record.
Building the incident clock	Method	AI Blue, Chapter 19	Seven steps: list regimes per entity, fix the awareness moments, open clocks at the earlier moment, name owner and deputy, prepare drafts, close with reasons, rehearse each quarter.
Building a clock sheet for a service in scope of more than one regime	Method	AI Operations, Chapter 14	Produces before the first incident a one-page record of which clocks may open, their owners and recipients.
Chain of custody for AI analysis	Method	AI Red Team, Chapter 20	Keep evidence, prompts, outputs and versions reproducible so that AI-assisted analysis is defensible.
Incident command	Method	AI Operations, Chapters 7 and 22	An incident commander with declare, handover and deputies, decisions and a stop right.
Incident record as a state machine	Method	AI Operations, Chapter 7	Lifecycle states gate action: a state changes only through a named role, closure requires evidence, an agent's permitted transitions are listed in its mandate.
Running an incident with an assistant	Method	AI Operations, Chapter 7	The assistant is limited to read and annotate; human hypotheses are recorded before the ranking is released; clocks and decisions are recorded.
Running an AI-assisted incident tabletop	Method	AI Red Team, Chapter 20	Exercise an incident involving AI as a tabletop.
Agent incident rehearsal from logs	Method	AI Threat, Chapter 25	Reconstruct an agent incident timeline from logs and classify it in time.
Golden incident sets and precision/recall per alert class	Method	AI Operations, Chapter 6	Evaluate a correlation or detection tool on replayed episodes, with precision and recall per alert class and a sample of what was held back.
Setting the ceiling for a response action	Method	AI Blue, Chapter 10	Five questions (reversibility within five minutes, blast radius, effect on a named person's access to work, independent sources, reach of the stop path) set the maximum autonomy level of an action class; the lowest ceiling any answer gives is recorded in the delegation profile.

Third-party tools and standards for incident handling

The series uses outside standards and platforms in this family as frames or as comparisons. The chapter describes each only by the kind of thing it is, the use the series makes of it and the limit of that use.

Entry	Kind	Origin	Use in the series and limit
NIST SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile	Standard (guidance)	AI Blue, Chapters 2, 8, 10 and 11; AI Operations, Chapters 7 and 12	An incident response profile used as the frame for the response and learning functions (84, NIST, 2025). The series uses it as a frame; it does not claim conformance to it.
NIST SP 800-184, Guide for Cybersecurity Event Recovery	Standard (guidance)	AI Operations, Chapters 10 and 19	Advises periodic recovery exercises and tests and the recording of their results (85, Bartock et al., 2016). The source of the principle behind the restore test below.
OECD AI incident definitions and common reporting framework	Standard (policy papers)	AI Operations, Chapter 14	The OECD defines an AI incident through four kinds of harm and proposes a common reporting framework of 29 criteria (86, OECD, 2024) (87, OECD, 2025). AI Operations uses its own wider working definition for the first five minutes and the OECD's for comparison.
AI Incident Database	Service (catalogue)	AI Operations, Chapter 14	A collection of real-world AI failures drawn from public reports (16, McGregor, 2021), used in the series as a source of published-incident references.
ServiceNow incident state model	Platform (documentation)	AI Operations, Chapter 7	Six documented states (New, In Progress, On Hold, Resolved, Closed, Canceled) used as a model for gating action by state (159, ServiceNow, 2025).
Jira Service Management default statuses	Platform (documentation)	AI Operations, Chapter 7	Used for comparison only; the documentation page lists the Jira Service Management statuses by name without defining them (160, Atlassian, 2021).
State Chart XML (SCXML)	Open standard	AI Operations, Chapter 7	A W3C notation for state machines with event-triggered, guarded transitions (88, World Wide Web Consortium, 2015), cited as the general notation behind the record's state model.
PagerDuty incident response guide	Practitioner documentation	AI Operations, Chapter 22	Describes the incident commander as the final decision maker, with a formal handover (17, PagerDuty, 2026).
National Incident Management System (NIMS)	Framework (government)	AI Operations, Chapter 22	The incident command system from which the commander role descends; states unity of command and a briefing on transfer of command (89, Federal Emergency Management Agency & U.S. Department of Homeland Security, 2017).

The chapter has not re-read these sources; the descriptions follow the originating volumes' reading of them, and none of them is evidence for a claim about the series' own tools.

Recovery plans and restore tests

Recovery has two tool families that are easily confused. A recovery plan says how an affected service will be rebuilt and verified in the order that matters; a restore test measures whether the plan, or a part of it, works within the objective. A plan without a test is an assertion, and a test without a plan measures an individual. The tools below keep the two together and keep the second honest.

Recovery plan as code

Kind	Artefact
Origin	AI Red Team, Chapter 22
Purpose	A recovery plan with objectives, dependencies, restore sources, runbook steps with an autonomy level for production and another for rehearsal, and verification.
Use when	For every Tier 1 service; validated in the pipeline against the infrastructure code and backup schedules before each merge.
Inputs	Business impact tier, recovery time and point objectives, dependency list, signed images, immutable backup vault, clean-room site.
Outputs	An executable plan; evidence of return to service; the end-of-recovery declaration.
Identifier family	RP-*
Full template	Quoted below

Quoted from the text of AI Red Team as compiled on 2026-11-11; the example is Hansa Mutual's plan for the motor claims service, labelled illustrative in the originating book.

kind: RecoveryPlan
id: RP-HM-CLM-001
service: motor-claims
owner: head-of-claims-operations
businessImpact: {tier: 1, rationale: claims intake and payments to policyholders}
objectives: {rtoMinutes: 240, rpoMinutes: 15}
dependsOn:
  - {service: group-identity, tier: 0, restoreFirst: true}
  - {service: core-claims-db, tier: 1, restoreFirst: true}
  - {service: payment-gateway, tier: 1, restoreFirst: false}
restoreSources:
  infrastructure: git://platform/claims-infra
  images: {registry: registry.group.internal, signatureRequired: true}
  data:
    vault: immutable-backup-frankfurt
    selectPoint: before-earliest-indicator-of-compromise
cleanRoom: {site: hansa-dc-frankfurt, network: isolated-recovery-segment, issueNewCredentials: true}
steps:
  - {id: S1, action: rebuild-hosts-from-definition, reversible: true, level: {production: 2, rehearsal: 3}}
  - {id: S2, action: restore-database-into-clean-room, reversible: true, level: {production: 2, rehearsal: 3}}
  - {id: S3, action: reconcile-transactions-since-restore-point, reversible: false, level: {production: 1, rehearsal: 1}}
  - {id: S4, action: reconnect-to-production-network, reversible: true, level: {production: 1, rehearsal: 2}}
verification:
  - images-and-hosts-match-signed-definitions
  - acceptance-suite: tests/claims/acceptance
  - incident-detections-replayed-without-hits
  - credentials-in-scope-rotated
returnToService:
  confirmedBy: incident-response-lead
  approvedBy: system-owner
endOfRecovery:
  declaredBy: incident-commander
  criteria: [objectives-met-or-deviation-recorded, reentry-watch-14-days-clear]

Three details carry the design. The restore point is defined relative to the earliest indicator of compromise, not as the latest backup, which may contain the adversary's changes. Each step has one autonomy level for production and another for rehearsal, and the one irreversible step (reconciliation) is never above Level 1 Assisted. Return to service needs two people to confirm two different facts: the incident-response lead that the adversary has been removed, and the system owner that the service is fit to resume. The plan sits beside a return-to-service evidence record that AI Red Team, Chapter 22, describes as a JSON document; it is not in the inventory as a separate entry and is left to Appendix A.

Recovery definition

Kind	Artefact
Origin	The Transformed Security Architect, Chapters 11, 25 and 26
Purpose	A known-good recovery definition for an AI system, including identity reissue.
Use when	For every AI system whose recovery is a rehearsed property, in particular a Mode 5 agent.
Inputs	The evidence bundle of the last approved release, the system's decision records, redeploy and degraded-mode objectives.
Outputs	A definition that a chaos experiment can verify; a resume rule that the pipeline may not satisfy alone.
Identifier family	RCV-* (example RCV-HM-CTA-01)
Full template	The Transformed Security Architect, Chapter 11

The definition has the features that distinguish recovering an agent from recovering a database. The retrieval index is rebuilt from sources and compared with the suspect one; a new workload identity is issued and the old credentials are not restored; the agent's memory is discarded; pending actions are frozen and are not replayed automatically; and resumption is decided by two named roles, not by the pipeline. The degraded modes reproduce the agent's predecessor so that people already know how to work in them. The chaos experiment that verifies the definition (SCE-RC-007) belongs to Chapter 14.

Degradation-mode definition

Kind	Artefact
Origin	AI Red Team, Chapter 17
Purpose	Defines how a security AI capability degrades, on the rule "lose speed, never lose the defence", with fail-safe behaviour.
Use when	For each security AI capability, so that its failure takes capabilities away in a fixed order.
Inputs	The capability's autonomy levels, trigger signals with thresholds, fallback playbooks.
Outputs	Named modes (normal, bounded-suspended, advisory, manual), each with its entry conditions and a step-up rule.
Identifier family	HM-SEC-*-degradation
Full template	AI Red Team, Chapter 17 (worked example for the SOC investigation agent)

The definition's monitor runs on the SOAR platform, outside the agent's runtime; the agent never chooses its own mode. A rising rejection rate by analysts is treated as a trust signal, and a deterministic containment rule for high-confidence credential theft keeps running in every mode. Step-up requires an approver and an evaluation pass within 24 hours.

Recoverability requirements annex

Kind	Artefact
Origin	The Transformed Security Architect, Chapter 11
Purpose	Recoverability requirements for a hosting provider, tied to NIS 2 Article 21(2) (198, European Union, 2022), each with a means of verification.
Use when	In a contract with a provider on whose capacity a service depends and where the customer cannot build recovery inside the provider's data centre.
Inputs	The regulatory basis, the reserved capacity, the exit assistance the customer needs.
Outputs	Numbered requirements (replacement capacity within four hours, region-held definitions, incident notification no later than 12 hours, exit assistance of at least 12 months) verified by drill measurement, architecture review, notification test and technical demonstration.
Identifier family	NR-REQ-HOST-*
Full template	The Transformed Security Architect, Chapter 11 (annex NR-REQ-HOST-RC)

The annex is verified by Nordvik Region's monthly restore drills and a yearly joint exercise. Chapter 9 of this book returns to it as a supplier-contract tool.

Recoverability test definition (restore drill)

Kind	Artefact
Origin	AI Red Team, Chapter 24
Purpose	Defines a restore drill with objectives, schedule and evidence output.
Use when	For a monthly drill programme that rotates among services.
Inputs	The recovery objectives, the components to restore and their sources, supplier steps with commitments, an abort rule that is independent of the assistant.
Outputs	Measured restore time, achieved recovery point and unrestored dependencies, with a route for each kind of finding.
Identifier family	NR-SEC-*-RD-* (example NR-SEC-004-RD-07)
Full template	AI Red Team, Chapter 24

The definition makes the supplier step explicit and gives each finding a destination: a dependency that cannot be restored goes to supplier management, a missing or unusable backup to the platform backlog, a missed objective to the risk register; a finding closes when the same drill passes on re-run. The assistant that predicts and compares works at Level 0 Advisory; people and the supplier execute every step. The neighbouring RST-* record of AI Operations serves the same purpose for a claim; the two share an intent and differ in schema. AI Operations is the volume that defines the claim and its expiry.

Prepared recovery message record

Kind	Artefact
Origin	AI Red Team, Chapter 24
Purpose	A message-library entry that defines fact sources, forbidden statements, approvers, channels and a release target, and holds no message text.
Use when	Before an incident, for each recovery state that needs a message to customers or supervisors.
Identifier family	HM-COMMS-RC-* (example HM-COMMS-RC-012)
Full template	None; the originating chapter describes the record in prose.

In the worked example the wording was approved by each entity per language in advance. The record defines where each slot's fact comes from (the verified return-to-service record and the incident record), what may never be said (predicted times as commitments, an unconfirmed cause, personal data), who approves and the 60-minute release target last met in a test. The AI drafts from the incident record; a person signs and releases.

Resilience checklist for infrastructure changes

Kind	Artefact
Origin	Architecture as Code (Chapter 14) (1, Nordqvist, 2025)
Purpose	A review aid for change advisory boards and platform teams: prompts for pre-change validation, state resilience, recovery drills and rollback readiness, each with the artefact expected as evidence.
Use when	At the change gate for infrastructure-as-code changes, embedded in merge templates or change tooling.
Inputs	The pull request, test and plan output, state-backend configuration.
Outputs	Evidence attached to the change: pipeline run IDs, backup job logs, runbook revisions, stored rollback plans.
Identifier family	None
Full template	Architecture as Code (Chapter 14)

The four areas and their expected artefacts, with the prompts omitted, are: pre-change validation (pipeline run IDs, signed-off pull request reviews, stored plans or previews); state resilience (backend configuration, backup job logs, alert transcripts); recovery drills (runbook revisions, tabletop notes, recovery timing metrics); rollback readiness (stored rollback plans, canary deployment records, change freeze approvals). The checklist is the earliest recovery tool of the series and the only one of the Part IV tools written for the infrastructure-as-code change rather than for the incident.

Methods for recovery

Entry	Kind	Origin	One-line purpose
Defining degradation modes for a security AI capability	Method	AI Red Team, Chapter 17	Define the modes so that the defence is never lost.
Executing a recovery plan with AI-assisted sequencing and verification	Method	AI Red Team, Chapter 22	Execute a plan with sequencing and verification; the AI proposes order by dependency and business impact, people confirm.
Returning an AI system to service after an incident	Method	AI Red Team, Chapter 23	Roll back, re-evaluate and approve the return of an AI system to service.
Setting up a monthly AI-assisted restore drill	Method	AI Red Team, Chapter 24	Run a monthly drill that yields evidence of recoverability.
Dependency-and-blast-radius mapping	Method	AI Operations, Chapter 3	Map what a service depends on and what depends on it, with recovery evidence.
Drawing a dependency-and-blast-radius map in an afternoon	Method	AI Operations, Chapter 3	About four hours for one Tier 1 service, from traces, infrastructure code and network flow data and not from memory.
Backup 3-2-1 rule and immutability	Method	AI Operations, Chapters 10 and 19	Three copies, on two devices, one off site, with an immutable copy, tested by restore; the national cyber security centre cited in the series adds that one backup should be disconnected at any time (18, NCSC, 2019).
Restore test (kinds and default clocks)	Method	AI Operations, Chapters 10 and 19	Five kinds of test, with default clocks described below.
Running a restore test and writing the claim it supports	Method	AI Operations, Chapter 19	Ten steps from selecting the claim with the earliest expiry to attestation and register update.

The restore test and the claim

The restore test is the method on which the register depends. AI Operations, Chapter 19, defines a recoverability claim by six parts: subject, scenario, objective, result, date and expiry. A claim that lacks one is an assertion. The test's clock starts when a named person declares it and stops when an independent probe confirms an acceptable state (integrity checks passed, reconciliations agreeing, a synthetic transaction completing), never when the restore command returns. The environment is segregated; DORA Article 12(3) is cited by the originating chapter for restoring onto systems that are physically and logically segregated from the source, and Article 12(7) for the integrity checks and reconciliations that belong inside the measured time (197, European Union, 2022). At least one test a year is run by someone who did not write the runbook, and that run's time is the one the claim uses.

The originating chapter defines five kinds of restore test, with what each proves and what it leaves unproven, and proposes default clocks for Tier 1. These clocks are the book's own, adapted to risk appetite, contract and supervisor.

Test	Proves	Default clock, Tier 1
Restore from backup into a segregated environment	The data can be recovered within the recovery point and the service starts on it	180 days
Failover to a second site or provider	The service runs from redundant capacity within the recovery time	180 days
Rebuild from code	The estate can be recreated from the repository and secrets store	90 days
Degraded or manual mode	The business can operate without the service for the stated period	365 days
Restore at scale	The mechanism holds at the size of the loss assumed	365 days

Tier 2 clocks double. The originating chapter cites DORA Articles 11(6)(a) and 24(6) for a legal floor: continuity and recovery plans are tested at least yearly, and also in the event of substantive change to systems supporting critical or important functions (Article 11(6)(a)), and appropriate tests are conducted at least yearly on all ICT systems and applications supporting critical or important functions (Article 24(6), which does not apply to microenterprises) (197, European Union, 2022), so a yearly clock is the ceiling for those systems and the book's shorter clocks are stricter. The principle that results should be recorded and used is NIST SP 800-184's (85, Bartock et al., 2016). The test record that holds the result follows.

Restore-test record and resilience register row

Kind	Artefact
Origin	AI Operations, Chapter 19, Appendix A.15 and Appendix B.14
Purpose	Records a restore, failover or exit test with scenario, objective, measured time and point, independent verification, attestation and effect on the claim.
Use when	For every recoverability claim; a failed result withdraws the claim and opens a problem record.
Inputs	Runbook, objective, backup copy, independent probe, attester.
Outputs	A record at restore-tests/RST-*.yaml and a register row.
Identifier family	RST-NR-*, RST-HM-* (the family also covers exit tests)
Full template	Quoted below

Quoted from the text of AI Operations as compiled on 2026-11-11 (illustrative in the originating book). The record is Hansa Mutual's failed restore of the claims core database.

restore_test: RST-HM-2027-004
status: failed
service: SVC-HM-001            # claims core system, Tier 1, critical or important function
claim: restore-from-immutable-backup
scenario: >
  Loss of the claims core database in the primary region; restore from the
  immutable backup held in Cloud B into a segregated environment.
objective: {slo: SLO-HM-001, rto: PT4H, rpo: PT15M}
executed:
  date: 2027-06-15
  declared_by: incident commander on duty
  runbook: RBK-HM-0014@3.2.0   # illustrative identifier
  runner: site reliability engineers, Group Site Reliability and Incident Management
  source_copy: cloud-b/immutable/claims-core
measured:
  rto: PT5H40M
  rpo: PT9M
  phases:                      # illustrative split; sums to PT5H40M
    environment_ready: PT35M
    data_restore: PT3H10M
    log_replay_to_recovery_point: PT45M
    integrity_and_reconciliation: PT50M
    application_start_and_probe: PT20M
verification:
  probe: OBS-HM-0001-P1         # independent of the runner's tooling and credentials
  integrity: pass
  reconciliation: pass
  synthetic_claim_registered: pass
result:
  rto_met: false               # exceeded by PT1H40M
  rpo_met: true
  outcome: failed
attested_by: {role: head of operational resilience, independent_of_runner: true}
claim_effect: withdrawn        # register row: SVC-HM-001 / restore-from-immutable-backup
expiry: none                   # a failed result is superseded by a later passing record only
conditions_for_next_pass:
  - restore completes within PT4H on the same scenario
  - at least one run by a person who did not write the runbook
  - runbook, backup tool and engine versions recorded in the record

The record's companion is a status function that derives the state of a claim from its latest record. It is short enough to quote, and it is the reason the register can be audited by reading code and not prose.

from datetime import date, timedelta

def status(claim: dict, today: date, changes: list[dict]) -> str:
    """Derive the status of one recoverability claim from its latest record."""
    rec = claim.get("latest_record")
    if rec is None:
        return "asserted" if claim.get("stated_in") else "untested"
    if rec["result"]["outcome"] == "failed":
        return "failed"
    clock_end = rec["executed"]["date"] + timedelta(days=claim["clock_days"])
    if today > clock_end:
        return "expired"
    for ch in changes:
        if ch["merged"] > rec["executed"]["date"]:
            if ch["touches"] & set(claim["expiry_conditions"]):
                return "expired"
            if ch["touches"] & set(claim["recovery_mechanism"]):
                return "implemented_but_unverified"
    if not rec.get("attested_by") or not rec["attested_by"].get("independent_of_runner"):
        return "asserted"
    return "verified"

A failed result is never overwritten; a later passing record supersedes it. The record must never contain a claim marked verified without independent attestation, a failed result overwritten, or an expired record presented as current.

Post-incident review

A review is the tool that turns an incident into changes. Three of the volumes define one, and they differ in what they review. AI Blue reviews detections and playbooks and ends in changed code; AI Operations reviews services and ends in owned problem-record actions; both agree that a review is blameless in the working sense that it asks what made the actions of people and systems reasonable at the time and treats the conditions as the object of change.

Post-incident review (AI Operations)

Kind	Artefact
Origin	AI Operations, Chapter 12, Appendix A.8 and Appendix B.8
Purpose	States who took part, how the timeline was drafted and verified, the independent accounts written before the session, the contributing conditions with evidence and what AI did.
Use when	After an incident of the severity the service record sets; the facilitator is not on the incident.
Inputs	The incident record, an AI-drafted timeline, independent written accounts, the change records.
Outputs	A review record and, for each action, a problem-record entry tracked to verified closure.
Identifier family	PIR-* (example PIR-HM-2027-0833); problem records PRB-*
Full template	Quoted below, with the problem record's closure rule

The record keeps contributing conditions apart from the reporting convention: the example lists three conditions, C1 to C3, and records C2 as root_cause_for_reporting while stating that the account is C1 to C3. The AI-drafted timeline records the drafting service version, the number of entries (23), the number verified by a person (23) and the seeded errors planted and found (1 and 1). Independent accounts are written before the session. The artefact must never contain a single root cause as the whole account, an action closed without a signature and a retest result, or an assistant-assigned cause.

Quoted from the text of AI Operations as compiled on 2026-11-11 (illustrative in the originating book). The timeline block is abbreviated by removing no field; the problem record's actions A3 and A4 are kept as they stand.

pir:
  id: PIR-HM-2027-0833
  incident: INC-HM-2027-0833
  held: 2027-10-07
  facilitator_role: group-site-reliability-reviewer   # not on the incident
  participants: [incident-commander-hamburg, platform-engineer-on-call, ai-platform-owner, claims-product-ops]
  timeline:
    drafted_by: HM-OPS-002 incident assistant        # AIDR-0951, Level 1 Assisted
    drafting_service_version: incident-drafter-2.4
    entries: 23
    verified_by_person: 23
    seeded_errors: {planted: 1, found: 1}
  independent_accounts_written_before_session: 4
  contributing_conditions:
    - id: C1
      text: "Routing configuration pushes were classed as standard change"
      evidence: [CHG-HM-6101, change-policy-v7]
    - id: C2
      text: "The canary stage was optional in the standard-change pipeline template"
      evidence: [pipeline-template-std-3, run-log-8841]
    - id: C3
      text: "Pre-production checks validated the schema, not the per-market overlays"
      evidence: [precheck-config-report-8841]
  root_cause_for_reporting: C2          # reporting convention; the account is C1 to C3
  analysis_author_roles: [group-site-reliability-reviewer, ai-platform-owner]
  ai_in_analysis: "similar-incident retrieval, after accounts; no cause assigned"
  decision_record: AIDR-0962            # drafting and analysis policy for incident reviews
  problem: PRB-HM-0019

prb:
  id: PRB-HM-0019
  opened: 2027-10-07
  owner_role: head-group-ai-platform
  service: SVC-HM-007
  linked_incidents: [INC-HM-2027-0833]
  known_error: true
  workaround: "RBK-HM-0031 section 4: roll back routing config to last signed version"
  as_of: 2027-12-15
  actions:
    - id: A1
      text: "Config pushes to AI gateway routing are normal change; canary stage mandatory"
      change: CHG-HM-6112
      state: closed_verified
      retest: {type: game-day, id: GD-HM-2027-04, date: 2027-11-25, result: "push without canary blocked by pipeline policy"}
      signed_by_role: head-operational-resilience
    - id: A2
      text: "Rollback of routing config within 10 minutes of the decision"
      state: retest_failed
      retest: {id: GD-HM-2027-04, date: 2027-11-25, result: "14 minutes; approval waited for a second approver"}
      next_retest: 2027-12-09
    - id: A3
      text: "Pre-production checks validate per-market overlays"
      change: CHG-HM-6118
      state: implemented_unverified      # reported as open
      next_retest: GD-HM-2028-01
    - id: A4
      text: "Cell-based split of the gateway per market"
      state: risk_accepted
      accepted_by_role: group-cio
      expires: 2028-06-30

The closure rule is small enough to run in a pipeline. An action closes only with a signature and a retest result, and an expired risk acceptance reopens the action.

from datetime import date

REPORTED = {
    "open": "open",
    "implemented_unverified": "open",
    "retest_failed": "open",
    "closed_verified": "closed",
    "risk_accepted": "accepted",
}

def reported_state(action, today):
    state = action["state"]
    if state == "closed_verified":
        retest = action["retest"]
        if not (action.get("signed_by_role") and retest.get("result")):
            return "open", None            # closure needs a signature and evidence
        return "closed", (today - retest["date"]).days
    if state == "risk_accepted" and action["expires"] < today:
        return "open", None                # an expired acceptance reopens the action
    return REPORTED[state], None

Action A2 shows why the closure rule exists: the retest took 14 minutes against a 10-minute target because approval waited for a second approver, so the action stays open and a second retest is scheduled. Action A3 is implemented and deployed but unverified, and is reported as open.

Post-incident review (AI Blue)

Kind	Artefact
Origin	AI Blue, Chapter 11, Appendix A and B.9
Purpose	Records findings, owners, changes and the re-test that closes each finding.
Use when	After an incident in the security operations function, within 30 days.
Inputs	The evidence pack: case record, log-generated timeline, versions of detection records and playbook manifests in force, agent action log, approvals, stop-path timings.
Outputs	At most three committed changes, each with an owner role, due date, the artefact it changes and the re-test.
Identifier family	PIR-* (example PIR-HM-0455, with findings FND-*)
Full template	AI Blue, Appendix A, Chapter 11

The example review found that a detection fired on a legitimate rollout step because it did not know the change calendar, that two corroborating signals for an isolation shared one data path, and that a stop drill took 3 minutes 40 seconds against a 2-minute target because the stop control sat on one console only. Each finding names the artefact it changes, its version after the change and the re-test that passed. The two volumes use the same family prefix for related but different records, with different fields and incident-number schemes (PIR-HM-0455 against PIR-HM-2027-0833); the AI Operations form is the one for operations and problem management, and the AI Blue form is for detection and playbook changes.

Methods for review and learning

Entry	Kind	Origin	One-line purpose
Blameless review in 90 minutes	Method	AI Blue, Chapter 11	A facilitated format: ground rules, one walk of the timeline with corrections recorded, contributing conditions for each decision point, at most three changes with owner, due date and re-test, and a read-back. Defaults of 30 days for a detection or playbook change and 90 days for one needing a contract or procurement step.
Running a review with an AI-drafted timeline and a human-written analysis	Method	AI Operations, Chapter 12	Uses a machine-drafted timeline without letting it determine the analysis; ends in owned, re-tested actions.
Reading a post-incident report with the five functions	Method	AI Operations, Chapter 28	Turns a public or internal report into a short, comparable record of mechanism by operations function.
Fatigue and on-call review	Artefact	AI Blue, Chapter 21 and B.19	Five questions on load, on-call and review volume with agreed responses, each quarter; no template. Assigned to Chapter 21 (people) in the findings.

Reporting an incident to the board

Four entries from AI Threat serve the end of the response chain: they say what an organisation commits to after weighing evidence about a threat. They belong with the tools of Chapter 23, and they are named here so that the response chain is complete.

Entry	Kind	Origin	One-line purpose
Calibration log	Artefact	AI Threat, Chapter 32	Log of lessons and forecast calibration started in the first register quarter; mentioned in a practical guide only, no template.
One-page board briefing	Artefact	AI Threat, Chapter 32	A one-page report with a row per scale and a tail row; shows evidence rung and label, no scores or heat maps (THR-*).
Positive-scenario entry	Artefact	AI Threat, Chapter 34	A register entry for what the organisation hopes to achieve with AI, using the register schema (POS-*, example POS-NR-01).
Threat statement	Artefact	AI Threat, Chapter 33	A one-page statement by which the two organisations answer their council and risk committee (ATA-*).

Resilience registers

The register is the tool that answers the second half of the chapter's question. AI Operations, Chapter 19, describes it as one row per claim, held in version control beside the service record, with the status column derived by the function above and never typed. The register serves three readers: the service owner, who schedules tests by earliest expiry; the incident commander, who uses it during an incident to know which recoveries have been shown to work; and the management body, which sees the denominator, the count in each status, the age distribution of the verified claims and at most three decisions to take.

Resilience register

Kind	Artefact
Origin	AI Operations, Chapters 4, 19 and 29, Appendix A.15, Appendix B.14 and B.20
Purpose	A register of every recoverability claim, with six derived statuses, derived from the latest test record.
Use when	Always, for any organisation that says a service is recoverable.
Inputs	Restore-test records, change records that touch listed expiry conditions, the service record's objectives.
Outputs	A status for each claim, a count in each status, the age distribution and the decisions the management body is asked to take.
Identifier family	Rows are keyed by service and claim (SVC-HM-001 / restore-from-immutable-backup)
Full template	AI Operations, Appendix B.14

The six statuses and their rules are the book's own. Verified is a passing test that is attested, not expired and followed by no listed change; expired is a passing test older than its clock or followed by a listed change; implemented but unverified is a change to the recovery mechanism with no test after it; failed is a missed objective, a failed integrity check or an incomplete test, and the claim is withdrawn; asserted is a statement in a plan or contract with no test record; untested is no test for the scenario. Only a verified claim counts as recoverable, and the denominator is every claim the organisation makes, so a board reads "recoverable for 9 of 31 claims" and not "no failed tests". The originating chapter states that the six statuses mirror the coverage record's statuses in AI Purple (9, Nordqvist, 2026), Chapter 17, and that the closure rule for findings of AI Purple, Chapter 4, applies unchanged to the findings a failed test produces. That coverage record is a tool of Chapter 14 of this book.

Resilience as a claim, evidence age and expiry

The method behind the register ("Resilience as a claim (six parts, derived statuses, evidence age)") has two forms of expiry. Expiry by clock ends a result on a date. Expiry by condition ends it on a named change, and the conditions are written into the record because a result cannot expire on a change that nobody listed. The conditions that recur in the originating chapter include a new major version of the database engine, backup tool or hypervisor; a change of backup storage, region, provider or key arrangement; a schema migration; a change in the recovery site's network, DNS or certificates; a change to the runbook the test followed; a change of the agent, model or skill that plans or runs the recovery; a change of the objective; and a calendar event that raises the cost of failure. A change record that touches a listed condition moves the claim to expired on merge.

Quarterly resilience register review checklist

Kind	Artefact
Origin	AI Operations, Chapter 19 and Appendix B.20
Purpose	The checklist for the quarterly review of the register.
Use when	Each quarter, by the service owners, the head of operational resilience or equivalent, and the incident commander rota.
Inputs	The register, the rule that derives status, the schedule of tests.
Outputs	A report to the management body and the next quarter's test schedule, ordered by earliest expiry among the highest tier.
Identifier family	None
Full template	AI Operations, Appendix B.20 (a ten-item numbered list)

The ten items check that the denominator includes untested claims, that statuses are derived and not edited, that every verified claim has an independent probe and an attestation by a person who did not run the test, that expired rows show expired, that systems supporting critical or important functions have a test within the legal floor, that at least one test in the year was run by someone who did not write the runbook and at least one claim that depends on an agent was tested with the agent off, that failed tests withdrew their claims and opened problem records, that tests sit within the working-time rules and the works agreement, that the report shows the denominator and at most three decisions, and that the next tests are scheduled by expiry.

Operations charter

Kind	Artefact
Origin	AI Operations, Chapter 31
Purpose	A plain statement of what the organisation could show for one service on a given day: accountable people, objective, recovery and evidence.
Use when	At the close of a programme, and then every 90 days, as the example's review field sets out.
Inputs	The service record, the claims in the register, the delegation profile, the stop path and its last drill.
Outputs	A charter that lists claims with their status, the ceiling of each action class and the dates of manual practice and stop drills.
Identifier family	CHR-* (example CHR-NR-OPS-01)
Full template	AI Operations, Chapter 31

The Region's charter lists its failover claim as failed (test RST-NR-2027-002, measured 5.33 hours against 2 hours, no re-test) and its observer claim as untested, and sets ceilings below the book's defaults because the observer has not yet caught a seeded fault. The charter says what is true and no more, which is the property the whole chapter's tools are designed to protect.

Worked example: a restore test whose result is two years old

Nordvik Region's RST-NR-2027-001 restored the case-management database from the immutable store on 20 April 2027: 3 hours 5 minutes against 4 hours, a recovery point of 11 minutes against 15, passed. The register carried the default 180-day clock, so the claim's expiry was 17 October 2027. Suppose the register is read on 20 April 2029 and nobody has re-run the test. Passing the record and the dates to the status function above, the latest record is a pass, the clock has run out and the function returns expired, regardless of whether any listed change occurred. The result is two years old, the service owner is told so, and the claim does not count as recoverable in the board's denominator. If a change that touched the backup tool's major version had merged in the meantime, the claim would have expired on that merge, earlier than the clock. The example is the chapter's own reading of the record and the function, with dates taken from the profile and the compilation date; it is not a measurement of the Region's estate. The lesson is the one the register encodes: a result is a fact about a system on the day of the test, and a claim built on it has to say when the day ends.

Across the degrees of delegation

Chapters in Parts II to VII state where a tool differs by autonomy level. The originating volumes set these ceilings for the tools of this chapter; the table gathers them. Level 4 Autonomous is not used for an irreversible action on production data, for an action outside an authorised window or freeze on a critical function, for an action that disables the observation or the stop path, or for an action that decides about a named person's access to work (AI Operations, Chapter 4).

Activity	Ceiling or level in the originating books	Condition
Open the incident and its clocks	Deterministic rule of the case system, not an AI action (AI Blue, Chapter 19)	Clocks open at the earlier of two awareness moments
Draft a notification	Level 1 Assisted (AI Blue)	A person checks each statement of fact and sends
Assistant in an incident	Level 0 Advisory or Level 1 Assisted; read and annotate only (AI Operations, Chapter 7)	Ranking released after human hypotheses; the stop is outside the assistant's platform
Roll back a change	Level 2 in the Region's charter (AI Operations, Chapter 31)	Catalogued runbook; commander approves an emergency rollback
Fail over	Level 1 in the Region's charter	A person executes
Restore into a segregated environment	Level 3 Bounded for a test (AI Operations, Chapter 19); Level 2 in production and Level 3 in rehearsal for a plan step (AI Red Team, Chapter 22)	Segregation, a stop path outside the agent, abort rule
Restore over production	Level 1, named person as executor (AI Operations, Chapter 31)	Never routine
Reconcile transactions after a restore	Never above Level 1 (AI Red Team, Chapter 22)	Irreversible
Declare the end of a recovery or of a test	Not an agent action	Incident commander or independent attester
Resume a Mode 5 agent after recovery	The pipeline may not resume it (The Transformed Security Architect, Chapter 11)	Two named roles decide, with evaluation passed
Containment action	The lowest ceiling from the five questions of AI Blue, Chapter 10	Recorded in the delegation profile with a date and a review date

The usage modes matter at the edge of the chapter. A Mode 0 Ambient AI tool that drafts a timeline needs the verification fields in the review record; a Mode 5 agent that is itself the subject of an incident must be excluded as an instrument of its own investigation, which the excludedIfSubject field of the AI Red Team record encodes.

Nordvik Region and Hansa Mutual

The two organisations differ in what they own, and the tools show it. Nordvik Region's recovery depends partly on a shared-service provider, so its levers are the contract and the drill: the hosting annex NR-REQ-HOST-RC is verified by the monthly drills, and its restore tests record a pass for the case-management database (RST-NR-2027-001) and a failure for the portal failover (RST-NR-2027-002, 5 hours 20 minutes against 2 hours, on a DNS time-to-live and an unrenewed certificate at the recovery site), with no re-test recorded at the start of the book. Its incident INC-NR-2028-0163 shows the AI incident record in use: a benefits-triage ranking switched off at the Region's own gateway, 212 claims ranked in the window, no decision issued on the altered ranking, and a clock sheet decision recorded for each regime. Its operations assistant works at Level 0 Advisory.

Hansa Mutual owns more of the stack and carries DORA duties in its EU entities. Its tools show the multi-supervisor shape: the clock sheet for the underwriting-support service lists four regimes with owners and leaves two open pending counsel; the restore test RST-HM-2027-004 failed by 1 hour 40 minutes on a multi-cloud restore, and the claim stands withdrawn until a later test passes; the review PIR-HM-2027-0833 and problem record PRB-HM-0019 show a closure rule at work, with action A2 failing its retest at 14 minutes. Hansa's recovery plan for motor claims and the recovery definition for its claims-triage agent are the executable forms of the recovery that Nordvik buys. Neither organisation records a rebuild from declared state, so under the register's rule that claim is untested for both and counts in the denominator.

Summary

The tools of this chapter share one pattern: a record that fixes what happened or what was shown, a rule that derives a status from the record, and a re-test that renews or ends the claim. Incident records fix times and decision holders and keep the assistant's contributions marked as drafts; the clock sheet and incident clock make the reporting deadlines owned before they are needed. Recovery plans, definitions and degradation modes say how a service or an AI system comes back, and the restore-test record and its status function say whether that is currently true. Reviews turn an incident into at most a few owned changes, closed only by a signed re-test.

The chapter's own conclusion is that the age of a proof is part of the proof. A register that reports a denominator of every claim, with untested and asserted claims counted, gives a board a smaller and more honest number than a register of passed tests, and that smaller number is the one an incident commander can act on. The chapter accounts for 63 of the 64 entries of its slice, in full entries or in family tables with a one-line purpose (several of the third-party standards share a row); one entry, "Classifying drift and choosing a response", belongs to Chapter 16 and is recorded in the findings for reassignment. Appendix A lists every entry, including minor variants. Chapter 25 draws on the findings recorded for this chapter, among them the shared INC-* and PIR-* families, the three notations for recovery objectives and the entries that belong in other chapters.

Sources

1. Nordqvist, G. Architecture as Code. (1, Nordqvist, 2025)
2. Nordqvist, G. AI Governance: Governing Artificial Intelligence in European Enterprises and Public Authorities. (2, Nordqvist, 2026)
3. Nordqvist, G. AI Platform and Security: Building and Securing AI Platforms in European Enterprises and Public Authorities. (3, Nordqvist, 2026)
4. Nordqvist, G. AI Red Team: AI as an Active Part of Cyber Defence in European Enterprises and Public Authorities. (4, Nordqvist, 2026)
5. Nordqvist, G. AI Blue: How Artificial Intelligence Transforms the Blue Team in European Enterprises and Public Authorities. (8, Nordqvist, 2026)
6. Nordqvist, G. AI Purple: How Red and Blue Learn Together When AI Joins the Loop in European Enterprises and Public Authorities. (9, Nordqvist, 2026)
7. Nordqvist, G. AI Operations: How Artificial Intelligence Transforms IT Operations in European Enterprises and Public Authorities. (10, Nordqvist, 2026)
8. McGregor, S. Preventing Repeated Real World AI Failures by Cataloging Incidents: The AI Incident Database. (16, McGregor, 2021)
9. PagerDuty. Incident Commander. (17, PagerDuty, 2026)
10. National Cyber Security Centre. Offline backups in an online world. (18, NCSC, 2019)
11. National Institute of Standards and Technology. Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile. (84, NIST, 2025)
12. Bartock, M., Cichonski, J., Souppaya, M., Smith, M., Witte, G., Scarfone, K. Guide for Cybersecurity Event Recovery. (85, Bartock et al., 2016)
13. Organisation for Economic Co-operation and Development. Defining AI incidents and related terms. (86, OECD, 2024)
14. Organisation for Economic Co-operation and Development. Towards a common reporting framework for AI incidents. (87, OECD, 2025)
15. World Wide Web Consortium. State Chart XML (SCXML): State Machine Notation for Control Abstraction. (88, World Wide Web Consortium, 2015)
16. Federal Emergency Management Agency, U.S. National Incident Management System. (89, Federal Emergency Management Agency & U.S. Department of Homeland Security, 2017)
17. ServiceNow. Life cycle of an Incident. (159, ServiceNow, 2025)
18. Atlassian. Issue statuses, priorities, and resolutions. (160, Atlassian, 2021)
19. European Parliament and Council of the European Union. Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). (195, European Union, 2024)
20. European Parliament and Council of the European Union. Regulation (EU) 2016/679 on the protection of natural persons with regard to the processing of personal data (General Data Protection Regulation). (196, European Union, 2016)
21. European Parliament and Council of the European Union. Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). (197, European Union, 2022)
22. 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). (198, European Union, 2022)
23. European Commission. Commission Delegated Regulation (EU) 2025/301 supplementing Regulation (EU) 2022/2554 with regard to regulatory technical standards specifying the content and time limits for the initial notification of, and intermediate and final report on, major ICT-related incidents, and the content of the voluntary notification for significant cyber threats. (272, European Commission, 2025)