Compliance
SOC 2
System and Organization Controls 2
SOC 2 (System and Organization Controls 2) is a widely used US-originated attestation framework, developed by the American Institute of Certified Public Accountants (AICPA). Under it, an independent auditor evaluates and reports on a service organisation's controls relevant to one or more of five defined Trust Services Criteria: security (mandatory in every SOC 2 report and often called the common criteria), availability, processing integrity, confidentiality, and privacy.
Why SOC 2 matters in a Microsoft estate
SOC 2 matters because customers, resellers, and procurement teams need evidence that controls are defined, operated, and reviewable. A useful glossary definition should help a reader connect the term to audit preparation, policy work, or repeatable assurance activity.
How SOC 2 shows up in practice
The organisation itself selects which of the latter four criteria beyond security are actually relevant and in scope for its report. Unlike a certification such as ISO/IEC 27001, SOC 2 does not result in a certificate; it results in an attestation report written by the auditing CPA firm. It comes in two distinct types that are frequently confused: a Type I report assesses whether the described controls are suitably designed at a single point in time, while a Type II report, generally considered materially stronger and what most enterprise customers actually expect, assesses whether those controls operated effectively over an observation period, typically six to twelve months, based on evidence sampled throughout that window rather than a single snapshot.
SOC 2 reports are also not public documents in the way a certification badge is; they are shared under NDA directly with customers and prospects who need assurance, usually via a dedicated portal like a trust centre. That means SOC 2 status functions primarily as a sales and procurement enablement tool for organisations selling software or services to other businesses, particularly in the US market and increasingly in UK enterprise SaaS procurement, rather than a broad public trust signal in the way a website badge might imply. For a UK-based Microsoft 365 or Azure-focused vendor or MSP, SOC 2 most commonly arises when selling into US-headquartered customers or customers with US-influenced vendor risk processes, where it is often requested alongside or instead of ISO/IEC 27001.
Organisations pursuing both frequently find substantial control overlap, since both frameworks expect similar underlying practices around access control, change management, monitoring, and incident response, even though SOC 2's criteria structure and reporting format differ meaningfully from ISO's clause-and-Annex-A structure. A common evaluation mistake is treating any SOC 2 report as equivalent assurance regardless of type or scope. A Type I report, a report covering only the security criterion with no availability or confidentiality commitments, or a report with a heavily carved-out or narrowly defined system description, all represent materially less assurance than a Type II report with a broad scope and a clean opinion. Reviewing the actual report, including its scope, the auditor's opinion, and any noted exceptions, rather than relying on the vendor's claim of having "a SOC 2", is standard due diligence practice before relying on it.