SaaS Forensics: Evidence, Retention and Timelines

When an incident happens inside a SaaS application there is no disk to image and no memory to capture: the evidence is whatever the provider logs, for as long as your licence keeps it, and much of it expires before anyone asks for it. SaaS forensics is the work of finding, preserving and interpreting that evidence across several applications at once, usually starting from a compromised identity or a stolen integration token. This guide covers the evidence sources common to SaaS platforms, retention and lag limits, how to collect and preserve evidence defensibly, how to investigate identity and token abuse across applications, and how to build a single timeline. It is for incident responders, detection engineers and security leads who own investigations in SaaS-heavy organisations. For platform-specific detail on Microsoft Teams, Slack and Google Workspace, see the Collaboration platform investigations guide; for infrastructure clouds, see the Cloud Forensics Guide.

Key takeaways

Logs are the only evidence, and they expire. Default windows are measured in months: 180 days for Microsoft Purview Audit (Standard) and GitHub organisation audit logs, and six months for most Google Workspace logs, which admins cannot extend.
Retention changes are never retroactive. Microsoft states that a record's lifetime is set when it enters the audit pipeline, so upgrading a licence after an incident does not bring back expired events. Export before you need it.
Start with the identity, not the app. Most SaaS incidents begin with a stolen session, password or OAuth token; the IdP and token logs tell you which applications to pull next.
Integrations leave different traces from people. Token-based access bypasses SSO and MFA, appears as a trusted application and is often visible only as API volume, user agent and source address.
Normalise time and lag before you conclude. Providers log in UTC with different delays (Google token events can take a couple of hours to appear), so a missing event may simply not have arrived yet.

Why SaaS forensics is different

Aspect	Endpoint or IaaS forensics	SaaS forensics
Evidence you control	Disk, memory, network captures, OS logs	Provider audit logs, admin exports, content holds; no system-level artefacts
Retention	Set by you	Set by the provider and your licence tier
Collection method	Imaging tools, agents	Admin consoles, audit APIs, streaming, eDiscovery or legal hold tools
Who can collect	Responders with host access	Accounts or integrations with audit roles in each tenant
Typical attacker footprint	Malware, persistence on hosts	Sign-ins, consent grants, mailbox rules, sharing changes, bulk exports, new API tokens
Provider involvement	Optional	Often required for data the customer cannot see

NIST's NISTIR 8006 collects and categorises the forensic challenges investigators face in cloud environments, many of which stem from the differences above. NIST SP 800-86 still frames the process (collect, examine, analyse, report) and reminds investigators to involve legal counsel before acting, which matters more in SaaS because content often contains personal data.

Evidence sources across SaaS applications

The names differ, but most enterprise SaaS platforms expose the same evidence categories. Map each application you depend on to this table before an incident.

Evidence category	What it answers	Typical sources
Sign-in and session logs	Who signed in, from where, with which method, and whether MFA was satisfied	IdP sign-in logs; application login events; access logs listing IP and device
Admin and configuration audit	Who changed SSO, roles, security settings, retention or logging	Admin audit logs; setup audit trails; organisation audit logs
Token and integration events	Which OAuth apps were authorised, which API tokens or keys were created and used	OAuth or token logs; integration and connected-app events; personal access token events
Data access and export	What was read, downloaded, exported, shared externally or made public	File and object access events; export and report-run logs; sharing and publishing events
Content and versions	What the data said at a point in time, including edits and deletions	Legal hold and eDiscovery tools; version history; trash and retention settings
API request logs	Exact API calls by tokens and integrations, with user agent and source address	API event streaming; event monitoring add-ons; request logs
Provider-side records	Activity only the provider can see	Provider security team via support or contract

Licence gaps: several categories, especially API request logs and long retention, are add-ons or top-tier features. The SaaS Audit Log Retention and Licensing Guide covers what major platforms document.
Content is not in the audit log: audit events normally carry metadata, not message or document content. If you need to know what a leaked page or message contained, you need a hold, export or version history, not the log.
Collaboration tools: chat and meeting platforms store content in unusual places (for example Teams messages in mailboxes). Follow the Collaboration platform investigations guide.

Retention, lag and the evidence clock

