Most organisations learn how well they recover on the worst day of the year. Backups are configured, plans approved and objectives agreed, but the first time anyone measures whether a service can actually be restored from those backups, within that objective, by the people and suppliers named in the plan, is during a real incident. Recovery is reactive by default, because rehearsing it is expensive and easy to postpone.
This chapter turns recovery into a proactive, continuously verified capability. It shows how AI makes frequent rehearsal affordable, including for AI artefacts such as models and retrieval stores; how AI predicts recovery times and finds unrecoverable dependencies before an incident does; how recoverability findings feed Govern, Identify and Protect; and how recovery communication is prepared in advance and drafted with AI under human sign-off. It is responsible for two Categories of the Recover Function of NIST CSF 2.0 (19, NIST, 2024). From RC.RP Incident Recovery Plan Execution, whose outcome is that restoration activities ensure the operational availability of affected systems and services, it treats the part decided long before the incident: whether the plan can be executed at all. RC.CO Incident Recovery Communication asks that restoration activities are coordinated with internal and external parties. Chapters 22 and 23 covered executing a plan and restoring AI systems; this chapter makes both verified rather than assumed.
A recovery plan states an intention; recoverability is the measured ability to fulfil it. Almost every organisation can show an auditor a plan and a backup schedule, but far fewer can show the restore time they measured last month. NIST's guide to cybersecurity event recovery makes the same distinction, treating recovery as something planned, tested and continuously improved, with metrics that show whether capability is improving (22, Bartock et al., 2016).
Primary topics explored
- From reactive to proactive recovery
- AI-assisted rehearsal and restore testing
- Recovery findings as input to other Functions
- Recovery communication
- Evidence of recoverability
- Proactive recovery in practice
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 24: Proactive Recovery: Recoverability, Rehearsal and Communication 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.