Microsoft Purview Audit and eDiscovery: From Activity Records to Defensible Investigation

An Audit Event Is a Workload’s Account of an Operation

Microsoft Purview Audit brings together records for thousands of supported activities across Microsoft services. A record can identify an operation, actor, time, workload, target, result, client context, or other properties. The exact schema depends on the service and event type.

The Microsoft Purview Audit documentation describes the unified audit log as evidence for security, forensic, internal, compliance, and legal investigations. Read the word evidence carefully. An audit event can establish that a service recorded a particular operation with particular fields. It does not automatically establish why the person acted, whether every side effect occurred, or whether the service observed activity outside that operation.

Build interpretations from the operation’s documented meaning. Preserve raw identifiers and timestamps before normalization. Distinguish the actor from the target, application, delegated identity, and affected resource. A friendly activity name in the portal is useful for search, but the underlying record remains the source for precise reasoning.

Search Design Determines Which Evidence You Can See

An audit search uses a time range and optional filters such as users, activities, workloads, record types, files, sites, or other properties. Every filter narrows the evidence population. That is useful for focus, but it can silently remove activity when identifiers are incomplete or when the investigator assumes the wrong operation name.

Begin broad enough to validate the actor, workload, time, and record types, then refine. Account for time zones, service delay, aliases, application identities, administrative delegation, and operations that generate more than one record. Save the search definition and export the results with enough metadata to reproduce it.

Absence is not proof of nonoccurrence. Check whether the operation is audited, whether auditing was active, which license and retention applied, whether the period has expired, whether the event uses another workload, and whether the search constrained it away. Record these limits alongside the result.

Retention Determines Whether Yesterday’s Activity Is Still Investigable

Audit Standard and Audit Premium provide different retention and advanced capabilities. Microsoft currently documents 180-day retention for standard audit data, with Premium providing longer default retention for selected workloads, retention policies, higher-bandwidth access, and options that can extend eligible user audit data further with the required licensing.

Do not reduce this to a single number. Retention can differ by workload, record type, user licensing, policy, and non-user activity. Identify which identities and events a requirement depends on, then verify their actual retention before an incident. A one-year policy created today cannot reconstruct records already expired.

Align audit retention with investigation and legal requirements, while considering privacy and cost. Data Lifecycle and Records Management governs business content; audit retention governs activity records. Related purposes do not make the retention mechanisms interchangeable.

An eDiscovery Case Creates an Authorized Boundary

eDiscovery is not simply a larger search box. A case provides a controlled workspace for a defined legal, regulatory, or investigative matter. Membership, roles, data sources, hold policies, searches, review sets, exports, and case actions are tied to that boundary.

Write the matter’s purpose and scope before collecting. Identify custodians or data locations, relevant issues, time periods, preservation duties, exclusions, reviewers, and approval authority. Overcollection increases privacy exposure and review cost. Undercollection can omit relevant evidence. The search should follow the matter, not the investigator’s curiosity.

Cases can receive escalations from capabilities such as Insider Risk Management. Preserve the original alert and case reasoning, but do not allow the upstream risk label to predetermine the legal investigation. eDiscovery should evaluate relevant content under its own authorized scope.

Preservation, Collection, and Review Are Different Acts

A hold preserves content at specified locations according to the hold policy. It prevents relevant content from being permanently removed while the matter requires preservation. The Microsoft eDiscovery hold guidance emphasizes monitoring hold status and correcting errors; creating the policy is not enough if a location never applies it successfully.

Collection searches the chosen sources and processes potentially relevant content. Adding results to a review set creates a static population for analysis, query, tagging, review, and export. The Microsoft review set guidance describes review sets as case-contained document populations rather than live views of every later source change.

Keep these states visible. A held source is not fully collected. A search estimate is not a reviewed population. A review set is not automatically all relevant content. Each transition has criteria, processing reports, errors, and a person accountable for the decision.

Review Should Preserve Families, Context, and Competing Interpretations

A responsive document often cannot be understood alone. Email threads, attachments, cloud-file versions, Teams context, and related items can establish who knew what and when. Review-set grouping helps present related material, but reviewers must understand whether the system is grouping by thread, conversation, family, or another identifier.

Develop issue tags and review instructions before volume makes inconsistency expensive. Separate responsiveness, privilege, confidentiality, technical relevance, and substantive conclusions. A message can be responsive without proving the allegation. A technical artifact can be important even when its author never saw it.

Protected content requires advance planning. The existing encryption readiness resource explains why recovery and compliance access should be validated before broad encryption deployment. An investigation is the wrong time to discover that critical content cannot be processed or reviewed.

Make Every Investigative Conclusion Reproducible

A defensible investigation can show how it moved from sources to results. Retain the case authorization, members, hold definitions and status, searches, collection statistics, processing reports, review-set changes, tags, reviewer decisions, exports, and known errors. Audit privileged case activity as part of the matter.

When content leaves Purview, preserve export metadata and integrity information, document transfer and storage, restrict access, and maintain the link between the exported item and its review decision. An export does not end chain-of-custody responsibility; it moves that responsibility to another system and owner.

Conclusions should distinguish records from interpretation. Audit and content evidence can establish activity and communication. The investigator assesses relevance, intent, and consequence. Missing sources, expired logs, processing exceptions, inaccessible encryption, and ambiguous identities belong in the final uncertainty statement, not in a hidden technical appendix.