SOC 2 on Azure reports and bridge letters, what you own

How much of a SOC 2 on Azure does Microsoft's report cover?

Microsoft's SOC 2 Type 2 report covers Azure, Dynamics 365, Power Platform and select Microsoft 365 services against the security, availability, processing integrity and confidentiality criteria. Azure DevOps has its own separate report, so a team that builds on Azure DevOps should not assume the Azure report reaches its pipelines. Azure publishes the report on a rolling 12-month audit period, with new reports issued semi-annually for periods ending March 31 and September 30. Each new report takes about six weeks to publish. Between reports, bridge letters are issued in the first week of each quarter and are available from the Service Trust Portal. Confirm the exact service list in the current report before you rely on it, because the list is set by Microsoft and the report names what it includes.

Microsoft's report describes Microsoft's controls. It does not describe yours. Your organization still owns the controls over its own identities, configurations, data, change process and incident response, and it must write its own system description covering the Azure services it runs. The report also lists user entity responsibilities at the very end, and those are the controls you must operate to make the Microsoft report useful. A user entity that requests a service auditor's report to assess its risk is not relieved of its own responsibility for that risk. Map each listed responsibility to a named owner and an evidence source before your auditor arrives.

Your own SOC 2 report is issued by your independent CPA firm, not by Microsoft and not by a consultant. The CPA firm will decide how to treat Azure in your scope: as a carved-out subservice organization, whose controls it reviews through Microsoft's report, or as an included component. Ask your auditor which approach it expects and how it will evaluate the bridge letter gap between Microsoft's period end and yours. Management responses to exceptions appear toward the end of Microsoft's report, so read them alongside the user entity responsibilities when you assess residual risk.

How the Azure report and bridge letters arrive through the year

This sequence shows how Microsoft's Azure SOC evidence arrives on a rolling schedule, so your team knows which document to file for each part of the audit period and where any gap needs its own cover.

Understand the rolling 12-month audit period
Microsoft's Azure SOC 2 Type 2 report covers a rolling 12-month audit period rather than a single fixed calendar year. Your compliance lead reads the period stated in the current report and records its start and end dates in the evidence index. This is done by the customer, not by Microsoft, and it is complete when the period dates appear in your own vendor register next to the Azure entry.
Retrieve the semi-annual report for March 31
Microsoft issues a new SOC 2 Type 2 report semi-annually for periods ending March 31 and September 30. The report for the period ending March 31 typically becomes available about six weeks after that date, so you should expect it roughly six weeks after the period closes. Download it from the Service Trust Portal, save the file with its period end date in the name, and log the publication date. It is complete when the report is stored in your evidence set with its period dates visible.
Retrieve the semi-annual report for September 30
The second semi-annual report covers the period ending September 30 and follows the same publication pattern. Download it from the Service Trust Portal, confirm the stated audit period matches the rolling 12-month window you recorded, and file it alongside the March report. It is complete when both reports for the year sit in the same folder with consistent naming, so an assessor can see the full coverage.
Collect the quarterly bridge letters
Microsoft supplements the full reports with bridge letters issued in the first week of each quarter. A bridge letter covers the gap between the end of an audit period and the current date, so it is the document that links the latest report to the present. Download each letter from the Service Trust Portal at the start of every quarter and file it with the date it was issued. It is complete when no quarter in your audit window lacks a letter covering it.
Check the report's exceptions and management responses
Before filing a report, read the auditor's opinion and the section listing exceptions. Microsoft places management responses to exceptions toward the end of the attestation report, so read that part rather than stopping at the opinion. Record any exception that touches a control you depend on, and note Microsoft's response. This is done by your security or compliance lead, and it is complete when each relevant exception has a written note in your own control matrix.
Map Azure controls to your own control set
Read the user entity responsibilities, which Microsoft places at the very end of the report, and list each one against your own controls. These are the controls your organization must operate for the Azure services to meet the criteria, such as managing your own identities, access reviews and configuration choices. Your team owns these controls even though Microsoft's report describes them. The step is complete when every listed responsibility points to a named control and an evidence source in your matrix.
File each output with its evidence purpose
Store each full report as the basis for the Azure vendor relationship, and store each bridge letter as proof that coverage continued between reports. Note in the index that the reports support the vendor-side controls you review, while your own user entity responsibility evidence covers the rest. Confirm with your auditor which documents they expect for the examination period. The step is complete when the evidence index shows, for each quarter, the letter and the report that cover it.

