SaaS Incident Response: Scoping and Containment

Most SaaS incidents are not stolen integration tokens: they are a hijacked admin, a user account turned into an exfiltration tool, or a malicious app a user approved, and each needs a different first move. SaaS incidents also cut across tools: the attacker signs in through the identity provider, reads mail, downloads from file storage and exports the CRM, so containing one application while the others stay open achieves little. This guide covers how to classify a SaaS incident, scope it across business applications, contain it in the right order, preserve the evidence you need first, and decide when notification clocks start. It is for incident responders, SaaS and identity administrators and security leads. Token breaches at a vendor have their own guide, the SaaS integration token breach response, and deep evidence work is in SaaS Forensics; this page is the response layer that connects them.

Key takeaways

Classify before you act. Admin compromise, user account takeover, malicious app consent and data exfiltration need different containment, and the wrong first step (a password reset for a consent grant) leaves the attacker in place.
Scope from the identity outward. The identity provider and its token grants tell you which applications to check next; working app by app misses the ones nobody thought of.
Disabling a user is not the same as ending access. Sessions, refresh tokens, app passwords, OAuth grants and API keys each have their own revocation step, and several survive a password change.
Preserve, then contain, in minutes not days. Export the affected identities' audit events and suspend rather than delete accounts, because deletion can remove the records you need.
Persistence lives in configuration. New admins, added app credentials, mail forwarding rules, registered devices and MFA methods are how attackers come back; eradication means finding all of them.

What kind of SaaS incident is this?

Classify the incident in the first 30 minutes using the first confirmed signal. The class decides who leads, which accounts to touch first and which playbook to run alongside this guide.

Incident class	Typical first signal	Who leads	First containment move	Companion playbook
Admin account compromise	New admin role assignment, SSO or MFA policy change, audit logging turned off, bulk destructive action	Identity team with incident lead	Disable the admin, revoke sessions, remove any admin the attacker created, check for break-glass use	SaaS Admin Account Protection
User account takeover	Risky sign-in, new MFA method, inbox forwarding rule, impossible travel alert	SOC	Disable or block sign-in, revoke sessions and refresh tokens, remove attacker MFA methods	Account Takeover Response Playbook
Malicious app or consent grant	New OAuth consent with broad scopes, new connected app, app with a misleading name	SaaS or identity admin	Remove the grant and block the app tenant-wide; a password reset does not stop it	Consent Phishing and Illicit OAuth Grants Guide
Data exfiltration	Mass download, bulk export or report run, external sharing spike, large API volume	SOC with data owner	Stop the identity doing it (user or integration), then lock the sharing links it created	Insider Data Theft Response Playbook
Session theft	Activity from a new address on an existing session with no fresh sign-in	SOC	Revoke sessions everywhere, then find the infected device	Session Token Theft Response Playbook
Vendor or integration token breach	Vendor notification, API calls by a trusted integration from unusual addresses	SaaS owner with vendor management	Disable the integration, revoke and rotate	SaaS integration token breach response

Incidents often move between classes. A help desk call that resets a user's MFA becomes a user takeover, which becomes a malicious app consent, which becomes bulk exfiltration. In the ShinyHunters Salesforce data theft campaign, callers posing as IT support talked staff into authorising an attacker-controlled connected app, which then bulk-exported CRM tables through the API. Record the class as a working hypothesis and revisit it at each update.

The first hour: triage questions

Which identity is confirmed bad? A person, an admin, a service account or an integration. Write down every identifier it has: UPN, email, IdP user ID, app user IDs, OAuth client IDs and token IDs.
Is it still active? Look for events in the last hour. Active attacker activity raises the priority of containment over observation.
Does it hold admin rights anywhere? In the IdP, in any SaaS tenant, or through delegated administration. Admin access changes the order of work (see below).
Is it federated? If the application signs in through SSO, IdP containment cuts new sign-ins; local accounts, API keys and app passwords need separate action in each application.
What can it reach? List the applications assigned to it in the IdP, its OAuth grants, and any integrations it owns.
What is the evidence clock? Check the retention of each affected application's audit log now. The SaaS Audit Log Retention and Licensing Guide lists documented defaults.
Is personal or regulated data involved? If it might be, bring in the privacy lead now, because notification clocks may already be running.

