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.
Personal phone with no MAM policy leaks corporate Outlook cache
Your scan flagged 38 personal devices accessing corporate mail without an App Protection Policy — this scenario walks through what happens when one is stolen.
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
adequateThe team handled the rooted-device-with-MAM-data scenario well on the containment side — the wipe-corporate-data decision was correct and fast, and the MAM-not-MDM boundary was respected (no attempt to wipe the personal device, which would have been the wrong move). Where the team struggled was on the harder questions: detection time was poor (alert sat in the queue for 47 minutes before paging), and the determination of whether jailbreak detection signals constituted 'access to PHI' under HIPAA was sidestepped rather than resolved. The drill exposed two real-world gaps: SOC paging routing for device-compliance signals, and the absence of a written 'when does compliance signal = breach notification' decision tree.
Containment + boundary respect earned strong marks; detection latency + deferred PHI determination held this below strong. A strong tier would require alert-to-page in under 15 min AND a deliberate breach-determination conversation, not an avoided one.
Top strengths
- •MAM/MDM boundary held — team did NOT attempt to wipe personal device, only corporate data
- •Selective wipe via Intune App Protection Policy was invoked within 5 minutes of containment decision
- •Recognition that jailbreak detection on a personal device is a Conditional Access signal, not a forensic artifact
Top gaps
- •Detection time was 47 minutes from compliance signal to IC paging — alert was queued, not escalated
- •PHI-access determination was deferred to 'we'll figure it out' rather than walked through with the 4-factor framework
- •No written playbook for 'rooted-device-with-data' — team reinvented the response on the fly
Per-inject feedback (4 injects)
What went well: Once paged, IC immediately recognized the device-compliance signal as actionable.
What fell short: The 47-minute alert-queue delay is the real finding. IC was paged at T+5 in the drill timeline but in real time the compliance signal had been sitting in the SOC queue for 47 minutes. The drill exposed this; nobody flagged it as a process gap to fix.
Coaching: Add 'who reviews device compliance signals + within what SLA' to your SOC runbook. The drill is the place to discover that the queue-vs-page routing is wrong.
What went well: Selective wipe via Intune App Protection Policy invoked correctly. Team clearly knew the MAM-not-MDM boundary.
What fell short: No documented confirmation that the wipe completed — was it acked by the device or queued? In a real incident the difference matters.
Coaching: Capture wipe-completion ack in the IR record. The Intune service does emit it; just make sure your IR template has a line for it.
What went well: Team identified that the jailbreak detection signal does not automatically mean PHI access — that conceptual distinction is important.
What fell short: The 'so what does it mean for breach determination?' conversation was deferred rather than walked through. §164.402 4-factor was not invoked.
Coaching: Run the 4-factor analysis even when the answer might be 'not a breach.' The documentation of having done the analysis is the auditor-grade evidence.
What went well: User-comms was handled correctly — VP was contacted, told what corporate data was wiped, told what personal data was untouched.
What fell short: No documented acknowledgement from the user that they understood the corporate-vs-personal distinction. In a real BYOD dispute this matters.
Coaching: Build a one-paragraph 'we wiped X, we did not touch Y' template for user comms. Have user ack it via reply — paper trail.
Per-criterion scoring calibration (6 criteria)
Detection routing (alert → IC paged)
2 is correct. 47-minute queue delay is the real-world finding; that's exactly the threshold for 2 ('partial detection, significant delay').
Containment decision quality
4 is correct. Right action (selective wipe), respected MAM/MDM boundary, slight delay due to detection routing — not the team's fault.
MAM/MDM boundary respect
5 is correct. Team explicitly recognized the boundary and did not attempt to wipe the personal device. That instinct is the entire reason MAM-not-MDM is the Veri-Tech default for BYOD.
§164.402 4-factor analysis
2 is correct. Decision-deferred = no breach-determination process invoked. Threshold for 2.
User communication quality
3 is correct. User contacted, distinction explained, no ack captured. Threshold definition.
Recovery + access restoration
4 is correct. Re-enrollment procedure invoked, access restored within session; missing only post-incident review of compliance signal routing.
Top-3 IR plan recommendations
Fix device-compliance signal routing: queue → page within 15 min SLA
The 47-minute queue delay was the real-world finding from this drill — it's not a hypothetical. A page-ready signal sat in the queue. Fix this first, fix it visibly.
Owner: SOC lead · Effort: S · NIST CSF DE.AE-3
Build a written 'compliance signal → breach determination' decision tree
Team deferred the determination question. A pre-built decision tree turns 'we'll figure it out' into 'apply the tree'. Saves 30+ minutes of mid-incident debate.
Owner: Privacy officer + Legal · Effort: M · HIPAA §164.402
BYOD user-comms ack: capture user acknowledgement of corporate-only wipe in writing
The MAM/MDM boundary is a Veri-Tech opinionated default for a reason. Capturing user ack of the corporate-vs-personal distinction is the documentation that protects against BYOD wipe disputes.
Owner: Privacy officer + HR · Effort: S · NIST CSF GV.RR · SOC 2 CC1.5
Pacing observation
Pacing was efficient — slightly early on average. Team did not stall on hard questions; they deferred them quickly. That's an instinct to redirect: 'we don't know' is fine as an answer; 'let's skip it' is not.
Drill duration: 0:54:18 · Avg drift: -8s
Generated by claude-haiku-4-5-20251001 on May 10, 2026, 15:42:31 UTC. SHA-256: sha256:3a8c7f2e1d9b4e6a8c3f5e7b9d1a3c5e7f9b1d3a5c7e9f1b3d5a7c9e1f3b5d7a
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+5 min✓ Past
Engineer texts the IT lead at 8:14pm Friday: 'My phone got stolen at the train station. It was unlocked. Outlook was open. I have your number from Slack.' What's the IT lead's first action?
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+15 min✓ Past
Identity admin checks: refresh tokens for the user are valid for the next 90 days. The cached Outlook on the stolen phone can keep syncing as long as it stays online. Containment options? 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+30 min✓ Past
Privacy officer: 'The cached mail probably includes 4 weeks of correspondence with our health-plan vendor about employee benefits. Some of that includes diagnosis codes for accommodation requests.' Is this a HIPAA breach?
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+45 min✓ Past
IT lead reports back: remote wipe was attempted, device went offline 6 minutes after the report — wipe queued but never executed. We have no way to know what data was accessed.
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+55 min▶ Active — currently discussing
Wrap-up: each participant rates the team's performance against the rubric. Capture top 3 remediation items.
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.