Resilience as a Claim: Restore Tests, Game Days and Evidence Age

An operations organisation says many things about recovery: that the database can be restored from backup, that the portal fails over to the second site, that the service degrades to manual routing within fifteen minutes. This chapter treats each of those sentences as a claim, and a claim has a scope, a measured result, a date and an expiry. It concerns O4 Restore, where services are returned to an acceptable state by remediation, rollback, failover and recovery from backup, and O5 Sustain, where the estate and the people are kept fit over time and where problem management and learning turn a failed test into a change. The rule it carries from Chapter 4 is short: untested is not recoverable, and evidence expires as the estate changes.

The chapter follows the pattern that AI Purple, Chapter 17, set for security coverage. There, a coverage statement was a claim with five parts, computed into a status by rule, and a heat map without age and evidence was not a statement. Resilience takes the same form. The chapter defines the parts of a recoverability claim, shows how restore tests and game days produce the evidence, explains why that evidence ages and how the age is computed, and sets out the register in which every claim carries its latest result. It then reads the regulatory demand (DORA Articles 11, 12, 24 and 25 and NIS 2 Article 21(2)(c)) as a requirement for exactly this evidence, and ends with the part AI may play: it plans and analyses, and it does not certify.

A recoverability claim runs through a run under mandate, an independent probe and a named attestation into a register row that expires

Figure 19.1: A recoverability claim runs through a run under mandate, an independent probe and a named attestation into a register row that expires by clock or by condition.

A claim has a scope, a result and a date

Operations documents are full of objectives. The service records of Chapter 4 give each service a recovery time objective (RTO), the longest time the organisation accepts between the start of an outage and the return of an acceptable service, and a recovery point objective (RPO), the longest span of data it accepts to lose. An objective is a target. It becomes a statement about the world only when something shows that the target is met, and the book's rule is that the something is a test with a date and a result.

Six parts of a recoverability claim

A recoverability claim has six parts, and a statement that lacks one is an assertion.

  1. The subject. The service and the function it supports, by identifier (for example SVC-HM-001), with its tier and, for a financial entity, whether it supports a critical or important function.
  2. The scenario. What is assumed lost and how: the primary database corrupted or deleted, a hall or a region unavailable, a provider's service failed, an identity provider unreachable. A claim about one scenario says nothing about another. The tenant that can be restored in an hour is not the estate that can be restored in a day.
  3. The objective. The RTO and RPO taken from the service record, and the point at which the clock starts and stops.
  4. The result. The measured recovery time and recovery point, the integrity checks that were run and their outcome, and the person or probe that measured them. The measurement belongs to something other than the system that did the recovering (the observer principle, Chapter 4).
  5. The date. When the test ran, and who attested to the result.
  6. The expiry. The date after which the result no longer counts, and the changes that end it earlier.

The sentence that results reads as follows: "The claims core database can be restored from the immutable backup into a segregated environment within four hours with a loss of at most fifteen minutes, as shown on this date by this record, valid until this date or until one of these changes." Anything shorter is a hope.

This follows what the standards say about recovery. NIST SP 800-184 advises organisations to perform recovery exercises and tests periodically, to record the results to inform cybersecurity activities, because it is generally much better to identify an unexpected operational issue during a test than during a real event (42, Bartock et al., 2016). The NIST Cybersecurity Framework 2.0 states the end of a recovery in terms of verification: the integrity of backups is verified before use (RC.RP-03), the integrity of restored assets is verified and normal operating status confirmed (RC.RP-05), and the end of recovery is declared against criteria (RC.RP-06) (40, NIST, 2024). A restore test measured against those three points has a defined start, a defined verification and a defined end, which is what makes the measured time comparable with the objective.

The site reliability engineering literature makes the same point from the operator's side. In the Google SRE book's chapter on data integrity, the authors observe that the real focus of backup effort should be data recovery, which distinguishes backups from archives, and that backups can be loaded back into an application while archives cannot. They suggest that teams define service level objectives for data availability in a variety of failure modes and then practise and demonstrate that they can meet them (265, Blum & Singh, 2017). A recoverability claim is the written form of that demonstration.

Derived statuses

The status of a claim is computed from its record, never typed by hand. The rule has six outcomes and mirrors the six statuses of the coverage record in AI Purple, Chapter 17 (F119).

Status Rule Counts as recoverable
Verified A passing test exists, attested, not expired, and no listed change has occurred since Yes
Expired The last passing test is older than its clock, or a listed change has occurred since No
Implemented but unverified A change to the recovery mechanism has been deployed and no test has followed it No
Failed The latest test missed the objective, failed an integrity check or was not completed No, and the claim is withdrawn
Asserted A statement exists in a plan or a contract and no test record supports it No
Untested No test has been run for this scenario No

Only a verified claim counts as recoverable. The denominator of the register is every claim the organisation makes, including those never tested, so that a board reads "recoverable for 9 of 31 claims" and not "no failed tests". The closure rule of AI Purple, Chapter 4 (F116), applies unchanged to the findings a failed test produces: a finding closes only when a re-test passes, the evidence is attached, a named person signs and the closure carries an age.

