.svg){kind=logo}
A customer's security team sends over a vendor questionnaire. Question four asks whether the cloud infrastructure provider is SOC 2 compliant. The workload runs on Azure, so the answer is "yes," and the form moves on to question five.
That answer takes seconds to give, and it feels like a formality. But when an auditor asks the same question during the company's own SOC 2 audit, "yes" on its own doesn't hold up. Auditors expect the actual Azure SOC 2 report, not a quick self-serve download the way AWS handles its own SOC 2 report through Artifact, and they expect clarity on exactly what it does and doesn't cover. That's the gap this article closes. Here's the direct answer, upfront:
This article covers:
- What's actually inside the report, and who audits it
- Why "Azure is compliant" isn't the same as being compliant
- The carve-out method an auditor will actually use
- SOC 1 vs. SOC 2 vs. SOC 3, and what Azure DevOps handles separately
- Shared responsibility, mapped to the real Trust Services Criteria codes
- How to actually get the report, bridge letters included
- Reading the report's Management Response and User Entity Responsibilities sections
- What changes for companies also running AWS
- Common mistakes and the questions that come up most
What's Actually Inside Microsoft's Azure SOC 2 Report
A SOC 2 Type 2 report isn't a certificate. It's an auditor's opinion on whether a company's controls actually worked consistently over a period of time, not just on the day someone checked.
For Azure, that means an independent auditor examined Microsoft's controls over security, availability, processing integrity, and confidentiality, and tested whether they held up across the audit window. Azure's SOC 2 report covers four criteria out of the full set of SOC 2 trust services criteria. Microsoft's own compliance page doesn't list privacy as in scope.
To be precise: that reflects what Microsoft's public page states, not a claim that Azure "excludes" privacy in some stronger sense. Where privacy is material to a specific use case, it's worth confirming directly with Microsoft rather than assuming either way.
One detail worth flagging for audit planning: Microsoft reissues the report semi-annually, for periods ending March 31 and September 30. That's a different rhythm than AWS uses, and it matters the moment a customer-supplied report needs to be checked for currency.
Who Audits the Azure SOC 2 Type 2 Report, and How
The audit runs under SSAE 18 (specifically AT-C 105 and 205) and AICPA TSP Section 100, using the 2017 Trust Services Criteria including the March 2020 updates. That's the same standard most enterprise cloud providers are audited against, so nothing unusual there.
What's easy to miss is that Azure's SOC 1 Type 2 report exists in parallel, on a quarterly cadence, and is aimed at a different audience: auditors focused on financial reporting controls, relevant to SOX or GLBA contexts. Different report, different reader, different rhythm.
Both the SOC 1 and SOC 2 reports are issued as Type 2 only. Microsoft doesn't reference a separate Azure "Type I" report anywhere in its documentation. For teams less familiar with the distinction, it's worth understanding the difference between Type 1 and Type 2 before going further.
Why Azure SOC 2 Compliance Isn't the Whole Story
The misconception that shows up in a failed audit, almost word for word, is: "we're on Azure, so we're SOC 2 compliant."
That confusion isn't hypothetical. A thread on Microsoft's own Q&A forum shows it directly: someone asks, plainly, whether their Azure subscription itself is SOC 2 Type 2 compliant, or where they can get a compliance report for their subscription.
The official answer simply points to where to download Microsoft's report. It never clarifies that Microsoft's attestation and the asker's own compliance are two different things, leaving the exact confusion we are discussing in this article.
Azure's report proves Microsoft's infrastructure controls held up. It says nothing about how identity and access management is configured, whether logging captures what an auditor wants to see, or whether access is reviewed on a schedule. When an auditor asks for evidence of access reviews, incident response, or vulnerability management, Azure's report can't answer for that; only the company's own controls and evidence can.
That tension is exactly what the shared responsibility model, covered further down, is built to resolve.
Azure Subservice Organization SOC 2: Carve-Out vs. Inclusive Method
This distinction is often glossed over, even though it's one of the more useful things to understand about how Azure fits into a company's own audit.
When a SOC 2 auditor examines a company, Azure sits underneath it as what auditors call a subservice organization; the same lens applied to any vendor in a third-party risk lifecycle. Auditors handle that relationship one of two ways.
The carve-out method excludes Azure's controls from the report's scope entirely. The auditor notes reliance on Azure's own SOC 2 report as evidence for that carved-out portion. This is what nearly every cloud-hosted SaaS company actually gets.
The inclusive method tests Azure's controls as if they were part of the company's own environment. In practice, this is rare and largely impractical, since no auditor independently tests Microsoft's global infrastructure as part of a single company's SOC 2 engagement. It exists as an option; almost nobody uses it for a hyperscale cloud provider.
The part that matters most: if an auditor uses the carve-out method (which they likely will) Azure's own SOC 2 report still has to be produced as evidence that the carved-out controls are covered. Getting that report isn't background reading. It's a required piece of audit evidence.
The carve-out method is really just how an auditor formalizes "Microsoft owns this" versus "the company owns this" inside a specific report.
Microsoft Azure SOC 2 vs. SOC 1 and SOC 3: What Each Proves
Three reports, three different jobs. Here's how they break down:
One detail worth knowing: the SOC 2 Type 2 report is bundled together with the CSA STAR Attestation and Germany's C5:2020 framework in the same package. If a customer or auditor asks for either of those specifically, one request covers all three.
For a fast answer on a vendor security questionnaire, the Azure SOC 3 report is the more practical reference point. It's the public summary of the same audit, with no NDA required and no waiting on portal access.
Azure SOC 2 Report Scope: What's In (and What Azure DevOps Handles Separately)
The main report covers Azure itself, Azure Government, Dynamics 365, select Microsoft 365 services, and Power Platform.
Azure DevOps deserves its own mention here, because it's genuinely a separate offering. It has a standalone SOC 1 Type 2 and SOC 2 Type 2 report, completely separate from the main Azure report. If a CI/CD pipeline runs on Azure DevOps, the main report won't cover it.
The Azure DevOps report specifically can be requested at AzureDevOpsSOCReport@microsoft.com if it doesn't show up in Service Trust Portal access by default.
This matters more for teams pursuing SOC 2 and ISO 27001 together, since CI/CD pipelines often need both frameworks (SOC 2 and ISO 270001) covered at once. Evidence from both the main Azure report and the separate Azure DevOps report is needed, since pipeline compliance doesn't live in just one of them. It's an easy thing to miss until an auditor asks why the evidence only covers half the infrastructure. For the ISO 27001 side of that comparison, a separate breakdown covers how the two frameworks overlap and where they don't.
Beyond the DevOps carve-out, per-service scope isn't fully public. Microsoft's own documentation states plainly that different audits can have different services in scope, and the itemized list lives inside the report's own appendix, behind the same NDA-gated access. A specific service shouldn't be assumed covered just because it sounds like it should be.
This is also where azure openai soc 2 compliance belongs, since it's a frequent question. Microsoft's public scope summary lists broad categories, Azure, Dynamics 365, Power Platform, select Microsoft 365 services, without naming Azure OpenAI Service specifically, one way or the other. The definitive per-service answer requires the gated report; Microsoft's Foundry and OpenAI data privacy documentation is the appropriate reference for what is publicly stated in the meantime.
One more thing worth stating plainly, since several teams conflate it: PCI DSS is not bundled into the SOC 2 report the way CSA STAR and C5:2020 are. It's a separate attestation, obtained from a different section of the Service Trust Portal, with its own auditor.
Azure Shared Responsibility SOC 2: Who Owns Which Controls
The logic mirrors the AWS shared responsibility model, though the specific tools differ.
In short: Microsoft is responsible for the security of Azure. Customers are responsible for security in Azure. Same logic as AWS, different tools underneath.
Mapping Azure Services to the SOC 2 Trust Services Criteria
A useful reference that's often missing from similar resources: a real azure soc 2 controls mapping that goes down to the actual Trust Services Criteria codes, not just loose categories like "IAM" or "logging."
One honest caveat: this mapping applies standard SOC 2 control codes to Azure's native tools, intended to support control implementation on the customer side. It is not a claim about what Microsoft's own attestation report actually tests.
How to Actually Get the Azure SOC 2 Report
To download the Azure SOC 2 report:
- Go to the Microsoft Service Trust Portal.
- Sign in with a Microsoft Entra organizational account tied to an active Azure, Microsoft 365, or Dynamics 365 subscription. A trial subscription works fine for this.
- Review and accept the Microsoft Non-Disclosure Agreement for Compliance Materials. This step is required before the SOC 1 and SOC 2 downloads unlock.
- Download the report. It's marked "Microsoft Confidential," so it can't be redistributed once downloaded.
- If the Azure DevOps report is needed specifically and isn't visible in the portal, request it directly at AzureDevOpsSOCReport@microsoft.com.
- For a faster path that skips the NDA, the public SOC 3 report covers a quick vendor questionnaire answer. It won't substitute for the full report in an actual audit, but it's often enough for a first pass.
This process involves more friction than AWS's self-serve Artifact flow. It's worth building that extra step into the audit timeline rather than discovering it the week before the audit kicks off.
One detail often missing from other resources on this topic, despite being clearly documented by Microsoft: bridge letters exist, and they matter. The rules for when a report is still valid versus when a bridge letter is needed apply here just as much as they do for a company's own SOC 2 report.
Reading the Azure SOC 2 Report: What "Management Response" and "User Entity Responsibilities" Actually Mean
Microsoft's documentation identifies where these two sections sit in the report, but it doesn't explain what they mean or how to use them. If the report format itself is unfamiliar, it helps to first see what a SOC 2 report looks like end to end for context.
Management Response is Microsoft's own written reply to any exceptions or qualifications the auditor noted. This section is worth reading first as it clarifies whether a flagged exception is a genuine issue or something Microsoft has already remediated and explained.
User Entity Responsibilities, sometimes labeled Complementary User Entity Controls or CUECs, is the report's own explicit list of what Microsoft assumes the customer is handling. It's essentially the shared responsibility model from above, written directly into the audit document in the auditor's own language.
Checking this list line by line against actual practice is worthwhile. Anything on Microsoft's list that isn't being done is a gap and exactly the kind of gap an auditor will find first, because they know to look for it.
The carve-out method, the shared responsibility model, and this CUEC section of the actual report describe the same boundary from three different angles.
Turning the Azure SOC 2 Report Into Your Own Audit Evidence
The report serves as evidence for infrastructure-layer criteria; it should be paired with separate evidence for everything in the customer-owned bucket.
Microsoft provides a genuine tool for this. Defender for Cloud has a built-in Azure Regulatory Compliance dashboard, with a dedicated SOC 2 initiative that checks specific control codes like CC6.1 automatically. It continuously reviews Azure resource configuration against SOC 2-mapped controls and can generate PDF reports.
To be precise about what this is: it's a self-assessment tool for the customer side of the line, not Microsoft's audited attestation. Microsoft says as much itself, calling it "only a partial view of your overall compliance status." It's a useful starting point for gathering evidence, not a shortcut past the work.
Practically, since the main report reissues every six months, a calendar reminder tied to the March 31 and September 30 periods is a simple safeguard against handing an auditor a report that expired months ago.
What If a Company Is Running Both AWS and Azure?
Most available documentation, including Microsoft's own, quietly assumes a single-cloud setup. Companies past a certain size often aren't.
The answer is straightforward, if a little more work: an auditor needs carve-out evidence from each provider separately. Azure's report covers Azure's infrastructure. AWS's report covers AWS's. Neither covers the other, and there's no combined report available from either side. Control documentation needs to make clear which workloads live where, so the auditor isn't left guessing which report applies to which piece of the environment.
For teams splitting workloads across both, the shared responsibility breakdown in the AWS SOC 2 report article is a useful companion to this one.
Mistakes Teams Make Relying on Microsoft's Attestation
Common patterns, roughly in order of frequency:
- Treating "Azure is SOC 2 compliant" as the same claim as "we're SOC 2 compliant." They aren't the same statement, and auditors know the difference even when the person answering a vendor questionnaire doesn't. The Microsoft Q&A thread referenced earlier is a live example of this exact mix-up.
- Assuming the public SOC 3 summary is sufficient evidence for an actual audit. It's a summary; auditors will want the full report.
- Forgetting that Azure DevOps requires its own separate report request.
- Citing a report period that's already expired without checking for reissue, or overlooking that a bridge letter exists for the gap in between.
- Assuming all five Trust Services Criteria are in scope because that's how competitors' reports read. Azure's public page lists four.
- Not building the NDA and portal access step into the audit timeline, then scrambling for it the week before the audit starts.
- Skipping the User Entity Responsibilities section entirely, and assuming Microsoft's attestation implicitly covers something the report explicitly assigns to the customer.
- Treating the Regulatory Compliance dashboard as a one-time check instead of ongoing monitoring. Resource configurations may change, so a control that passed last month can quietly fail this month. Such unnoticed gaps gets highlighted in the audit easily.
How ComplyJet Helps With What Azure Doesn't Cover
Everything in the customer-owned bucket above including access reviews, logging, incident response, pulling together evidence for an auditor, is exactly the work that consumes the most time during a SOC 2 audit, regardless of which cloud server is in use.
Rather than handing you software and expecting you to manage the audit on your own, ComplyJet helps with evidence collection and continuous control monitoring, mapped directly to your Azure environment. That closes the gap between what Microsoft's SOC 2 report covers and what your auditor expects, so you're not rushing to gather evidence just weeks before the audit.
FAQs About the Azure SOC 2 Report
Is Azure SOC 2 compliant?
Microsoft's Azure holds its own SOC 2 Type 2 report, reissued twice a year. But "Azure is compliant" only describes Microsoft's infrastructure layer. It says nothing about how a customer has configured and operated on top of it.
How do I get the Azure SOC 2 report?
Through the Microsoft Service Trust Portal at aka.ms/STP, signing in with an active Azure, Microsoft 365, or Dynamics 365 account and accepting Microsoft's NDA for compliance materials. For the public summary, the SOC 3 report requires no NDA at all.
Does the Azure SOC 2 report cover Azure DevOps?
No. Azure DevOps has its own standalone SOC 1 Type 2 and SOC 2 Type 2 report, entirely separate from the main Azure report. It can be requested directly at AzureDevOpsSOCReport@microsoft.com.
What's the difference between Azure SOC 1, SOC 2, and SOC 3?
SOC 1 covers controls relevant to financial reporting, reissued quarterly. SOC 2 covers security, availability, processing integrity, and confidentiality, reissued semi-annually. SOC 3 is a public summary of the same SOC 2 audit, and it needs no NDA to access.
Do I still need my own SOC 2 audit if I use Azure?
Yes. Azure's report covers Microsoft's infrastructure. A company's own controls such as access management, logging, incident response, vendor management still need independent audit evidence, separate from anything Azure provides.
Does Azure's SOC 2 report cover the privacy Trust Service Criteria?
Microsoft's own compliance summary page lists four Trust Service Criteria: security, availability, processing integrity, and confidentiality. Privacy isn't named there, which is worth knowing when comparing it against another provider's report.
How often is the Azure SOC 2 report updated?
Twice a year, for periods ending March 31 and September 30. It's worth checking the date on any copy before citing it as current evidence for an auditor.
Is Azure OpenAI Service covered by the Azure SOC 2 report?
Not publicly confirmed either way. Microsoft's scope summary names broad categories without calling out Azure OpenAI Service specifically. The definitive per-service answer lives in the attestation report's own appendix, which requires Service Trust Portal access to view.
Is PCI DSS included in Azure's SOC 2 report?
No. Unlike CSA STAR and Germany's C5:2020, which are bundled into the same SOC 2 report, PCI DSS is a fully separate attestation with its own report, obtained from a different part of the Service Trust Portal.
Does Azure have a tool to track SOC 2 compliance automatically?
Yes. Microsoft Defender for Cloud's Regulatory Compliance dashboard includes a built-in SOC 2 initiative that continuously checks Azure resource configuration against mapped controls. It's a self-assessment tool for the customer side of the shared responsibility line, not a replacement for Microsoft's own audited report.
Does using Azure automatically make my app SOC 2 compliant?
No, a genuinely common point of confusion, documented even in Microsoft's own support channel. Azure's SOC 2 report covers Microsoft's infrastructure. Application-level design, access controls, and operational practices still need their own audit evidence.
Does Azure use the carve-out or inclusive method in my SOC 2 report?
Almost certainly carve-out. The auditor excludes Azure's controls from the report's direct scope and accepts Azure's own SOC 2 report as evidence that those controls are covered elsewhere. The inclusive method i.e. testing Azure as if it were part of the company's own environment is rare and impractical at this scale.
If I use both AWS and Azure, do I need both SOC 2 reports?
Yes. Each provider's report only covers its own infrastructure, and there's no combined report covering both. An auditor will expect carve-out evidence from every provider in use.
What does "User Entity Responsibilities" mean in the Azure SOC 2 report?
It's the report's own list of what Microsoft assumes the customer is handling, sometimes called Complementary User Entity Controls or CUECs. It's worth checking against a company's own control list; anything not being done from that list is a gap an auditor is likely to find first.