Platform (documented default)	Retention	Notes
Microsoft Purview Audit (Standard)	180 days (90 days for records created before 17 October 2023)	Applies to non-E5 and guest users
Microsoft Purview Audit (Premium)	1 year for Entra, Exchange, OneDrive and SharePoint for E5 users; 180 days for other workloads by default	Up to 10 years with E5 plus the 10-Year Audit Log Retention add-on; not retroactive
Google Workspace Admin console and Reports	Generally 6 months; admins cannot change or delete it	Vault logs kept indefinitely; email log search 30 days
GitHub organisation audit log	Last 180 days, owners only	GraphQL returns 90 to 120 days; GitHub advises enterprise streaming, API request streaming and source IP disclosure

Lag: Google documents near real time (minutes) for admin, Drive and login events, tens of minutes for user account events, and a couple of hours for token events. Wait out the documented lag before treating an absence of events as evidence.
The evidence clock: attackers who move slowly can outlast default retention. If the initial access date is unknown, assume your earliest logs may already have expired and pull everything available on day one.
Decide in advance: stream audit logs to a SIEM or storage you control, sized to your investigation and regulatory needs (12 months or more is a common target), rather than relying on provider defaults.

Collecting and preserving evidence

Freeze the evidence before containment where you can. Disabling a user or revoking a token is necessary, but first export the user's recent audit events, sign-ins, token grants and sharing changes. Some platforms delete or anonymise data when an account is deleted, so suspend rather than delete.
Use a dedicated collector identity. Collect through a read-only audit role or a purpose-built integration, not a global admin account. Record which identity collected what, because the collector itself appears in the logs.
Pull wide, then narrow. Export the full available window for the affected identities and all admin events, not only the suspected days. Store raw JSON or CSV exactly as returned by the API.
Hash and record. Calculate a SHA-256 hash of each export at collection, store it in write-once storage, and keep a chain of custody record: source, query or filter, time range, collector, time collected, hash.
Place content holds. Use the platform's legal hold or eDiscovery feature on affected mailboxes, drives, channels or pages so later deletion by the attacker or by retention does not destroy content.
Ask the provider early. Open a security case with each provider the same day. Ask what they can see that you cannot (backend access logs, token use from their side), how long they keep it, and whether they will preserve it.
Document your own actions. Every responder action (resetting passwords, revoking tokens, changing settings) generates log events. Keep a timestamped action log so you can separate your activity from the attacker's.

Investigating identity and token abuse

Most SaaS investigations follow an identity across applications. Work outward from the first confirmed event.

Question	Where to look	ATT&CK technique
How did the attacker get in?	IdP sign-ins (new device, location, MFA method changes), help desk tickets, infostealer exposure	T1078.004 Cloud Accounts
Did they steal or mint tokens?	OAuth consent events, new personal access tokens, new app passwords or API keys	T1528 Steal Application Access Token
Did they add persistence?	New credentials on applications or service principals, new integrations, new admin role assignments	T1098.001 Additional Cloud Credentials
Did they use tokens to move between apps?	API calls by integrations from unusual addresses or user agents; token use after the user was disabled	T1550.001 Application Access Token
What did they read or take?	File downloads, exports, report runs, bulk queries, sharing to external accounts	T1530 Data from Cloud Storage; T1213 Data from Information Repositories
Did they read email or chat?	Mailbox access events, inbox rules, chat exports	T1114.002 Remote Email Collection; T1213.005 Messaging Applications

Human versus integration activity: integration access does not produce interactive sign-ins and is not subject to MFA. Look for API volume, unusual user agents, source addresses in anonymising networks and access to objects the integration never normally touches.
Token lifetimes: resetting a password does not always revoke OAuth refresh tokens or API keys. Confirm in each application that tokens stopped working after revocation by checking for later use.
Secrets inside the data: if the attacker exported tickets, wikis or chat, assume any credentials stored there are compromised and widen the scope to the systems those credentials reach. See the SaaS integration token breach response guide.
Where identity fits: the collector integrations, SIEM connectors and SCIM tokens used for investigation are themselves high-value non-human identities. Inventory them and protect them like admin accounts. See the SaaS API Token Security Guide.

Building a cross-application timeline

