Azure Security Review for Regulated Mid-Market: The Eight-Domain Method We Run on Every Tenant

What an Azure security review is, and is not A regulated mid-market organization running on Azure has, in our experience, two existing artifacts that look like a security review and are not. The first is the Microsoft Defender for Cloud Secure Score dashboard, a numeric score, a recommendation list, and a remediation queue. The second is the CIS Microsoft Azure Foundations Benchmark exception report from a third-party scanner. Both are useful inputs. Neither is a written security review, and neither answers the questions a SOC 2, HITRUST, or HIPAA assessor will ask. A security review, in the form a regulated buyer needs, is a fixed-scope, written deliverable that walks a defined set of architectural domains, captures evidence at each step, scores findings against the controls the regulator cares about, and ships a remediation calendar with the deliverable. The artifact is the deliverable; the assessor reads it without follow-up because it is structured the way the assessor structures the audit. We run this method on every regulated Azure engagement. The format is fixed: three weeks of work, eight domains, one deliverable. The buyer keeps the deliverable regardless of what they do with the remediation calendar afterward. The domains are not a function of which Azure services the buyer uses; they are a function of what an audit walks, in the order the audit walks them. This is the method. The eight domains, in walk order Domain 1, Tenant and subscription structure The walk opens at the management-group / subscription / resource-group hierarchy. The question is whether the organization's resources are organized in a way that supports policy enforcement at the right scope, billing/cost attribution at the right tier, and least-privilege RBAC assignment at every layer. A flat tenant, every resource in a single subscription with one resource group per environment, produces RBAC findings throughout the rest of the review. A management-group structure with environments segregated and policy-applied at the management-group root produces a structurally clean baseline. Evidence artifact: a current architecture diagram of the management-group / subscription / resource-group tree, with environment labels (production, staging, development, sandbox), regulated-workload tagging, and the responsible cost-center attribution per subscription. The diagram is exported from Azure (the subscription tree is queryable through the Azure CLI or the Resource Graph), annotated with the regulated-workload posture, and included as Exhibit 1 of the deliverable. Common findings: production and non-production resources in the same subscription, regulated workloads alongside non-regulated workloads in shared resource groups, and management groups configured but not used for policy or RBAC scope. Domain 2, RBAC and Privileged Identity Management The second domain is the RBAC posture. Every role assignment on a subscription, management group, resource group, or individual resource has a principal (user, group, service principal, managed identity), a role, and a scope. The audit-relevant questions: how many standing administrative role assignments exist outside Privileged Identity Management; how many service principals hold privileged roles; how many role assignments are at the subscription or management group level (versus the narrowest scope that supports the workload); how recently were the role assignments reviewed. This domain ties directly to the M365 + Entra ID Hardening Field Guide, the identity layer is the same Entra tenant, and the audit walks them as a single surface. PIM coverage on Entra directory roles is necessary; PIM coverage on Azure resource roles (subscription Owner, Contributor, User Access Administrator, the dozens of resource-specific privileged roles) is the part most mid-market tenants have not extended to. Evidence artifact: the role-assignment export, scoped to every subscription and management group in the tenant, with the standing-versus-eligible flag, the principal type, and the assignment date. The deliverable's Exhibit 2 is the privileged role inventory: every account holding any privileged Azure role, the scope of the assignment, the activation history (or "always active" if not under PIM), and the last access review. Common findings: subscription Owner role assigned to Microsoft 365 administrator groups (a transitive over-privilege common in Microsoft-shop mid-market); managed identities with Contributor at the subscription scope when the workload only needs read access on a resource group; service principals provisioned for one-time deployment work and never deprovisioned. Domain 3, Network architecture and segmentation The third walk is the network. The questions: how is virtual network segmentation organized; what is the posture on public endpoints versus Private Endpoint / Service Endpoint; how is east-west traffic between virtual networks governed; what is the egress posture; what controls sit in front of any internet-exposed surface (Application Gateway, Front Door, Firewall, third-party WAF). For regulated workloads the audit-passing baseline is: no PaaS service exposes a public endpoint by default; Private Endpoints with Private DNS Zones for every PaaS service that supports them; Network Security Groups with explicit allow-rules and a default deny; Azure Firewall or equivalent for centralized egress control; diagnostic settings on every NSG, firewall, and gateway with a destination Log Analytics workspace. Evidence artifact: a written network architecture diagram (Exhibit 3) showing every virtual network, subnet, NSG, peering, gateway, firewall, and the data flow for the regulated workload from ingress to egress. The diagram is paired with the NSG rule export and the Private Endpoint inventory. Common findings: Storage Accounts and SQL Databases with public-endpoint access still enabled (even when Private Endpoints are configured), NSG rules with overly broad source ranges, virtual network peering between production and non-production environments without firewall enforcement. Domain 4, Identity and key material on resources The fourth domain narrows to the identity attached to compute and the key material protecting data. Three sub-questions: which workloads run with managed identities versus which run with service principals or stored credentials; where is key material stored (Key Vault, HSM-backed Key Vault, managed HSM, on-disk); how is access to Key Vault controlled (RBAC versus access policies, soft delete, purge protection). For regulated buyers the audit-passing baseline is: managed identities (system-assigned where the workload supports it, user-assigned where multiple workloads share an identity) on every compute resource that needs to call another Azure service; Key Vault with the RBAC permission model, soft delete and purge protection enabled, diagnostic settings to a Log Analytics workspace, and Private Endpoint access; encryption at rest with customer-managed keys for any service that supports it on the regulated record set. Evidence artifact: the managed-identity inventory, the Key Vault inventory with configuration settings (Exhibit 4), and the customer-managed-key configuration for the regulated data services. Common findings: SQL Database, Storage Account, and Cosmos DB encrypted with platform-managed keys when the workload sits inside a regulated record set; Key Vault still on the legacy access-policy model with broad permissions granted to administrative groups; managed identities granted Storage Blob Data Contributor at the storage-account level when only a specific container is needed. Domain 5, Data services and the regulated record set The fifth domain is the data layer. Every Azure data service holding regulated data, SQL Database, SQL Managed Instance, Cosmos DB, Storage Account (Blob, Files, Queue, Table), Data Lake Storage Gen2, Synapse, Databricks, PostgreSQL Flexible Server, MySQL Flexible Server, has a security posture that the audit will walk individually. The audit-relevant questions per service: encryption posture (platform-managed versus customer-managed keys), public-endpoint posture, authentication mode (SQL auth versus Entra-only), audit logging enabled and routed to retention, transparent data encryption / always encrypted where applicable, and backup retention with restore-test evidence. Evidence artifact: the data-services inventory (Exhibit 5) with one row per service instance, columns for each of the audit-relevant settings, and the regulated-data-flag indicating which instances hold the regulated record set. The inventory is exported via Azure Resource Graph queries; the configuration values per service are pulled from the Azure CLI or PowerShell. Common findings: SQL authentication still enabled on databases that support Entra-only authentication; Storage Accounts with shared-key authorization enabled when the workload only uses Entra-based access; long-term backup retention not configured on databases holding records subject to a multi-year retention obligation. Domain 6, Monitoring, logging, and Defender posture The sixth domain is the observability layer. The questions: what diagnostic settings are configured on every regulated resource; what is the destination for the diagnostic data (Log Analytics workspace, Storage Account for long-term retention, Event Hub for SIEM forwarding); what retention is configured on the workspace; what Microsoft Defender for Cloud plans are enabled, on which subscriptions, and what is the alert configuration; whether Microsoft Sentinel is deployed and if so, what data connectors are active. For regulated buyers the audit-passing baseline is: diagnostic settings on every resource that supports them, routing to a Log Analytics workspace with retention configured for the obligation period (typically one year minimum, six years for HIPAA breach investigation); Defender for Cloud enabled on the relevant plans (Servers, App Service, Storage, SQL, Containers, Key Vault, Resource Manager, DNS, APIs) with alerting wired to a defined response process; Sentinel or an equivalent SIEM ingesting the audit-relevant data. Evidence artifact: the diagnostic-settings inventory (Exhibit 6), the Defender for Cloud configuration export with plans and alert routing, and the Log Analytics retention settings. Where Sentinel is deployed, the data-connector inventory and a sample query proving end-to-end coverage on a regulated record class. Common findings: diagnostic settings configured on production but not on staging or development environments that contain regulated copies; Defender for Cloud enabled on the subscription but with the auto-provisioning of agents disabled, leaving compute resources without the Defender agent; Log Analytics retention at the default thirty or ninety days when a longer obligation applies. Domain 7, Azure Policy, governance, and tenant-wide guardrails The seventh domain is governance. Azure Policy is the enforcement surface that prevents the next configuration drift from producing a finding. The audit-relevant questions: what built-in Policy initiatives (Azure Security Benchmark, NIST SP 800-53, HIPAA HITRUST, SOC 2 Type II) are assigned to the tenant; what custom policies enforce the organization's standards; what is the deny-versus-audit posture; what is the compliance state per initiative; how does drift get remediated. For regulated buyers the audit-passing baseline is: at least one regulator-aligned built-in initiative assigned at the management-group root with deny-mode policies on the highest-risk configurations (public IP creation on regulated resources, public network access to Storage Accounts, deletion of audit-relevant resources, deployment of resources outside approved regions); custom policies for organization-specific standards; Policy compliance dashboard reviewed on a monthly cadence with documented remediation. Evidence artifact: the Policy assignment export (Exhibit 7), the compliance state by initiative, and the remediation log for the prior six months. Common findings: Policy initiatives assigned in audit mode only with no deny-mode posture; custom policies that enforce the organization's tagging standard but no policies enforcing the regulated-workload security configuration; compliance review cadence not documented and not exercised. Domain 8, Change management, exceptions, and the evidence library The eighth and final domain is the meta-control: how the organization manages change to the seven domains above. Every Conditional Access edit, RBAC assignment change, network rule modification, data-service configuration change, Key Vault access policy update, diagnostic-setting change, and Policy assignment change has a corresponding change record. The change record names the change, the approver, the executor, the date, and the post-change verification. The seventh domain governs the cloud's preventive controls; the eighth governs the operational discipline that keeps them in place. SOC 2 CC8.1, HITRUST 09.b, HIPAA §164.308(a)(8). Audit evidence: the change-management procedure, the change records for the prior six months cross-referenced against the Azure activity log entries that captured the technical changes, the exceptions register, and the evidence that exceptions are time-bounded with documented approvers. Common findings: change records exist for new resource deployments but not for configuration changes on existing resources; exceptions register exists but is stale, with multiple expired exceptions still flagged as active; the audit log shows configuration changes that have no corresponding change record. The deliverable structure The eight-domain walk produces a single written deliverable, typically forty to sixty pages, structured the same way every time so the buyer's team and the buyer's assessors know where to look. The structure: Executive summary. One page. Three paragraphs: what we walked, what we found at the highest priority, what we recommend in the next thirty / sixty / ninety days. Scope and method. One page. The eight domains, the time period of the data we collected, the access we used, the people we interviewed. Architecture overview. Two to four pages. The tenant / subscription / management-group structure, the regulated-workload posture, the data-flow narrative for the in-scope record set. Findings by domain. Eight sections, one per domain. Each section: the audit-passing baseline, the current state, the findings (with severity), and the evidence artifact (Exhibits 1–7 mapped here). Remediation calendar. Two to four pages. Each finding ranked by severity, with a target close date, a control owner, and the evidence artifact that will answer the auditor's question once the close is in place. Exhibits. The structured artifacts the buyer keeps and uses in the next audit. The buyer keeps the deliverable. If the engagement extends to remediation, the calendar drives the work. If it does not, the deliverable is still the artifact the buyer hands the next assessor and the answer to the audit committee's first question. How this fits with the Diagnostic and the broader engagement portfolio The Azure Security Review is one of the engagement shapes inside Securem's regulated-buyer portfolio. The other adjacent engagements are the Adopt-AI-Safely Diagnostic (the AI-architecture review), the HIPAA AI Architecture reference (the AI-specific deeper dive), the SOC 2 Type II preparation work covered in the SOC 2 Field Guide, and the HITRUST r2 roadmap from the HITRUST Field Guide. The Azure Security Review is the cloud-resource-side companion to the M365 + Entra ID Hardening Field Guide, the same tenant, walked from the resource side rather than the identity side. For organizations running predominantly on AWS rather than Azure, the equivalent method is the AWS Security Review (the cloud-resource side of an AWS-centric tenant). The eight domains translate cleanly: management-account structure replaces management groups, IAM replaces RBAC, VPC replaces VNet, KMS replaces Key Vault, the data-services list shifts to RDS/S3/DynamoDB, GuardDuty/Security Hub replaces Defender for Cloud, AWS Config replaces Azure Policy, and the change-management discipline is identical. We run the same method on AWS engagements; the deliverable structure and the eight-domain walk are constant. What we recommend A regulated mid-market organization on Azure should run the eight-domain review on a defined cadence, annually at minimum, with a focused mid-cycle review on any domain where the tenant's footprint changed materially (a new subscription, a new regulated data service, a new business acquisition that landed Azure resources into the existing tenant). The cadence is the discipline. The deliverable is the artifact. For organizations preparing for a SOC 2 Type II, HITRUST r2, or HIPAA assessment in the next ninety days, the right move is to run the review before the audit fieldwork starts, treat the deliverable as the assessor-facing evidence package, and use the remediation calendar to close the gaps before the auditor's first walkthrough. The orgs that operate in this mode reduce audit-cycle effort, surface the findings on their own timeline rather than the auditor's, and produce an artifact the assessor reads as the answer to most of the controls walkthrough rather than the start of the gap analysis. Eight domains. One written deliverable. Three weeks. The audit walks the same surface. Walk it first.