Scoping across business applications

Scope is the set of identities, applications, data and configuration the attacker touched. Work outward from the first confirmed identity in rings, and stop widening only when a ring adds nothing new.

Ring	Question	Where to look	ATT&CK technique
1. Access	How did the attacker sign in, and with what?	IdP sign-in logs, MFA registration events, help desk tickets	T1078.004 Cloud Accounts; T1621 Multi-Factor Authentication Request Generation
2. Persistence	What did they add so they can return?	New MFA methods, registered devices, app credentials, admin role assignments, OAuth consents	T1098.001 Additional Cloud Credentials; T1098.003 Additional Cloud Roles; T1098.005 Device Registration
3. Spread	Which other applications did the identity or its tokens reach?	IdP application sign-ins, OAuth grants, API activity by the user's tokens	T1550.001 Application Access Token; T1528 Steal Application Access Token
4. Collection	What did they read, download or export?	File access and download events, report and export logs, mailbox access	T1530 Data from Cloud Storage; T1213 Data from Information Repositories; T1114.003 Email Forwarding Rule
5. Secrets in data	Did the data they took contain credentials?	Search exported tickets, wikis, chat and CRM notes for keys and passwords	T1213.005 Messaging Applications
6. Other identities	Did they phish or impersonate others from inside?	Internal mail and chat sent by the identity, new sharing to external accounts	T1567 Exfiltration Over Web Service

Pivot on infrastructure: take every source IP address and user agent seen on the compromised identity and search all application logs for them. This finds other accounts the attacker controls.
Pivot on the app: for a malicious app, find every user who consented to the same client ID, not just the one who reported it. Microsoft's guidance on illicit consent grants treats a grant with ConsentType AllPrincipals as access to everyone's content in the tenant.
Mark what you cannot see: applications whose logs expired or were never licensed are scope unknowns, not scope negatives. Record them as such.

Preserve before you contain

Containment generates its own log events and some actions destroy evidence, so take a fast snapshot first. If the attacker is actively deleting data or creating admins, contain immediately and preserve in parallel.

Export the last 30 days (or the full retained window if feasible within minutes) of audit events for each confirmed identity, plus all admin audit events, as raw API output.
Export current OAuth grants, app registrations, admin role assignments, mail rules and MFA methods for the affected identities. These are what eradication must undo.
Place legal holds on affected mailboxes, drives and channels where the platform supports it.
Hash each export and start a responder action log with UTC timestamps.

Suspend, freeze or disable accounts rather than delete them. Salesforce, for example, documents freezing a user as a way to block login while deactivation steps are completed. Full collection methods, hashing and chain of custody are in SaaS Forensics.

Containment by priority

Contain in this order. Each step closes a route that the steps after it depend on.

Admin access first. Remove or disable any admin the attacker controls or created, in the IdP and in each SaaS tenant. An attacker with admin rights can undo every other containment step. The Stryker Intune wiper attack shows how a compromised admin account plus a newly created Global Administrator could issue destructive commands through a legitimate management service.
Block new sign-ins at the IdP. Disable the account or block sign-in, then revoke sessions and refresh tokens.
End existing sessions in each application. IdP revocation stops new tokens; application sessions already issued may continue until they expire.
Revoke non-interactive credentials. App passwords, personal access tokens, API keys and OAuth grants issued to or by the identity.
Remove attacker persistence. MFA methods, registered devices, mail forwarding and inbox rules, added app credentials.
Stop data leaving. Remove external sharing links and guest access created during the incident; block the malicious app tenant-wide.
Reset credentials last. Reset the password once persistence is gone, so the attacker cannot reset it back through an MFA method or recovery address they added.