Normalise: convert every timestamp to UTC, keep the original field and source, and note each platform's documented lag.
Map identities: build a table linking the same person or integration across systems (UPN, email, user ID, app ID, token ID, OAuth client ID). Attackers often appear under different identifiers in each app.
Anchor on high-confidence events: IdP sign-ins with IP and device, token creation and consent events, admin changes. Place lower-confidence events (user agent strings, which are client-supplied) around them.
Correlate by address and session: group events by source IP, ASN and session or token ID across applications to see one actor moving between tools.
Mark gaps explicitly: record where logs expired, were not licensed or did not exist. Gaps are findings, and regulators and insurers will ask about them.

The Forensic Timeline Analysis Guide covers timeline tooling and methods in general.

Choosing the approach

Option	Strengths	Trade-offs	Fits
Continuous streaming to SIEM or data lake	Retention you control, fast queries, detection and forensics from one store	Ingest cost; connectors need maintenance and privileged tokens	Medium and large organisations, regulated sectors
Scheduled exports to cold storage	Cheap long retention, simple	Slow to query; gaps if a job fails silently	Small teams, lower-volume applications
On-demand collection at incident time	No standing cost	Limited to provider retention; slow under pressure	Only acceptable for low-risk applications
External DFIR retainer	Experience across many SaaS platforms, surge capacity	Needs pre-agreed access and collector accounts to be fast	Any size, alongside one of the above

Small organisations should at least stream IdP and email or collaboration logs and export the rest monthly. Large organisations should treat SaaS audit streams as tier-one log sources with health monitoring; the joint Best Practices for Event Logging and Threat Detection guidance led by ASD's ACSC with CISA, NCSC-UK and other partners is a useful reference for the logging programme. Build this into planning with the Forensic Readiness Guide.

Detection and measurement

Log coverage: percentage of business-critical SaaS applications whose audit logs are streamed or exported to storage you control. Target 100 percent for tier-one applications.
Effective retention: days of searchable history per application compared with your target. Alert when it drops.
Collector health: hours since last successful ingest per source; failed or revoked collector tokens.
Time to evidence: time from incident declaration to a preserved, hashed export for all affected identities.
Integration visibility: percentage of OAuth apps and API tokens with an owner and a monitored activity baseline.

Framework mapping

Activity	NIST SP 800-53 Rev. 5	NIST CSF 2.0
Incident handling and investigation	IR-4	RS.AN-03
Preserving evidence integrity and provenance	AU-9	RS.AN-06, RS.AN-07
Retaining audit records long enough	AU-11	RS.AN-07
Correlating logs across applications	AU-6	DE.AE-03

Common failure patterns

Relying on default retention: the intrusion started seven months ago and the earliest six months of logs are all that remain.
Buying the higher tier after the incident: retention upgrades apply only to new records.
Deleting compromised accounts: deletion can remove the very audit trail and content needed to scope the incident. Suspend and preserve.
Collecting with a global admin: the collector's own activity muddies the timeline and creates another privileged credential to protect.
Ignoring integrations: investigators review interactive sign-ins, see nothing unusual, and miss bulk API exports by a trusted application.
Not verifying revocation: tokens and sessions keep working after a password reset because no one checked later activity.

Lessons from incidents

The Salesloft Drift breach shows the SaaS forensics problem in full. Between 8 and 18 August 2025 the actor used stolen Drift OAuth tokens to call Salesforce APIs as an application customers had already authorised, so SSO and MFA did not apply. The useful evidence was API-level: count queries against Account, Opportunity, User and Case objects followed by bulk exports, a distinctive tool user agent, and calls from TOR and anonymising proxies. The actor then searched exported support cases for AWS keys, passwords and Snowflake tokens, which widened every affected customer's investigation to the systems those secrets reached. Organisations with API event logging and integration baselines could scope quickly; those with only login history could not. See also the OAuth and SaaS integration breaches guide.

Practitioner checklist

List every business-critical SaaS application with its evidence categories, retention, lag, licence tier and collection method.
Stream or export IdP, email, collaboration and code platform audit logs to storage you control with at least your target retention.
Create read-only collector identities in each tenant and document them as non-human identities with owners.
Write a SaaS evidence preservation runbook: export, hash, hold, provider contact, before containment.
Suspend rather than delete compromised accounts until evidence is preserved.
Baseline integration and API token activity so bulk exports by trusted apps stand out.
Verify token and session revocation by checking for later use in each application.
Keep a provider security contact list and confirm what each provider will preserve on request.
Exercise a cross-application token theft scenario at least annually.

SaaS Forensics: Evidence Sources, Retention Limits and Cross-App Timelines