Azure SOC 2 Monitoring Is Coming

SecureSpect's AWS and GitHub integrations are fully live. Microsoft Azure is next on the roadmap.

This post details which Azure services will be monitored, how the read-only connection will work, and which SOC 2 controls it will satisfy — so you can plan your compliance programme before the integration ships.

---

How the Connection Will Work

The Azure integration will use a scoped service principal — the Azure equivalent of an AWS cross-account read-only role.

You will:

Register an application in Entra ID (Azure AD)

Grant the application the built-in Reader role (or a custom read-only role) scoped to your subscription

Paste the application (client) ID, tenant ID, and a client secret into SecureSpect

SecureSpect will use the Microsoft Graph API and Azure Resource Manager APIs to collect evidence. No write permissions. No changes to your infrastructure.

---

Services Planned for the Initial Release

Microsoft Entra ID (formerly Azure AD)

Planned checks:

• MFA enforcement status for all users
• Conditional Access policies requiring MFA for admin roles
• Guest user access level and review status
• Service principal credential expiry

SOC 2 controls: CC6.1, CC6.2

---

Azure Key Vault

Planned checks:

• Soft-delete is enabled on all vaults
• Purge protection is enabled
• Key rotation policies are configured
• Diagnostic logging is enabled

SOC 2 controls: CC6.1 (credential management), CC6.7 (encryption key management), CC7.1 (change detection)

---

Azure Storage Accounts

Planned checks:

• Public blob access is disabled
• HTTPS-only traffic enforcement is enabled
• Storage encryption uses customer-managed keys (or at minimum Microsoft-managed keys with key rotation)
• Soft-delete is enabled for blobs and containers

SOC 2 controls: CC6.6, CC6.7, CC9.1

---

Microsoft Defender for Cloud

Planned checks:

• Defender plans are enabled (Servers, Storage, SQL, Key Vault, etc.)
• Secure Score and active high-severity recommendations

SOC 2 controls: CC7.1, CC7.2

---

Azure Policy

Planned checks:

• At least one custom policy initiative is assigned at the subscription or management group level
• No non-compliant policy assignments exist at the subscription level

SOC 2 controls: CC6.3 (least privilege, segregation of duties), CC7.1

---

Azure Monitor

Planned checks:

• Diagnostic settings are configured to export activity logs to a Log Analytics workspace or storage account
• Activity log retention meets the minimum 90-day requirement

SOC 2 controls: CC7.1

---

Azure Kubernetes Service (AKS)

Planned checks:

• RBAC is enabled on all AKS clusters
• Azure Active Directory integration is enabled
• Audit log collection is enabled
• Clusters are running a supported Kubernetes version

SOC 2 controls: CC6.3, CC6.6, CC7.1

---

Azure SQL

Planned checks:

• Transparent Data Encryption (TDE) is enabled
• Advanced Threat Protection (ATP) is enabled
• Long-term backup retention is configured
• Auditing is enabled and logs are sent to a storage account or Log Analytics

SOC 2 controls: CC6.7, CC7.1, CC9.1

---

SOC 2 Coverage Planned

|---|---|

---

When Will It Be Available?

The Azure integration is on the active roadmap. Sign up for early access notifications at the bottom of the [integrations page](/#integrations) or email [feedback@securespect.com](mailto:feedback@securespect.com) to be added to the beta list.

If you're currently managing Azure compliance manually and want to be among the first to connect, let us know — beta customers help shape which checks ship first.

---

Why Azure After AWS?

AWS accounts for the majority of infrastructure in SOC 2 audits we've seen. But hybrid and Azure-primary organisations face the same compliance burden — and the same broken spreadsheet workflows.

Azure's IAM model (Entra ID, managed identities, service principals, conditional access) is different enough from AWS IAM that it warrants its own evidence collector and check suite — which is why it's a separate integration rather than a bolt-on to the AWS connector.

The GitHub integration works the same way regardless of whether your cloud is AWS or Azure, so GitHub-hosted teams are already covered.