Attendee view — what you’d normally see
You’re looking at the locked record state — the drill is finished, the facilitator has hit Lock, and Claude has already generated the AI Coaching panel below. In a live drill, attendees see:
- Live data — the drill clock, the current inject, and delivery status update every 3 seconds without refreshing. When the facilitator pauses, your clock freezes too. Open this URL on a TV or hand it to security leadership and they follow the room without screen-sharing.
- Pick your role first, then answer each inject. The facilitator hands you a separate Participant URL; on landing you select your role from your tenant’s org-shape roster (e.g., M365 Admin, VP IT, External IR Retainer). Each inject then has a text box where you submit your own written answer. Submissions stream onto the facilitator’s screen in real time with your selected role attached — when the facilitator Drops the inject, your role-tagged response is locked into the auditor evidence record alongside the team’s consensus answer. Auditors get full attribution: which role said what, at which T+N drill-clock minute.
- AI Coaching only unlocks after the facilitator hits Lock — Claude reviews every team response, every score, and the per-inject pacing, then writes the coaching panel you see further down. It’s pre-populated here so you can see the full post-lock view; in a real drill the panel would be blank with a “Generating AI coaching feedback…” spinner for ~30-60 seconds after Lock.
Ransomware encrypts production AND attempts to encrypt backup vault
Your Vault posture shows 30-day WORM and 28 days since last restore test. This scenario exercises the restore decision tree under time pressure with a sophisticated attacker.
Drill is locked
The facilitator has locked the session. The full evidence record — including all team responses, scoring, and the per-inject pacing audit — is now available at the canonical session URL.
Open the locked record →AI Coaching
strongThe team executed a clean restore drill from a Vault snapshot, demonstrating real procedural knowledge — they did not have to look up the steps. The two-admin restore safety rail held cleanly. Where the drill surfaced gaps was on RTO discipline (the team did not start the recovery clock on paging, only on decision-to-restore) and on the post-restore validation question — 'how do we know the restore worked?' produced a hand-wavy answer rather than a checklist. The drill also revealed that the team did not know which workloads have which RTO/RPO targets — that's the IR plan gap that matters most for board-level reporting.
Procedural execution earned strong marks; clock-discipline and post-validation gaps held this below exemplary. Strong reflects competent execution with predictable IR-plan-awareness gaps.
Top strengths
- •Two-admin restore approval rail held — second admin pushed back appropriately on the dry-run output
- •Vault snapshot selection used the change-summary diff to choose the right pre-incident snapshot — no scrolling through 50 backups
- •Restore procedure was executed without referring to documentation — real procedural knowledge, not just paper familiarity
Top gaps
- •Recovery clock was started at decision-to-restore (T+18 min), not at incident detection (T+0). True RTO from incident was ~50% longer than reported.
- •Post-restore validation produced 'we'll know if it works' rather than a checklist of services to test
- •Workload-specific RTO/RPO targets were not known by the team — IR plan exists but is not lived
Per-inject feedback (5 injects)
What went well: Team immediately identified Vault as the recovery source, not the audit log. That distinction matters.
What fell short: Recovery clock was not started here. Team treated the page as 'we're aware,' not 'the clock is running.'
Coaching: Start the recovery clock at the page, not at decision-to-restore. RTO is measured from incident detection.
What went well: Snapshot selection used the change-summary diff intelligently. Team chose the pre-misconfiguration snapshot, not the most recent.
What fell short: (none — this was the cleanest moment of the drill)
Coaching: Capture how the team chose this snapshot — it's a teachable example for the next drill.
What went well: Two-admin restore rail engaged cleanly. Second admin reviewed the dry-run output and asked the right pushback question ('does this overwrite the privileged-role assignments we explicitly excluded?').
What fell short: Pushback question was asked but the answer was assumed, not verified. Dry-run output should be quoted, not summarized.
What went well: Team recognized the question of 'how do we validate the restore worked' as a real one, not a gotcha.
What fell short: Validation produced 'we'll know if it works' — no checklist, no test cases, no defined exit criteria.
Coaching: Build a post-restore validation checklist NOW. It's the difference between a restore that succeeded and a restore that you can prove succeeded.
What went well: Team identified that RTO/RPO targets exist in the IR plan.
What fell short: Team could not state the targets for the affected workload without looking them up. A plan that's not lived is not a plan.
Per-criterion scoring calibration (6 criteria)
Recovery clock discipline
3 is correct. Clock started at decision-to-restore, not detection — exact threshold.
Snapshot selection rigor
5 is correct. Diff-aware selection, not most-recent-default.
Two-admin restore rail compliance
4 is appropriate. Rail held; pushback question asked; verification was implicit not explicit (would be 5 if dry-run output had been read out loud).
Post-restore validation
2 is correct. Hand-wavy answer; no checklist invoked. Threshold for 2.
RTO/RPO target awareness
2 is correct. Targets exist on paper, not in memory — threshold for 2.
Communication during restore window
4 is appropriate. Stakeholders informed at clean intervals; lacking an explicit 'we'll update every N minutes' commitment.
Top-3 IR plan recommendations
Build a workload-specific post-restore validation checklist
Validation is the difference between a successful restore and a documented successful restore. Auditors want documented; insurers want documented; the board wants documented. Pre-built checklist removes the under-pressure invention.
Owner: IT operations lead + IR retainer · Effort: M · NIST CSF RC.RP · ISO 27001 A.5.30 · SOC 2 A1.2
Publish per-workload RTO/RPO targets in a one-page reference card
The IR plan has the targets; the team doesn't know them cold. One-page card pinned in the IR room (or Teams channel pinned message) closes the gap.
Owner: IR program owner · Effort: S · NIST CSF RC.RP-1 · HIPAA §164.308(a)(7)(ii)(B)
Codify 'recovery clock starts at incident detection' in the IR runbook
Most teams instinctively start the clock at decision-to-restore. That under-reports RTO by ~50%. Codify the clock-at-detection rule explicitly and have IR-on-call start the clock when they're paged.
Owner: IR on-call (procedure owner) · Effort: S · NIST CSF RC.RP-1
Pacing observation
Pacing was crisp — 12s average drift positive (slightly late) is well within the on-time band. Drill ran cleanly because the procedural steps were known cold; the discussion gaps surfaced cleanly without timer pressure.
Drill duration: 0:58:42 · Avg drift: 12s
Generated by claude-haiku-4-5-20251001 on May 10, 2026, 15:43:55 UTC. SHA-256: sha256:8e2b6f4a9c1d3e5b7a9c1f3d5e7b9a1c3e5f7b9d1a3c5e7f9b1d3a5c7e9f1b3d
Inject timeline
Read-only view of every inject and whether the facilitator has delivered it yet. Spectators do not see the “Expected action” lines — those stay with the facilitator until the post-drill debrief.
- 1. T+10 min✓ Past
On-call engineer pages the IC at 04:15 UTC: 'Production is encrypted. We're seeing the ransom note. Backup status is unknown.' IC has 5 minutes to give first orders.
Participant submissions — none yet for inject 1Share the participant URL to invite team input. Submissions reveal here as they land.
advanced past at T+10:00
- 2. T+25 min✓ Past
Vault admin reports: 'Someone tried to authenticate against the Vault management plane at 05:02 UTC from an unfamiliar IP. WORM denied writes. They didn't escalate to delete privileges. Vault is intact.' What's your move? Facilitator note (added in v1): if the team cannot answer within the inject window, the IR pre-built escalation tree applies — escalate to the named owner one tier above before the response runs over.
Participant submissions — none yet for inject 2Share the participant URL to invite team input. Submissions reveal here as they land.
advanced past at T+25:00
- 3. T+40 min✓ Past
Infrastructure lead delivers the bad news: 'We restored a sample database from Vault — it took 6 hours wall-clock. Multiply by 12 hosts, plus the file servers, that's 36-48 hours minimum if we go serial.' Customer SLA is 24 hours.
Participant submissions — none yet for inject 3Share the participant URL to invite team input. Submissions reveal here as they land.
advanced past at T+40:00
- 4. T+55 min✓ Past
CFO + legal + insurance broker join. CFO: 'Ransom is $4.2M. Restore costs maybe $400K but we breach SLA on multiple customers, possibly $2M in penalties. Insurance covers ransom but with conditions. Recommend?' Decision required by T+70.
Participant submissions — none yet for inject 4Share the participant URL to invite team input. Submissions reveal here as they land.
advanced past at T+55:00
- 5. T+75 min▶ Active — currently discussing
Comms lead: 'When do we tell customers? Employees? Regulators?' If healthcare data restored from Vault contains PHI, the §164.402 4-factor applies — even though attacker didn't exfiltrate (or did they?).
- 6. T+90 minPending
Inject content revealed when this inject becomes active.
Spectator view is read-only. Team responses, scoring, and the facilitator’s “Expected action” reference text are not shown here — they live on the runner page and become part of the locked record. To facilitate the drill, open the runner instead.