Microsoft 365 Compliance and Audit Readiness: The Purview Evidence Surface Regulated Buyers Get Wrong

The audit's first request inside Microsoft 365 A regulated mid-market organization receiving a SOC 2 Type II report request, a HIPAA OCR letter, a HITRUST assessment scope, or a regulator's first inquiry rarely starts with a question about Defender for Cloud or Sentinel. It starts with a content question. Produce the email a named workforce member sent to a named external party in a named date range. Produce the SharePoint document set that holds patient-care plans for the named program over the prior twelve months. Produce the Teams conversation between two named workforce members about the named patient. Produce the records of disclosure for the named patient under the named authorization. These are not infrastructure questions. They are content-evidence questions, and the evidence surface that answers them inside Microsoft 365 is Microsoft Purview. The same product line that ships with most regulated mid-market M365 tenants, frequently underused, frequently misconfigured, frequently treated as a license cost with no operational discipline behind it, is the compliance evidence library the audit will walk first. We see the same pattern across every regulated M365 engagement. The licensing is in place; the workloads are partially configured; the documentation that ties the configuration to the regulator's evidence request does not exist. The audit findings cluster in a small set of places: retention labels deployed without the corresponding policies, eDiscovery cases never tested under realistic load, audit log retention at the standard tier when the assessment cycle requires longer, communication compliance configured but not tuned, insider risk management licensed but never enabled. This Field Guide is the configuration baseline. It walks the five Purview workloads an audit asks for, the specific audit-side question each one has to answer, the configuration settings that produce the right evidence, and the documentation artifact that turns the technical configuration into a defensible evidence library. The five workloads, in audit-walk order Workload 1, Audit (Standard and Premium) Microsoft Purview Audit (formerly the Unified Audit Log) is the activity-record evidence surface. Every signal-relevant action across Exchange, SharePoint, OneDrive, Teams, Entra ID, Power Platform, and Defender flows into the audit log. The audit-side question it answers: who did what, when, with which content, in which application. Standard tier retention is ninety days. Audit Premium extends to one year by default, with up to ten years available on appropriate licenses. Premium also surfaces a set of "high-value" events, MailItemsAccessed, Send, SearchQueryInitiatedExchange, SearchQueryInitiatedSharePoint, that are not captured at the Standard tier. For most regulated mid-market organizations, the audit-passing baseline is Audit Premium with at least one-year retention, with the long-tail retention extension on records that fall under multi-year obligations (HIPAA breach investigation, financial-services record-keeping, clinical-trial data integrity). The configuration evidence: the Audit configuration export showing the active tier, the retention policy applied, the high-value events enabled, and the role assignments that authorize audit log search. The documentation artifact: a written audit-log query path, the named query the compliance function runs to produce the typical evidence package, with the parameters the auditor will ask for substituted in. The most common finding: Audit Standard tier in place, with a downstream SIEM forwarding receiving events in real time. The SIEM is a useful supplement; it is not the evidence the regulator asks for. The regulator's request is for the M365 audit log extract, not the SIEM extract. License the right tier. Workload 2, Information Protection (sensitivity labels) Microsoft Purview Information Protection is the data-classification surface. Sensitivity labels, applied automatically by trainable classifiers, applied manually by the workforce, or applied by Microsoft 365 services through label inheritance, produce the structured metadata that downstream Data Loss Prevention, retention, and encryption policies depend on. The audit-side question they answer: for any record in the regulated workload, what is its classification, who applied it, and how is it being protected as a result. The audit-passing baseline for a regulated mid-market organization is a labeling taxonomy that names the regulated record class explicitly (PHI, PCI, HITRUST in-scope, regulated proprietary), automated labeling rules for known patterns (HIPAA identifiers via the named pattern matchers, PCI patterns via the same), label inheritance configured on emails and documents so the classification follows the content, encryption applied at the label level for the highest-tier records, and a recurring Information Protection report quantifying label coverage across the regulated workload. The configuration evidence: the labeling taxonomy export, the auto-label policy export, the label-encryption configuration, and a recent Information Protection report. The documentation artifact: a one-page labeling taxonomy reference for the workforce, plus a one-page audit-side reference mapping each label to the framework citations and the policies it triggers downstream. Most common finding: labels deployed with no auto-labeling and minimal manual labeling discipline. The taxonomy exists; the coverage does not. The Information Protection report shows single-digit-percentage label adoption on the regulated record set. Workload 3, Data Lifecycle Management (retention and records) Purview Data Lifecycle Management is the retention surface. Retention labels and retention policies produce the structured retention behavior that meets the obligation horizon for each regulated record class. The audit-side question they answer: for the named record class, how long is it retained, where is it retained, what triggers deletion, and what is the chain of custody on records under hold. The audit-passing baseline: a retention taxonomy aligned to the legal-and-regulatory retention obligations the organization carries (HIPAA's six-year minimum on covered records, financial-services retention on transactions, contract retention obligations, jurisdiction-specific retention rules); retention labels published and applied through manual workflows or auto-apply policies; retention policies covering the workload-level surfaces (Exchange, SharePoint, OneDrive, Teams, Yammer); records management configured for the highest-obligation classes with the records-hold chain of custody; a written retention schedule that maps each record class to its label, its policy, its destination, and its disposition. The configuration evidence: the retention label and policy export, the records management configuration, and the disposition review log. The documentation artifact: the written retention schedule as a single referenceable document, signed off by the compliance function and updated annually. Most common finding: retention labels deployed without retention policies enforcing them at the workload level. The label exists on a small percentage of content; the policy that should be retaining at the SharePoint-site or mailbox level is not configured. The audit-side answer to "how is the named record class retained" is then "we labeled some of it." That answer does not pass. Workload 4, eDiscovery (Standard and Premium) Purview eDiscovery is the legal-hold and content-search surface. Standard eDiscovery covers basic case management, custodian holds, content searches, and exports. eDiscovery Premium adds advanced indexing, machine-learning-based review, custodian communications, and the case-management workflow expected in litigation-heavy and regulator-investigation-heavy contexts. The audit-side question it answers: given a named investigation scope (a custodian, a date range, a content pattern), produce the relevant content set with chain of custody preserved. The audit-passing baseline: eDiscovery Standard at minimum across the tenant (Premium for organizations with a meaningful litigation footprint or with regulator investigations as an expected workload), case templates configured for the typical investigation patterns (HIPAA breach response, OCR investigation response, internal investigation response), legal-hold workflows tested and documented, custodian-notification templates aligned to the legal team's standard, and a recent test-case record showing the workflow was exercised end to end. The configuration evidence: the eDiscovery role assignments, the case templates, the recent case log, and the test-case artifact. The documentation artifact: a written eDiscovery procedure that names the workflow from notification to export, with the role assignments, the custodian-communication templates, the export format, and the chain-of-custody record-keeping practice. Most common finding: eDiscovery licensed but never exercised. The first time the workflow runs is in response to an actual regulator request, with predictable consequences for response time, evidence completeness, and the audit committee's confidence. Test the workflow on a fabricated case quarterly; document the exercise. Workload 5, Communication Compliance and Insider Risk Management The fifth workload is two related products that walk in roughly the same audit step. Communication Compliance, the policy-driven monitoring of internal communications for harassment, sensitive-information leakage, regulatory-language patterns (financial-services language, healthcare language), and Insider Risk Management (signals across Microsoft 365 endpoints, Defender for Cloud Apps, and Entra ID that surface workforce-side risk patterns). The audit-side question they answer: what controls does the organization operate to detect workforce-side conduct that violates policy or regulation, and what is the workflow when a signal triggers. The audit-passing baseline depends on the regulatory context. For organizations subject to FINRA-style supervisory obligations, communication compliance is non-optional and the policy library is prescriptive. For healthcare organizations, the baseline is lighter, communication compliance configured for HIPAA-language patterns, insider risk management configured for the predictable PHI-exfiltration signals (mass downloads, off-network egress, departing-employee patterns). For regulated SaaS organizations, insider risk management for source-code and customer-data exfiltration is a frequent inclusion. The configuration evidence: the communication compliance policy export, the insider risk management policy state, recent alert and case logs, and the disposition records. The documentation artifact: the written supervisory or insider-risk procedure with role assignments, escalation triggers, and case-disposition standards. Most common finding: insider risk management licensed but disabled, with the assumption that the workload's signals would be redundant with Defender for Cloud Apps or Sentinel. The two products have meaningful overlap, but the audit asks for the M365-native artifacts when the question is M365-scoped, and the absence of insider risk records is a finding the SIEM cannot answer for. The evidence library that holds the five together The five workloads above produce a meaningful volume of configuration and operational evidence. Without a structuring artifact, the evidence is scattered across Purview portals, Exchange admin centers, Defender consoles, and policy exports. The audit finding shows up at the moment the evidence is requested, when the compliance function has to assemble the response under time pressure and discovers the gaps. The structuring artifact is the M365 compliance evidence library. The library is a single document, updated quarterly, that names every workload, the configuration evidence that proves it operational, the documentation artifact that ties the configuration to the framework citations, and the location where the auditor or the compliance function can pull each artifact on demand. A typical evidence library structure: Section 1: Audit log evidence. Tier, retention, query path, role assignments, recent query records. Section 2: Information Protection evidence. Taxonomy, auto-labeling configuration, encryption configuration, coverage report, recent label-applied report. Section 3: Retention evidence. Schedule, labels, policies, records management, disposition log. Section 4: eDiscovery evidence. Procedure, case templates, role assignments, recent test-case artifact. Section 5: Communication compliance and insider risk evidence. Policies, recent alert log, case dispositions, supervisory procedure. Section 6: Cross-workload artifacts. Role assignments across the Compliance Center, the configured retention obligations, the audit committee reporting cadence. The library is the artifact a regulated buyer hands the SOC 2 auditor, the HITRUST assessor, the HIPAA investigator, and the audit committee. It is the part of the audit posture that compounds, once it is structured, the next assessment cycle becomes evidence reaffirmation rather than evidence collection. How the workloads tie together with the rest of the audit surface The Purview evidence library is one part of a regulated mid-market organization's broader audit posture. The identity and tenant-level controls live in the M365 + Entra ID Hardening Field Guide. The Azure-side controls live in the Azure Security Review Method. The framework-level posture for SOC 2 Type II first-time customers lives in the SOC 2 Type II Field Guide. The HITRUST r2 roadmap lives in the HITRUST Field Guide. The HIPAA AI architecture reference lives in the HIPAA AI Architecture Field Guide. The audit walks all of them as a single surface. The buyer who treats them as a single evidence package, identity controls, cloud-resource controls, compliance-content controls, AI-architecture controls, framework-level controls, produces an audit posture that survives multiple cycles. The buyer who treats them as separate workstreams produces gaps where the surfaces meet. What we recommend A regulated mid-market organization on Microsoft 365 should run the five-workload Purview review on a defined cadence, annually at minimum, with a focused mid-cycle review on any workload where the tenant's footprint changed materially (a new regulated record class introduced, a new acquisition with M365 resources merged into the tenant, a regulatory change that altered the retention horizon). For organizations preparing for an audit in the next ninety days, the right move is to assemble the evidence library now, identify the gaps against the audit-passing baseline, and close the gaps on a remediation calendar that lands inside the audit window. The orgs that operate in this mode reduce audit-cycle effort and produce an artifact the assessor reads as the answer to the controls walkthrough rather than the start of the gap analysis. The Purview workloads are not exotic. The licenses are typically already in place. The discipline that turns the licenses into a defensible evidence library is the missing piece. Build the library before the regulator's first request.