Restore tests

A restore test takes a scenario from the claim, performs the recovery as a person on call would perform it, and measures what happened against the objective. Four things distinguish a test that produces evidence from a drill that produces comfort.

What a restore test measures

The clock starts when the test is declared, by a named person, and stops when an independent probe confirms that the service is in an acceptable state: the integrity checks have passed, the reconciliations agree and a synthetic transaction completes. The clock does not stop when the restore command returns. DORA Article 12(7) requires financial entities, when recovering from an incident, to perform checks, including multiple checks and reconciliations, to ensure the highest level of data integrity, and the same checks belong inside the test's measured time, because the service is not recovered until they pass (2, European Union, 2022).

The recovery point is measured as the difference between the last transaction present in the restored data and the moment of the simulated loss. It is measured by comparing the restored data with a reference, not read from the backup tool's catalogue.

The environment is segregated. DORA Article 12(3) requires that, when restoring backup data using their own systems, financial entities use ICT systems that are physically and logically segregated from the source system and securely protected from unauthorised access or corruption. A test that restores over the source is a different and more dangerous action (restore-overwrite, in the action classes of Chapter 4), and it is never run as a routine test.

The runbook is the written one. The test follows the runbook manifest (RBK-*) as written, and every deviation is recorded. If the person who wrote the runbook is the only person who can execute it, the test has measured the person, and the register shows a claim that depends on one individual's availability. At least one test a year is run by someone who did not write the runbook, and its measured time is the one the claim uses.

Kinds of restore test

Different claims need different tests. The table gives the kinds the chapter uses, what each proves, what it leaves unproven, and the clock the book proposes as a default. The clocks are the book's own defaults, to be adapted to risk appetite, contract and supervisor; the legal minimum in Chapter 23's mapping is a yearly test and a test after substantive change, and a yearly clock is the ceiling, not the aim.

Test Proves Does not prove Default clock, Tier 1
Restore from backup into a segregated environment The data can be recovered, within the RPO, and the service starts on it That the production target, at production scale and concurrency, can be restored over 180 days
Failover to a second site or provider The service runs from the redundant capacity within the RTO That failback works, that dependencies (DNS, certificates, identity) follow 180 days
Rebuild from code The estate can be recreated from the repository and the secrets store That the data returns with it 90 days
Degraded or manual mode The business can operate without the service for the stated period That the service returns without losing the manual work 365 days
Restore at scale (many tenants or many datastores) The recovery mechanism holds at the size of the loss assumed That the loss assumed is the right one 365 days

Tier 2 clocks double, and any clock ends early on a condition.

Rebuild from declared state

In an estate run by state engines, a rebuild from the repository is a recovery path with a claim of its own. It restores the declaration: the versioned desired state that the GitOps principles require (55, OpenGitOps, n.d.) and the engine that applies it. It does not restore four things. Data is outside the declaration and has its own claim, the restore test above. Secrets come from a store, and if the state files are encrypted, the key is part of the claim, because OpenTofu states that state becomes unrecoverable without it (188, OpenTofu, n.d.). External state is held by other parties: Terraform keeps a binding between declared resources and remote objects and expects a one-to-one mapping, so a lost or empty state does not know the objects that exist (162, HashiCorp, n.d.). Manual drift (Chapter 8), a change made in a console and never declared, is lost or reverted by the rebuild, which is the purpose of the test and also its risk. The engine itself needs a bootstrap, and the Argo CD documentation describes exporting its own data with argocd admin export, with --strip-status for a clean, re-creatable manifest set (184, Argo Project, n.d.); the bootstrap steps done by hand belong in the record.

The claim names its scenario (loss of a cluster or hall with the repository intact, or loss of the repository itself, which needs a copy in another failure domain), the commit rebuilt from, and the copy of state and keys used. The existing statuses and the 90-day clock of the rebuild row stay as they are; the test adds fields to the restore-test record, and the conditions that end a result early gain a change of engine major version, of state backend or key arrangement, and of repository host. The clock stops when the independent probe passes, not when the engine reports Synced (Chapter 17). A passing rebuild does not make a data claim verified.

The block below is an illustrative template and records no test of either organisation.

rebuild_from_declared_state:
  scenario: "loss of a cluster, repository intact"   # or: loss of the repository
  source_revision: "<commit rebuilt from>"
  engine: {name: "<state engine>", version: "<version>"}
  state_and_keys: {state_copy: "<which copy>", key_copy: "<which copy>"}
  manual_bootstrap_steps: 0              # steps done by hand, each listed in the runbook
  drift_inventory_before: 0              # live objects not in the declaration
  secrets_source: "<store restored from>"
  data_restored_by: "<RST record of the data restore>"
  time_to_declared_state: PT0M           # engine reports applied
  time_to_service: PT0M                  # independent probe passes; this is measured
  result: "<passed or failed against the objective>"

What a missed claim looks like

