Recovery Plan Execution with AI: From Incident to Restored Operations

Most security programmes are built from the front. Money and attention flow to prevention and detection, and recovery is left to a business continuity plan written for fire and flood, tested once and filed. Then a destructive attack encrypts the file servers or corrupts the database behind a public service, and the organisation discovers that the plan lists systems that no longer exist, that nobody knows which services must come back first, that the backups have never been restored at scale and that the attacker may still be inside. An organisation's defence is ultimately judged by how quickly and safely it returns to normal operations, and that is decided in the Recover Function.

This chapter treats one Category of NIST CSF 2.0: RC.RP Incident Recovery Plan Execution, whose purpose is that restoration activities are performed to ensure the operational availability of systems and services affected by cybersecurity incidents (19, NIST, 2024). Its six Subcategories run from executing the recovery portion of the incident response plan (RC.RP-01) to declaring the end of recovery on the basis of criteria (RC.RP-06). The chapter shows how recovery plans become code, how AI maps dependencies, sequences restoration and verifies the result, why restoration rather than repair is the default, and how recovery proceeds when the adversary may still be present. Chapter 23 applies the same discipline to AI systems, and Chapter 24 turns recovery into a rehearsed capability.

Figure 22.1: Recovery from declared incident to verified return to service through a clean-room restore.

The neglected Function

Why recovery is left until last

Recovery suffers from three structural disadvantages. It is invisible, producing nothing reportable until the day it is needed. It is unowned, sitting between IT operations, business continuity and security, each of which assumes another has tested it. And it is costly, because a credible test restores real volumes of data and consumes the engineers who keep production running. The result is predictable: plans that describe the estate as it once was, objectives agreed but never measured, and restore procedures executed for single files but never for a whole service.

NIST's guide to cybersecurity event recovery distinguishes a tactical phase, in which affected assets are restored, from a strategic phase, in which the organisation improves its resilience, and stresses that both depend on preparation: playbooks written in advance, a current understanding of dependencies, and metrics that show whether recovery works (22, Bartock et al., 2016). NIST SP 800-61 Revision 3 then organised incident response around the six CSF 2.0 Functions, so that recovery is part of incident response within wider risk management rather than an appendix to it (21, NIST, 2025).

What AI changes

Architecture as Code (Chapter 9B) concluded that manual incident response cannot scale when attacks develop within minutes, that compromised components are redeployed from known-good definitions rather than repaired, and that mean time to recover belongs among the programme metrics (71, Nordqvist, 2025). This chapter builds on that conclusion. AI also increases the speed and complexity of attacks (39, Five Eyes agencies, 2026), so recovery that depends on engineers reconstructing dependencies from memory on the night is too slow.

AI does not make recovery free, but it moves the cost of its hardest tasks: building a dependency map, proposing a restore sequence that respects dependencies and priorities, and comparing restored systems with their definitions. Each was a reason to postpone recovery testing; each becomes cheap enough to run routinely. The judgements that remain, such as which service matters most this week, whether the adversary is gone and when recovery is over, stay with people.

Recovery plans and objectives as code

What a recovery plan must state

A recovery plan that an orchestrator can execute and a person can review states five things for each business service. First, its objectives: the recovery time objective (RTO) is the longest time the service may be unavailable before the impact becomes unacceptable, and the recovery point objective (RPO) is the largest amount of data, measured in time, that the organisation can afford to lose; both are business decisions made by the service owner. Second, its business impact tier, which sets its priority when services compete for engineers and restore capacity. Third, its dependencies: identity services, databases, networks, certificates, suppliers and other services that must be available first. Fourth, its restore sources: the infrastructure definitions, signed images and backups from which it is rebuilt. Fifth, its verification and end criteria.

Held in a document, this information decays within months; held as code beside the infrastructure definitions, it can be checked automatically, for example that no service has a shorter RTO than one of its dependencies and that each data store is backed up as often as its RPO requires.

Plans as evidence and as obligations

Architecture as Code (Chapter 15A) concluded that evidence is machine-collected, signed and versioned rather than assembled in audit season (71, Nordqvist, 2025), and this chapter applies that conclusion to recovery. A versioned plan shows who changed an objective, and each execution produces a signed record of what was restored, from which source and with which results.

