Azure Architecture Review Checklist

What to check: Check policy assignments, initiatives, exemptions, remediation tasks, deny controls, tagging policies, budgets, and compliance reporting.

Why it matters: Policy only helps when it is assigned at the right scope and remediated against existing resources.

Common failure pattern: DeployIfNotExists policies are assigned but no remediation tasks have been run.

Example finding: DeployIfNotExists policies are assigned but no remediation tasks have been run.

Suggested remediation direction: Assign baseline initiatives at the right scope and schedule remediation for existing non-compliant resources.

Evidence to collect: capture the Azure objects, scopes, assignments, resource identifiers, and timestamps that prove the condition exists. Good evidence should let another reviewer understand the result without reopening the Azure portal and repeating the same investigation.

How to review it: separate isolated exceptions from repeated patterns. One exception may be acceptable when it has an owner, expiry, and rationale; a repeated pattern usually indicates a platform or operating model issue that belongs in the report.

How to report it: write the finding in business-readable language, then attach the technical evidence. The reader should understand the risk, the affected scope, and the recommended direction before they reach the detailed resource list.

Automation note: automate the evidence collection and consistency checks where possible, but keep human review for scope decisions, materiality, accepted exceptions, and remediation sequencing.

What to check: Check hub-spoke design, private endpoints, public exposure, NSGs, route tables, DNS, firewall policy, DDoS protection, and controlled outbound traffic.

Why it matters: Networking determines blast radius, inspection points, and whether sensitive services remain private.

Common failure pattern: Management endpoints are exposed publicly without restricted administrative access paths.

Example finding: Management endpoints are exposed publicly without restricted administrative access paths.

Suggested remediation direction: Use private endpoints, approved jump paths, NSG rules, and central inspection where required.

Evidence to collect: capture the Azure objects, scopes, assignments, resource identifiers, and timestamps that prove the condition exists. Good evidence should let another reviewer understand the result without reopening the Azure portal and repeating the same investigation.

How to review it: separate isolated exceptions from repeated patterns. One exception may be acceptable when it has an owner, expiry, and rationale; a repeated pattern usually indicates a platform or operating model issue that belongs in the report.

How to report it: write the finding in business-readable language, then attach the technical evidence. The reader should understand the risk, the affected scope, and the recommended direction before they reach the detailed resource list.

Automation note: automate the evidence collection and consistency checks where possible, but keep human review for scope decisions, materiality, accepted exceptions, and remediation sequencing.

What to check: Check Defender coverage, security contacts, Key Vault controls, storage public access, encryption posture, vulnerability signals, and privileged access hygiene.

Why it matters: Security posture is strongest when prevention, detection, and response signals are all present.

Common failure pattern: Defender plans are inconsistent across subscriptions that host production workloads.

Example finding: Defender plans are inconsistent across subscriptions that host production workloads.

Suggested remediation direction: Enable relevant Defender plans and route alerts to an accountable security team.

Evidence to collect: capture the Azure objects, scopes, assignments, resource identifiers, and timestamps that prove the condition exists. Good evidence should let another reviewer understand the result without reopening the Azure portal and repeating the same investigation.

How to review it: separate isolated exceptions from repeated patterns. One exception may be acceptable when it has an owner, expiry, and rationale; a repeated pattern usually indicates a platform or operating model issue that belongs in the report.

How to report it: write the finding in business-readable language, then attach the technical evidence. The reader should understand the risk, the affected scope, and the recommended direction before they reach the detailed resource list.

Automation note: automate the evidence collection and consistency checks where possible, but keep human review for scope decisions, materiality, accepted exceptions, and remediation sequencing.

What to check: Check orphaned resources, unused disks, unassociated public IP addresses, reservations, budgets, tagging, SKU selection, and underutilised services.

Why it matters: Waste hides ownership gaps and makes platform improvement harder to fund.

Common failure pattern: Unattached disks and idle public IP addresses remain after workload changes.

Example finding: Unattached disks and idle public IP addresses remain after workload changes.

Suggested remediation direction: Remove unused resources, enforce owner tags, and review budget coverage for production scopes.

Evidence to collect: capture the Azure objects, scopes, assignments, resource identifiers, and timestamps that prove the condition exists. Good evidence should let another reviewer understand the result without reopening the Azure portal and repeating the same investigation.

How to review it: separate isolated exceptions from repeated patterns. One exception may be acceptable when it has an owner, expiry, and rationale; a repeated pattern usually indicates a platform or operating model issue that belongs in the report.

How to report it: write the finding in business-readable language, then attach the technical evidence. The reader should understand the risk, the affected scope, and the recommended direction before they reach the detailed resource list.

