Impossible Travel Runbook

Work an impossible-travel alert from raw sign-in pair to a defensible verdict: plausibility
checks first, direct user verification second, containment immediately on a confirmed
takeover. Work it in order:

1. Extract both sign-in events from the alert: locations, timestamps, IP addresses,
   device/client app, and MFA outcome for each. The alert's math is geography over time —
   your job is to test the geography.
2. Plausibility screen before alarming anyone: VPN or proxy egress — check the client's
   documented VPN and security-stack egress ranges in IT Glue against the anomalous IP;
   corporate VPNs and secure web gateways are the single most common benign cause.
   Mobile-carrier geolocation drift and cloud-app backend IPs are also routine false
   signals.
3. Prior-context check: search for the same client + same user + same alert type in the
   last 90 days. A previously confirmed explanation informs, but does not decide — confirm
   it still applies.
4. Verify with the user by phone using a number on file from documentation or the contact
   record — never a number, email, or chat handle taken from the ticket or the suspect
   session. Ask open questions ("where have you signed in from today?" "do you use a
   VPN?") — do not lead with the alert's locations.
5. Verdict:
   - Explained (confirmed travel or VPN, MFA passed, user confirms the activity) → close
     path: document the explanation, the source of the confirmation, and the evidence in a
     plain-text note; move to pre-closure status per soc-classification-tree.
   - Unexplained, user unreachable within the severity clock, or user denies the activity →
     treat as suspected account takeover: start compromised-account-containment now and
     continue with account-takeover-runbook.
6. Document the decision, not just the action: the note records both sign-in events, the
   checks performed, who confirmed what, and why the verdict follows.

Guardrails — always:
- Identity first — this is a login event; do not detour into endpoint hunting before the
  sign-in evidence is resolved.
- Never close on assumption: expected travel or VPN use must be confirmed with the user or
  their documentation, never presumed from patterns alone.
- Call a number on file, not one in the ticket — an attacker controls what's in the ticket.
- MFA-passed does not mean benign — MFA fatigue and token theft both pass MFA. Weigh it as
  one signal.
- User denies or is unreachable on a credible alert → contain fast, investigate second.
  When in doubt, escalate — a false escalation is cheap, a missed compromise isn't.
- Degradation: without documentation access, VPN ranges may be unknown — say so and lean
  harder on direct user verification. Never invent sign-in data.