What Is the SaaS Shared Responsibility Model?
Every major cloud provider publishes a shared responsibility model that defines which security obligations belong to the provider and which belong to the customer. In SaaS, the provider's share is largest—they control the infrastructure, application code, and physical security. The customer's responsibility is narrower but critically important: identity management, access controls, OAuth app governance, data classification, and tenant configuration. The overwhelming majority of SaaS security incidents in 2023–2026 exploited weaknesses in the customer's responsibility layer, not the provider's.
| Layer | SaaS Provider Responsible | Customer Responsible |
|---|---|---|
| Physical & Infrastructure | Data centers, hardware, networking, hypervisor | Nothing — fully provider-managed |
| Application Layer | Application code, patching, availability, multi-tenancy isolation | Configuration choices (sharing settings, retention policies, MFA enforcement) |
| Identity & Access | Authentication mechanisms, SSO connectors, MFA infrastructure | Who has access, what roles, MFA enrollment, privileged account protection |
| OAuth / Third-Party Apps | OAuth framework, app marketplace review policies | Which apps are approved, what permissions they hold, ongoing app governance |
| Data | Encryption in transit and at rest, backup infrastructure | Data classification, what data is stored in the platform, retention settings |
| Endpoints | Nothing — fully customer-managed | Device health, MDM enrollment, local credential protection |
Forensic implication: When investigating a SaaS breach, you cannot subpoena the provider's infrastructure logs or image their servers. Your investigation is bounded by the logs the provider makes available to customers—and those logs have retention limits that may have already expired by the time you discover the breach.
What Logs Are Available and How Long Do They Last?
Cloud log retention is one of the most consequential variables in SaaS forensics. If the breach occurred outside the retention window, you may have no logs to work with. The table below documents key log sources, default retention, and options to extend retention for AWS, Azure, and GCP. For application-layer SaaS (M365, Google Workspace, Salesforce), see the platform-specific sections below.
| Provider | Log Source | What It Captures | Default Retention | Extended Retention |
|---|---|---|---|---|
| AWS | CloudTrail — Management Events | API calls for resource creation, deletion, and modification (IAM, EC2, S3 bucket config) | 90 days in CloudTrail console (Event history) | Unlimited — configure a Trail to export to S3; standard S3 storage rates apply |
| AWS | CloudTrail — Data Events | S3 object-level reads/writes, Lambda invocations, DynamoDB item-level activity | Not logged by default — must be explicitly enabled per Trail | Export to S3 with lifecycle policy; Athena for querying |
| AWS | VPC Flow Logs | Accepted and rejected network traffic to/from ENIs | Not retained by default — publish to CloudWatch Logs or S3 | CloudWatch Logs retention configurable 1 day – 10 years; S3 unlimited |
| Azure | Azure Activity Log | Subscription-level operations: resource create/delete/modify, policy changes, role assignments | 90 days | Export to Log Analytics Workspace (up to 2 years interactive; archive up to 12 years); or Storage Account (unlimited) |
| Azure | Entra ID Sign-In Logs | User and service principal interactive and non-interactive sign-ins, MFA results, Conditional Access outcomes | 30 days (free / Microsoft 365 F1); 90 days (P1/P2 / E3/E5) | Export to Log Analytics or Storage Account to retain beyond the tier limit |
| Azure | Entra ID Audit Logs | Directory changes: user/group/app creation, role assignments, MFA registration, consent grants | 30 days (free); 90 days (P1/P2) | Export to Log Analytics or Storage Account |
| GCP | Cloud Audit Logs — Admin Activity | Admin writes: resource configuration changes, IAM policy changes, project creation/deletion | 400 days (always enabled, cannot be disabled) | Export to Cloud Storage or BigQuery for longer retention or cross-project aggregation |
| GCP | Cloud Audit Logs — Data Access | Data reads/writes on GCP resources (BigQuery, Cloud Storage, etc.) | 30 days — must be explicitly enabled per service | Export to Cloud Storage or BigQuery |
| GCP | Cloud Audit Logs — System Events | GCP infrastructure actions (live migration, automatic restarts) | 400 days (always enabled) | Export to Cloud Storage or BigQuery |
| M365 | Unified Audit Log | User and admin activity across Exchange, SharePoint, Teams, OneDrive, Azure AD | 90 days (E3); 180 days (E5 / Purview Audit Premium) | Purview Audit Premium: configurable up to 10 years |
| Google Workspace | Admin Audit Log | Admin console actions: user creation, group changes, app access grants | 6 months | Export to BigQuery via Workspace reporting; or third-party SIEM |
| Salesforce | Setup Audit Trail | Configuration changes made in Setup by admins | 180 days | Export to CSV periodically; or Event Monitoring add-on (30 days for event logs) |
Critical action before any incident: Configure log export to a separate, immutable storage location (S3 with Object Lock, Azure Storage with immutable policies, GCS with retention locks) before you need it. Once a breach occurs and you discover the logs are gone, there is nothing you can do. This is the single highest-value pre-breach SaaS security investment.
How Do You Respond to an M365 Tenant Compromise?
M365 tenant compromises typically begin with a phished credential or an over-privileged OAuth app. Once an attacker holds a Global Administrator or Exchange Administrator account, they have access to all email, SharePoint, Teams conversations, and OneDrive files across the organization. The standard attack sequence: phish or credential-stuff a privileged account, create a backdoor account or add a malicious OAuth app, establish email forwarding rules to exfiltrate email silently, then pivot to other systems using harvested credentials.
Phase 1: Contain (Hours 0–2)
- Revoke all active sessions: Azure AD > Users > select compromised account(s) > Revoke Sessions. For global revocation: use the Revoke-AzureADUserAllRefreshToken PowerShell command.
- Disable compromised accounts: Immediately disable any admin accounts where compromise is suspected or confirmed.
- Enable Conditional Access: Block sign-ins from suspicious geographies or require MFA for all users, especially admins.
- Audit OAuth apps: Azure AD > Enterprise Applications > review all apps with access to your tenant. Revoke any you did not explicitly approve.
- Check mailbox forwarding rules: Run
Get-InboxRule -Mailbox * | Where-Object {$_.ForwardTo -ne $null}to find any rules forwarding email to external addresses.
Phase 2: Investigate (Hours 2–48)
- Pull the Unified Audit Log: Microsoft Purview > Audit > search for the past 90 days (or 180 days on E5). Focus on: unusual sign-ins, new user creation, new app registrations, bulk file downloads, mailbox rule creation.
- Check Azure AD Audit Logs: Review role assignments, new users, app consent grants, and conditional access policy changes made in the attack window.
- Identify exfiltrated data scope: Use eDiscovery or Content Search in Purview to identify which mailboxes and SharePoint sites the attacker accessed based on sign-in and access events.
- Check for backdoor accounts: List all users created in the past 90 days; list all service principals and app registrations; identify any accounts added to privileged roles.
- Review Azure AD Risky Sign-ins: Identity Protection > Risky sign-ins and Risky users for Microsoft's own anomaly detections in your tenant.
Phase 3: Remediate (Days 2–7)
- Force password reset for all admin accounts and all accounts showing suspicious activity.
- Revoke all refresh tokens for affected accounts using Revoke-AzureADUserAllRefreshToken.
- Remove all backdoors: Delete suspicious user accounts, service principals, app registrations, and OAuth app consents.
- Enforce MFA: Use Conditional Access to require phishing-resistant MFA (FIDO2 or Microsoft Authenticator) for all users—not just admins.
- Delete malicious mailbox rules identified in Phase 1.
- Configure log export: If not already done, configure Unified Audit Log export to an immutable storage destination.
How Do You Investigate a Salesforce Data Exfiltration?
Salesforce data exfiltration typically happens through a compromised admin account using Reports, Data Loader, or the Bulk API to export the entire Contact, Lead, Account, or Opportunity object. A single Report run can export hundreds of thousands of customer records as a CSV in under a minute. Salesforce's native audit trail is limited unless the Event Monitoring add-on is licensed, which provides detailed API and export event logs retained for 30 days.
Immediate Actions
- Freeze the compromised user account (System Admin > Users > Freeze)
- Check Login History for anomalous IPs, times, or login types (API vs. UI)
- Review Setup Audit Trail (Admin > Security > Setup Audit Trail) for configuration changes in the past 180 days
- If Event Monitoring is enabled: pull Report Export and API Usage event logs to identify mass data exports
- Identify which Connected Apps have OAuth access and revoke any unauthorized ones
What to Look For in Logs
- Large report exports of Contact, Lead, Account, or Opportunity objects — especially CSV downloads
- Data Loader or Bulk API activity from IPs not used by your data team
- New Connected Apps added to the org
- Changes to permission sets or profiles that expanded data access shortly before the incident
- Login from unexpected geographies or impossible travel (same account, two distant locations within minutes)
If you don't have Event Monitoring: Salesforce's standard audit capabilities are limited to Setup Audit Trail (admin config changes) and Login History (sign-in records). Report export and API data access are not logged without the Event Monitoring add-on. If a forensic investigation reveals this gap, prioritize enabling Event Monitoring as part of your remediation plan.
What Is OAuth Token Abuse and How Do You Stop It?
OAuth token abuse is now one of the most common SaaS attack techniques. An attacker tricks a user into authorizing a malicious OAuth app—or compromises an existing legitimate app—and obtains a persistent access token that survives password resets. Unlike stolen passwords, OAuth tokens are not invalidated when the user changes their password. They persist until explicitly revoked, often for months or years. Microsoft's Threat Intelligence team reported in 2023 that consent phishing (tricking users into granting OAuth app access) was used in the majority of business email compromise campaigns targeting M365 tenants.
Revoke OAuth Access in Microsoft 365 / Entra ID
- Go to Azure Portal > Microsoft Entra ID > Enterprise Applications
- Find the suspicious app — look for unfamiliar names, apps requesting Mail.Read or Files.ReadWrite.All permissions
- Under Properties, set "Enabled for users to sign-in?" to No
- Under Permissions, click Grant admin consent tab and Revoke admin consent
- For tenant-wide removal: delete the Enterprise Application; users will need to re-authorize if it is a legitimate app
- Use Get-AzureADServicePrincipal PowerShell to audit all OAuth apps and their permissions in bulk
Revoke OAuth Access in Google Workspace
- Go to Admin Console > Security > API Controls > App Access Control
- Find the app by name or client ID
- Click the app and select Block Access to prevent any user from granting it access
- Notify affected users to also revoke access from their personal Google account > Security > Third-party apps
- Review OAuth Token Audit in Google Workspace for all currently authorized apps
Revoke OAuth Access in Slack
- Go to Settings & Administration > Manage Apps
- Find the suspicious app and click Remove App
- Review Audit Logs (Enterprise Grid only) to see what channels and files the app accessed
- For non-Enterprise Grid: check individual user OAuth connections at Your Apps in the Slack App Directory
What Are the Unique Risks in Multi-Tenant SaaS Breaches?
In multi-tenant SaaS architectures, multiple customers share underlying infrastructure, application code, and—in misconfiguration scenarios—data stores. A breach that exploits a tenant isolation failure can expose multiple customers simultaneously from a single attack. This is distinct from a credential-based breach affecting only your tenant. The Snowflake breach of 2024, in which attackers used stolen credentials to access hundreds of individual customer tenants, illustrates how a SaaS platform breach can have enormous blast radius without any failure in the platform's own isolation controls.
Tenant Isolation Failure
If your SaaS provider notifies you of a tenant isolation vulnerability, treat it as a potential exposure of your data even if no confirmed access occurred. Request:
- Confirmation of whether your tenant data was in scope
- The time window of potential exposure
- What data types could have been accessible
- Evidence of access or confirmed no-access
SaaS-to-SaaS Integration Risk
Modern SaaS stacks involve dozens of integrations—Salesforce syncing to HubSpot, Slack connected to Jira, Zapier automating workflows between platforms. Each integration is a potential lateral movement path. During a SaaS breach:
- Audit all OAuth integrations between your SaaS apps
- A breach in one SaaS platform may have allowed the attacker to reach connected platforms
- Revoke and re-authorize integrations after confirming the primary breach is contained
Platform Breach vs. Credential Breach: Different Responses
Platform breach (provider's fault):
- Send vendor demand letter (see Third-Party Breach Guide)
- Document discovery date for your regulatory notification clock
- Do not assume vendor will notify your affected customers
- Review provider's forensic report when available
Credential breach (your tenant's credentials stolen):
- You are responsible for the full response
- Focus on identity remediation (password resets, MFA, token revocation)
- Audit log review is your primary forensic path
- Notification obligations fall entirely on you
Frequently Asked Questions
How do I know if my M365 tenant was breached?
Check the Microsoft 365 Unified Audit Log for suspicious sign-ins (impossible travel, unfamiliar IPs or ASNs), new OAuth app consents, mailbox forwarding rule creation, and mass file downloads from SharePoint. Azure Entra ID sign-in logs, retained 30 days on free tiers and up to 90 days on P1/P2 or E3/E5, are your primary forensic source. Use Hawk (open-source) or Microsoft's DART tooling to automate IOC detection across the Unified Audit Log.
What should I do if a third-party OAuth app is compromised?
Immediately revoke the OAuth tokens for that app. In M365, go to Entra ID > Enterprise Applications, find the app, revoke all permissions, and disable sign-in. In Google Workspace, go to Security > API Controls > App Access Control and block the app. Then audit what data the app accessed during the period it held tokens, and notify affected users and the vendor.
Can I recover deleted data from Salesforce after a breach?
Salesforce retains deleted records in the Recycle Bin for 15 days (25 days for some editions). After that, you need a backup or Salesforce's Data Recovery Service, available for up to 90 days at additional cost. For forensic reconstruction, Salesforce Event Monitoring (add-on) retains API and export event logs for 30 days—enough to identify what was exported in a recent incident.
What is the shared responsibility model in SaaS breach response?
SaaS providers secure the underlying infrastructure, application layer, and physical facilities. Customers are responsible for identity and access management, OAuth app governance, data classification, user behavior, and tenant configuration. Most SaaS breaches in 2024–2026 occurred in the customer's responsibility layer—compromised credentials, over-privileged OAuth apps, or misconfigured sharing settings—not due to provider-side failures.
Related Resources
Need SaaS Security Expertise?
SaaS breaches require platform-specific forensic knowledge and experience working within each provider's log retention constraints. Find IR firms that specialize in M365, Google Workspace, Salesforce, and cloud-native breach investigations.