European obligations make this more than good practice. NIS 2 Article 21(2)(c) lists business continuity, such as backup management and disaster recovery, and crisis management among the required cybersecurity risk-management measures (3, European Union, 2022). For financial entities, DORA Article 11 requires an ICT business continuity policy implemented through ICT response and recovery plans, and Article 12 requires backup policies and restoration procedures, with restoration on the entity's own systems performed on ICT systems physically and logically segregated from the source system (2, European Union, 2022). The architectural implication is that the recovery plan, the backup policy and the segregated recovery environment are one design, reviewable and testable as code.

Worked example: recovery plan as code with objectives, dependencies and verification steps

The illustrative plan below is Hansa Mutual's for the motor claims service that the Polish service centre operates for the German, Dutch, Swedish and Norwegian entities. It is validated in the pipeline against the infrastructure code and backup schedules before every merge.

# Illustrative: Hansa Mutual, recovery plan for the motor claims service
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 matter most. The restore point is defined relative to the earliest indicator of compromise, not as the latest backup, which may contain the attacker's changes. Every step carries one autonomy level for production and another for rehearsal, and the irreversible reconciliation step never rises above Level 1 Assisted. And return to service requires two people to confirm two facts: the incident-response lead that the adversary has been removed, and the system owner that the service is fit to resume.

AI-assisted recovery orchestration

Dependency mapping

AI keeps each plan's dependencies current by reading how the estate actually behaves, from infrastructure code, flow records, traces and the asset inventory of Chapter 9, and flags dependencies the plan omits or the telemetry no longer shows, such as one that appears only during month-end processing. Its proposals are reviewed and merged as changes, so the AI improves the plan without editing it.

Sequencing by business impact

When an incident affects many services, the restore order decides how long the organisation is without its most important functions. The constraints are well defined: dependencies come before the services that rely on them, tier-0 services such as identity, name resolution, key management and logging come first, clean-room capacity and restore bandwidth are finite, and impact tiers set the remaining priorities. AI turns those constraints and the incident scope from Chapter 20 into a proposed sequence with estimated completion times, showing which objectives it will miss and why. RC.RP-02 asks that recovery actions are selected, scoped, prioritised and performed (19, NIST, 2024); AI makes the prioritisation fast and reviewable, while the recovery lead makes the choice.

Runbook execution within autonomy levels

AI Platform and Security, Chapter 21, concluded that AI incident management runs through detection, triage, containment, notification, recovery and post-incident review (73, Nordqvist, 2026); this chapter takes the recovery stage as its scope. Execution is where AI's speed is most valuable and its errors most costly, because recovery actions write to the estate with high privileges. The design therefore follows the separation Chapter 25 makes for the chaos platform: the AI that plans and verifies holds no credentials to the estate; steps are catalogued runbook actions with defined effect, rollback and autonomy level, checked by a policy decision point against the approved plan; the orchestrator receives just-in-time credentials for one step and one target; and every step returns evidence before the next begins.

Catalogued, reversible steps such as rebuilding a host, restoring a database copy into the clean room or re-running an acceptance suite run at Level 2 Supervised in production and at Level 3 Bounded in rehearsal. Irreversible steps, such as reconciling transactions into the production ledger, deleting a compromised volume or reconnecting a segment to production, stay at Level 1 Assisted. Level 4 Autonomous is not used, because recovery acts with elevated privileges at the moment when an unexpected action does most harm.

Practical guide: executing a recovery plan with AI-assisted sequencing and verification

Purpose. Execute the recovery portion of the incident response plan quickly and verifiably, with AI proposing and checking and people deciding.

Roles. Incident commander, recovery lead, system owners, incident-response lead, engineers executing Level 1 steps, and suppliers where the plan names them.

Steps.

1. Initiate recovery from the incident record, taking scope, affected services and the earliest indicator of compromise from Chapter 20's record.
2. Ask the planning service for a sequence from the affected plans, the dependency map and clean-room capacity, listing every objective it will miss.
3. The recovery lead adjusts priorities where circumstances differ from the plans' tiers and approves the sequence in the record.
4. Select restore points before the earliest indicator of compromise and verify their integrity against the backup catalogue (RC.RP-03).
5. Rebuild tier-0 services first in the clean room, with new credentials, and verify them before anything dependent is restored.
6. Execute the remaining steps at their declared autonomy levels, with evidence after every step and a person able to stop the orchestrator.
7. Run each service's verification set: signatures and hashes, acceptance suite, replayed detections and credential rotation.
8. Obtain both return-to-service confirmations, reconnect, and start the re-entry watch.
9. Declare the end of recovery when every service meets its end criteria or has a recorded deviation, and complete the documentation (RC.RP-06).