The table shows documented containment controls for common platforms, listed alphabetically. Plan and edition availability varies; confirm in each vendor's documentation.

Platform	Documented containment control	What the documentation says it covers
GitHub (organisation with SAML SSO)	People, member, SAML identity linked: revoke active SAML sessions and authorised credentials	Revoking a credential removes its SAML authorisation for the organisation; the token or key itself is not deleted, so revoke it at the user level too
Google Workspace	User, Security, Sign-in cookies, Reset; suspend the user; revoke third-party app access	Resets browser and mobile sessions; suspending also resets sign-in cookies; signed-in desktop apps such as Google Drive for desktop are handled separately
Microsoft Entra ID	Clear Account enabled, then Revoke sessions (Revoke-MgUserSignInSession); disable registered devices	The user cannot obtain new tokens; existing access tokens last one hour by default, and Continuous Access Evaluation can revoke tokens sooner for CAE-capable apps
Okta	Revoke all user sessions (User Sessions API), with oauthTokens=true	Ends IdP sessions; oauthTokens=true also revokes OpenID Connect and OAuth refresh and access tokens; sessions inside downstream apps are ended in each app
Salesforce	Freeze the user, then deactivate; remove the connected app's access	Freezing blocks login while deactivation steps are completed
Slack (Enterprise)	admin.users.session.reset API	Wipes all valid sessions on all devices for the user; options limit it to mobile or web only

Malicious apps need app containment, not user containment. Microsoft states that password resets and MFA do not stop an illicit consent attack, because the app holds its own access. Remove the delegated grant (Remove-MgOauth2PermissionGrant in Entra ID), remove app role assignments, then block the app so other users cannot consent to it. The same principle applies on every platform: revoke the grant and block the client ID. See the SaaS and OAuth App Governance Guide for the controls that prevent it recurring.

Eradication and recovery

Configuration diff: compare current SSO settings, MFA policies, conditional access rules, admin roles, audit settings and integrations against a known-good baseline. Restore from configuration backup where you have one; see SaaS Configuration Backup and Recovery.
Credentials in stolen data: rotate every secret found in exported tickets, wikis, chat or CRM records, and treat the systems those secrets reach as in scope.
Data integrity: where the attacker had write access, check for altered records, deleted content and changed payment or contact details before restoring business use.
Verify revocation: query each application's logs for any use of revoked sessions, tokens or keys after the revocation time. An incident is not closed while any old credential still works.
Return the account carefully: re-enable the user only after re-enrolment of MFA in person or through a verified channel, and watch the account closely for 30 days.
Close the entry route: phishing-resistant MFA for admins, consent restrictions, help desk verification, network restrictions on admin consoles.

Notification triggers

Three questions decide notification: was personal data involved, are you the controller or processor, and does a sector or contractual rule apply. Under GDPR Article 33(1) a controller must notify the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of a personal data breach, unless it is unlikely to result in a risk to individuals. Article 33(2) requires a processor to notify the controller without undue delay. If your SaaS provider is the source, its contract sets how and when it tells you; the SaaS Provider Incident Notification Guide covers that side. Sector and national rules vary widely: use the Cyber Incident Reporting Requirements Map to check which apply, and record the moment of awareness, because that is when most clocks start.

Decision guidance

Decision	Choose option A when	Choose option B when
A: contain now / B: observe first	The attacker is active, holds admin rights, or is moving data	Activity has stopped, scope is unclear and law enforcement or counsel has asked for observation (time-boxed, with sign-off)
A: suspend / B: delete the account	Almost always: suspension keeps audit history and content	Only an attacker-created account, after its activity and content are exported
A: block the app tenant-wide / B: remove one user's grant	The app is unknown, malicious or consented by several users	The app is approved and only one user's token is in question
A: in-house response / B: bring in a retainer	Fewer than a handful of applications, logs streamed, team practised	Many applications, expired or unlicensed logs, regulated data, or admin compromise at the IdP

