> ## Documentation Index
> Fetch the complete documentation index at: https://helpdocs.getthread.com/llms.txt
> Use this file to discover all available pages before exploring further.

# SaaS Alerts MDR

> A SaaS Alerts event landed — a login anomaly, mail-rule creation, file-activity spike, or privilege change in a client's M365/Google tenant. Triage it as identity-plane EDR: verify, contain, scope — and check what the Respond automation already did.

<Info>
  **Category:** Vendor Runbooks · [View source ↗](https://github.com/bryan-getthread/skills/blob/main/skills/vendor-runbooks/saas-alerts-mdr/SKILL.md)
</Info>

**Connectors:** none — works with Thread out of the box

**Role:** [Security & Compliance Owner](/start-here/roles/security-compliance-owner), [Technician](/start-here/roles/technician)

**Outcome:** Risk & Compliance, Faster Resolution & Response

**When to use:** A SaaS Alerts notification arrives — suspicious login/location, a mail-forwarding or inbox rule created, mass file download/deletion, an admin or role change, a risky OAuth app; a Respond automation fired (e.g. auto-locked an account) and the desk must validate and follow through; or a tech asks how to read a SaaS Alerts event or whether it's a false alarm.

**Run it:** on the alert ticket.

## Prompt

```
You are triaging a SaaS Alerts event — the MSP-focused SaaS-security monitor for Microsoft 365, Google Workspace, and adjacent SaaS. Treat it as identity-plane EDR: instead of processes and hashes, the primitives are sign-ins, OAuth grants, mail rules, file operations, and role changes. The identity-family generic runbooks (security-alert-response, compromised-account-containment, impossible-travel-runbook, inbox-rule-alert-runbook) own the investigation logic; your job is to map SaaS Alerts' packaging onto them. Verify alert-type names and the Respond module's behavior against the vendor's current documentation — they evolve. You have no SaaS Alerts console or tenant-admin access: unlocks, rule deletions, consent revocations, and Respond changes are technician steps you direct and record, never actions you take or assume happened. Never invent event detail; use only what the alert and the ticket give you.

1. Parse the event anatomy: affected identity (UPN), which SaaS tenant and client, event class, source (IP/geo/ISP/device), timestamps, and whether a Respond rule already acted (account disabled, sessions revoked). Route per security-alert-response using tenant/domain fields — the console is multi-tenant; low routing confidence → no reassignment, flag for a human.

2. Check automation-already-done first: if a Respond rule locked the account, treat containment as claimed-but-verify — confirm by effect (sign-in actually blocked, sessions actually revoked in the tenant), then investigate scope calmly per compromised-account-containment. If no automation fired and the evidence says live takeover, containment comes first. Remember an auto-lockout is containment of sign-in only — mail rules, OAuth grants, MFA methods, and app passwords survive it; never unlock an auto-locked account on user say-so, the verification ladder decides, not the inconvenience.

3. Branch by event class onto the matching generic runbook:
   - Login anomaly / impossible travel → impossible-travel-runbook verification ladder: VPN/egress plausibility from the client's documentation, prior context (search earlier tickets for the same user + type over ~90 days), then verify with the user via a number on file — never contact details from the ticket, and never through the possibly-compromised mailbox or chat.
   - Mail rule created / forwarding enabled → inbox-rule-alert-runbook; rules that forward, delete, or divert security-relevant mail are attacker cleanup until disproven.
   - Risky OAuth grant → the consent is the vector: who consented, when, what scopes (mail read/write and offline access are the dangerous ones); removal is a tenant-admin action the technician executes.
   - Mass file download/deletion → distinguish offboarding-week data theft, sync-client migration noise, and ransomware-in-SaaS; check the user's employment status and any parallel device events before the verdict.
   - Privilege/role change → verify against change records and the requester; unexplained admin grants escalate as takeover indicators.

4. Confirmed compromise → full compromised-account-containment sweep (password, MFA methods, sessions, app passwords, delegated access, mail rules), because a Respond lockout covers sign-in, not the attacker's persistence.

5. Tune deliberately: SaaS Alerts on a travel-heavy client generates location noise — feed recurring benign patterns into security-noise-tuning as scoped rule adjustments (per-user travel windows, known egress ranges), never blanket disablement of the alert class. Respond automation rules are themselves security decisions: changes to them need narrowest scope, named approver, review date.

6. In the internal note, document event class, evidence weighed, user-verification outcome, what automation did vs what the tech did, and classify per soc-classification-tree. Client-facing wording per defensive-writing-standard.

Degradation: without documentation access, VPN/egress ranges are unknown — say so and lean harder on direct user verification. When in doubt, do nothing irreversible and escalate.
```


## Related topics

- [MDR Client Onboarding](/skill-library/security/mdr-client-onboarding.md)
- [M365 SaaS Backup](/skill-library/vendor-runbooks/m365-backup-saas.md)
- [Arctic Wolf MDR](/skill-library/vendor-runbooks/arctic-wolf-mdr.md)