In this blog post The Azure Security Controls I Check First in an Enterprise Review, I will walk through the controls I look at before I spend time debating tooling, architecture diagrams, or vendor claims. When I review an Azure estate, I want to know one thing quickly: is the environment fundamentally governable, or are we looking at a collection of cloud resources that only appear secure from a distance?

Azure gives you a very large security surface to work with. Microsoft frames it as defense in depth across identity, network, compute, data, operations, and monitoring, and that is the right way to think about it. The mistake I still see is teams treating Azure security as a list of products instead of a control system.

I do not start with the flashiest service. I start with the controls that tell me whether the platform can resist obvious failure modes, whether privilege is contained, whether exposure is measurable, and whether the environment will hold up under audit pressure.

Identity Comes Before Everything Else

Identity is still the primary control plane in Azure. If identities are weak, over-privileged, or unmanaged, every other control can be bypassed by somebody who should never have had that level of access in the first place.

The first things I check are Microsoft Entra MFA coverage, Conditional Access enforcement, Privileged Identity Management for administrative roles, and whether service-to-service access uses managed identities instead of embedded secrets. If Global Administrator is effectively permanent, or if subscription owners are scattered across operational teams with no approval flow, the review already has a direction.

This is also where I look for separation between human admin accounts, workload identities, and emergency access design. Most Azure breaches I worry about do not begin with a nation-state-grade exploit. They begin with an avoidable privilege problem.

Policy and Posture Tell Me Whether Governance Is Real

Once identity is in reasonable shape, I move to Azure Policy and Microsoft Defender for Cloud. This is where I find out whether the organisation has actual platform guardrails or just good intentions documented in PowerPoint.

The Microsoft cloud security benchmark v2 preview is useful here because it turns the conversation into concrete control domains: identity management, privileged access, network security, data protection, logging and threat detection, posture and vulnerability management, backup and recovery, and now artificial intelligence security as well. More importantly, it maps many of those controls to Azure Policy so you can measure them instead of arguing about them.

In practice, I check whether core policies are denying risky deployments, auditing drift, and feeding a working remediation backlog. If Defender for Cloud secure score is low, that alone does not tell me much. What matters is whether the underlying recommendations are being operationalised or ignored month after month.

Network Isolation Still Separates Mature Azure Estates from Messy Ones

After that, I look at how the estate handles network exposure. I want to know how much is publicly reachable, how much is privately routed, and whether the organisation can explain its north-south and east-west traffic model without hand-waving.

At minimum, I expect to see sensible subnet segmentation, Network Security Groups used deliberately, and a clear strategy for private connectivity. In better environments I usually see Azure Private Link, Azure Firewall where central inspection makes sense, DDoS protection for exposed workloads, and Application Gateway or Front Door with WAF where internet-facing applications exist.

One control I pay more attention to now is Azure Virtual Network Manager. Its security admin rules let central teams enforce non-negotiable network controls across estates without relying on every landing zone owner to make the right call. That is a meaningful maturity signal in large environments.

Secrets, Keys, and Data Protection Usually Reveal Operational Discipline

The next control area is data protection, but I do not start with an abstract encryption discussion. I start with where secrets live, who can retrieve them, and whether key management is being treated as a platform responsibility.

Azure Key Vault or Managed HSM should be doing the heavy lifting for sensitive secrets and customer-managed keys where the risk profile justifies them. If I find connection strings in automation scripts, certificates being handled manually, or broad access to key material without role separation, that usually points to deeper operational shortcuts.

I also check whether teams understand the current Azure encryption direction. For virtual machines, encryption at host is the modern baseline, and Azure Disk Encryption is now on a retirement path. That matters because many estates still treat old encryption decisions as permanent architecture.

For data services, I look for the basics done properly: private endpoints where required, RBAC over shared keys wherever possible, short-lived delegated access rather than long-lived exceptions, and clear ownership of backup and restore protections. Good data security in Azure usually looks boring. That is the point.

Logging and Threat Detection Need to Be Designed, Not Assumed

One of the fastest ways to expose a weak Azure operating model is to ask a simple question: if a privileged identity makes a suspicious change right now, where would you see it, who would be alerted, and how fast could you investigate it?

I expect to see Azure Activity Logs, resource logs, diagnostic settings, and workload telemetry routed with intent, not enabled randomly. Azure Monitor gives the data plane, Defender for Cloud gives posture and threat recommendations, and Microsoft Sentinel gives organisations a way to centralise investigation and response. But none of that helps if log retention is inconsistent or critical services are not forwarding telemetry.

This is where I often align the conversation to the ACSC and broader Australian audit expectation: evidence matters. It is not enough to say a control exists. You need to show that it is enforced, monitored, and retained long enough to support incident analysis and compliance review.

Resilience Controls Matter More Than Most Security Reviews Admit

A surprising number of security reviews underweight backup, recovery, and incident readiness. I do not. Availability failures are security events when the business cannot recover critical systems or prove recovery paths under pressure.

So I check Azure Backup, Site Recovery where it is relevant, privileged protection around backup infrastructure, and whether recovery testing is actually happening. I also want to see incident roles, escalation paths, and at least some evidence that containment and recovery have been thought through before the next bad day arrives.

The Cloud Adoption Framework security guidance is useful here because it treats security as something sustained across strategy, planning, readiness, governance, and operations. That reflects reality better than a one-off hardening project ever will.

My First-Hour Azure Control Checklist

If I only had an hour with a new environment, this is the order I would review it in:

1. Entra MFA, Conditional Access, PIM, and privileged role sprawl
2. Azure Policy coverage and Defender for Cloud recommendations
3. Public exposure, private endpoints, segmentation, and egress control
4. Key Vault usage, secrets handling, and encryption design
5. Logging coverage, alert routing, and investigation readiness
6. Backup protection, recovery posture, and incident response readiness

That order is deliberate. It moves from who can act, to what they can deploy, to what is exposed, to what is protected, to what you can detect, to whether you can recover.

What a Strong Review Usually Shows

The strongest Azure environments are not the ones with the most security products switched on. They are the ones where identity is constrained, policy is automated, network paths are intentional, secrets are centrally managed, telemetry is usable, and resilience is tested.

That is why I check these controls first. They tell me very quickly whether the organisation has built an Azure estate that can scale safely, or whether it is still relying on skilled individuals to compensate for missing platform discipline.

In enterprise reviews, that distinction matters more every year. Azure security is no longer about whether the platform has enough controls. It is about whether the organisation has turned those controls into an operating model that can survive growth, audits, and real incidents.