Using the C5, SOC 2 and CSA STAR combined report

A US buyer asking for SOC 2 usually wants the SOC 2 Type 2 attestation under the 2017 Trust Services Criteria. Microsoft states that its SOC 2 Type 2 attestation is performed under SSAE No. 18 (AT-C sections 105 and 205), the AICPA SOC 2 guide and TSP section 100. The combined document carries that attestation alongside C5:2020 and CSA STAR, so the SOC 2 content sits in the same file, but it should be read and sent as a SOC 2 report in its own right. See the Microsoft Learn Azure SOC 2 page for the current listing.

Service scope: Confirm which Azure services the report covers and which trust criteria apply to each.
Audit period: Azure SOC reports use a rolling 12-month audit period, with new reports for periods ending March 31 and September 30.
Bridge letters: Quarterly bridge letters, issued in the first week of each quarter, cover the time between the period end and the present.
Exceptions and management responses: Management's responses to exceptions appear toward the end of the attestation report, so read them before relying on clean results.
What you still show: Your own SOC 2 must cover your application, your controls and any Azure controls you inherit or share, with user entity responsibilities listed at the very end of the report.

Confirm the edition, period and bridge letter date match what your customer asked for before you attach the document to a questionnaire.

Reading the Azure report and its user entity responsibilities

The most important parts of Microsoft's Azure SOC report for your own control design are near the back. Management's responses to exceptions appear toward the end of the attestation report, and the user entity responsibilities sit at the very end. Read both before you rely on the report in your own SOC 2. An exception tells you where a control did not operate as described during the period, and the management response tells you what Microsoft says it has done about it. The user entity responsibilities list the controls Microsoft expects its customers to perform. Each item there is a control obligation for your organization, and it should appear in your own control matrix with an owner and evidence.

Your auditor will look for the same things in your system. Under the AICPA's SOC 2 Report Walkthrough, the two concepts to map are complementary user entity controls (CUECs), which are controls the service organization assumes you operate, and complementary subservice organization controls (CSOCs), which are controls its own subservice providers are expected to operate. For each Azure CUEC, confirm who in your organization performs it, how often, and where the record lives, such as access review exports or key rotation tickets. For subservice organizations, check whether the Azure report uses the inclusive method, where the provider's controls are tested within the report, or the carve-out method, where they are excluded and their own reports must be obtained. Your system description must state which method you rely on.

Requesting a service auditor's report does not transfer your risk. The AICPA's Journal of Accountancy guidance is direct on this point: a user entity that asks for a report to assess risk remains responsible for that risk. Treat the Azure report as evidence about a provider's controls, not as a substitute for your own. Confirm the report period against your own audit period, identify any bridge letter gap (the Azure bridge letters are issued in the first week of each quarter), and document how you reviewed exceptions and carved-out controls. Ask your CPA firm how it will test your CUECs and whether it expects the Azure report to be read against your own system boundary.

Which controls stay with you on Azure

Microsoft's SOC 2 report covers the platform it operates, not how your organization configures and runs its own workloads on that platform. The areas below are where your controls begin, and each one needs evidence your auditor can sample across the whole observation period.

Identity and access in Entra ID

You own who can sign in to your tenant, which roles they hold, and how privileged access is granted and removed. Auditors will ask for user registration and termination records, role assignment exports from Entra ID, and evidence of periodic access reviews. Map this to CC6.1 through CC6.3. Check whether privileged roles require multi-factor authentication and whether break-glass accounts are documented and monitored.

Logging and monitoring of your resources

Microsoft logs the platform, but you decide which diagnostic logs from your subscriptions reach a central store, how long they are kept, and who reviews alerts. Auditors will ask for log retention settings, samples of security alerts with their triage notes, and evidence that log integrity is protected. This work maps to CC7.2, which covers monitoring for anomalies and security events. Confirm that your logging covers every subscription in scope.