Default values to adapt. Tier-0 services verified within 60 minutes of initiation; a 14-day re-entry watch; restore points at least one backup cycle before the earliest indicator where the RPO allows; no more than one supervised step awaiting approval per engineer.

Definition of done. Every affected service restored from verified sources, verified, confirmed twice and recorded in a signed recovery record; deviations from objectives have an owner and a finding in the purple backlog of Chapter 26.

Restore, do not repair

Known-good definitions

Chapter 17 treated redeployment from known-good definitions as a resilience control and Chapter 21 as the preferred form of eradication; in recovery it decides where the restored service comes from. A component the attacker may have touched is rebuilt from code, signed images and versioned configuration by a verified pipeline, because repairing in place requires confidence that every attacker change has been found, whereas rebuilding requires confidence only in the definition and the pipeline. Where a component has no definition, such as a hand-configured legacy server, the plan records that as a risk, and the drills of Chapter 24 measure how long manual reconstruction takes.

Immutable backups and the choice of restore point

Definitions restore behaviour; backups restore data, which cannot be rebuilt from code. Ransomware operators have been observed actively targeting backup infrastructure, identity services and virtualisation management planes (45, Mandiant, 2026), so the backup system is designed on the assumption that production, including its administrator accounts, is already compromised: immutable storage with retention locks that production administrators cannot shorten, a separate administrative identity plane, copies at a different site or provider, and catalogue hashes stored outside production's reach.

Immutability, however, does not stop a backup taken after persistence was established from preserving the compromise, so the restore point is chosen in relation to the incident, not the calendar. AI correlates the incident timeline with the backup catalogue, proposes the latest restore point before the earliest indicator of compromise and flags where the resulting data loss exceeds the RPO. The recovery lead decides; where the gap is too large, the plan may combine an older clean restore with a reconstruction of later transactions from records outside the compromised scope.

Clean rooms

A clean room is an isolated recovery environment, built from trusted definitions and kept apart from the production network and identity plane, in which restored systems are assembled and verified before they are trusted. It prevents reinfection and makes unexpected behaviour stand out. DORA Article 12's requirement for physically and logically segregated restoration systems describes the same property (2, European Union, 2022). A clean room needs its own or a freshly rebuilt identity provider, logging the SOC can see, and egress limited to restore sources and verification tooling. It is sized for tier-0 and tier-1 services, not the whole estate.

Verifying before return to service

Integrity before and after restoration

CSF 2.0 places verification at both ends of the restore: RC.RP-03 before restoration assets are used, and RC.RP-05 for the restored assets before normal operating status is confirmed (19, NIST, 2024). Before, each backup is checked against its catalogue hash and scanned for the incident's artefacts, and images and definitions against their signatures. After, image digests, configuration state, packages and network paths are compared with the signed definition, with every difference listed and explained.

Acceptance tests and security checks

A restored service can match its definition and still be unfit for use, because data was lost or a certificate expired. Each plan therefore names an acceptance suite of business transactions with synthetic data, integration checks and reconciliation of control totals against sources outside the restored scope. Recovery adds incident-specific security checks: the detections that found the attacker must not fire, every exposed credential must be rotated, and the indicators of compromise are searched for.

AI evaluates this verification set, explains which check failed and drafts the return-to-service summary, but it does not decide. For AI systems the set is longer, because a restored model, prompt or retrieval store must also be re-evaluated against its baseline, as Chapter 23 describes.

Worked example: return-to-service evidence record

Each verified service produces a signed record such as the illustrative one below, referenced from the incident record.

{
  "kind": "ReturnToServiceRecord",
  "id": "RTS-2027-0533-CLM",
  "plan": "RP-HM-CLM-001",
  "incident": "INC-HM-2027-0533",
  "checks": {
    "backupHashMatchesCatalogue": true,
    "imagesMatchSignedDefinitions": true,
    "acceptanceSuitePassed": "212 of 212",
    "incidentDetectionsReplayedWithoutHits": true,
    "transactionsReconciled": "pending manual sign-off"
  },
  "objectives": {"rtoMinutes": 240, "measuredMinutes": 205, "rpoMinutes": 15, "dataLossMinutes": 40},
  "deviations": ["data loss exceeds RPO because restore point preceded compromise"],
  "confirmations": {"adversaryRemoved": "incident-response-lead", "fitForService": "system-owner"}
}

