Every control in this part assumes that something can go wrong and that the organisation must then return to a trusted state. Operators run that return, but whether it can be run at all is decided earlier, by architecture: whether systems can be rebuilt from unaltered definitions, whether AI systems can be restored to behaviour shown to be sound, whether people can still operate a fallback, and whether anyone has proved this recently. The architect's share is therefore design, verification and requirements; the operators' share is execution.
The chapter concerns two of the four shifts. Shift 1, from documents to code applies because a recovery plan in a document is a promise, while a recovery definition in version control can be redeployed, tested and diffed. Shift 3, from periodic to continuous, at machine speed applies because a recovery capability tested once a year describes an estate that no longer exists. The chapter builds on the conclusion of Architecture as Code (Chapter 9B) that compromised components are redeployed from known-good definitions rather than repaired (161, Nordqvist, 2025), and on the conclusion of AI Red Team, Chapters 22 to 24, that recoverability becomes a measured and continuously rehearsed property (164, Nordqvist, 2026). Chapter 10 owns how fast the estate acts; this chapter owns what it can return to.
A recovery plan states an intention; recoverability is the measured ability to carry it out. NIST's guide to cybersecurity event recovery treats recovery as something planned before an event, tested and improved with metrics (36, Bartock et al., 2016), and its contingency planning guide sets out the business impact analysis from which recovery objectives are derived (183, Swanson et al., 2010). The CSF 2.0 expresses the same idea as outcomes, such as backups that are created, protected and tested (PR.DS-11) and restoration assets whose integrity is verified before use (RC.RP-03) (29, NIST, 2024); each is met by a design decision and shown by a test.
Primary topics explored
- Recoverability as a property
- Known-good definitions
- Recovering AI systems
- Degraded modes and the fallback that eroded
- Security chaos engineering as verification
- Resilience obligations as design constraints
About The Transformed Security Architect
The Transformed Security Architect is Book 6 of The Transformed Architecture. It describes how the security architect role is transformed when architecture is code, when AI drafts and acts, and when adversaries move at machine speed: the craft, the architect's own AI team, the role in the organisation, the competences and the career, for European enterprises and public authorities.
It builds on the conclusions of Architecture as Code, AI Governance, AI Platform and Security, AI Red Team and AI Threat.
Security architects, CISOs and heads of security architecture, enterprise, solution and AI architects, engineering leads, competence and hiring leads, procurement and programme leaders, and risk, compliance and audit.
Gunnar Nordqvist
Conceived, directed and published the books of The Transformed Architecture.
Continue with the full chapter
Chapter 11: Resilience and Recovery by Design: The Architect's Share of Recoverability in The Transformed Security Architect gives the detailed explanations, practical examples and implementation patterns behind this summary.
This whitepaper belongs to “The Craft” and is one of 31 drawn from the manuscript.