SOC2 Readiness and Azure Architecture: What the Assessment Process Reveals Before the Auditor Arrives

SOC2 doesn’t test whether your policies say the right things — it tests whether your Azure configuration actually implements them. A pre-audit assessment produces the evidence auditors ask for: a documented record of live configuration state, mapped to the Trust Services Criteria, for logical access, data protection, and availability.

The information security policy is written. The risk register is current. The incident response plan has been reviewed and signed off. Three-quarters of the SOC2 prep checklist is genuinely under control.

Then there’s the architecture evidence section. And it’s a different category of problem.

Not “we need to write a document.” More like: “we need to prove our Azure configuration actually implements what our policies claim.” Nobody warned you that was part of the deal.

It is. And you’re not alone in finding this out late.

Key takeaways

• SOC2 evaluates whether your Azure configuration implements your policies — not whether the policies exist. The gap between the two is where Dutch scale-ups fail, or pass with a findings list.
• Auditors ask for configuration evidence in three areas: logical access control (CC6), data protection (CC6), and availability and monitoring (A1) — not architecture diagrams.
• Four patterns cause most findings: Entra ID role sprawl, unconfigured diagnostic settings, backup gaps on later-added resources, and undocumented network segmentation.
• A pre-audit assessment runs against Azure Resource Graph to read live state across every subscription, mapping each finding to a Trust Services Criterion.
• A third of compliance professionals spend 30% or more of their time on the repetitive administrative work of audit preparation (2024 Hyperproof benchmark, 1,000+ respondents) — much of it evidence gathering, avoidable when configuration state is already documented.

The thing nobody explains up front

SOC2 doesn’t care that your policy says “we follow least-privilege principles.” Your auditor cares whether your Azure environment implements least-privilege principles. Those are different questions with different answers.

The gap between them is where Dutch scale-ups fail their first SOC2 Type II audit. Or pass — but with a findings list that buys them another six months of remediation before the report is clean enough to hand to a customer.

The frustrating part is that the gap is usually not huge. The architecture is often fine. The controls are often mostly in place. What’s missing is the evidence — a documented, structured record of what’s actually configured, tied to the Trust Services Criteria the auditor is evaluating against. Engineers know what’s deployed. They haven’t produced what an auditor needs to see.

What auditors actually ask for

For an Azure-hosted SaaS company, the evidence requests cluster into three areas.

Logical access control. This is CC6. The auditor wants to see your Entra ID role assignments, specifically who holds Owner or Contributor at subscription scope and why. They want PIM configured for administrative roles. They want Conditional Access policies documented — MFA enforcement for all users, what happens when a device is non-compliant, sign-in risk handling. A policy statement that says “we enforce least privilege” satisfies nothing. A Resource Graph export showing every role assignment across all subscriptions, with a documented justification for anything broader than workload scope — that satisfies the auditor.

Data protection. CC6 again, different angle. At-rest and in-transit encryption. Azure Storage accounts: is supportsHttpsTrafficOnly true? Is minimumTlsVersion set to TLS 1.2? Azure SQL: is Transparent Data Encryption enabled? Key Vault: are access policies scoped correctly, and are diagnostic logs retained? The auditor is looking for configuration evidence, not architecture diagrams. One of the most common configuration gaps — two Key Vaults out of five with no diagnostic settings — is invisible until someone actually queries the live state.

Availability and monitoring. SOC2 A1. If you’ve made availability commitments to customers, the auditor checks whether your architecture can actually meet them. Azure Monitor alert rules, Log Analytics workspace configurations, Backup vault policies with documented RTOs, Traffic Manager or Front Door if high availability is in scope. Again, configuration state. Not intent.

None of this requires exotic tooling to produce. It requires that someone has actually assessed the configuration, documented the state, and mapped the findings to the Trust Services Criteria — before the auditor does it for you.

The four patterns that cause findings

These are the gaps that come up repeatedly, across Azure environments of every size.

Entra ID role sprawl. A small team at series A gives everyone Contributor at subscription level because it’s convenient. Three years later, there are former contractors still in there, service principals with more permissions than their workloads need, and no documented rationale for any of it. Running a Resource Graph query that shows every role assignment across every subscription takes about thirty seconds. Most companies do it for the first time during the audit.

Diagnostic settings that were never configured. Azure services don’t emit logs by default. Every service — Key Vault, Azure SQL, App Service, Storage Account, API Management — needs a diagnostic setting explicitly configured to forward logs to a Log Analytics workspace. A company that’s been growing fast through feature development rarely has consistent diagnostic settings across all resources. The auditor asks for evidence of centralised log retention. The engineering team discovers two of their five Key Vaults have no diagnostic settings at all. This is a CC7.2 finding.