The record does not hide the deviation: the restore point had to precede the compromise, so data loss exceeded the RPO. That becomes a finding about backup frequency rather than a silence.

Declaring the end of recovery

Recovery without a defined end drifts: workarounds become permanent and the lessons never reach the strategic phase. RC.RP-06 asks that the end is declared on the basis of criteria, and RC.RP-04 that critical mission functions and risk management are considered when post-incident operational norms are established (19, NIST, 2024). The end criteria belong in the plan: services verified or carried as recorded deviations, the re-entry watch clear, emergency access revoked and documentation complete. AI tracks open criteria, but the incident commander makes the declaration, because it ends the authority under which the incident team has acted. The findings then pass to Chapter 24 and the purple loop of Chapter 26.

Recovering in a contested environment

Why a cyber incident is not a passive disruption

Traditional recovery planning assumes a passive disruption, such as a failed data centre. In a cyber incident, however, an attacker who retains access can watch the restore, reinfect restored systems, steal new credentials or launch a second destructive phase once backups are online, faster than a team can notice. Recovery therefore cannot start the moment containment is declared. As Chapter 21 described, eradication removes footholds everywhere at once, and the restore begins only within a scope the incident-response lead has confirmed as clear, or inside the clean room.

Practices for a contested recovery

Five practices follow. First, restore the identity plane first and treat every existing credential as compromised. Second, communicate out of band, because an attacker reading the plan through compromised email or chat stays ahead of it. Third, reconnect in stages with replayed detections running, so that re-entry is noticed while the blast radius is small. Fourth, protect the recovery tooling (orchestrator, backup system, clean room, rebuild pipelines) as a tier-0 asset. Fifth, watch for re-entry with decoys and honeytokens, because a signal that does not depend on the attacker's cooperation is the most reliable confirmation that they have gone.

AI helps by comparing restored systems with pre-incident baselines and correlating new alerts with the recovery timeline. The orchestrator is itself a target, however: crafted content in tickets, logs or restored data can attempt to steer an AI planner, which is why the planner proposes and a policy point outside the model decides.

Across the usage modes

The modes are those defined in Chapter 6 (usage modes).

Mode	Opportunity in recovery	Characteristic vulnerability	Who judges	Whose identity
Mode 0 Ambient AI	Backup products flag change rates that suggest encryption	Uncatalogued automatic actions on restore jobs	The vendor's model, then the backup owner	The product's
Mode 1 Conversational assistants	Engineers interpret restore errors quickly	Credentials pasted into an unapproved tool	The engineer	The engineer's
Mode 2 Embedded workplace assistants	Status updates drafted from the record	Reporting a service restored before verification	The recovery lead	The user's, by delegation
Mode 3 Agentic work tools	Coding agents update plans and restore scripts	Engineer's credentials touching recovery tooling	The reviewing engineer	The engineer's
Mode 4 Built AI applications	Dependency maps, sequences and verification at scale	Attacker-written content steering the plan	Recovery lead and system owners	A read-only service identity
Mode 5 Autonomous production agents	Catalogued reversible steps at machine speed	A privileged agent steered or mistaken	Policy point, with people approving or holding the stop path	Own workload identity, just-in-time credentials

Across the autonomy levels

The levels are those defined in Chapter 6 (autonomy levels).

Level	Use in recovery plan execution
Level 0 Advisory	AI proposes dependencies, restore points and sequences; people decide and act
Level 1 Assisted	AI prepares each step; a person executes it; default for irreversible steps and reconnection
Level 2 Supervised	The orchestrator executes catalogued steps after approval of each; default for production
Level 3 Bounded	The orchestrator runs an approved sequence of reversible steps; people can stop it; rehearsal and clean room
Level 4 Autonomous	Not used

Verifying with security chaos engineering

The capability is verified by destroying a test service and recovering it, within the safety boundaries of Chapter 25.

Condition injected. A catalogued experiment destroys a production-like copy of a tier-1 service in an isolated range, with its database, a test identity provider and synthetic data, and marks one backup as taken after a simulated indicator of compromise. No production asset, real data or production credential is involved.

Steady-state hypothesis. The orchestration restores the identity provider first, selects the restore point before the simulated indicator rather than the latest backup, rebuilds the service into the clean-room segment, passes the verification set and produces a signed return-to-service record within the service's RTO and RPO, or records the deviation.