Change management for your infrastructure as code

Templates, pipeline definitions and configuration baselines for your workloads are changes you control. Auditors will ask for pull request history, approvals, and proof that production deployments trace back to reviewed code. This maps to CC8.1. Check that the people who can approve a change are not the only people who can merge it, and that emergency changes are recorded and reviewed afterward.

Backup and recovery testing

Microsoft operates the underlying availability of its services, but you must configure backups for your data and prove that restores work. Auditors will ask for backup policy definitions, job success records, and results of restore tests with dates and outcomes. These controls relate to the availability criteria (A1) when that category is in scope, and to CC7.5 for recovery from incidents. Confirm which of your data sits outside the backed-up scope.

Secrets and key handling

Application credentials, certificates and encryption keys that you create are your responsibility, even when stored in a managed vault. Auditors will ask for vault access policies, rotation records, and a list of who can read or export secrets. This maps to CC6.1 and CC6.7 on restricting and protecting information. Check that secrets are not embedded in templates or pipeline variables where reviewers cannot see them.

Vendor and subservice management

Your own third-party tools, contractors and SaaS providers sit outside Microsoft's report. Auditors will ask for your vendor inventory, the reports you collected from them, and records of how you reviewed any exceptions. This work maps to CC9.2. Confirm that you have read Microsoft's user entity responsibilities at the end of its report and built a matching control for each one.

Who is paid for what in an Azure-based SOC 2

This table compares the five groups of spend in an Azure-based SOC 2: the CPA firm, implementation partner work, tooling, internal staff time and Microsoft's own reports. Read each row for who is paid, whether the cost is one-time or recurring, and what moves it up or down. Microsoft's Azure reports reduce the scope you must test directly, but they do not remove your own control work.

Cost component	Who is paid and for what	One-time or recurring, and cost drivers
CPA firm or service auditor	The independent CPA firm examines your controls and issues the SOC 2 report. Only the auditor issues the opinion.	Recurring each audit period. Drivers include the number of Trust Services Criteria in scope, the observation period length, sample sizes and the number of systems and locations tested. Ask for a fixed fee tied to written scope.
Implementation partner work	An implementation partner prepares Azure configurations, logging, access controls and evidence for auditor requests. It does not issue reports or certificates.	Mostly one-time for setup, then recurring if you retain support. Drivers include how many Azure subscriptions and services you run, the state of existing controls and how much evidence automation you want. Ask for a fixed scope with deliverables.
Tooling and licenses	Vendors and open-source hosting costs for logging, identity, GRC tracking, vulnerability scanning and infrastructure as code pipelines inside your Azure environment.	Mixed. Some licenses are annual or per user, while self-hosted open-source tools carry infrastructure and maintenance costs. Ask whether Azure-native logging in your subscriptions is already paid for under your agreement.
Internal staff time	Your engineers, security owners and operations staff who own controls, answer auditor questions, review access and approve changes.	Recurring. Drivers include the number of user entity responsibilities you must operate, the frequency of access reviews, change volume and how many auditor requests arrive during fieldwork.
Microsoft's SOC reports and bridge letters	Microsoft publishes its own SOC 2 Type 2 report, its combined C5 and CSA STAR report and quarterly bridge letters on the Service Trust Portal. You access these at no separate audit fee to you, but reviewing them is your task.	Recurring access to reports on Microsoft's schedule. Your cost is the time to review the report, map the controls it covers and record the user entity responsibilities that fall to your team. Confirm current access terms with Microsoft.

Where Azure-based SOC 2 projects stall

Most delays on an Azure-based SOC 2 come from the gap between what Microsoft's report covers and what your organization must still prove. The cards below cover the pitfalls that surface most often, each with a check to run before fieldwork starts.

Assuming Microsoft's report covers your controls

Microsoft's SOC 2 Type 2 report describes Microsoft's controls over its cloud platform. It does not test the access reviews, change approvals, or application controls you run on top of Azure. Auditors will ask for your own control set, and a clean Microsoft report does not answer those requests. Map each criterion in your scope to either a Microsoft control you inherit or a control you own, and write that split down before the examination begins.

Missing the bridge letter gap

