Microsoft 365 and Google Workspace: An Investigator's Guide to SaaS Audit Logs

Most workplace fraud, account takeover and insider cases now run through two cloud suites: Microsoft 365 and Google Workspace. Both record a rich trail of who signed in, from where, what mail rules and sharing changed, and which apps were granted access. This guide explains, in general professional terms, what those audit logs hold and how to obtain them lawfully. It is operational guidance, not legal advice, and it assumes you are acting only under proper legal authority for your jurisdiction. Always work through your own prosecutors and the platform's process, and preserve evidence before you analyse it.

What SaaS audit logs record

A productivity suite logs activity at several layers. The identity layer records authentication: every sign-in, the source IP and approximate location, the client app, and whether multifactor authentication (MFA) was satisfied. The mailbox and collaboration layer records actions inside the service: messages sent, items read or deleted, files shared or downloaded, and mailbox rules created. An administrative layer records changes to the tenant itself: new admins, password resets, MFA registration, licence changes and granting of third-party application access. For an investigator these answer different questions, so you usually need more than one log type to build a timeline.

Ask the organisation or serve the provider

The single most important decision is who holds the data you need. In the SaaS model the customer organisation, not Microsoft or Google, is the controller of its own tenant data and the day-to-day custodian of these logs.

• Internal case (the org is the victim or your complainant). The organisation's own administrators can run the audit search, export sign-in logs and place a legal hold. With the organisation's consent or a production order to it, this is the fastest route and gives you the most complete data. Ask them to preserve first and export second.
• External case (the org is uncooperative, the suspect, or unknown). Here you serve legal process on Microsoft or Google through their law-enforcement channels. The provider holds account-level metadata and, with the appropriate order, content. This is slower, content generally requires the higher legal threshold in your jurisdiction, and the provider may notify the customer unless an order bars it.

Microsoft 365 log sources

• Purview Unified Audit Log. The central record across Exchange, SharePoint, OneDrive, Teams and Entra, searchable in the Microsoft Purview portal. It captures actions such as file access, sharing, inbox-rule creation and admin changes.
• Mailbox auditing. Per-mailbox logging of mail accessed, sent, moved and deleted, including by delegates. This is what shows whether an intruder actually read or exfiltrated mail.
• Entra ID (Azure AD) sign-in logs. Authentication events with IP, location, device, client app, MFA result and risk detections; the primary source for spotting a hostile sign-in.
• Message trace. Exchange Online delivery records showing the path of individual messages, useful for tracing spoofed or auto-forwarded mail.

Google Workspace log sources

• Admin console audit logs. Separate logs for Login, Admin, Drive, Gmail (with the right edition), Groups, Tokens (OAuth) and more, viewable in the Admin console and Cloud Logging.
• Login audit log. Successful and failed sign-ins with IP and challenge details, the equivalent of the Entra sign-in log.
• Drive and Gmail logs. File views, downloads, sharing changes and message-level email events that show data access and exfiltration.
• Security Investigation Tool and Google Vault. The investigation tool correlates events and can take bulk action; Vault is the eDiscovery and legal-hold service for Gmail, Drive, Chat and Meet.

What each log proves

Retention and why logging must be on first

These logs are not kept forever, and several are not even on by default at the depth you will need. This is why the preservation request must go out immediately and why organisations should enable rich auditing before an incident, not after.

Investigating account takeover and business email compromise

Business email compromise (BEC) and account takeover follow a consistent pattern in these logs. Work the timeline from the first hostile sign-in outward, and remember that a password reset alone does not end the compromise.

1. Fix the reported event. Anchor on the known fact, for example a fraudulent invoice or a complaint of sent mail the user did not write, and note its date and time with the time zone.
2. Preserve before you search. Have the administrator place an eDiscovery hold (M365) or a Vault hold (Workspace) on the affected accounts so logs and mail cannot age out or be wiped during the investigation.
3. Triage the sign-in logs. In Entra sign-in logs or the Workspace Login log, look for authentication from unexpected countries, hosting or VPN IP ranges, impossible-travel pairs, and sign-ins where MFA was bypassed or satisfied from a new device.
4. Hunt for inbox rules. Roughly half of account-compromise incidents include a malicious mail rule. Check for rules that auto-forward to an external address, or that move or delete messages containing words such as invoice, payment or wire, used to hide the attacker's activity from the real user.
5. Check OAuth and token grants. Review the Entra consent and OAuth events or the Workspace Token audit log for third-party apps granted mailbox or drive access; this is a persistence mechanism that survives a password reset.
6. Review identity changes. Look in the admin and audit logs for new MFA methods, app passwords, added delegates or forwarding configured at the mailbox level around the time of intrusion.
7. Map data access and exfiltration. Use mailbox audit, Drive and SharePoint or OneDrive logs to establish what was actually read, downloaded or shared, which drives both the charge and the harm assessment.
8. Trace the fraudulent mail. Use message trace or the Gmail log to follow spoofed or forwarded payment-redirection emails to and from external parties.
9. Build the timeline and corroborate. Correlate sign-in, rule-creation and grant events into one chronology, and where the case is contested, validate the organisation's export against a provider-side request.

Preserving with eDiscovery and Vault legal hold

Preservation in these suites is built in. In Microsoft 365, an eDiscovery hold (Standard or Premium in Purview) freezes mailbox and site content in place even if a user deletes it. In Google Workspace, a Vault hold preserves Gmail, Drive, Chat and Meet data indefinitely for the held accounts. Place holds early, scope them to the relevant accounts and date ranges where possible, and document who set the hold and when.

Admissibility

Treat an audit-log export like any other digital exhibit. Record the exact query, the tool or portal used, the operator, and crucially the time zone, because cloud logs are often stored in coordinated universal time and a careless conversion can break a timeline. Preserve the original export file and hash it, work from copies, and keep a continuous chain of custody from the administrator or provider through to your analysis. Where the producer is the victim organisation, a witness statement from the administrator who ran the export, plus corroboration from the provider for key events, strengthens authenticity. In India, evidence served on the provider should be obtained through proper production process under the Bharatiya Nagarik Suraksha Sanhita, and electronic records should be accompanied by the certificate the Bharatiya Sakshya Adhiniyam requires for computer-generated records; align equivalent certification with your own jurisdiction's rules elsewhere.

Frequently asked questions

Should I ask the company or serve Microsoft or Google? If the company is the victim and cooperative, its administrators can produce richer logs faster, so start there with consent or a production order to the company. Serve the provider when the organisation is the suspect, is uncooperative, or you need provider-side corroboration or account-level data the tenant cannot give.

How far back will the logs go? Often not far. Entra sign-in logs may be only 7 to 30 days, message trace up to 90 days, and many Workspace and Purview logs around 180 days, depending on licence and configuration. Send a preservation request immediately rather than assuming the data will still be there.

The victim reset the password. Is the case over? No. Attackers commonly keep access through OAuth app grants, app passwords or hidden forwarding rules that a password reset does not remove. Check the token and consent logs and the mailbox rules, not just the credentials.

Is this the same as cloud-infrastructure evidence? No. This guide covers software-as-a-service productivity logs. Servers, storage buckets and virtual machines are infrastructure evidence and are covered in our separate AWS, Azure and Google Cloud guide.

This guide is part of our Guides for Investigators & Police reference series, covering Foundations, Mobile, Web & Social, Crypto, Cloud and AI.