Illustrative scenario: the organization below is a fictional composite. It reflects problems and fixes we commonly see in Microsoft 365, Intune, Purview and Azure environments. Names and figures are examples, not a specific client.
This Azure SOC 2 readiness case study follows a fast-moving biotech startup whose first enterprise customer asked for a SOC 2 report. A pre-audit review found a storage container open to the internet and every developer holding Owner on production. Here is how the team fixed both and built the evidence an auditor would ask for.
At a glance
Item
Detail
Industry
Biotechnology, research software (fictional: Helixa Bio)
Size
70 staff, 18 developers and data scientists, 3 Azure subscriptions
Microsoft licensing
Microsoft 365 Business Premium, Microsoft Entra ID P2 for 6 admins, Azure pay-as-you-go with Microsoft Defender for Cloud
Challenge
Publicly accessible blob container and Owner rights for every developer ahead of a SOC 2 Type 1 audit
What we did
Defender for Cloud, Azure Policy to deny public blob access, management groups, least-privilege RBAC with PIM, Key Vault, audit-ready evidence
Outcome
Zero public storage accounts, Owner holders cut from 22 to 2 eligible admins, Defender for Cloud secure score from 42% to 81%
The challenge
Helixa had built its platform quickly. Every developer had Owner on all three subscriptions because it was the easiest way to unblock work. Storage accounts, databases and app services were created by hand, often by whoever needed them that week.
When the company’s first large pharmaceutical customer asked for a SOC 2 report, the COO hired an audit firm and asked us to get Azure ready. In the first hour of our review we found a blob container holding exported assay results and a few test datasets, set to anonymous read access. Anyone with the URL could list and download the files.
What we found
One container with anonymous public access, plus 5 other storage accounts that allowed it at the account level.
22 accounts with Owner across the subscriptions, including two former contractors and a service principal created for a demo.
No management groups. Each subscription had its own settings, and nothing was enforced centrally.
Database connection strings and API keys stored in app settings and in a shared notes file.
Defender for Cloud on the free tier with 140 open recommendations nobody had looked at.
No activity log retention beyond the 90-day default.
What we changed
1. Close the public container the same day
We checked storage logs to understand who had been reading the data, confirmed with the science team that nothing needed anonymous access, and set Allow Blob anonymous access to Disabled on every storage account under Storage account > Settings > Configuration. The access logs went to the COO and counsel to assess whether any notification was needed.
2. Management groups and Azure Policy
We created a management group hierarchy with Platform, Production, Non-production and Sandbox branches, and moved the subscriptions under it. At the top level we assigned the built-in policy Storage account public access should be disallowed with the Deny effect, so nobody can create or reconfigure a storage account to allow anonymous access. Microsoft describes this approach in Remediate anonymous read access to blob data. We added policies to require secure transfer, restrict regions, and require tags for owner and data classification.
3. Least-privilege RBAC with PIM
Developers got Contributor on Non-production and Sandbox, and Reader on Production.
Production changes now go through the deployment pipeline’s managed identity, scoped to specific resource groups.
Owner on the root management group is held by two admins as an eligible assignment in Privileged Identity Management, with approval and a two-hour limit.
Former contractor accounts and the demo service principal were removed, and quarterly access reviews were scheduled.
4. Secrets into Key Vault
We created one Key Vault per application and environment, using Azure RBAC with soft delete and purge protection on. Apps read secrets through managed identities, so no connection strings remain in app settings or code. We rotated every secret that had lived in the notes file.
5. Defender for Cloud and logging
We turned on the Defender CSPM plan and Defender for Storage, added SOC 2 to the regulatory compliance dashboard, and worked the recommendations by severity. The Azure activity log and Key Vault logs now stream to a Log Analytics workspace with one-year retention.
6. Evidence for the auditor
We built a shared evidence folder with policy assignment and compliance exports, the management group structure, role assignment reports, PIM activation history, access review results, Key Vault configuration, and a monthly Defender for Cloud compliance snapshot. Each item maps to a control in the auditor’s request list.
Results
In this scenario, ten weeks after the review:
Zero storage accounts allow anonymous access, and policy blocks any new ones.
Standing Owner assignments went from 22 to none, with 2 admins eligible through PIM.
All 31 application secrets moved into Key Vault and rotated.
Defender for Cloud secure score rose from 42% to 81%, with no high-severity recommendations open.
The SOC 2 Type 1 fieldwork found no exceptions on Azure access or data protection controls.
Lessons for your business
Owner for everyone is the most common startup shortcut, and the first thing an auditor will question.
Fix the setting, then enforce it with policy. A one-time fix drifts. A Deny policy at a management group does not.
Secrets do not belong in app settings or notes. Managed identities and Key Vault remove most of them.
Collect evidence as you go. Exports and reports dated during the work are worth more than screenshots taken the week before the audit.
Does turning off anonymous access break existing apps?
It can if an app or partner reads blobs without authentication. Check storage logs for anonymous requests first, then move those consumers to SAS tokens or Microsoft Entra authentication before you disable access.
Do we need paid Defender for Cloud plans for SOC 2?
Not strictly, but the free tier only gives foundational recommendations. Defender CSPM adds attack path analysis and governance features, and workload plans such as Defender for Storage add threat detection that auditors and customers often ask about.
How long does SOC 2 readiness in Azure take?
For a small environment like this one, 8 to 12 weeks is typical for the technical controls. Policies, HR processes and vendor management run in parallel and often take longer.
Preparing for SOC 2 or a customer security review? Book a free security assessment and we will review your Azure and Microsoft 365 setup together.
Illustrative scenario: the organization below is a fictional composite. It reflects problems and fixes we commonly see in Microsoft 365, Intune, Purview and Azure environments. Names and figures are examples, not a specific client.
This Azure SOC 2 readiness case study follows a fast-moving biotech startup whose first enterprise customer asked for a SOC 2 report. A pre-audit review found a storage container open to the internet and every developer holding Owner on production. Here is how the team fixed both and built the evidence an auditor would ask for.
At a glance
The challenge
Helixa had built its platform quickly. Every developer had Owner on all three subscriptions because it was the easiest way to unblock work. Storage accounts, databases and app services were created by hand, often by whoever needed them that week.
When the company’s first large pharmaceutical customer asked for a SOC 2 report, the COO hired an audit firm and asked us to get Azure ready. In the first hour of our review we found a blob container holding exported assay results and a few test datasets, set to anonymous read access. Anyone with the URL could list and download the files.
What we found
What we changed
1. Close the public container the same day
We checked storage logs to understand who had been reading the data, confirmed with the science team that nothing needed anonymous access, and set Allow Blob anonymous access to Disabled on every storage account under
Storage account > Settings > Configuration. The access logs went to the COO and counsel to assess whether any notification was needed.2. Management groups and Azure Policy
We created a management group hierarchy with Platform, Production, Non-production and Sandbox branches, and moved the subscriptions under it. At the top level we assigned the built-in policy Storage account public access should be disallowed with the Deny effect, so nobody can create or reconfigure a storage account to allow anonymous access. Microsoft describes this approach in Remediate anonymous read access to blob data. We added policies to require secure transfer, restrict regions, and require tags for owner and data classification.
3. Least-privilege RBAC with PIM
4. Secrets into Key Vault
We created one Key Vault per application and environment, using Azure RBAC with soft delete and purge protection on. Apps read secrets through managed identities, so no connection strings remain in app settings or code. We rotated every secret that had lived in the notes file.
5. Defender for Cloud and logging
We turned on the Defender CSPM plan and Defender for Storage, added SOC 2 to the regulatory compliance dashboard, and worked the recommendations by severity. The Azure activity log and Key Vault logs now stream to a Log Analytics workspace with one-year retention.
6. Evidence for the auditor
We built a shared evidence folder with policy assignment and compliance exports, the management group structure, role assignment reports, PIM activation history, access review results, Key Vault configuration, and a monthly Defender for Cloud compliance snapshot. Each item maps to a control in the auditor’s request list.
Results
In this scenario, ten weeks after the review:
Lessons for your business
Our Azure security assessment is where this work usually starts, with managed Azure to keep it in shape and our broader Azure services for build-out.
Frequently asked questions
Does turning off anonymous access break existing apps?
It can if an app or partner reads blobs without authentication. Check storage logs for anonymous requests first, then move those consumers to SAS tokens or Microsoft Entra authentication before you disable access.
Do we need paid Defender for Cloud plans for SOC 2?
Not strictly, but the free tier only gives foundational recommendations. Defender CSPM adds attack path analysis and governance features, and workload plans such as Defender for Storage add threat detection that auditors and customers often ask about.
How long does SOC 2 readiness in Azure take?
For a small environment like this one, 8 to 12 weeks is typical for the technical controls. Policies, HR processes and vendor management run in parallel and often take longer.
Preparing for SOC 2 or a customer security review? Book a free security assessment and we will review your Azure and Microsoft 365 setup together.