Azure Security Assessment Checklist for Enterprise Organizations

Enterprise Azure environments rarelylook like the reference architecture diagrams. Years of mergers, business unitsprawl, contractor access, and "temporary" permissions that never gotrevoked leave most large tenants with a security posture nobody has a completepicture of. A structured assessment checklist is how you get that picture back.

This is a working checklist,organized the way an assessor actually moves through a tenant: identity first,then the resources identity protects, then the data those resources hold, thenthe ability to detect and respond when something goes wrong.

Why Enterprise AzureAssessments Are Different

A startup's Azure tenant might haveone subscription and a handful of admins. An enterprise tenant typically has:

• Multiplesubscriptions across business units, environments, and acquired companies
• Hybrididentity (Azure AD Connect / Entra Connect syncing from on-prem AD)
• Dozensor hundreds of app registrations and service principals, many undocumented
• ComplexConditional Access policies layered over years by different teams
• Regulatoryobligations spanning multiple jurisdictions (UK GDPR, FCA, HIPAA, PCI DSS,depending on sector)

The checklist below is scoped forthat complexity. Each section notes what "good" looks like and thespecific enterprise failure modes to watch for.

1. Identity and Access(Microsoft Entra ID)

This is where the assessment shouldstart. Identity compromise is the single most common entry point intoenterprise Azure environments.

• GlobalAdministrator count is minimal (ideally fewer than 5) and every holder hasphishing-resistant MFA
• PrivilegedIdentity Management (PIM) is enabled for all privileged roles, with just-in-timeactivation rather than standing access
• ConditionalAccess policies enforce MFA for all users, block legacy authentication, andapply device compliance checks for privileged access
• Emergency"break-glass" accounts exist, are excluded from Conditional Access,and are monitored for any sign-in activity
• Guestuser access is reviewed on a defined cadence, with expiration policies onexternal sharing
• Serviceprincipals and app registrations have an owner of record, and credentials(client secrets/certificates) are rotated on a defined schedule
• Staleaccounts (no sign-in in 90+ days) are identified and disabled, not just flagged
• Directoryrole assignments are reviewed against actual job function, not historicalconvenience
• AzureAD Connect / Entra Connect synchronization account permissions are scopedcorrectly and the sync server is hardened
• Cross-tenantaccess settings are explicitly configured, not left on default

Enterprise failure mode to watch for: service principalscreated years ago for a project that no longer exists, still holdingContributor or Owner rights at the subscription level, with no owner able toexplain why.

2. Subscription andManagement Group Structure

• Managementgroup hierarchy reflects actual organizational and compliance boundaries, notjust historical subscription sprawl
• AzurePolicy is applied at the management group level for baseline controls (allowedregions, required tags, encryption enforcement)
• Subscriptionowners are documented and reviewed; orphaned subscriptions (owner left thecompany) are identified
• Resourcelocks are applied to critical production resources to prevent accidentaldeletion
• Costanomalies are monitored, since unexpected spend is often the first visible signof a compromised account provisioning resources

3. Network Architecture

• Hub-and-spokeor Virtual WAN topology is documented and matches what's actually deployed
• NetworkSecurity Group (NSG) rules are reviewed for any rule permitting inbound accessfrom Any/0.0.0.0/0 on management ports (RDP, SSH, database ports)
• AzureFirewall or a comparable NVA is positioned at trust boundaries, not relied ononly at the perimeter
• PrivateEndpoints are used for PaaS services (Storage, SQL, Key Vault) instead ofpublic endpoints, particularly for anything holding regulated data
• ExpressRouteor VPN connections back to on-premises are reviewed for the scope of accessthey grant
• DDoSProtection Standard is enabled for internet-facing critical workloads
• NetworkWatcher and flow logs are enabled on production VNets

Enterprise failure mode to watch for: a peered VNet from anacquired subsidiary that was never re-segmented, giving that subsidiary's(differently governed) environment a network path into core production.

4. Data Protection

