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.
Hand out attendee links — no screen sharing required
At drill kickoff you hand out two URLs so every attendee can follow + participate live from their own device, no Teams call needed:
- 1Spectator URL — read-only timer + current inject + delivery progress, refreshes every 3 seconds. For observers, security leadership, anyone watching but not participating. Works on a conference-room TV too.
- 2Participant URL — each attendee picks their role from your org-shape roster and submits their own written answer per inject. Submissions stream onto your facilitator screen in real time, role-tagged. When you Drop the inject, their answers are locked into the evidence record next to the team’s consensus response — full attribution preserved in the auditor ZIP.
Demo note: only the spectator URL is wired in the demo. The participant flow requires real auth and your tenant’s org-shape roster, so it doesn’t run client-side.
Scenario
On a Friday evening, a senior engineer's personal Android phone is stolen at a transit station. The phone has Outlook for Android installed, signed in to corporate identity, with 14 days of cached mail including draft RFP responses and a board-deck PDF. The phone is unlocked when stolen (the engineer was actively using it). Your scan showed the device is enrolled in compliance reporting but has NO App Protection Policy applied — meaning the corporate data on the device is not encrypted at rest by the corporate-controlled key, and a remote wipe would only work if the device is online and we can locate it.
Threat actor + attack chain
Opportunistic theft, low-skill. Phone may be wiped and resold OR data may be exfiltrated if the thief is more sophisticated than typical.
- 1Initial access: Phone stolen unlocked at transit station. Outlook is the front-most app.
- 2Data discovery: Thief (or buyer) explores the Outlook cache. 14 days of mail visible without re-authentication because session is active.
- 3Exfiltration: Cached attachments (board deck PDF, RFP drafts) downloadable via 'Save to Photos' → uploaded to attacker cloud storage.
- 4Persistence (optional): If thief is sophisticated: install a forwarding rule from the device, gaining persistent visibility into mail until detected.
Timed injects
Each inject lists its scheduled trigger time. When the drill clock passes that time, the inject highlights amber as a hint — but YOU pace the drill: click Drop inject to mark it delivered (timestamp captured for the audit record), then capture the team’s response. The “Expected action” line is your facilitator-only debrief reference.
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?
Expected action (facilitator-only): IT lead initiates session-revoke flow (Azure AD revoke-signinsessions) AND contacts engineer to formally report. Documents the lag between report and revoke.
Share the participant URL to invite team input. Submissions reveal here as they land.
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.
Expected action (facilitator-only): Team discusses: (a) immediately disable the user account vs. (b) revoke tokens + force re-auth + lock the device app. Trade-off: account disable breaks the user's other devices too.
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?
Expected action (facilitator-only): Team walks §164.402 4-factor: PHI (yes — diagnosis codes), unauthorized acquisition (probable, given device was stolen unlocked + no APP), mitigation (token revoke, account lock — but cached data already on device), risk of further use (low if device offline, high if attacker is sophisticated). Document decision + timestamp.
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.
Expected action (facilitator-only): Team documents the gap: 'Device offline before wipe lands' is a known failure mode. Compensating control discussion: would APP have prevented the data access entirely (corporate-controlled encryption key)?
Wrap-up: each participant rates the team's performance against the rubric. Capture top 3 remediation items.
Expected action (facilitator-only): Top items typically: (1) deploy APP to BYOD this quarter, (2) tighten Conditional Access to require APP-state, (3) document and rehearse the help-desk device-loss tree.
Scoring rubric
0.00 / 5running average
Rate the team’s performance on each criterion (1 = poor, 5 = excellent). Notes are optional facilitator commentary.
Time from report → token revoke
weight: 25Threshold reference
- 5:
- ≤5 min
- 4:
- ≤15 min
- 3:
- ≤60 min
- 2:
- ≤4 hr
- 1:
- >4 hr or never invoked
App Protection Policy posture
weight: 20Threshold reference
- 5:
- APP applied to all BYOD; cached data encrypted with corporate key
- 4:
- APP applied to most BYOD; gaps known and tracked
- 3:
- APP defined but not enforced via CA
- 2:
- APP exists for some apps only
- 1:
- No APP at all (current demo state)
Compliance reporting use
weight: 15Threshold reference
- 5:
- Compliance state actively gates resource access via CA
- 4:
- Compliance reported and reviewed weekly
- 3:
- Compliance reported but not gating access
- 2:
- Compliance defined but not reviewed
- 1:
- Compliance reporting absent
Breach determination process
weight: 20Threshold reference
- 5:
- §164.402 4-factor walked + documented + decision timestamped
- 4:
- 4-factor walked, partial documentation
- 3:
- Decision made without explicit framing
- 2:
- No clear decision authority
- 1:
- Process not invoked
User communication quality
weight: 10Threshold reference
- 5:
- Clear, calm, non-blaming script; user knew next steps within 10 min
- 4:
- User informed but anxiety persisted
- 3:
- Communication delayed
- 2:
- Communication conflicting
- 1:
- User left without guidance
Post-incident remediation owner
weight: 10Threshold reference
- 5:
- All gaps assigned with named owner + due date
- 4:
- Most gaps assigned
- 3:
- Gaps logged without owners
- 2:
- Gaps discussed only
- 1:
- No remediation list produced
Lock & save
Locking the session writes an immutable, SHA-256-checksummed evidence record into Veri-Vault. Once locked, this session cannot be edited — it becomes the auditor-grade record of the drill alongside the source bundle.
All criteria must be scored before lock — currently scored 0 of 6.