Is Microsoft 365 SOC 2 Compliant?
Microsoft 365 holds a semi-annual SOC 2 Type 2 report for its cloud services — but that report covers Microsoft's infrastructure, not how your organization has configured its tenant.
Microsoft 365 shows up on nearly every vendor security questionnaire. Email lives in Exchange Online, documents in SharePoint, video calls in Teams, file sync in OneDrive. For most companies it's not a productivity tool, it's the operating environment. That proximity to sensitive data is exactly why customers, auditors, and partners ask about it. The question they usually ask is some version of: "Does Microsoft 365 have a SOC 2 report?"
Yes. The longer answer covers what that report proves and, more usefully, what it leaves entirely on your plate. Conflating the two is one of the most common gaps I see during SOC 2 readiness work.
Microsoft 365 does hold a SOC 2 Type 2 report
Microsoft publishes SOC 2 Type 2 attestation reports for its commercial cloud services, and Microsoft 365 is included in that scope alongside Azure and Dynamics 365. A few things are worth knowing before you go looking for it.
Semi-annual cadence. Microsoft releases new SOC 2 reports twice a year, with audit periods ending on March 31 and September 30. Each report covers a rolling 12-month window. Bridge letters are available for the periods between report releases, which matters when your own audit window doesn't align cleanly with Microsoft's report cycle and you need continuous coverage documented.
Type 2 only. Microsoft issues Type 2 reports for its commercial cloud services, not Type 1 snapshots. That's the right call for infrastructure at this scale, and it gives the report meaningful evidentiary weight. The difference between Type 1 and Type 2 matters both for reading a vendor's report and for planning your own audit.
Trust Services Criteria covered. Microsoft's SOC 2 Type 2 for cloud services addresses Security, Availability, Processing Integrity, and Confidentiality. The Security criterion (the Common Criteria) is what most buyers reference. Availability matters for contracts with uptime commitments; Confidentiality matters for anything governed by data handling obligations.
Confidential, not public. Microsoft distributes its SOC 2 reports under terms of use, not a separately negotiated NDA. But the reports are marked confidential. You can share them with your auditors and use them for internal vendor due diligence; you can't post them publicly or forward them freely. Read the terms on download; they're specific about permissible use.
How to get the report from the Service Trust Portal
Microsoft's compliance reports live at servicetrust.microsoft.com. You'll need to sign in with a Microsoft 365 organizational account associated with an active subscription or a free trial. A personal Microsoft account won't work; it needs to be a work or school account tied to an M365 tenant.
Once signed in:
- Go to Trust Documents, then Audit Reports
- Click the SOC tab in the filter panel
- Filter by Microsoft 365 (older reports may appear under Office 365)
- Download the most recent SOC 2 Type 2 report and any applicable bridge letters for your coverage window
No sales process, no manual request. If your organization has an active Microsoft 365 Business or Enterprise subscription, you can pull the document today.
Microsoft also publishes a SOC 3 report for its cloud services, and that one is publicly available without authentication. It confirms an independent auditor issued a clean opinion on Microsoft's controls, useful for a customer who just needs that confirmation. For your own SOC 2 audit, or for genuine vendor due diligence, the full SOC 2 Type 2 is what you actually need. The SOC 3 doesn't include the auditor's control descriptions or test results.
What the report actually covers
Microsoft's SOC 2 is an auditor's opinion on the controls Microsoft operates to keep its cloud infrastructure secure and running. The scope is substantial: data center physical security, environmental controls (power, cooling, fire suppression), network architecture and redundancy, hardware lifecycle procedures, and the platform-level isolation that prevents one tenant's workloads from accessing another's. On the operational side, it covers Microsoft's employee access controls for production systems, change management discipline, and incident response at the platform level.
What it says nothing about is the Microsoft 365 tenant your organization runs on top of that infrastructure. How you've configured Entra ID, who holds Global Administrator roles, whether Conditional Access policies are enabled and what they enforce, how SharePoint external sharing is set, whether audit logs are retained for long enough to cover your audit window — none of that is in Microsoft's report. That layer belongs entirely to you.
This is how every major cloud provider works. What makes M365 slightly more complex is the breadth of services: email, calendaring, documents, video, identity, endpoint management, each with its own configuration surface. That's a wide gap to own.
The controls that belong to your team
This is where SOC 2 findings tend to concentrate for organizations running on Microsoft 365. The specific controls depend on your scope, but these areas appear consistently.
Conditional Access policies. Entra ID Conditional Access is how you enforce MFA, block legacy authentication protocols, and require device compliance before granting access to organizational resources. The catch: Conditional Access policies don't exist by default in any form that satisfies SOC 2. Your team has to create them. Auditors ask to see the actual policy configuration (exportable as JSON from the Entra admin center) plus sign-in logs showing those policies applying during the audit period. A policy that exists but exempts half the user base, or a policy that was created after the audit window started, reads as a gap. What the auditor is testing is whether MFA enforcement was continuous, not just enabled.
Privileged role minimization. Global Administrator is the highest-privilege role in Microsoft 365. It has unrestricted access across every service in the tenant. Most organizations have more Global Admins than they need; it's easy to assign and rarely cleaned up. The least-privilege principle applies here: assign scoped roles (Exchange Administrator, SharePoint Administrator, Teams Administrator) for day-to-day administration, and reserve Global Admin for break-glass scenarios with the account count kept minimal. Auditors pull the role assignment list and check authentication methods for every privileged account. If your Global Admins don't have phishing-resistant MFA configured, that's a finding.
External sharing settings. Microsoft 365 defaults toward sharing. SharePoint and OneDrive can, depending on your tenant configuration, generate anonymous sharing links accessible to anyone with the URL, or allow sharing to any external email address. Those defaults are appropriate for broad collaboration scenarios, not for a compliance environment. Tighten them deliberately: restrict external sharing to specific verified domains, disable or limit anonymous link creation based on your data classification, and document those settings as a formal control.
Audit log retention. The unified audit log in Microsoft 365 captures admin activity, user sign-ins, file access events, Teams messages in certain configurations, DLP policy matches, and sensitivity label changes. Default retention varies by license tier: some plans retain 90 days, enterprise plans extend to a year or beyond. For a SOC 2 audit, retention needs to cover the full audit period plus whatever lead time your auditor works in. Configure retention explicitly through Microsoft Purview rather than assuming your license tier covers you, and verify the services your auditor will sample are actually flowing into the log. Auditors frequently request samples of specific event types; if those events aren't retained, you can't produce them.
Offboarding completeness. When employees leave, Microsoft 365 offboarding should be systematic: disable the account in Entra, revoke active sessions, remove licenses, convert the mailbox to a shared mailbox or apply a retention hold if needed before account deletion. The order matters, because deleting an account before preserving the mailbox contents can complicate legal or compliance holds. This is an access termination control. Auditors test it by pulling a sample of departures from the audit period and verifying the steps happened in the right sequence and within your policy's stated timeline.
Using Microsoft's report in your own SOC 2 audit
When you go through your own SOC 2 Type 2 audit, your CPA will ask about the controls you've delegated to subservice organizations, Microsoft among them. This means more than naming Microsoft as a vendor. It requires obtaining their actual SOC 2 report, reviewing which controls you're relying on Microsoft to operate, confirming those controls appear in the report and were operating effectively during the relevant period, and documenting that review as a formal vendor risk activity.
The review needs to be specific to the services you use. Microsoft's SOC 2 scope covers Azure, Dynamics 365, Power Platform, and multiple Microsoft 365 services together; verify that the specific workloads your organization depends on (Exchange Online, SharePoint Online, Teams, OneDrive) appear in the report period you're referencing, and don't assume scope is automatic.
A structured review process makes this repeatable across vendors and audit cycles. The vendor risk assessment checklist covers what to document when reviewing subservice organization reports, including how to map the controls you're relying on to what the report actually attests. Microsoft 365 is almost always the first vendor on that review list for office-productivity-dependent organizations. Building the habit early (download the report, document the review, store the evidence) means you're producing something your auditor can actually test, not reconstructing it from memory six months later.
The vendor risk guide covers how auditors evaluate subservice organization relationships and where documentation gaps typically appear.