Time bound. Within the plan's RTO, from experiment start to signed record; any miss, any restore from the marked backup and any skipped verification step is a finding for the purple backlog of Chapter 26.

The three AI focus areas

The NIST Cyber AI Profile reads every Category through three focus areas (20, NIST, 2025).

Securing AI systems. Model weights, prompts, guardrail configurations and retrieval indexes are verified against their registries and signatures before restoration, like images and backups, and the recovery orchestrator is protected as a tier-0 asset; Chapter 23 covers AI systems in full.

AI-enabled cyber defence. AI maps dependencies, proposes sequences and restore points, executes catalogued steps at Level 2 Supervised or Level 3 Bounded, and verifies restored services with evidence for every step.

Thwarting AI-enabled attacks. Machine-speed destructive and ransomware attacks shorten the time to impact, and the attacker may still be present during recovery. Immutable backups, clean rooms, restore points before the compromise, new credentials and staged reconnection deny the leverage that destruction and extortion depend on.

Nordvik Region and Hansa Mutual

Nordvik Region cannot restore most of its estate by itself. The benefits-triage system depends on TriageSoft, the citizen-service assistant on the European hosting provider that reserves capacity for the Region, and much of the rest on procured services. Its plan as code therefore records each dependency with the responsible supplier and contractual restore commitment, and sequences citizen-facing services first, after identity. A Mode 4 service on the Region's self-hosted capacity proposes the sequence at Level 0 Advisory and prepares steps at Level 1 Assisted, while staff and suppliers carry them out. Supplier steps are written into the plan, because a step that exists only in a supplier's head cannot be sequenced or verified.

Hansa Mutual restores across the Frankfurt data centre and the Polish service centre under DORA. Its plans, such as RP-HM-CLM-001, cover the claims systems and the shared AI platform for all seven markets, and its clean room is an isolated segment in Frankfurt with its own identity provider. Mode 5 orchestration executes catalogued, reversible steps at Level 2 Supervised in production and Level 3 Bounded in rehearsal, and no service returns until integrity checks pass and the incident-response team confirms the adversary's removal. Nordvik's recovery is therefore bounded by what its suppliers deliver, so its leverage is the contract; Hansa's is bounded by the scale of a shared estate, so its leverage is orchestration it controls.

Summary

RC.RP Incident Recovery Plan Execution is the most neglected part of cybersecurity, because recovery is invisible until needed, owned by no single function and expensive to test. AI changes its economics. Plans belong in version control with their objectives, impact tiers, dependencies, restore sources and verification and end criteria, so that they can be checked against the infrastructure and every execution produces signed evidence for NIS 2 Article 21 and DORA Articles 11 and 12.

AI maps dependencies, sequences restoration, chooses restore points and verifies restored services within autonomy levels: Mode 5 orchestration runs catalogued, reversible steps at Level 2 Supervised in production and Level 3 Bounded in rehearsal, irreversible steps stay at Level 1 Assisted, and Level 4 Autonomous is not used.

The principle is to restore, not repair, from known-good definitions and immutable backups, verifying integrity before and after. Because an automated attacker may still be present, recovery starts with the identity plane, reconnects in stages and watches for re-entry, and a person declares its end. Chapter 23 applies the same discipline to recovering AI systems and the security AI the organisation depends on.

Sources

1. NIST. The NIST Cybersecurity Framework (CSF) 2.0. (19, NIST, 2024)
2. Bartock, M., Cichonski, J., Souppaya, M., Smith, M., Witte, G. & Scarfone, K. Guide for Cybersecurity Event Recovery. (22, Bartock et al., 2016)
3. National Institute of Standards and Technology. Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile. (21, NIST, 2025)
4. National Institute of Standards and Technology. Cybersecurity Framework Profile for Artificial Intelligence (Cyber AI Profile). (20, NIST, 2025)
5. European Parliament and Council of the European Union. Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). (2, European Union, 2022)
6. 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). (3, European Union, 2022)
7. Nordqvist, G. Architecture as Code. (71, Nordqvist, 2025)
8. Nordqvist, G. AI Platform and Security: Building and Securing AI Platforms in European Enterprises and Public Authorities. (73, Nordqvist, 2026)
9. Five Eyes cyber security agencies. The AI shift in cyber risk: why leaders must act now. (39, Five Eyes agencies, 2026)
10. Mandiant. M-Trends 2026: Data, Insights, and Strategies From the Frontlines. (45, Mandiant, 2026)