Automation note: automate the evidence collection and consistency checks where possible, but keep human review for scope decisions, materiality, accepted exceptions, and remediation sequencing.

What to check: Check diagnostic settings, Log Analytics retention, action groups, alert coverage, backup coverage, activity logs, and incident routing.

Why it matters: Operational readiness decides whether teams can detect and recover from failures.

Common failure pattern: Critical resources do not send diagnostics to a central workspace.

Example finding: Critical resources do not send diagnostics to a central workspace.

Suggested remediation direction: Apply diagnostic policies, validate alert routing, and set retention based on audit and operational needs.

Evidence to collect: capture the Azure objects, scopes, assignments, resource identifiers, and timestamps that prove the condition exists. Good evidence should let another reviewer understand the result without reopening the Azure portal and repeating the same investigation.

How to review it: separate isolated exceptions from repeated patterns. One exception may be acceptable when it has an owner, expiry, and rationale; a repeated pattern usually indicates a platform or operating model issue that belongs in the report.

How to report it: write the finding in business-readable language, then attach the technical evidence. The reader should understand the risk, the affected scope, and the recommended direction before they reach the detailed resource list.

Automation note: automate the evidence collection and consistency checks where possible, but keep human review for scope decisions, materiality, accepted exceptions, and remediation sequencing.

What to check: Check whether identity, connectivity, management, security, and workload subscriptions follow a clear landing zone model.

Why it matters: Landing zone design is the foundation for scalable governance and operations.

Common failure pattern: Shared platform services are mixed into workload subscriptions.

Example finding: Shared platform services are mixed into workload subscriptions.

Suggested remediation direction: Separate platform services, clarify subscription roles, and align policy inheritance to the target structure.

Evidence to collect: capture the Azure objects, scopes, assignments, resource identifiers, and timestamps that prove the condition exists. Good evidence should let another reviewer understand the result without reopening the Azure portal and repeating the same investigation.

How to review it: separate isolated exceptions from repeated patterns. One exception may be acceptable when it has an owner, expiry, and rationale; a repeated pattern usually indicates a platform or operating model issue that belongs in the report.

How to report it: write the finding in business-readable language, then attach the technical evidence. The reader should understand the risk, the affected scope, and the recommended direction before they reach the detailed resource list.

Automation note: automate the evidence collection and consistency checks where possible, but keep human review for scope decisions, materiality, accepted exceptions, and remediation sequencing.

What to check: Avoid treating Azure Advisor output as a full architecture review, ignoring landing zone structure, skipping evidence, or producing findings without remediation direction.

Why it matters: The review only creates value when the output helps people decide what to fix.

Common failure pattern: A spreadsheet lists issues but does not explain impact or priority.

Example finding: A spreadsheet lists issues but does not explain impact or priority.

Suggested remediation direction: Write findings with severity, evidence, impact, recommendation, and affected resources.

Evidence to collect: capture the Azure objects, scopes, assignments, resource identifiers, and timestamps that prove the condition exists. Good evidence should let another reviewer understand the result without reopening the Azure portal and repeating the same investigation.

How to review it: separate isolated exceptions from repeated patterns. One exception may be acceptable when it has an owner, expiry, and rationale; a repeated pattern usually indicates a platform or operating model issue that belongs in the report.

How to report it: write the finding in business-readable language, then attach the technical evidence. The reader should understand the risk, the affected scope, and the recommended direction before they reach the detailed resource list.

Automation note: automate the evidence collection and consistency checks where possible, but keep human review for scope decisions, materiality, accepted exceptions, and remediation sequencing.

What to check: Automate evidence collection, scoring, findings structure, and report generation while keeping expert review for interpretation and prioritisation.

Why it matters: Automation makes reviews repeatable and reduces time spent formatting output.

Common failure pattern: Teams automate checks but still hand-build reports each time.

Example finding: Teams automate checks but still hand-build reports each time.

Suggested remediation direction: Use Hygiara to turn automated Azure checks into structured findings and stakeholder-ready reports.

Evidence to collect: capture the Azure objects, scopes, assignments, resource identifiers, and timestamps that prove the condition exists. Good evidence should let another reviewer understand the result without reopening the Azure portal and repeating the same investigation.

How to review it: separate isolated exceptions from repeated patterns. One exception may be acceptable when it has an owner, expiry, and rationale; a repeated pattern usually indicates a platform or operating model issue that belongs in the report.

How to report it: write the finding in business-readable language, then attach the technical evidence. The reader should understand the risk, the affected scope, and the recommended direction before they reach the detailed resource list.

Automation note: automate the evidence collection and consistency checks where possible, but keep human review for scope decisions, materiality, accepted exceptions, and remediation sequencing.