Think of this guide as your quick-start guide to build a secure Azure setup which is SOC 2 compliant from day one. Whenever you spin up a VM, database, or storage account, jump to its section, toggle the handful of settings we list, and you’ll launch fully SOC 2-ready—no firefighting later.
1. Virtual Machines (Azure VM)
Public SSH access denied on Azure VM
Go to the Azure Portal and open the VM.
Click on Networking and find the associated NSG.
Check Inbound rules for any rule allowing port 22 from
0.0.0.0/0.Delete the rule or restrict it to known IPs like your VPN or admin subnet.
VM has Network Security Group attached (Azure)
Go to the VM’s Networking tab.
Confirm that an NSG is attached to either the network interface (NIC) or the subnet.
If missing, click Associate NSG and select one.
Server CPU monitored and alarmed (Azure)
Navigate to Monitor > Alerts.
Click + Create alert rule.
Select the VM as the resource.
In the Condition section, choose Percentage CPU and set the threshold to trigger when it's over 80%.
Add an Action Group to notify your team.
2. Network Security Groups (NSG)
SSH access denied via NSG (Azure)
Go to Network Security Groups in Azure.
Filter to only show NSGs actively associated with subnets or NICs.
Open each NSG and inspect Inbound security rules.
Remove any rule that allows TCP traffic on port 22 from
Anyor0.0.0.0/0.
NSG flow logs forwarded (recommended)
Open any NSG and go to Diagnostic settings.
Click + Add diagnostic setting.
Enable Flow logs (version 2).
Send them to a Log Analytics Workspace or Storage Account.
Set the retention to at least 90 days.
3. Storage Accounts
Storage encryption enabled (Azure)
Open the Storage Account in the Portal.
Go to Encryption under Security + networking.
Ensure encryption is enabled (MMK by default; use CMK if required).
Public access blocked for storage account (Azure)
In the Storage Account, go to Configuration.
Ensure Allow blob public access is set to Disabled.
Go to Containers, and for each one, set Public access level to Private.
Blob containers versioned (Azure)
Navigate to the Storage Account > Data protection.
Under Blob service, enable Blob versioning.
Save the changes and verify the setting is active.
Storage account monitored and alarmed (Azure)
Go to Monitor > Alerts.
Create alert rules for metrics like:
Used capacity (e.g., alert if > 85%)
Transactions (based on usage patterns)
Success E2E Latency (e.g., > 500ms)
4. Azure SQL Database
SQL databases encrypted at rest (Azure)
Go to the SQL server in Azure Portal.
Click Transparent data encryption.
Make sure TDE is enabled for all databases.
SQL backups enabled (Azure)
Select the database and go to Manage Backups.
Under Short-term retention, set a value between 7–35 days.
Database CPU monitored and alarmed (Azure SQL)
In Monitor > Alerts, create a rule:
Select the SQL database.
Use the metric cpu_percent.
Set threshold to alert when over 80%.
Database free memory monitored and alarmed (Azure SQL)
Create an alert rule with:
Metric: sql_instance_memory_percent
Threshold: less than 20%
Database free storage space monitored and alarmed (Azure SQL)
Create an alert with:
Metric: storage
Condition: free space < 20%
Database read I/O monitored and alarmed (Azure SQL)
Create a rule for:
Metric: physical_data_read_percent
Threshold: over 80%
Diagnostic logs enabled
Go to the SQL database > Diagnostic settings.
Set up forwarding to Log Analytics or a Storage Account.
5. Azure Database for PostgreSQL
PostgreSQL encryption at rest enabled (Azure)
Open your PostgreSQL server.
Go to Security > Data encryption.
Confirm MMK encryption is enabled.
PostgreSQL backups enabled (Azure)
Navigate to Backups.
Set retention between 7 and 35 days.
PostgreSQL CPU monitored and alarmed (Azure)
Create an alert:
Metric: cpu_percent
Trigger if usage > 80%
PostgreSQL free storage space monitored and alarmed (Azure)
Create an alert using:
Metric: storage_used > 85% or storage_free < 10GB
PostgreSQL read I/O monitored and alarmed (Azure)
Create a rule with:
Metric: read_iops
Threshold: over 1,000
Enable diagnostic settings
Go to the server > Diagnostic settings.
Forward metrics and logs to Log Analytics or Storage.
6. Azure Database for MySQL
MySQL encryption at rest enabled (Azure)
Go to the MySQL server.
Under Security > Data encryption, confirm encryption is active.
MySQL backups enabled (Azure)
Open the server > Backups.
Set a retention period (7–35 days).
MySQL CPU monitored and alarmed (Azure)
Create a metric alert:
Metric: cpu_percent
Threshold: > 80%
MySQL free storage space monitored and alarmed (Azure)
Alert on:
storage_used > 85% or storage_free < 10GB
MySQL read I/O monitored and alarmed (Azure)
Metric: read_iops
Threshold: over 1,000
Enable diagnostic settings
Turn on Diagnostic settings for logs and metrics.
7. Cosmos DB
Backups enabled for Cosmos DB (Azure)
Go to the Cosmos DB account > Backup & Restore.
Choose Periodic (set interval + retention) or Continuous (30-day restore).
Encryption at rest enabled for Cosmos DB (Azure)
Under Settings > Encryption, ensure encryption is active.
Use MMK (default) or set up CMK if needed.
Cosmos DB requests monitored and alarmed (Azure)
In Monitor > Alerts, create a rule:
Metric: TotalRequests
Threshold: tuned to workload (e.g., > 10,000 per 5 minutes)
8. Logging & Diagnostics
Subscription Activity Logs Archived (Azure)
Go to Monitor > Diagnostic settings.
Under your subscription, click + Add Diagnostic Setting.
Select Administrative, Policy, and Security logs.
Route them to a Storage Account (and/or Log Analytics).
Retain logs for at least 90 days.
9. Identity & Access (Azure AD)
Unique Azure Access Accounts
Review accounts via ComplyJet.
Ensure each Azure AD account maps to a single employee.
Disable or reassign any shared or orphaned accounts.
Infrastructure Console has MFA enabled (Azure)
Go to Azure Active Directory > Conditional Access.
Create a policy enforcing MFA for all users accessing cloud apps.
Exclude only break-glass accounts (if necessary).
Azure Account Access Removed on Termination
Cross-check Azure users with HR records.
For any ex-employee:
Disable sign-in
Remove roles, group access, and app permissions
Ensure no active sessions or credentials remain.
By ticking off these settings every time you create a resource, you’re locking SOC 2 best practices into your day-to-day build process—not tacking them on after the fact. Keep this checklist handy, bake it into your IaC templates and code reviews, and you’ll ship new Azure infrastructure that’s audit-ready the moment it goes live.