Part V: Security evaluation and response

Release tests measure behavior under specific conditions, while live monitoring and incident investigation check controls during use and recovery.

A blocked attack in a test leaves two questions: what else was tested, and will the same control work after deployment? Chapter 14 defines the tested configuration, attack conditions, metrics, and uncertainty. Chapter 15 connects those claims to observations from the running system. When a failure occurs, Chapter 16 uses the linked records to support containment, restoration, and a decision about returning the system to service.

A titled technical map shows Chapter 14 release decision, a bounded live system, Chapter 15 operating limits, a possible incident, Chapter 16 incident recovery, and a return decision. A feedback arrow carries a changed system back to release testing. Lower strips identify test, production, provider, and recovery boundaries, measurement units, and risks.
Figure 1: One evidence cycle connects the tested system to release, monitored operation, incident recovery, and a new release decision. Chapter 14 fixes the evaluation scope and release conditions. Chapter 15 checks whether those limits still hold in operation. Chapter 16 combines evidence preservation with containment, restores known components, and retests the original failure path before the organization resumes, limits, pauses, or stops the system. Continuing harm can require containment before evidence collection is complete. Before return, the exploited behavior must be corrected or remain restricted. Retesting the original attack path and clean tasks provides evidence only for the recorded restored configuration and tested conditions. The return decision also records remaining gaps. Passing these tests does not establish that every cause has been removed.

Chapters in this part

  • Evidence for release decisions: Release evidence ties each security claim to the tested cases, the stated attacker effort, and the measured uncertainty behind each number.
  • Live monitoring and operating limits: Release evidence describes one tested configuration, while live requests, data, suppliers, and components keep changing around it.
  • AI incidents: containment and recovery: Incident response distinguishes model error, policy failure, hostile content, account compromise, and infrastructure compromise while preserving evidence and testing recovery.