• StorageAccounts have "Allow Blob public access" disabled at the accountlevel unless a specific container requires it, with that exception documented
• Storagefirewall rules restrict access to known networks or Private Endpoints
• Encryptionat rest is confirmed for Storage, SQL, and Cosmos DB, with customer-managedkeys used where compliance requires it
• KeyVault access policies (or RBAC model) follow least privilege, and Key Vaultlogging is enabled
• Dataclassification labels (via Microsoft Purview or equivalent) are applied tosensitive data stores
• Backupcoverage exists for all production data stores, with recovery actually tested,not just configured
• Softdelete and versioning are enabled on storage holding critical or regulated data

5. Compute and WorkloadSecurity

• MicrosoftDefender for Cloud is enabled across all subscriptions, with plans activatedfor the resource types actually in use (Servers, Storage, SQL, App Service,Containers)
• SecureScore is tracked over time as a management metric, not just reviewed once
• Just-In-TimeVM access is configured for any VM with management port exposure
• Endpointdetection and response is deployed on all VMs, with coverage gaps identified
• Patchcompliance is measured and enforced through Azure Update Manager or equivalent
• Containerimages (AKS, Container Instances) are scanned for vulnerabilities beforedeployment
• AppService and Function App configurations avoid storing secrets in applicationsettings in favor of Key Vault references

6. Logging, Monitoring,and Detection

This is the section that determineswhether the SOC (internal or managed) can actually do its job.

• Diagnosticsettings are enabled on all resource types relevant to security, forwarding toa central Log Analytics workspace
• AzureActivity Log is retained for a period matching compliance requirements andforwarded to the SIEM
• MicrosoftEntra ID sign-in and audit logs are ingested, not just retained in the portal'sdefault window
• Alertingexists for high-risk events: privileged role assignment changes, ConditionalAccess policy modifications, mass permission grants, disabled MFA
• LogAnalytics workspace access is itself restricted and audited
• Retentionperiods are documented against specific regulatory requirements (UK GDPR, FCA,sector-specific rules), not a generic default
• There'sa documented and tested path from "alert fires" to "analyst hasenough context to triage without further access requests"

Enterprise failure mode to watch for: logging enabled at theresource level but never actually flowing into a monitored workspace, so theorganization believes it has visibility it doesn't.

7. Governance, Compliance,and Third-Party Risk

• AzurePolicy compliance is mapped to the specific regulatory frameworks theorganization is subject to
• Third-partyand vendor access (via guest accounts, app registrations, or ManagedIdentities) is inventoried, with scope of access documented per vendor
• Dataresidency requirements are validated against actual resource region deployment,not assumed
• Regularaccess reviews are scheduled for privileged roles, guest users, and applicationpermissions, with evidence retained for audit
• Incidentresponse runbooks reference actual Azure tooling and escalation paths, notgeneric templates

Turning the Checklist Intoa Program

A checklist run once produces areport. A checklist run on a cadence, with findings tracked to closure andSecure Score trending upward over time, produces an actual security program.For enterprise organizations specifically, three things separate the two:

1. Ownershipper finding. Every open item needs a named owner and a due date, not just aseverity rating in a spreadsheet.
2. Recurrence,not a one-off. Enterprise tenants change fast enough that a checklist from sixmonths ago is already partially stale. Quarterly reviews of identity andnetwork findings, annual full assessments, is a reasonable baseline.
3. Connectionto detection. Findings from the assessment (missing logging, over-permissionedservice principals) should directly feed what the SOC is tuned to watch for. Anassessment that doesn't inform detection content is only half useful.

Key Takeaways

• Startwith identity. In enterprise Azure environments, Entra ID misconfiguration isthe highest-frequency root cause of serious incidents.
• Thefailure modes that matter most in enterprise environments are structural:forgotten service principals, unsegmented acquired subsidiaries, logging that'senabled but not actually monitored.
• Achecklist is a starting point, not the finish line. The value comes fromtracking findings to closure and repeating the assessment on a defined cadence.
• Assessmentfindings should feed directly into what your SOC or managed detection provideris tuned to detect, closing the loop between "we found a gap" and"we'd actually catch it if exploited."