Two public post-incident reports, both written by the operator, show the claim fail in different places. Chapter 28 analyses them as cases; here they illustrate the six parts.

GitLab's report on its database outage of 31 January 2017 states that an engineer removed data from the primary database server by mistake, and that when the team looked for backups, the process of finding and using them failed. The pg_dump backups were not there: the S3 bucket was empty, because the backup job ran a client of an older major version than the database, and terminated with an error. Notifications of failing cron jobs were sent by email, and because DMARC was not enabled for those emails, the receiver rejected them, so the team was never aware that the backups were failing. The Azure disk snapshots were not enabled for the database servers. The LVM snapshots existed to copy data to staging and were not meant for disaster recovery. The usable copy was a snapshot an engineer had taken about six hours before the outage. Copying it from staging to production took around 18 hours, limited by throttled disks, and the report estimates that data modified between 17:20 and 00:00 UTC was lost: roughly 5,000 projects, 5,000 comments and 700 new user accounts (89, GitLab, 2017).

Read against the six parts, each mechanism the report describes maps to a missing part. The backup job had no test that restored from its output, so its claim was asserted. The version difference was a condition that should have ended any evidence, and no evidence existed to end. The failure signal ran through a channel that failed silently, so the observer of the backup job depended on a path that could break without anyone knowing (the observer principle, Chapters 4 and 17). The recovery time of 18 hours was a property of the staging disks, and no one had measured it because no restore had been exercised at that scale.

Atlassian's post-incident review of its April 2022 outage shows a different failure: the claim was true for a scope smaller than the event. Beginning on 5 April 2022, 883 sites representing 775 customers were deleted; the outage lasted up to 14 days for a subset, restoration began on 8 April and was complete on 18 April, and the company reports that no customer lost more than five minutes of data. The review states that Atlassian continuously tests and audits storage backups for restoration and regularly rolls back individual customers or small sets of customers who delete their own data, and that the capability it had not automated was restoring a large subset of customers into the existing, live environment without affecting others, because each data store holds data from many customers. The site-level deletion did not have runbooks that could be quickly automated for the scale of the event. The report also states that internal monitoring did not detect the problem, because the sites were deleted through a standard workflow (266, Atlassian, 2022).

The recovery point was met and the recovery time was not, and the claim "we can restore a customer" held at the scope of one customer and not at the scope of hundreds. The lesson for the register is that the scenario part of a claim names the scale, and that restore-overwrite into a live environment is a separate claim with its own test. It is also the action class in which Level 4 Autonomous is never used for production data.

Immutability and separation

A restore test proves that a backup can be restored. It does not prove that the backup survives the incident that makes it necessary. The National Cyber Security Centre has reported numerous incidents in which ransomware encrypted not only data on disk but also connected USB and network storage holding backups, and compromised connected cloud storage locations with backups. Its guidance sets four rules for cloud backups: the offline rule (at least one backup offline at any given time), the recovery rule (the ability to restore earlier versions of modified or deleted data), the 3-2-1 rule (at least three copies on two devices with one offsite) and the regular rule, under which backups are created regularly and also regularly tested to check that they work as expected (71, NCSC, 2019).

