A regulated organization running on Azure usually has two artifacts that look like a security review and are not. The first is the Microsoft Defender for Cloud Secure Score dashboard. The second is a CIS Azure Foundations Benchmark exception report from a scanner. Both are useful inputs. Neither answers the questions a SOC 2, HITRUST, or HIPAA assessor will actually ask, because automated tools score posture and an assessor walks architecture.
When I review an Azure tenant that has to survive an audit rather than a board slide, I walk eight domains in a fixed order — the order an audit walks them — and I make each one produce a named evidence artifact and a finding mapped to the control a regulator cares about. This is the method.
1. Tenant and subscription structure
The walk opens at the management-group, subscription, and resource-group hierarchy. The question is whether resources are organized to support policy enforcement at the right scope, cost attribution at the right tier, and least-privilege RBAC at every layer. A flat tenant produces RBAC findings throughout the rest of the review; a management-group structure with environments segregated and policy applied at the root produces a clean baseline. Evidence: a current architecture diagram of the tree, with environment and regulated-workload labels.
2. RBAC and Privileged Identity Management
Every role assignment has a principal, a role, and a scope. I count standing administrative assignments outside PIM, service principals holding privileged roles, and assignments granted at subscription or management-group level rather than the narrowest scope the workload needs. Most tenants have extended PIM to Entra directory roles but not to Azure resource roles, and that is where the over-privilege hides. Evidence: a privileged-role inventory with the standing-versus-eligible flag and the last access review.
3. Network architecture and segmentation
The passing baseline for regulated workloads: no PaaS service exposes a public endpoint by default, Private Endpoints with Private DNS for every service that supports them, NSGs with explicit allow-rules over a default deny, centralized egress control, and diagnostic settings on every NSG, firewall, and gateway. Evidence: a written network diagram tracing the regulated data flow from ingress to egress, paired with the NSG rule export.
4. Identity and key material on resources
Which workloads run with managed identities versus stored credentials; where key material lives; how Key Vault access is controlled. The baseline is managed identities on every compute resource that calls another service, Key Vault on the RBAC permission model with soft delete and purge protection, and customer-managed keys on the regulated record set. Evidence: the managed-identity and Key Vault inventories with their configuration settings.
5. Data services and the regulated record set
Every data service holding regulated data gets walked individually: encryption posture, public-endpoint posture, authentication mode, audit logging, and backup retention with restore-test evidence. The common findings are SQL authentication still enabled where Entra-only is available, shared-key authorization left on, and long-term retention never configured. Evidence: a data-services inventory, one row per instance, flagged for the regulated record set.
6. Monitoring, logging, and Defender posture
Diagnostic settings on every regulated resource, routed to a Log Analytics workspace with retention set to the obligation period; Defender for Cloud enabled on the relevant plans with alerting wired to a real response process; a SIEM ingesting the audit-relevant data. The recurring gap is logging configured on production but not on the staging and development environments that hold regulated copies. Evidence: the diagnostic-settings inventory and the Defender configuration export.
7. Azure Policy and tenant-wide guardrails
Policy is the surface that prevents the next configuration drift from becoming the next finding. The 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 rather than audit-mode only. Evidence: the policy assignment export, the compliance state by initiative, and the prior six months of remediation.
8. Change management and the evidence library
The meta-control: how the organization manages change to the seven domains above. Every privileged change should have a record naming the change, the approver, the executor, the date, and the post-change verification — cross-referenced against the Azure activity log. The common finding is change records for new deployments but not for configuration changes on existing resources, and a stale exceptions register full of expired exceptions still flagged active.
The deliverable
The eight-domain walk produces one written deliverable, structured the same way every time: an executive summary, scope and method, an architecture overview, findings by domain with severity and evidence, and a remediation calendar that ranks each finding with a target close date and the artifact that will answer the auditor's question once it is closed. The same eight domains translate cleanly to AWS — management accounts for management groups, IAM for RBAC, VPC for VNet, KMS for Key Vault, GuardDuty and Security Hub for Defender, Config for Policy. The audit walks this surface either way. Walk it first.