Backup gaps on resources added after the initial build. Backup policies get applied to the original infrastructure. Then a database gets added during a feature sprint six months later, and nobody applies the backup policy. No one notices because it’s not visible without an inventory audit. The auditor notices.

Network segmentation that’s configured but undocumented. NSG rules exist. Private Endpoints are in place. VNet peerings are there. What doesn’t exist is a documented assessment of whether those rules actually achieve the intended isolation between production and development. The auditor asks. The honest answer is “probably, but we haven’t formally reviewed since initial deployment.”

What a pre-audit assessment gives you

A pre-audit assessment runs against Azure Resource Graph — the query layer that reads the live configuration of every resource across all your subscriptions. Not what you think is deployed. Not what the Terraform files say. What’s actually there right now.

The output is a WAF alignment report mapped across all five pillars, with every finding tied to a specific resource, a specific configuration property, and specific remediation guidance. For SOC2 prep, the Security and Reliability pillars carry the most weight. But operational and availability findings map directly to CC7 and A1.

A Dutch payment technology firm ran a PAA assessment in advance of their Type II audit and found eleven configuration gaps they hadn’t known about. Three were material: two Key Vaults with no diagnostic settings, a production SQL database added eight months prior with no backup policy, and a service principal from a former integration partner that still held Contributor access on the production subscription. All three were closed before the auditor started. None of them appeared as findings. The Type II report was clean.

That’s the point of running the assessment before you hand the auditor access. You find what they’d find, and you fix it first.

Hyperproof’s 2024 IT Risk and Compliance Benchmark Report, based on responses from over 1,000 IT and compliance professionals, found that a third of them spend 30% or more of their time on the repetitive administrative work of preparing for audits. That’s where the hours go — and much of it is evidence gathering, which is avoidable if the configuration state is already documented.

The practical timeline question

A typical SOC2 audit preparation cycle for a Dutch scale-up with a moderately complex Azure environment: eight to twelve weeks. The majority of that time is not spent writing policies. It’s spent gathering evidence — extracting configuration state from Azure, reconciling what’s actually deployed against what was intended, and producing documentation that an auditor can review without requiring three engineering hours of explanation per finding.

PAA compresses the evidence-gathering phase to hours. The Resource Graph scan covers all subscriptions in a tenant. The WAF and compliance mapping runs automatically. The output — mapped to SOC2 Trust Services Criteria, with specific resource identifiers, configuration values, and remediation guidance — syncs to GitHub or Confluence. That becomes the living architecture evidence record.

Not a document you produce for the audit and then discard. The baseline you update as the architecture changes, so the next audit cycle doesn’t start from scratch.

FAQ

What architecture evidence does a SOC2 auditor actually want?

Configuration evidence, not diagrams. For an Azure-hosted SaaS company it clusters into three areas: logical access control (Entra ID role assignments, PIM, Conditional Access) under CC6, data protection (encryption at rest and in transit, Key Vault settings) under CC6, and availability and monitoring (alert rules, backup policies, RTOs) under A1.

Why do companies fail their first SOC2 Type II audit on architecture?

Rarely because the architecture is wrong — usually because the evidence is missing. The controls are mostly in place, but no one has produced a structured, documented record of live configuration tied to the Trust Services Criteria. Engineers know what’s deployed; they haven’t produced what an auditor needs to see.

What does a pre-audit assessment produce?

A Well-Architected alignment report across all five pillars, with every finding tied to a specific resource, configuration property, and remediation step, mapped to SOC2 criteria. It runs against Azure Resource Graph, reading live state rather than Terraform or diagrams, and syncs to GitHub or Confluence as a maintained evidence record.

How long does SOC2 audit preparation take?

For a Dutch scale-up with a moderately complex Azure environment, eight to twelve weeks is typical. Most of that is evidence gathering, not policy writing — Hyperproof’s 2024 benchmark report found a third of compliance professionals spend 30% or more of their time on the repetitive administrative work of audit preparation. Documenting configuration state in advance compresses that phase to hours.

The organisations that complete SOC2 Type II without a findings list aren’t the ones with the most thorough policy documentation. They’re the ones where the architecture configuration matches the policy intent, and where someone verified that alignment before the auditor checked.

So the question to ask before you sign the auditor engagement is a quieter one. If someone queried your live Azure configuration this afternoon — not the Terraform, not the diagrams, the actual deployed state — how many of the gaps above would it find?

What’s the one control you’re least sure you could evidence today?