Being in the cloud isn't the same as being secure in the cloud. Here's a practical checklist based on Microsoft's own Well-Architected Framework.
Azure's underlying infrastructure is secured by Microsoft. What runs on top of it — identity, network configuration, access policies, monitoring — is the customer's responsibility. That split is the shared responsibility model, and it's the single most common source of gaps we see: businesses assume Microsoft's security covers more of the stack than it actually does.
Microsoft's own Well-Architected Framework gives a structured way to review this, with security as one of five pillars covering the full environment.
| Pillar | What it covers |
|---|---|
| Security | Identity, data protection, network isolation, threat detection |
| Reliability | Recovering from failure, redundancy, resilience |
| Cost optimisation | Spending on the right things, at the right scale |
| Operational excellence | Monitoring, automation, keeping systems running smoothly |
| Performance efficiency | Meeting demand efficiently as load changes |
You don't need to adopt the whole framework to get value from the security pillar alone — here's where to start.
Most Azure security incidents trace back to identity, not infrastructure. Questions worth asking of your own environment:
It's worth actually listing what's publicly exposed rather than assuming. Management ports (RDP, SSH) open directly to the internet on a VM are still one of the most common findings in real reviews — usually left open from an early setup and never revisited once the environment matured.
Network security groups, private endpoints where appropriate, and a clear boundary between what's public-facing and what isn't are the basics worth confirming, not assuming.
An environment can be reasonably well configured and still be blind — no one gets alerted when something changes, a new admin role is granted, or unusual sign-in activity occurs. Azure Monitor, Microsoft Defender for Cloud recommendations, and sign-in log review aren't optional extras once an environment is handling anything business-critical; they're what turns "probably fine" into something you can actually verify.
Environments drift. A configuration that was correct six months ago may not be today, especially as new resources, integrations and staff changes accumulate. A periodic review — quarterly is reasonable for most SMEs — catches drift before it becomes an incident, rather than after.
This pairs naturally with keeping spend under control too — see our Azure cost optimisation guide if a security review surfaces resources that shouldn't exist at all.
No — the five pillars can be reviewed independently. Most SMEs get the most value starting with the security pillar alone, then expanding to cost, reliability and the others later.
For a typical SME environment, a focused review of identity, network exposure and monitoring can usually be done in days, not weeks — it's a review of configuration, not a rebuild.
It's a strong source of recommendations, but it surfaces findings — it doesn't act on them. Someone still needs to review, prioritise and actually close the gaps it identifies.
Book a free Well-Architected review and we'll walk through identity, network and monitoring with you — no commitment required.
