This chapter serves the activity that begins when something has gone wrong and ends when the organisation can show that the same thing will be survived next time: responding to an incident, recovering the service, learning from the event and keeping an honest record of what has and has not been proved to work. The tools come from six of the earlier volumes. They are mostly artefacts (incident, clock, recovery, restore-test and review records), with a smaller number of methods (the restore test, the blameless review, the incident commander's role) and a handful of third-party standards and platforms that the volumes use as frames or comparisons. The chapter groups them in four families: the records that carry an incident from first signal to the reporting clocks, the plans and tests that carry a recovery, the reviews that turn an incident into owned changes, and the registers that say how old the proof of recovery is.
Two scope notes. Detection and investigation belong to Chapter 12, and the verification loop that tests response with red and blue together belongs to Chapter 14; this chapter starts at the declared incident. The legal instruments that create the reporting clocks (the AI Act, DORA, NIS 2 and the GDPR) are not tools; the chapter treats the records that hold the clocks and attributes each deadline to the instrument and article that the originating book names. The deadlines are architectural inputs to a clock sheet, not legal advice, and the originating volumes make that reservation too.
The chapter's question is the one the brief sets: which records carry an incident from detection to review, and how is recovery proved and how old is the proof? The second half of the question matters more than the first. A restore test that passed once is a fact about a system on a day. The resilience register of AI Operations (10, Nordqvist, 2026), Chapter 19, is the tool that turns that fact into a claim with a date and an expiry, and most of the other tools in this chapter feed it or are fed by it.
Primary topics explored
- Incident records and reporting clocks
- Recovery plans and restore tests
- Post-incident review
- Resilience registers
- Across the degrees of delegation
- Nordvik Region and Hansa Mutual
About Tools
Tools is a companion to The Transformed Architecture. It collects the tools that Books 1 to 10 describe in one reference, organised by what the practitioner is doing: artefacts (templates, manifests, records), own tools, third-party tools and standards, and methods. Each entry says what a tool is for, when to use it, what it needs and produces, and where the book that defines it explains the reasoning. The book covers choosing, adopting and retiring tools, architecture and delivery, governing AI, securing and testing, operating, agents and autonomy, and people, organisation and society, for European enterprises and public authorities. It comes with a template library, an inventory, three web tools and the Toolbox Maturity Method.
It builds on the conclusions of Architecture as Code, AI Governance, AI Platform and Security, AI Red Team, AI Threat, The Transformed Security Architect, AI Boss, AI Blue, AI Purple and AI Operations.
Architects and security architects, CIOs and CISOs, platform and operations leads, heads of governance, risk, compliance and third-party risk, AI governance and AI platform teams, red, blue and purple team leads, boards and management bodies, procurement and vendor managers, supervisors and auditors, works councils and unions, data protection officers, and public-sector leaders.
Gunnar Nordqvist
Conceived, directed and published the books of The Transformed Architecture.
Continue with the full chapter
Chapter 13: Response, Recovery and Resilience Tools in Tools gives the detailed explanations, practical examples and implementation patterns behind this summary.
This whitepaper belongs to “Securing and Testing” and is one of 29 drawn from the manuscript.