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.
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.
Primary topics explored
- The neglected Function
- Recovery plans and objectives as code
- AI-assisted recovery orchestration
- Restore, do not repair
- Verifying before return to service
- Recovering in a contested environment
About AI Red Team
AI Red Team is Book 4 of The Transformed Architecture. It shows how large European enterprises and public authorities put artificial intelligence to work as an active part of cyber defence: AI-assisted red teaming and adversary emulation, red teaming of AI systems themselves, the AI-assisted security operations centre, detection engineering, threat intelligence, incident response and purple teaming, all under a lawful mandate and with evidence a supervisor can inspect.
It builds on the conclusions of Architecture as Code, AI Governance and AI Platform and Security.
CISOs, SOC leads, red and blue team practitioners, security architects, AI architects and technical decision-makers.
Gunnar Nordqvist
Conceived, directed and published the books of The Transformed Architecture.
Continue with the full chapter
Chapter 22: Recovery Plan Execution with AI: From Incident to Restored Operations in AI Red Team gives the detailed explanations, practical examples and implementation patterns behind this summary.
This whitepaper belongs to “Recover” and is one of 32 drawn from the manuscript.