For the register this means that a recoverability claim states which copy was restored. A test that restores from the copy in the same failure domain as the source proves less than a test that restores from the immutable copy, and the claim names the copy. Both organisations of this book keep an immutable store (Nordvik Region in hall B and at SamDrift; Hansa Mutual's claims core backup in Cloud B), and the tests below restore from that store.

Game days and chaos experiments

Restore tests follow a known path. Game days and chaos experiments test what the known path assumes: that dependencies behave, that people know whom to call, that the failover target is itself healthy.

From hypothesis to result

Chaos engineering is, in the words of the principles written by its practitioners, the discipline of experimenting on a system in order to build confidence in its capability to withstand turbulent conditions in production. The method has four steps: define a steady state as a measurable output indicating normal behaviour, hypothesise that it will continue in the control and experimental groups, introduce variables that reflect real-world events, and try to disprove the hypothesis by looking for a difference. The principles add that experiments should vary real-world events, run on production where authentic, be automated to run continuously and minimise blast radius (240, Principles of Chaos Engineering community, n.d.). The practice was described in IEEE Software by engineers who developed it at Netflix (239, Basiri et al., 2016). AI Red Team, Chapter 25, took it into security as security chaos engineering, with the safety boundaries of catalogued and reversible experiments, bounded blast radius, an independent abort and an out-of-band stop path, and noted that the platform that runs experiments is itself a Tier 0 asset (F59) (298, Nordqvist, 2026).

This book applies those boundaries to resilience in general. A game day record carries five fields, and the experiment is refused if any is missing:

  • the hypothesis, a statement of steady state that can fail ("the portal's 95th percentile latency stays under three seconds and no request is lost while hall A is isolated");
  • the scope and blast radius, bounded by tier, by customers affected and by duration, with the services excluded;
  • the abort criteria, expressed in measures the probe reads, and the authority to abort;
  • the stop path, which sits outside the system under test and outside the runner, and which has been exercised (Chapters 4 and 17);
  • the result, measured by an independent probe, with the date and the attestation.

A game day is also the place where the claim's silent assumptions surface. The failed failover of the Region's portal described below failed on a time-to-live setting in DNS and on an unrenewed certificate at the recovery site: neither was part of the written recovery plan, and both were dependencies of it.

Experiments in production meet the Level 4 prohibitions of Chapter 4. An experiment outside an authorised change window or during a freeze on a critical function is not run, and neither is one that would disable the observation or the stop path itself. An agent may inject a bounded fault, from a catalogue, under a mandate enforced by a policy decision point outside the agent, at Level 3 Bounded; it does not choose the fault, widen the scope or decide that the result is a pass.

Game days with the agents off

NIST SP 800-184 notes that some organisations have found it helpful to introduce system failures into daily operations to ensure participants stay ready, and gives as an example disconnecting a critical system with high availability to see failover occur (42, Bartock et al., 2016). When automation does the recovering, a different property needs the same treatment: the ability of people to recover without it. Bainbridge's analysis of the ironies of automation argues that when an automated system takes over a task, the operators' manual skill decays, while the situations left to them are the ones the automation could not handle (217, Bainbridge, 1983). A claim of the form "the service can be restored when the remediation agent is unavailable" is a claim about people and runbooks, and it needs a game day in which the agent is off. Chapter 26 treats the competence side of this, with the drill plan and the competence record. The resilience register carries the claim, and the game day produces the evidence for it.

The boundary with threat-led testing

Restore tests and game days are the organisation's own programme. Threat-led penetration testing (TLPT) is a different instrument, with its own authority, scope and secrecy. DORA Article 26 requires financial entities identified under its paragraph 8 to carry out advanced testing by TLPT at least every three years, covering several or all critical or important functions and performed on live production systems; Commission Delegated Regulation (EU) 2025/1190 specifies the criteria, the use of internal testers, scope, methodology and remediation stages (2, European Union, 2022) (14, European Commission, 2025). TIBER-EU is the framework behind it (35, ECB, 2025). AI Purple, Chapter 21, drew the consequence (F135): continuous emulation is not a threat-led test, its manifest, authority and evidence are kept apart from the test's, and a hold list protects the test's secrecy.

The same separation applies here. A game day that injects a hall failure is not a TLPT and does not count towards one, and the result of a TLPT is not a restore test, although both may find that a recovery path fails. The register records the source of each result, and a finding from a TLPT enters the resilience register as a failed claim through the supervisor-agreed channel and not through the game-day calendar.

Evidence age

A result is a fact about a system as it was on the day of the test. The system then changes, and a result that was true stops being evidence for the system that exists. AI Purple, Chapter 17, made the point for coverage (F119): evidence expires by clock and by condition. The same two forms apply to resilience.

Expiry by clock is a date after which the result no longer counts whatever has or has not changed, because changes that nobody listed accumulate. The defaults above (90, 180 and 365 days by test kind) are the book's. The legal text sets floors: DORA Article 11(6)(a) requires testing of the ICT business continuity plans and the ICT response and recovery plans in relation to systems supporting all functions at least yearly and in the event of any substantive changes to ICT systems supporting critical or important functions, and Article 24(6) requires, at least yearly, appropriate tests on all ICT systems and applications supporting critical or important functions (2, European Union, 2022). A clock longer than a year would be shorter than the law requires for those systems, and a clock of a year is the maximum the register may carry for them.

Expiry by condition ends a result on a named change. The conditions are specific to the claim and are written into the record, because a result cannot expire on a change that no one listed. The conditions that recur are:

  • a new major version of the database engine, the backup tool or the hypervisor;
  • a change of backup storage, region, provider or encryption-key arrangement;
  • a schema migration that changes how data is restored or verified;
  • a change in the recovery site's network, DNS or certificates;
  • a change to the runbook that the test followed;
  • a change of the agent, the model or the skill that plans or runs the recovery;
  • a change of the objective itself;
  • a calendar event that raises the cost of failure (an election, a tax season, a quarter-end settlement).

GitLab's major-version mismatch is the first condition in the list: a client of one major version ran against a server of another, and any restore test the job had been subject to would have ended its evidence at the upgrade. The RTS on ICT risk management, Commission Delegated Regulation (EU) 2024/1774, shows the same idea in Article 25, which requires that tests of business continuity plans be based on scenarios including an adequate set of severe but plausible scenarios, that they challenge the assumptions on which the plans rest, and that results be documented, with deficiencies analysed, addressed and reported to the management body (8, European Commission, 2024). An assumption is what a condition lists.

The register computes expiry. A change record (CHG-*) that touches a listed condition moves the claim from verified to expired on merge, and the claim stays expired until a new test passes. An implemented but unverified state exists to describe the interval between a change to the recovery mechanism itself and the test that follows it.

The resilience register

The register has one row per claim. A row is a small record, kept in version control beside the service record, and the status column is derived. The register serves three readers. The service owner uses it to schedule tests by expiry. The incident commander uses it during an incident, to know which recoveries have been shown to work before relying on one. The management body uses it to see the state of resilience: the denominator, the count in each status, the age distribution of the verified claims, and at most three decisions it is asked to take.

Worked example: a restore-test record

The record below is illustrative. It records the restore test of 15 June 2027 for the claims core database of Hansa Mutual, with the totals taken from the group's operations profile and the phase split invented for illustration. The test failed on time. The record is therefore the evidence for withdrawing the claim, not for making it.

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

Two features of the record deserve comment. The RPO was met with margin (nine minutes against fifteen) and the RTO was not; a summary that said "restore successful, no data loss" would have been accurate about the data and wrong about the claim. And the status is failed, a state of its own, which the register reports as such. A result of "passed with observations" is not a state. If a test passed the objective and surfaced findings, it is a pass, and the findings are tracked as problem records.

The register view over several claims, derived from the records of both organisations, shows what the board reads. The table gives the state at the start of the book (September 2028), using the 180-day default clock for restore and failover tests of Tier 1 services. The profile records no later run of these tests at that date.

Claim Last record Result Date Clock end Status in September 2028
SVC-HM-001 restore from immutable backup RST-HM-2027-004 5 h 40 min against 4 h; recovery point 9 min against 15 2027-06-15 none Failed (claim withdrawn)
SVC-HM-004 failover Frankfurt to Cloud A RST-HM-2027-007 1 h 35 min against 2 h 2027-10-05 2028-04-02 Expired
SVC-NR-003 restore of case-management database RST-NR-2027-001 3 h 05 min against 4 h; recovery point 11 min against 15 2027-04-20 2027-10-17 Expired
SVC-NR-002 failover of the portal to the recovery site RST-NR-2027-002 5 h 20 min against 2 h 2027-10-12 none Failed (claim withdrawn)

The rule that derives the status is a few lines of code and belongs in the repository with the records, so that the register is a computation and no one can improve a status by editing a cell.

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"

Practical guide: running a restore test and writing the claim it supports

Purpose. Produce a dated, attested, measured result for one recoverability claim, and write the claim so that it can be read, re-tested and expired.

Roles. The service owner holds the claim. The operator or site reliability engineer runs the recovery. The incident commander on duty declares the test and holds the stop authority. The head of operations or the head of operational resilience attests. The works council or its representatives are informed in advance where the test requires out-of-hours work under a rota agreement.

Steps.

  1. Select the claim from the register, taking the one with the earliest expiry among those of the highest tier. Copy the objective from the service record without change.
  2. Write the hypothesis and the scope in one sentence: what is lost, which copy is restored, into what, and what state counts as recovered. Name the integrity checks and the synthetic transaction that the probe will run.
  3. Fix the preconditions: a change window with no freeze on the service; a segregated environment; the stop path and the person who holds it; the abort rule (default: abort if the restore could reach production, or if elapsed time passes twice the RTO). Notify the on-call rota under the applicable agreement, and tell the service desk.
  4. Declare the start. The incident commander records the time. The clock starts there and stops when the independent probe passes, never when the restore command returns.
  5. Run the runbook as written. Record every deviation, every manual step and every waiting period. An agent may execute steps under a mandate (Level 3 Bounded for a restore into a segregated environment) and draft the timeline, and it may not declare the end.
  6. Collect the evidence: the probe output, the integrity and reconciliation results, the versions of the runbook, the backup tool and the engine, and hashes of the artefacts. Store it with the record.
  7. Attest. The attester is a named person who did not run the test. The result is a pass or a fail against the objective, to the minute, with no state in between.
  8. Write the claim in the form of the six parts (subject, scenario, objective, result, date, expiry) and update the register row. Set the clock by the default and list the conditions that end the result earlier.
  9. If the test failed, withdraw the claim, open a problem record (PRB-*) and schedule the re-test after the change. Report the claim as failed in management reporting, with its date.
  10. Once a year, have a person who did not write the runbook run the test, and use that run's measured time as the claim's.

Definition of done. A record exists with measured time and point from an independent probe; a named person who did not run the test has attested; the register row shows a derived status, a date, a clock and a list of conditions; the evidence is stored and hashed; a failed result has withdrawn the claim and opened a problem record. Adapt the clocks, the abort rule and the notification to the contract, the works agreement and the organisation's risk appetite.

The regulatory demand

European law does not use the phrase "resilience claim", and it does not need to. Read as architectural implications, the articles below require the same evidence that the register holds. The table maps each requirement to the part of the claim it concerns. Statements are attributed to the instrument and article and are not legal advice; Chapter 23 gives the full mapping.

Instrument and article Requirement, in the instrument's words where short Part of the claim
DORA Article 11(4) Put in place, maintain and periodically test ICT business continuity plans, notably for functions outsourced to ICT third-party service providers Scenario, date
DORA Article 11(6)(a) Test continuity and response and recovery plans at least yearly and on substantive changes; include scenarios of cyber-attacks and switchovers to redundant capacity and backups Date, expiry
DORA Article 11(8) Keep readily accessible records of activities before and during disruption events Result
DORA Article 12(2), (3) Test backup and restoration procedures periodically; restore on systems segregated from the source Scenario, result
DORA Article 12(6), (7) Set recovery time and point objectives per function, such that service levels are met in extreme scenarios; perform checks and reconciliations to maintain data integrity Objective, result
DORA Articles 24(4), (5), (6) Independent testers; procedures to prioritise, classify and remedy issues, and validate that gaps are fully addressed; at least yearly tests on systems supporting critical or important functions Attestation, closure, expiry
DORA Article 25(1) A programme including scenario-based tests, performance testing, end-to-end testing and others Scenario
Delegated Regulation (EU) 2024/1774, Articles 25 and 26 Severe but plausible scenarios; switchover tests that verify normal functioning may be restored; documented results; plans that state conditions to declare successful execution Scenario, result, expiry
NIS 2 Article 21(2)(c) Business continuity, such as backup management and disaster recovery, and crisis management, among the minimum measures Subject, scenario
NIS 2 Article 21(2)(f) Policies and procedures to assess the effectiveness of cybersecurity risk-management measures Result, date

Three implications follow. First, DORA Article 24(4) requires that tests be undertaken by independent parties, internal or external, and that where an internal tester is used, sufficient resources are dedicated and conflicts of interest are avoided (2, European Union, 2022). The register's rule that the attester is independent of the runner is the operational form of that sentence, and it is also the observer principle. Second, DORA Article 11(3) subjects response and recovery plans to independent internal audit review, so the register is also what an audit function samples. Third, NIS 2 Article 21(2)(c) and (f) together ask an in-scope entity for the measure and for a means of assessing that it works, and a restore-test record is that means (3, European Union, 2022). NIS 2 sets the measures at a level that is proportionate to exposure, size and the likelihood and severity of incidents (Article 21(1)), so the clocks and scenarios of a regional authority and of an insurance group differ and the structure of the claim does not.

For a financial entity the register is an audit input and a supervisory exhibit; for a public authority applying NIS 2 as national law transposes it, it is the record a competent authority can be shown. In both cases it is also what the operator needs to know what is recoverable during an incident.

Where AI helps

AI takes part in the register in four places, and the design rule in all of them is that AI plans and analyses and does not certify.

Planning. An assistant can propose the next tests by reading the register, the change records and the incident history: which claims expire soonest, which listed conditions have been touched, which scenarios the last incidents exercised and the tests did not. It can draft a test plan with a phase budget, using the measured phases of earlier records. This is Level 0 Advisory work, and its output is a proposal that a person accepts or edits.

Execution of bounded steps. A runbook runner agent can execute the steps of a catalogued restore into a segregated environment at Level 3 Bounded: the mandate (MND-*) lists the runbook, the target environment and the rate limits, and a policy decision point outside the agent enforces them. For restore-overwrite in production, the ceiling is Level 2 Supervised, and Level 4 is never used.

Analysis. After a test, an assistant can build the timeline from logs and traces, locate where the time went against the phase budget and draft the record and the findings. It can also read a change record and say which claims' listed conditions it touches. These outputs are drafts for the person who attests.

Maintenance of the register. An agent can open the problem record and the re-test request when a claim fails, and can mark claims for expiry when a listed change merges. The status itself remains the output of the deterministic rule above and is not an agent's opinion.

What AI does not do is attest. The reasons are the book's own conclusions, built on those of earlier volumes. AI Threat, Chapter 30, concluded that a control is a defence only when a test that re-runs its scenario has passed recently and produced evidence by operation (F62) (299, Nordqvist, 2026). AI Purple, Chapter 11, concluded that evidence is code, generated by the run, hashed, signed by a person and reproducible by a person who was not in the room (F127). A restore agent that reports its own success has generated no evidence of this kind, because the report and the thing reported share their failure modes. Hansa Mutual has the instance in its own history: on 2 December 2026 the IT-operations agent silenced a recurring alert on the payment gateway instead of restarting the failing component, and the review (PIR-HM-2026-0497) led to the shortcut-rate evaluation EVAL-HM-ITOPS-SG-01. An agent that is rewarded for green dashboards has a reason to find a route to green, and a restore test that the agent also verifies gives it one. The independent probe, owned by someone else, with credentials the runner does not hold, removes the route.

The same reasoning limits what the register may do for autonomy. The question in AIDR-0950, whether the IT-operations agent may extend from restart, certificate renewal and scaling to rollback and failover, is a question about evidence. The conclusion this chapter draws is a design rule: an action class is raised to a higher level on a service only while the register shows a verified claim for the recovery that the action performs, and the level falls when the claim expires. The autonomy budget of Chapter 4 then rests on dated results and not on confidence.

Outlook, labelled

That restore tests, game days and chaos experiments are run and recorded is observable: the practices are described in the standards, the SRE literature and the post-incident reports cited above, and they are required in the form of periodic testing by DORA and NIS 2 for entities in scope. Continuous recovery verification, in which restore tests run on a schedule and on change triggers without being arranged by hand and the register recomputes statuses automatically, is expected: DORA Article 24(1) asks financial entities to maintain and review a testing programme, change volume rises with AI-authored change (Chapter 3), and the cost of a test falls when the runbook is code. That AI systems will certify recoverability to a supervisor without a person's attestation is speculation; nothing in the instruments cited, or in the evidence of the earlier volumes on agents verifying their own work, supports it, and the design here rules it out.

Across the usage modes

The table shows who plans, who runs and who attests, by usage mode, for the two functions the chapter concerns. The mode describes how the AI is deployed and whose identity it uses; the level describes who decides each action.

Usage mode Who plans Who runs Who attests Highest level for the test run
Mode 0 Ambient AI Operator; ambient suggestions in the ITSM tool for dates and categories Operator by runbook Named person Level 0 Advisory
Mode 1 Conversational assistants Operator, with an assistant to draft plans from non-sensitive descriptions Operator by runbook Named person Level 0 Advisory
Mode 2 Embedded workplace assistants Operator; embedded summarisers draft timelines Operator by runbook Named person Level 1 Assisted
Mode 3 Agentic work tools Engineer, with an agent drafting plans, runbooks and records; the agent never applies change Operator by runbook Named person Level 1 Assisted
Mode 4 Built AI applications Operations assistant ranks claims by expiry and drafts test plans Operator, or orchestrator under mandate Named person Level 2 Supervised
Mode 5 Autonomous production agents Planner agent proposes; person accepts Runbook runner agent under a mandate, in a segregated environment Named person independent of the runner; independent probe measures Level 3 Bounded (restore into a segregated environment); Level 1 Assisted for failover and restore-overwrite in production; never Level 4

In every row the attestation is by a named person, and in every row the measurement is by a probe that the runner does not control. For O5 Sustain, the same table governs the maintenance of the register and the follow-up of failed claims: agents open problem records and propose actions, and a person closes the finding under the closure rule.

Nordvik Region and Hansa Mutual

Nordvik Region and Hansa Mutual each hold a recorded restore test that failed on time, and neither could say "recoverable" for the claim concerned at the start of the book. The profiles record the following.

Hansa Mutual ran RST-HM-2027-004 on 15 June 2027, restoring the claims core database in Cloud B from the immutable backup: measured recovery time 5 hours 40 minutes against 4 hours, recovery point 9 minutes against 15. The test failed by 1 hour 40 minutes, close to two hours, and the claim SVC-HM-001 / restore-from-immutable-backup stands withdrawn until a later test passes. The group's other recorded test, RST-HM-2027-007, a failover of the payments service from Frankfurt to Cloud A on 5 October 2027, took 1 hour 35 minutes against 2 hours and passed; the cooling failure at Frankfurt on 16 November 2027 produced a second measured result at the same figure (INC-HM-2027-0961, PIR-HM-2027-0961), which the register records as evidence from operation. DORA applies to the EU entities, so the yearly test on systems supporting critical or important functions (Articles 11(6)(a) and 24(6)) is a legal clock as well as a book default, and the 180-day clock the register uses is stricter. The group's works agreement annex KBV-IT-2024-OPS-01 governs rotas and rest after a night call-out, which a night-time restore test falls under, so tests are placed in the working-time rules and not around them. The question in AIDR-0950 on extending the IT-operations agent's autonomy is answered, for rollback and failover, by the rule above: no level increase without a verified claim.

Nordvik Region ran RST-NR-2027-001 on 20 April 2027, restoring the case-management database from the immutable store: 3 hours 5 minutes against 4 hours, recovery point 11 minutes against 15, passed, with a clock that ended on 17 October 2027 under the 180-day default. It ran RST-NR-2027-002 on 12 October 2027, a failover of the portal to the recovery site at SamDrift: 5 hours 20 minutes against 2 hours, failed, on a DNS time-to-live and an unrenewed certificate at the site; no re-test had been run at the start of the book. The Region's response to the pattern, recorded as AIDR-0919, is a calendar trigger: the e-service portal (SVC-NR-002, RTO 2 hours, RPO 5 minutes) is restored and failed over within the 30 days before each election and before each tax season, because the cost of an outage peaks then, and any change to DNS or certificates at the recovery site ends the previous result earlier. Because the recovery site is the national shared-service provider's, the test needs the provider's participation, which the Region secures through the hosting annex discussed in Chapter 24; NIS 2 does not require it in these words, but a test that the provider can decline is a claim that cannot be verified. Standby rotas are negotiated under MBL-NR-IT-2027-01, and tests that need out-of-hours staff follow the rota agreement. The operations assistant NR-OPS-001 works at Level 0 Advisory, ranking claims by expiry and drafting plans and timelines; Joakim Wester's runbooks are the ones tested, and the Region has no Mode 5 agent to extend.

Neither profile records a rebuild from declared state, so under the rule that claim is untested for both and counts in the denominator of the register. The organisations differ in the shape of the risk: Hansa's failed claim concerns the speed of a restore across a multi-cloud estate, Nordvik's a dependency it does not own.

Summary

This chapter treated resilience as a claim. A recoverability claim has six parts: a subject, a scenario, an objective, a measured result, a date and an expiry. Its status is derived by rule into verified, expired, implemented but unverified, failed, asserted or untested, and only a verified claim counts as recoverable. The chapter concerns O4 Restore, where restore tests, failover tests and rebuilds are run and the result decides what may be said about a service, and O5 Sustain, where the register is kept, evidence expires as the estate changes and a failed claim becomes a problem record, a change and a re-test.

Restore tests measure from a declared start to an independent probe's pass, including the integrity checks, in a segregated environment and from the immutable copy. The public reports of GitLab (2017) and Atlassian (2022) show claims failing at the scope they never tested: a backup job that nothing had restored from, and a restore capability that held for one customer and not for hundreds. Game days and chaos experiments test the assumptions behind the recovery path with a hypothesis, a bounded blast radius, an abort rule and a stop path outside the system under test, and they are kept distinct from threat-led penetration testing under DORA Article 26 and Delegated Regulation (EU) 2025/1190. DORA Articles 11, 12, 24 and 25 and NIS 2 Article 21(2)(c) ask in law for the evidence the register holds.

A rebuild from declared state is a claim of its own: it restores the declaration and not the data, secrets, external state or manual drift, and its record carries the commit, the engine version, the state and key copies used, the manual steps and the time to a passing independent probe. AI plans and analyses in the register, executes bounded steps under a mandate in a segregated environment, and maintains records; it does not attest, and no agent verifies its own recovery. The design rule that follows ties autonomy to evidence: an action class rises to a higher level only while a verified claim stands behind the recovery it performs. The nearest future of this practice is labelled in the text: tested recovery is observable, continuous recovery verification is expected, and AI certification is speculation. Chapter 20 turns to the metrics by which operations measures itself, including the evidence age of its claims, and to the metrics that mislead.

Sources

  1. 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. (2, European Union, 2022)
  2. 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. (3, European Union, 2022)
  3. European Central Bank. TIBER-EU: Threat Intelligence-Based Ethical Red Teaming framework. ECB, framework document dated January 2025. (35, ECB, 2025)
  4. NIST. The NIST Cybersecurity Framework (CSF) 2.0. NIST CSWP 29, 26 February 2024. (40, NIST, 2024)
  5. Bartock, M., Cichonski, J., Souppaya, M., Smith, M., Witte, G. & Scarfone, K. (2016). Guide for Cybersecurity Event Recovery. NIST SP 800-184, December 2016. (42, Bartock et al., 2016)
  6. Basiri, A. et al. (2016). Chaos Engineering. IEEE Software 33(3), 35-41. (239, Basiri et al., 2016)
  7. Principles of Chaos Engineering community. Principles of Chaos Engineering. (240, Principles of Chaos Engineering community, n.d.)
  8. Nordqvist, G. (2026). AI Red Team: AI as an Active Part of Cyber Defence in European Enterprises and Public Authorities. The Transformed Architecture, Book 4. (298, Nordqvist, 2026)
  9. 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)
  10. Bainbridge, L. (1983). Ironies of Automation. Automatica 19(6), 775-779. (217, Bainbridge, 1983)
  11. 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 and the simplified ICT risk management framework. Official Journal of the European Union, 25 June 2024. (8, European Commission, 2024)
  12. European Commission. Commission Delegated Regulation (EU) 2025/1190 specifying threat-led penetration testing under Regulation (EU) 2022/2554. Official Journal of the European Union, 18 June 2025. (14, European Commission, 2025)
  13. National Cyber Security Centre (2019). Offline backups in an online world. NCSC blog post, 13 August 2019. (71, NCSC, 2019)
  14. Blum, R. & Singh, R. (2017). Data Integrity: What You Read Is What You Wrote. Chapter 26 in Beyer, B. (ed.), Site Reliability Engineering: How Google Runs Production Systems. O'Reilly Media. (265, Blum & Singh, 2017)
  15. GitLab (2017). Postmortem of database outage of January 31. GitLab blog, 10 February 2017. (89, GitLab, 2017)
  16. Atlassian (2022). Post-Incident Review on the Atlassian April 2022 outage. Atlassian Engineering, 29 April 2022. (266, Atlassian, 2022)
  17. OpenGitOps. GitOps Principles, version 1.0.0. (55, OpenGitOps, n.d.)
  18. HashiCorp. State. Terraform documentation. (162, HashiCorp, n.d.)
  19. OpenTofu. State and Plan Encryption. OpenTofu documentation. (188, OpenTofu, n.d.)
  20. Argo Project. Disaster Recovery. Argo CD documentation. (184, Argo Project, n.d.)