Azure SOC reports cover periods ending March 31 and September 30, and they take about six weeks to publish. The quarterly bridge letters fill the period between a report's end date and your own audit window. If nobody owns the bridge letters, a gap appears in the evidence an auditor expects you to hold for the subservice organization. Assign a named owner, set a calendar reminder for the first week of each quarter, and file each letter in your evidence repository on receipt.

Leaving the scope of Azure services unmapped

Microsoft's report names the services it covers, and that list does not match every service your product uses. Dynamics 365, Power Platform and select Microsoft 365 services are covered, while Azure DevOps has a separate report. Teams that rely on the wrong report, or that assume a service is covered when it is not, end up with unexplained gaps in the subservice section. Build a service inventory that lists each Azure resource in scope, then confirm its coverage against the current Microsoft report before you name it in the system description.

Skipping user entity responsibilities

Microsoft places its user entity responsibilities at the very end of the report, and many teams never read that section. These are controls the customer must run, such as protecting credentials, configuring tenant security, and managing its own access. If your organization does not operate them, the service's controls will not hold for your system. Read the section line by line, then assign each responsibility to a control owner and reference it in your control matrix.

Reading exceptions without management responses

Exceptions in a SOC report are easy to skim past, yet they show where testing found a control did not operate as described. Microsoft places its management responses toward the end of the attestation report, so a reader who stops at the opinion will miss them. Review every exception in the report, record whether it affects your own controls, and note the response in your vendor review file. An unexamined exception can later become a question from your auditor.

Treating carve-out as a one-time decision

Whether Azure is included in your report under the inclusive or carve-out method changes how much testing the auditor performs on the provider. Teams often choose a method early, then forget why they chose it once the platform changes. Document the method, the reason, and the subservice controls you rely on, and revisit the decision when you add a new Azure service or change regions. Confirm the method with your CPA firm before fieldwork, since the choice affects the system description.

Questions buyers ask about SOC 2 on Azure

Is Microsoft's SOC 2 report enough to cover my Azure environment?

Microsoft's report is necessary but rarely sufficient on its own. Microsoft's SOC 2 Type 2 attestation covers Azure, Dynamics 365, Power Platform and select Microsoft 365 services against the security, availability, processing integrity and confidentiality criteria. It describes Microsoft's controls for the cloud platform, not your workloads, identities, configurations or data handling. Your own SOC 2 must still show how your team configures, monitors and changes what runs on Azure. Confirm in the report's scope section which services and criteria it covers before you rely on it for any part of your system description.

How do I get Azure's SOC reports and bridge letters?

Microsoft publishes its SOC reports and bridge letters through the Service Trust Portal, and an Azure account holder accesses them there. Azure uses a rolling 12-month audit period, with new reports issued semi-annually for periods ending March 31 and September 30. Each report takes about six weeks to publish after its period ends. Bridge letters are issued in the first week of each quarter to cover the gap between the report's period end and the current date. Store each report and letter with its date in your evidence folder, since your auditor will ask which period your reliance covers.

What does my team have to provide for an Azure-based SOC 2?

Your team owns the controls that Microsoft's report explicitly leaves to customers. Microsoft places user entity responsibilities at the very end of its SOC reports, so start there. Typical customer-side work includes:

Identity and access management, including MFA, role assignments and periodic access reviews in Microsoft Entra ID
Configuration of subscriptions, network boundaries, logging and alerting for your resources
Change management for infrastructure and application deployments
Your own backup, recovery testing and incident response procedures
A system description that maps which parts of Azure you use and which you carve out

Each item needs written procedures and dated evidence that an auditor can sample.

Can my internal team run a SOC 2 on Azure without outside help?

Yes, a capable team can run the program in-house, but the work is larger than it looks. The main drivers are the number of Azure services in your system, how many people already understand the criteria, and how much time the team can spare for evidence collection over an observation period. Teams usually underestimate the recurring work: quarterly access reviews, change records, vendor reviews and bridge letter tracking. Ask yourself whether someone owns each control day to day. Whatever you decide, the independent CPA firm performs the examination and issues the report, and no internal or partner work replaces that.

What is the difference between the auditor's role and an implementation partner's role?

