A fintech must formalize card-data breach response with assigned roles, isolated forensic notebooks, and tracked tasks that auditors can review after each drill. Which response plan and runbook design meets isolation, accountability, and auditability?

The correct design satisfies all three governance pillars at once because Systems Manager Automation provides a versioned, executable plan, OpsCenter OpsItems creates stateful, ownable work items with history and status that auditors can replay after each drill, and isolated SageMaker AI notebooks provide a forensic enclave that prevents contamination of production card data while preserving chain of custody. The peered-notebook design fails on isolation by concept, since VPC peering for rapid copying reintroduces a blast-radius and evidence-tampering path that forensic isolation is meant to eliminate, even though assigned tasks and runbooks look complete. The notification-centric design fails on auditability by concept, since SNS plus CloudWatch Logs gives ephemeral messaging and telemetry rather than lifecycle-tracked tasks with owners, due dates, and resolution records that auditors require for post-drill review. The pooled-claim design fails on accountability by concept, since routing work to a general on-call queue for self-assignment at drill time replaces preassigned response roles with best-effort ownership and weakens proof of who was responsible. As an exam caveat, favor designs that preserve audit trail and segregation over those that optimize for speed or operational convenience when card data is involved, because urgency never waives isolation. As a practical check, validate in a drill that runbooks execute without production network routes, every OpsItem has a named owner and timeline, and an auditor role can read the closed drill record without production access.