Small organisations often have one person who administers every SaaS tenant. Keep a printed list of each tenant's admin console, break-glass account and support contact, and pre-agree with an external responder how they will get read-only access. Large organisations should pre-build the containment actions above as SOAR or scripted runbooks with approval steps, so revocation across a dozen applications takes minutes. For general containment strategy, see the Incident Scoping and Containment Strategy Guide; for infrastructure clouds, the Cloud Incident Response Guide.

Where identity fits

Integration users, service accounts and API tokens are frequently the identity at the centre of a SaaS incident, and the hardest to contain because they have no MFA, no interactive sign-in and often no clear owner. Before an incident, every integration identity should have an owner, a documented scope and a tested way to disable it without breaking the business process it supports. Responders' own collector accounts and automation tokens are privileged non-human identities too. See the SaaS API Token Security Guide.

Detection and measurement

Time to contain: from declaration to the moment the last attacker session, token and grant is revoked across all applications in scope.
Revocation verification rate: percentage of revoked credentials checked in logs for later use. Target 100 percent before closure.
Containment coverage: percentage of tier-one SaaS applications with a documented, tested containment runbook (disable, revoke sessions, revoke tokens).
Scope unknowns: number of applications in scope where logs were missing or expired. Track it down over time.
Re-compromise rate: incidents where the same identity or app returns within 90 days, a sign that persistence was missed.

The detection content that should trigger this guide is covered in the SaaS Threat Detection Guide.

Framework mapping

Activity	NIST CSF 2.0	NIST SP 800-53 Rev. 5
Running the plan with SaaS providers and other third parties	RS.MA-01	IR-8 Incident Response Plan
Scoping and root cause analysis	RS.AN-03	IR-4 Incident Handling
Containment	RS.MI-01	IR-4 Incident Handling; AC-2 Account Management
Eradication	RS.MI-02	IR-4 Incident Handling
Recovery	RC.RP-01	IR-4 Incident Handling
Reporting and notification	RS.CO (Incident Response Reporting and Communication)	IR-6 Incident Reporting

NIST SP 800-61 Rev. 3 (April 2025) recasts incident response as a CSF 2.0 Community Profile and supersedes Rev. 2, so these CSF outcomes are the current reference structure.

Common failure patterns

Resetting the password and calling it contained: sessions, OAuth grants, app passwords and API keys keep working. Revoke each one and verify.
Treating a consent grant as an account problem: the malicious app keeps its access after the user's password changes. Remove the grant and block the app.
Containing the reported app only: the attacker used the same identity in mail, files and CRM. Scope from the IdP outward.
Missing the attacker's admin: responders disable the compromised admin but not the new admin it created, which restores access the next day.
Ignoring weak sign-in on SaaS-local accounts: accounts outside SSO with no MFA are invisible to IdP containment. In the Snowflake breach, infostealer credentials worked against customer accounts that lacked MFA and network restrictions.
Deleting accounts too early: deletion can remove history needed to scope the incident and to support notification decisions.

Practitioner checklist

Classify the incident and name the companion playbook within 30 minutes.
Record every identifier for the compromised identity across IdP and applications.
Export audit events, grants, roles, rules and MFA methods before containment, unless the attacker is active.
Remove attacker-controlled and attacker-created admins first.
Disable or block sign-in, revoke IdP sessions and refresh tokens, then end sessions in each application.
Revoke app passwords, personal tokens, API keys and OAuth grants; block malicious apps tenant-wide.
Pivot on IP addresses, user agents and client IDs to find other affected identities.
Rotate secrets found in stolen data and diff configuration against a known-good baseline.
Verify in logs that no revoked credential was used after revocation before closing.
Record the time of awareness and run the notification decision with the privacy lead.

SaaS Incident Response Guide: Scoping, Containment and Evidence Across Business Apps