What is the difference between Microsoft’s SOC 2 report and a tenant’s SOC 2 evidence in Microsoft 365?

Why This Matters for Security Teams

Microsoft’s SOC 2 report answers a vendor assurance question: did Microsoft operate its cloud services and internal controls in line with the stated criteria. A tenant’s SOC 2 evidence answers a different question: did the organisation configure and operate Microsoft 365 in a way that actually enforces MFA, role separation, logging, retention, and offboarding. That distinction matters because auditors do not certify intent, they test the control environment that exists in the tenant.

This is where teams often over-rely on vendor attestations and under-collect operational evidence. A clean third-party report does not prove that privileged roles were limited, that guest access was reviewed, or that stale accounts were removed on time. NHIMG’s research shows that only 20% of organisations have formal offboarding and API key revocation processes, and even fewer rotate credentials consistently, which is exactly the kind of gap that tenant evidence must expose. See Ultimate Guide to NHIs — What are Non-Human Identities for the broader governance context, and compare it with ENISA Threat Landscape guidance on identity-driven risk.

In practice, many security teams discover the difference only after an auditor asks for tenant-level proof that Microsoft never had to provide.

How It Works in Practice

Microsoft’s SOC 2 report is a control assertion over Microsoft’s own environment. It is useful for assessing the provider, but it is not a substitute for tenant-side evidence. In Microsoft 365, the tenant is where your organisation sets conditional access, configures MFA, assigns administrative roles, enables mailbox auditing, defines retention, and governs guest access. Those tenant choices are what auditors sample when they want to see whether the shared responsibility model is being met.

Operationally, the difference shows up in the evidence pack. Microsoft’s report may support vendor due diligence, but your tenant evidence usually includes admin role assignments, conditional access policy exports, sign-in logs, privileged access reviews, offboarding tickets, group membership review records, and proof that sensitive settings were enforced over time. For identity-heavy environments, the same logic applies to non-human identities: service accounts, app registrations, and API permissions require tenant-owned evidence, not vendor attestations. NHIMG’s guidance on Microsoft Midnight Blizzard breach shows how identity compromise can become a tenant responsibility issue long before a vendor report changes.

Teams should also distinguish between design and operation. A control can be configured correctly today and still fail audit if there is no proof it was monitored, reviewed, and enforced during the period under review. That is why auditors often ask for dated exports, change records, and samples from the audit window rather than screenshots from the week before fieldwork. Current guidance suggests treating Microsoft’s report as upstream assurance and tenant evidence as the actual control outcome. For identity and secrets handling, the risk pattern is reinforced by attacks such as the JetBrains GitHub plugin token exposure case, where operational control failure mattered more than platform promises.

These controls tend to break down when Microsoft 365 is managed by multiple teams without a single evidence owner because proof becomes fragmented across security, IT, and compliance functions.

Common Variations and Edge Cases

Tighter tenant evidence collection often increases administrative overhead, requiring organisations to balance audit readiness against day-to-day operational speed. That tradeoff becomes sharper in large Microsoft 365 estates, mergers, or environments with many subsidiaries, where each tenant may have different baselines, delegated admins, and exception processes.

There is no universal standard for every audit request, but a practical pattern is emerging. If the control is Microsoft-operated, such as physical datacentre safeguards or core service resilience, Microsoft’s SOC 2 report may be the primary artifact. If the control is tenant-operated, such as MFA enforcement, privileged role governance, or data retention, the organisation needs its own evidence. In hybrid cases, both may matter. For example, a tenant may rely on Microsoft for service availability while still needing internal proof that access reviews, least privilege, and logging were enforced locally.

• Use Microsoft’s report for vendor due diligence and inherited control support.
• Use tenant evidence for access, configuration, monitoring, and offboarding controls.
• Keep dated exports and review records for the exact audit period.
• Document exceptions so auditors can see compensating controls and expiry dates.

For organisations managing non-human identities in Microsoft 365 adjacent workflows, this boundary becomes even more important because API keys, app registrations, and delegated permissions are tenant-owned assets. See Code Formatting Tools Credential Leaks and Microsoft Entra ID Flaw for examples where tenant-side identity controls determined the security outcome.

In practice, the cleanest audits fail when teams can prove Microsoft was audited but cannot prove their own tenant was controlled.

Related resources from NHI Mgmt Group

• What is the difference between attack surface management and NHI governance?
• What is the difference between reviewing human access and reviewing NHIs?
• What is the difference between role-based access and API key governance for NHI security?
• What is the difference between human IAM controls and NHI governance?