Most security audits produce a thick report and no findings that matter. They check whether MFA exists somewhere in the tenant and tick a box. They confirm a firewall is deployed without asking what it inspects. They generate compliance theatre.
This is the list we actually run. Ninety checks, grouped into nine control domains. Each one is a specific thing to look at, with a note on why it matters. We use it on every Azure tenant we audit, and it consistently surfaces real exposure that lighter reviews miss.
How to use it. Work domain by domain. For each check, find the evidence in the portal, in policy, or in logs, and record the state. Treat the severities as a triage order: critical findings are exploitable now and get fixed this week, important findings are material gaps to close this quarter, recommended findings are hardening that raises the floor over time. Scope it to a single tenant and subscription set; a multi-tenant estate runs the list once per tenant.
1. MFA enforced for all admin accounts. A Conditional Access policy requires MFA for any role above Reader. Verify there are no exemptions for service accounts that should be using managed identity instead.
2. No standing access on privileged roles. Owner, Contributor, and User Access Administrator assignments are routed through PIM with approval and time-bound activation. Permanent assignments are the finding.
3. Break-glass accounts exist and are controlled. At least two emergency access accounts, excluded from Conditional Access that could lock them out, with long random credentials in a sealed store and alerting on every sign-in.
4. Guest access is governed. External (B2B) identities are reviewed, scoped to least privilege, and subject to access reviews. Stale guests with lingering permissions are a common backdoor.
5. Legacy authentication is blocked. A Conditional Access policy blocks legacy protocols (POP, IMAP, SMTP auth, older clients) that bypass MFA entirely.
6. Sign-in risk policies are active. Identity Protection policies respond to risky sign-ins and risky users with MFA challenge or block, not just logging.
7. Service principals are inventoried and scoped. Every app registration and enterprise app is accounted for, scoped to least privilege, with no Owner or Contributor at subscription scope unless justified.
8. Credentials on service principals expire and rotate. No non-expiring secrets. Federated credentials preferred over client secrets for CI/CD. Anything with a static secret is stored in Key Vault and rotated.
9. Conditional Access requires compliant or managed devices. Access to sensitive applications is gated on device compliance or hybrid join, not just user credentials.
10. Access reviews run on a schedule. Periodic recertification of privileged roles, group memberships, and guest access, with owners who actually action the results.
11. No NSG allows 0.0.0.0/0 inbound on management ports. RDP (3389) and SSH (22) are never open to the internet. Administrative access goes through Bastion or a controlled jump path.
12. Public IPs are inventoried and justified. Every public IP maps to a deliberate need. Orphaned and forgotten public endpoints are the ones that get scanned and popped.
13. Private endpoints on PaaS services. Storage, databases, Key Vault, and other PaaS services use private endpoints with public network access disabled.
14. Hub-and-spoke with forced inspection. Spoke-to-spoke traffic is routed through the hub firewall via UDR. East-west traffic is inspected, not trusted by default.
15. Azure Firewall or NVA with the right feature set. For regulated workloads, the firewall does TLS inspection, IDPS, and URL filtering. A Standard SKU that can’t see encrypted traffic is a gap.
16. NSG flow logs enabled. Flow logs are on and feeding traffic analytics, so you can actually investigate lateral movement after an incident.
17. DDoS protection on internet-facing workloads. DDoS Network Protection is enabled on VNets hosting public services that matter, not left at the basic free tier for a production payments app.
18. WAF in front of public web applications. Application Gateway or Front Door WAF runs OWASP rule sets in prevention mode, not detection-only.
19. No overly permissive service endpoints. Service endpoints and firewall rules on PaaS resources don’t allow entire Azure regions or 0.0.0.0/0 where a private endpoint belongs.
20. DNS is private and controlled. Private DNS zones resolve private endpoints. There’s no accidental public resolution path leaking internal hostnames or routing around the firewall.
21. Storage account public blob access disabled. Public blob access is off at the account level, enforced by policy. This is the single most common cause of Azure data leaks.
22. Secure transfer required everywhere. HTTPS-only on storage, minimum TLS 1.2 on every data service. No plaintext data in transit.
23. Encryption at rest with managed keys. All data services encrypt at rest. For sensitive workloads, customer-managed keys in Key Vault rather than platform-managed defaults.
24. Key Vault is locked down. Soft delete and purge protection are on. Access is via RBAC or tightly scoped access policies. Public network access is disabled in favour of private endpoints.
25. SQL and PostgreSQL transparent data encryption verified. TDE is enabled on managed databases, with CMK where the data classification demands it.
26. Data classification is applied. Sensitive columns and stores are classified, with a DataClassification tag enforced so downstream handling policies have something to act on.
27. No secrets in code or config. Source repos and pipeline variables are scanned for keys, connection strings, and tokens. Secrets live in Key Vault, referenced not embedded.
28. Storage account network rules deny by default. The default action on storage firewalls is Deny, with explicit allow for the private endpoints and services that need it.
29. Immutable storage for compliance data. Audit logs and regulatory records use immutability (WORM) policies so they can’t be altered or deleted within the retention window.
30. Backups are encrypted and access-controlled. Backup vaults encrypt their contents and restrict restore permissions, so a compromised account can’t exfiltrate data through the backup path.
31. Diagnostic settings enabled on all resources. Every resource that can emit diagnostics sends them to a central Log Analytics workspace. Logging disabled is a finding on its own.
32. Logs go to Log Analytics, not just a storage account. Logs sent only to a storage account with default retention are effectively write-only. Centralise them where they can be queried and alerted on.
33. Activity log retention meets policy. The subscription Activity log is exported and retained for at least the period your compliance regime requires, typically a year or more.
34. Entra ID sign-in and audit logs are retained. Sign-in and audit logs are exported to Log Analytics or a SIEM, because the default retention in Entra is too short for an investigation.
35. Key Vault access is logged. Every secret, key, and certificate access is logged and monitored. Unexpected access to a signing key is something you want to see.
36. Alerting exists for high-signal events. Alerts fire on privileged role activation, policy changes, firewall rule changes, and break-glass sign-ins. Logs nobody reads are not monitoring.
37. Log integrity is protected. The logging pipeline and its storage are access-controlled so an attacker can’t quietly disable diagnostics or delete the trail.
38. A SIEM consumes the important signals. Sentinel or an equivalent ingests identity, network, and resource logs with detection rules, for tenants with the maturity to run one.
39. Time is synchronised and consistent. Timestamps across logs are coherent (UTC throughout) so correlation during an incident actually works.
40. Monitoring covers cost and quota anomalies. Sudden spend or quota spikes are alerted, because a crypto-mining compromise often shows up first as a billing anomaly.
41. Management group hierarchy exists. Policies and RBAC are applied at the management group level and inherited, not pasted subscription by subscription.
42. Region restriction policy is enforced. Resources deploy only to approved regions. This stops production data quietly appearing in an unapproved region after a test.
43. Tag enforcement at deployment. Required tags (CostCentre, Owner, Environment, DataClassification) are enforced by policy, not requested politely.
44. Allowed resource types and SKUs are constrained. Policy limits which resource types and SKUs can be deployed, reducing the surface and preventing expensive or risky services appearing unreviewed.
45. Azure Policy is in enforce mode, not just audit. Critical guardrails use Deny effects. A tenant full of audit-only policies documents drift instead of preventing it.
46. Resource locks on critical infrastructure. CanNotDelete locks protect platform resources, key vaults, and production data stores from accidental deletion.
47. Subscription ownership is clear. Every subscription has an accountable owner and a defined purpose. Orphaned subscriptions accumulate unmanaged risk.
48. Budgets and spend alerts are configured. Budgets exist per subscription with alerts, so cost surprises and abuse are caught early.
49. A baseline policy initiative is assigned. The Azure Security Benchmark or a CIS initiative is assigned and its compliance score is tracked over time.
50. Exemptions are documented and time-bound. Every policy exemption has a recorded reason, an owner, and an expiry. Permanent silent exemptions defeat the controls.
51. Defender for Cloud is enabled above the free tier. Production workloads have the paid Defender plans on, not the free tier that only does posture scoring.
52. Defender for Servers is on for VMs. Endpoint protection, vulnerability assessment, and threat detection are active on every VM, not a subset.
53. Defender for Storage is on. Malware scanning and anomaly detection on storage accounts catch malicious uploads and exfiltration patterns.
54. Defender for SQL and databases is on. Threat detection on managed databases flags SQL injection attempts and anomalous access.
55. Defender for Containers is on. AKS and container registries are scanned for vulnerabilities and runtime threats.
56. Defender for Key Vault is on. Anomalous access to secrets and keys is detected and alerted.
57. Vulnerability assessment is running and triaged. Findings from the integrated scanner are reviewed and remediated, not just generated.
58. Just-in-time VM access is enabled. Management ports on VMs are closed by default and opened on request for a limited window, where Bastion isn’t the access path.
59. Adaptive controls and recommendations are actioned. Secure score recommendations are worked through on a cadence, with the score trending up.
60. Threat alerts route to a responder. Defender alerts go somewhere a human (or an automated playbook) acts on them, with defined severity-based response times.
61. Backups exist for everything that matters. VMs, databases, and critical PaaS data have configured backups. Assuming the cloud backs things up for you is the finding.
62. Backup frequency meets the RPO. Backup schedules match the recovery point objective each workload actually requires, not a default daily for a system that can’t lose an hour.
63. Restores are tested. Backups are periodically restored to prove they work. An untested backup is a hope, not a control.
64. Backups are isolated from production credentials. Backup data is protected so a compromise of production identities can’t also delete or encrypt the backups (the ransomware path).
65. Soft delete on backup vaults. Soft delete is enabled so deleted backups are recoverable for a window, defending against malicious or accidental deletion.
66. Geo-redundancy matches the DR strategy. Backup and storage redundancy (GRS or paired-region) aligns with the documented disaster recovery plan.
67. A DR plan exists and names a paired region. There’s a written DR plan with a target region, an RTO, and an RPO, not just an assumption that failover will work.
68. Failover has been exercised. The DR plan has been tested at least once with a real or simulated failover, with results recorded.
69. Dependencies are mapped for recovery. Recovery order accounts for dependencies (identity, networking, data) so a restore doesn’t stall on a missing prerequisite.
70. Backup access and changes are logged. Modifications to backup policies and restore operations are logged and alerted, since attackers target the backup configuration first.
71. Pipelines authenticate with federated identity. CI/CD uses workload identity federation (OIDC) to Azure rather than long-lived service principal secrets.
72. Pipeline secrets are in a secret store. Build and release secrets come from Key Vault or a secured variable group, never plaintext in YAML or repo files.
73. Infrastructure as code is peer-reviewed. Terraform or Bicep changes go through pull request review before they can deploy. No console click-ops on production.
74. IaC is scanned for misconfiguration. A scanner (Checkov, tfsec, or equivalent) runs in the pipeline and blocks insecure infrastructure before it deploys.
75. Container images are scanned. Images are scanned for vulnerabilities at build and in the registry, with a policy that blocks critical findings from promotion.
76. Image provenance is controlled. Deployments pull from trusted registries only, with image signing or admission control rejecting unknown sources.
77. Branch protection and required reviews are enforced. The main branch requires review and passing checks. Direct pushes to production branches are blocked.
78. Secret scanning runs on the repository. Push protection and historical scanning catch credentials committed to source before they leak.
79. Pipeline permissions are least privilege. Deployment identities are scoped to the specific resource groups they manage, not Contributor across the subscription.
80. Dependencies are tracked and updated. A dependency and SBOM process flags vulnerable libraries, with a route to patch them rather than letting them rot.
81. Control-to-evidence mapping exists. Each required control maps to a specific, retrievable piece of evidence (a policy, a log query, a config export). Auditors ask for evidence, not assurances.
82. Compliance score is tracked over time. The regulatory compliance dashboard in Defender for Cloud is monitored against the relevant standard (CIS, ISO 27001, the applicable local regime).
83. Data residency is provable. You can demonstrate where regulated data physically resides, with policy enforcing the approved regions.
84. Retention policies match regulatory requirements. Log, backup, and record retention periods are set to the longest applicable legal requirement and enforced.
85. Access reviews are documented and signed off. The output of periodic access recertification is retained as evidence with owner sign-off.
86. Incident response plan exists and is current. A written, tested incident response plan defines roles, escalation, and regulatory reporting timelines.
87. Third-party and supplier risk is registered. External providers with access to data or systems are inventoried with their risk assessed, supporting DORA and NIS2 style obligations.
88. Change management is evidenced. Production changes are traceable through pull requests, approvals, and deployment logs, satisfying change-control requirements.
89. Penetration test results are tracked to closure. Findings from vulnerability scans and penetration tests are logged, prioritised, and tracked through remediation, not filed and forgotten.
90. Board-level reporting on cyber risk exists. Security posture is reported to leadership on a defined cadence, with a named owner accountable for ICT risk. Regulators increasingly require this explicitly.
A typical audit runs the full list against a tenant over one to two weeks. We pull evidence for each check, record the state, and assign a severity. The output is not a thick document. It’s a ranked list of findings, each tied to the check that surfaced it, with a concrete remediation and an owner.
Critical findings get a same-week fix plan. Important findings get scheduled into the quarter. Recommended findings feed a hardening backlog. We then re-run the relevant checks after remediation to confirm the gaps actually closed, because an audit that doesn’t verify the fix is half a job.
Most tenants we run this against fail somewhere between fifteen and thirty checks on the first pass, and a handful of those are critical and exploitable today. None of them are exotic. They’re the controls that get skipped under delivery pressure and never get revisited.
If you want this run against your environment, our cybersecurity team does exactly this work, with the evidence and the remediation plan delivered as one piece. Book a consultation and we’ll scope an audit against your tenant and tell you, before we start, roughly where we expect the gaps to be.