The auditor and the implementation partner have separate jobs. The organization owns its controls and its system description. An implementation partner, such as DeployOpen, can plan, configure and document self-hosted platforms inside your own infrastructure, prepare systems and evidence, and support your team. DeployOpen does not issue audit reports, attestations or certifications. Only the independent CPA firm can examine your controls and issue a SOC 2 report. Keeping these roles separate also protects independence, which the auditor needs to maintain.

Does using Microsoft's report reduce my own responsibility for risk?

No. A customer that requests a service auditor's report to assess a provider's risk is not relieved of its own responsibility for that risk. Microsoft's report helps you evaluate the platform, but your controls over your own workloads and data stay your responsibility. Auditors will check that your system description accounts for the complementary user entity controls Microsoft lists, and that you operate them. Ask your auditor early which Microsoft controls you can reference and which ones you must cover yourself.

What should I check in Microsoft's report before my audit starts?

Read three sections before anything else. First, confirm the services and criteria in scope match the services you use. Second, read the management responses to exceptions, which Microsoft places toward the end of the attestation report. Third, read the user entity responsibilities at the very end. Note any exception that touches a service you depend on, and record how your controls compensate. Azure also publishes a combined C5:2020, SOC 2 Type 2 and CSA STAR Attestation report, so confirm with your auditor whether that document or the standard SOC 2 report fits your evidence plan.

Who owns the controls, who prepares evidence, who issues the report

The organization owns and operates its controls. In a SOC 2 built on Azure, the service organization is the party whose system is examined, and it is accountable for the access reviews, change approvals, incident handling and monitoring that the Trust Services Criteria test. Microsoft's report covers Microsoft's own controls for the Azure services it names, but it does not cover the configuration, identities, data handling or procedures you build on top. Those remain your responsibility, and your report will describe them in your own system description. DeployOpen, as an implementation partner, can plan and build the Azure environment, configure the tooling that runs those controls and assemble the evidence, but the controls and the decisions behind them stay with your management team.

DeployOpen prepares systems, controls and evidence. Inside your own Azure subscriptions, DeployOpen can help define which Microsoft services are in scope, document where your report will rely on Microsoft's carve-out or inclusive treatment, set up logging and access reviews, and organize the evidence that your auditor will request across the examination period. Ask any partner to show you, in writing, which deliverables it will produce, who on your side owns each control and how the evidence will be stored and handed over. Confirm with your auditor what evidence format it accepts before work begins.

Only an independent CPA firm issues the report. The SOC 2 report is an opinion issued by a licensed CPA firm after its own testing under the AICPA attestation standards. DeployOpen does not issue reports, attestations or certifications, and engaging it does not guarantee a clean opinion, a particular outcome or a specific report date. Your auditor's independence is a requirement of the examination, so the firm that prepares your environment should not be the firm that signs your report. Before you sign an engagement, ask both parties to confirm these roles in writing.

How DeployOpen prepares your Azure controls and evidence

DeployOpen works on the controls and evidence that sit in your own environment, around the Microsoft reports you rely on for the cloud platform. We prepare your systems, documentation and records for the examination, while your organization owns its controls and an independent CPA firm issues the report.

How we scope

We agree a written scope that names the Azure services, subscriptions and tenants your system description covers.
The scope separates what Microsoft's SOC 2 report covers from the controls your organization must run and evidence itself.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.

How we build

We configure and document the identity, logging, change and access controls that your own Azure environment needs for the criteria in scope.
We map each control to the evidence an auditor will request, such as configuration exports, access review records and change tickets.
We run internal tests of the controls before the examination window so that gaps appear while there is still time to fix them.

How we hand over

You receive the control matrix, system documentation and evidence procedures, written so your team can run them after handover.
We document where your responsibilities begin under Microsoft's user entity responsibilities, so the boundary is clear to your auditor.
We walk your staff through the evidence pack and the records they must keep for the auditor's sampling.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer for the period between examinations.
We can review Microsoft's bridge letters and changes in the Azure services you use against your own control set.
The CPA firm remains responsible for the report. We prepare the systems and evidence it examines, and we do not issue attestations.

SOC 2 on Microsoft Azure: reports, bridge letters and your controls