Business services
List the revenue, clinical, financial, operational, customer, and safety processes that depend on Azure. Record maximum tolerable outage, data sensitivity, recovery objectives, peak periods, and executive owner.
Run an Azure Security Assessment That Produces Defensible Findings
Plan an Azure security assessment, collect reliable evidence, validate controls, rate risk, and turn findings into an accountable remediation plan.
Evidence before conclusions
An Azure assessment should explain what was tested, what was not, and why the finding matters
A useful Azure security assessment is more than a portal walkthrough or a list of Microsoft Defender for Cloud recommendations. It establishes the business and technical scope, gathers reproducible evidence, validates how controls behave, identifies attack paths, rates risk in context, and gives each finding an owner and closure test. Without that discipline, the report can miss unmanaged subscriptions, mistake a configured setting for an operating control, or bury urgent exposure beneath low-impact configuration noise.
This guide describes a practical method for assessing Azure tenants, management groups, subscriptions, workloads, and supporting Microsoft Entra controls. It is designed for internal reviews, pre-audit readiness, merger or migration due diligence, cyber-insurance preparation, vendor oversight, and planning a professional Azure Cloud Security Audit.
Preserve production safety. Use read-only roles and exports whenever possible. Any access test, policy change, network probe, failover, restore, or simulated detection must be authorized, scoped, scheduled, reversible, and supported by a rollback plan.
Assessment charter
Define the review boundary before opening the portal
Cloud boundary
Identify Microsoft Entra tenants, management groups, subscriptions, regions, landing zones, hybrid connections, Azure Arc resources, DevOps systems, and third-party security tools. Reconcile billing and directory records so shadow subscriptions do not escape review.
Technical services
Inventory identity, compute, containers, applications, storage, databases, networking, secrets, monitoring, backup, automation, and security plans. Include preview services and resources scheduled for retirement.
Responsibilities
Map what internal IT, security, developers, a managed service provider, application vendor, cloud architect, or business unit can change. Capture escalation contacts and access needed for evidence.
Assurance criteria
Select the Microsoft cloud security benchmark, internal standards, contracts, NIST CSF, HIPAA, PCI DSS, SOC 2, ISO 27001, CMMC, insurance requirements, or customer controls that matter. Document the version and interpretation used.
Exclusions and constraints
Record excluded subscriptions, unsupported systems, unavailable logs, inaccessible vendor-managed components, time limits, and prohibited testing. Treat a material evidence limitation as a report condition, not as a pass.
Collection plan
Use read-only evidence sources and preserve context
A screenshot may illustrate a point, but exports, queries, and dated inventories are easier to reproduce and compare. Keep the tenant, subscription, resource identifier, time range, filter, and collection method with the evidence.
| Domain | Evidence to collect | What it proves | Important limitation |
|---|---|---|---|
| Tenant and scope | Tenant details, management-group hierarchy, subscription list, Azure Resource Graph inventory, tags, owners | What exists and whether governance reaches the intended boundary | Tags can be missing or inaccurate; reconcile with business and billing records |
| Identity | Users, guests, authentication methods, Conditional Access policies, named locations, emergency accounts, sign-in and audit logs | Who can authenticate and under which conditions | Configuration alone does not prove a policy applied to real sign-ins |
| Privilege | Entra roles, Azure RBAC assignments, classic administrators, PIM settings, activations, access reviews | Who can change the directory, subscriptions, or critical resources | Custom roles and inherited assignments require permission-level review |
| Governance | Policy definitions, initiatives, assignments, exemptions, compliance, remediation tasks, locks | How unsafe configuration is prevented, detected, or corrected | An audit result without an owner and workflow may not reduce risk |
| Security posture | Defender plans, environment settings, recommendations, attack paths, alerts, regulatory mappings | Coverage and prioritized cloud posture findings | Plan availability, licensing, update latency, and preview status affect results |
| Network | VNets, subnets, peerings, public IPs, NSGs, effective rules, routes, firewalls, WAF, gateways, private endpoints, DNS | Which traffic paths may exist and how they are filtered | A diagram or rule list must be validated against effective routing and DNS |
| Workloads | VMs, extensions, endpoint status, update data, App Service, Functions, AKS, registries, images, Defender findings | Platform, runtime, vulnerability, and protection state | Agentless, agent-based, registry, and runtime views cover different risks |
| Data and secrets | Storage and database networking, authorization, encryption, auditing, Key Vault RBAC, keys, secrets, certificates, deletion protection | How sensitive information and credentials are reached and protected | Control-plane access does not fully describe data-plane permission |
| Monitoring | Activity Log export, diagnostic settings, workspaces, connectors, retention, analytics rules, incidents, playbooks | Whether important events become retained and actionable security signals | Enabled collection does not prove a rule fires or a responder acts |
| Recovery | Protected items, policies, vault settings, immutability, soft delete, Resource Guard, alerts, jobs, restore tests | Whether recovery points are covered, protected, and usable | A successful backup job is not evidence that an application can be recovered |
Repeatable testing
Use four evidence levels to distinguish claims from control operation
Statement
An owner says the control exists. Use the statement to locate evidence, not as final proof.
Documented design
A policy, standard, diagram, or procedure describes the intended control and responsibility.
Saved configuration
An export or query shows the setting is configured at a defined scope with identifiable parameters.
Operating result
Logs, controlled tests, alerts, tickets, reviews, and recovery results show that the control works over time.
High-impact safeguards such as privileged MFA, Conditional Access, external exposure controls, logging, alerting, and recovery deserve Level D evidence whenever testing can be performed safely.
Administrator procedure
Perform the assessment in a controlled sequence
Confirm authorization and least-privilege access
Document the sponsor, in-scope tenants and subscriptions, test window, prohibited actions, evidence retention, and incident contact. Prefer Global Reader, Security Reader, Reader, or specific read roles. Activate PIM only for the shortest period required. Do not request Global Administrator or Owner when a narrower read role will produce the evidence.
Establish a timestamped inventory
Export the management hierarchy and all subscriptions. Use Azure Resource Graph or an equivalent inventory source to enumerate resources, types, locations, resource groups, tags, public IP associations, and owners. Compare the result with architecture documentation and billing. Flag unmanaged subscriptions, orphan resources, expired projects, and untagged critical assets.
Examine control-plane identity
Review authentication methods, Conditional Access coverage, emergency access, sign-in risk, guests, service principals, managed identities, application credentials, Entra roles, Azure RBAC, custom roles, classic administrators, PIM eligibility, activations, and access reviews. Trace at least one high-impact administrator from authentication through effective resource permissions.
Trace governance inheritance
Select representative subscriptions from production, development, sandbox, identity, connectivity, and regulated boundaries. Review inherited policy, local assignments, exemptions, enforcement mode, remediation identity, compliance state, locks, and Defender plans. Confirm that the intended baseline reaches resources below the assignment scope.
Map attack surface and trust paths
Identify public IPs, internet-facing applications, load balancers, gateways, exposed management ports, public PaaS endpoints, private endpoints, peering, hybrid connectivity, DNS paths, egress, and third-party connections. Trace how a user or workload identity reaches a critical data store, including secrets and network controls.
Review workload and data protection
Sample every important service family. Examine supported versions, patch ownership, endpoint protection, vulnerability assessment, image and dependency provenance, deployment controls, managed identities, encryption, shared credentials, Key Vault, private access, auditing, and deletion protection. Enrich findings with internet exposure and business criticality.
Test visibility and response
Confirm required diagnostic categories reach their destinations. Review retention, workspace access, connector health, rule coverage, incident ownership, automation permissions, and evidence protection. With authorization, perform a benign event such as a test role assignment in a lab scope and trace it through Activity Log, Log Analytics, detection, incident creation, and response.
Validate recovery safeguards
Reconcile critical workloads with protected items and policies. Review immutability, soft delete, multi-user authorization, vault access, encryption, alerts, replication, and recovery documentation. Observe or review a representative restore test that measures data integrity, application startup, authentication, network dependencies, and recovery time.
Corroborate with interviews and records
Ask administrators how exceptions are approved, how urgent changes are made, how alerts are triaged, how owners are identified, and how restore decisions are authorized. Compare the answer with tickets, approvals, logs, and recent incidents. A process that depends on one person’s memory is an availability and governance risk.
Draft, challenge, and retest findings
Give technical owners an opportunity to provide missing evidence or correct factual errors. Do not weaken a valid risk because it is inconvenient. Finalize the finding with affected scope, evidence, risk, root cause, recommendation, owner, due date, dependency, and closure test. Retest priority issues after remediation.
Risk rating
Rate the scenario, not the isolated setting
A missing control can have very different significance depending on what it protects. Public access to a temporary demonstration service is not equivalent to public access to a production database containing regulated information. A permanent Contributor role may be moderate in an isolated development subscription but critical at a management group that contains production and security tooling.
Describe the threat actor or failure mode, the required access, the vulnerable condition, the reachable resource, the likely business effect, and the control that should interrupt the path. Consider likelihood and impact separately, then state the confidence level of the evidence. If logs are unavailable or asset ownership is uncertain, the uncertainty itself can increase risk or create an evidence finding.
Use Microsoft Defender for Cloud risk factors, attack paths, threat intelligence, known exploitation, and vulnerability data as inputs. Add business service criticality, data sensitivity, recovery dependence, concentration risk, and contractual duties. Do not automatically convert Secure Score or CVSS into the final business rating.
Finding anatomy
ConditionWhat is configured, absent, exposed, or operating incorrectly?
ScopeWhich tenants, subscriptions, resources, identities, or data are affected?
Threat pathHow could an attacker, insider, error, or outage use the condition?
Business impactWhat could happen to confidentiality, integrity, availability, safety, revenue, or obligations?
EvidenceWhich export, query, log, test, or interview supports the conclusion?
Closure testExactly what must be repeated to prove the risk has been reduced?
Deliverable quality
Make the report useful to executives and implementers
Executive summary
State the overall risk themes, most important attack paths, affected business services, material evidence limitations, and the decisions leadership must make. Avoid claiming that a point-in-time assessment proves continuous security.
Technical findings
Include observed condition, affected resources, evidence, threat scenario, business impact, severity rationale, control reference, recommended action, implementation caution, owner, target date, and validation method. Separate confirmed exposure from improvement opportunities.
Evidence index
Give every artifact a stable identifier, collection date, source, scope, custodian, sensitivity, and mapped finding or control. Do not include secrets, tokens, client data, or unnecessary personally identifiable information in the report package.
Remediation roadmap
Group work into immediate containment, near-term hardening, foundational governance, architecture projects, detection and recovery improvements, and recurring control operation. Show dependencies and change risk.
Residual risk and exceptions
Record why a recommendation is not adopted, what compensating control is operating, who accepts the remaining risk, when the decision expires, and what event requires early review.
Retest record
Reference the original finding, repeat the same procedure, record the new result, confirm the affected scope, note remaining exposure, and retain the evidence needed for audit or leadership review.
When the findings are ready for implementation, use the Azure security remediation roadmap. Technical teams can use the IT Perfection Azure security baseline guide when the work requires operational follow-through.
Assessment leadership
Independent Azure review led by a CISO with infrastructure depth
Ali Hassani brings 25+ years of IT, cybersecurity, Microsoft infrastructure, cloud security, network security, compliance, vulnerability management, incident response, and operations experience. That combination helps keep an Azure assessment technically specific while connecting findings to business impact, ownership, implementation dependencies, and evidence.
When an independent assessment is useful
- Executives need a prioritized view beyond the platform score
- Internal teams designed or operate the controls being reviewed
- An MSP or integrator’s scope and evidence need validation
- Regulated workloads are moving into Azure
- A security incident or insurer request created urgency
- Leadership needs a defensible remediation plan
Official guidance
Primary sources for continued review
Microsoft updates Azure capabilities, portal locations, licensing, defaults, feature status, and prerequisites. Confirm the current product documentation before a production change.
Overview of the Microsoft cloud security benchmarkMicrosoft official guidanceWhat is Cloud Security Posture ManagementMicrosoft official guidanceCloud Secure Score in Microsoft Defender for CloudMicrosoft official guidanceOverview of Azure PolicyMicrosoft official guidanceNIST Cybersecurity Framework 2.0NIST official guidanceCloud Security Technical Reference ArchitectureCISA official guidance
Practical questions
Frequently asked questions
What access is needed for an Azure security assessment?
Prefer least-privilege read roles such as Global Reader, Security Reader, Reader, or specific service read roles. Use PIM for temporary access and request broader authority only when an authorized test requires it.
How long does an Azure security assessment take?
Duration depends on tenant count, subscriptions, workloads, architecture, evidence availability, interviews, regulations, and testing depth. Define the scope and evidence plan before estimating effort.
What is strong Azure audit evidence?
Strong evidence is current, attributable, reproducible, complete for the stated scope, and connected to operation. Exports, queries, logs, controlled tests, tickets, reviews, and restore results are stronger than an undated screenshot alone.
Should every Defender recommendation become a finding?
Not automatically. Validate the condition, affected asset, exposure, business impact, compensating controls, and implementation risk. Group duplicates and preserve significant recommendations that require action or risk acceptance.
How are findings closed?
Repeat the original test, confirm the full affected scope, verify that no material bypass remains, preserve before-and-after evidence, and document residual risk and approval.
This material is for initial guidance only and does not replace a professional cybersecurity audit, compliance assessment, penetration test, or legal/compliance review. Validate configuration, licensing, service availability, architecture, and business impact before production changes.