SOC 2 Type II Azure architecture and audit evidence

What SOC 2 actually asks of an architecture

The trust services criteria are not a technical specification. They are outcome statements, and a CPA firm decides whether your system meets them. Read across real audits and the weight is concentrated in a few places.

Logical access (CC6). How identities are created, granted, reviewed and removed. How privileged access is restricted. Whether authentication is enforced everywhere, including for service principals and break-glass accounts. This criterion generates more exceptions than any other, and almost all of them are architectural.

Change management (CC8). Whether changes to infrastructure and applications are authorized, tested, approved and recorded before they reach production. The auditor samples changes from the window and asks to see the record. If the record is a ticket somebody wrote afterwards, the sample fails.

System operations and monitoring (CC7). Whether you detect vulnerabilities and anomalies, whether alerts reach a human, and whether incidents are handled according to a process that existed before the incident.

Risk assessment and control monitoring (CC3, CC4). Whether somebody checks that the controls are still operating between audits. Drift is the failure mode here.

If you have added the availability criterion, backup and restore become testable claims rather than assertions. If you have added confidentiality, classification and disposal come into scope. Each optional criterion adds real work, so choose them against what customers are actually asking for rather than adding all five.

The structural point: Type II reports operating effectiveness over a window. The system has to behave correctly for months without anyone remembering to make it behave. That is a design problem, not a documentation problem.

What we design and enforce in Azure

Identity, so CC6 stops generating exceptions. Microsoft Entra ID with Conditional Access enforcing MFA and device state, Privileged Identity Management so no standing administrative role exists (access is requested, justified, time-bound and logged), scheduled access reviews on privileged groups, and workload identities using federated credentials instead of client secrets sitting in a pipeline variable. Break-glass accounts exist, are excluded from the policies that could lock you out, and are alerted on every single use.

A policy set that denies rather than reports. Azure Policy assigned at the management group level: TLS minimum version, no public network access on storage, SQL and Key Vault, mandatory diagnostic settings, required tags for owner and data classification, and allowed regions. Auditing a violation is a finding waiting to happen; denying it is a control.

Change control in the pipeline. Infrastructure as Terraform or Bicep in a repository with branch protection, required reviewers, a plan output attached to the pull request, and environment approvals for production. Portal write access to production is removed, not discouraged. Drift detection runs on a schedule, so a manual change becomes an alert instead of an audit finding six months later.

Monitoring that reaches somebody. Diagnostic settings to Log Analytics with retention set deliberately, Microsoft Defender for Cloud for posture and vulnerability findings with an agreed remediation window per severity, and Microsoft Sentinel analytics rules for the detections that matter, routed to a real on-call rotation rather than a shared mailbox.

Availability, if it is in scope. Backup policies as code, recovery objectives written down, and restore tests scheduled and recorded. An untested backup is an untested control.

This is the same substrate described on the compliance pillar and enforced on the Azure landing zone. The SOC 2 work is the mapping and the evidence, not a parallel build.

What the evidence pipeline produces

Everything below is exported on demand, not screenshotted the week before fieldwork.

Azure Policy compliance state per assignment and per resource, with timestamps, mapped to the criterion it satisfies.
Defender for Cloud regulatory compliance assessment for SOC 2, tracked over the window so you can show the trend rather than a single day.
PIM activation history: who elevated, into what role, for how long, with what justification. This single export answers a large share of CC6 requests.
Access review outcomes per quarter, with the reviewer and the decisions.
Sign-in and Conditional Access logs, including MFA enforcement and failures.
Pull request and deployment history: author, reviewer, approval timestamp, pipeline run, test result, environment. This is the change management record, generated by working normally.
Alert and incident timelines from Sentinel and Azure Monitor, with acknowledgement times.
Vulnerability findings and remediation dates, against the SLA you committed to.
Backup job and restore test records where availability is in scope.

What you keep

A control matrix mapping each trust services criterion to the Azure configuration that satisfies it and the query that evidences it.
The policy set and the landing zone as code, in your repository, under your license.
A KQL query pack saved in your Log Analytics workspace, one query per evidence request.
An auditor runbook: which export answers which request, who runs it, how long it takes.
A written register of accepted risks and compensating controls, so the conversation with the auditor starts from your position rather than theirs.

Who this is for

Software, digital health and financial technology companies blocked by an enterprise customer’s security review. Organizations that hold a Type I and have to survive the Type II window. Teams whose second audit cost as much as their first, which means the evidence was manual. Anyone about to start an observation window on an estate that has never been assessed.

Who this is not for

If you need a Type II report within sixty days and the estate has no policy set, no identity model and no pipeline, we cannot help in that timeframe and will say so on the first call. If you want a GRC platform rolled out and the architecture left alone, that produces a dashboard showing controls that do not exist. And if you want the same firm to build the controls and attest to them, that is not a service anyone should sell you.

Compliance architecture, the engagement that delivers this.
ISO 27001 on Azure, where the same substrate maps to Annex A.
HIPAA on Azure, when the data in scope is health information.
Azure landing zone, where the policy set lives.
Compliance, the pillar.

Questions we get

Can you make us SOC 2 certified?

There is no SOC 2 certificate. A licensed CPA firm issues an attestation report, and only that firm can. We build the system the report describes and produce the evidence the auditor samples. We take no referral fee from any audit firm, which is deliberate.

Type I or Type II first?

Type I proves the design at a point in time and can be issued weeks after remediation. Type II proves operating effectiveness across a window, typically three to twelve months. If a customer is blocking a deal, a Type I buys time. If nobody is waiting, go straight to a short Type II window rather than paying for two audits.

When should the observation window start?

After remediation, never during it. Every control that fails inside the window is a sampled exception in your report, and exceptions are what a prospect's security team reads first. Two extra months before the window costs far less than a qualified report.

Half our production was built by hand in the portal. Is that a problem?

Yes, and it is the most common one. Change management criteria ask who approved a change and when. A resource created in the portal at 11pm has no author, no reviewer and no record. We reconcile the estate into code first, then the change record exists by construction.

Do you work with our GRC platform and our auditor?

Yes. We build to the control set you are being measured against and export in the format your platform or auditor expects. We have no preferred audit firm.

What does year two cost?

That is the real question. If evidence is exported from Azure Policy, PIM and pipeline history, the recurring effort is days rather than weeks. If it is assembled from screenshots, year two costs what year one cost, every year, forever.

Have a question about this work?

Three fields. An architect reads it and answers within one business day.