Microsoft Azure Security Assessment

Tenants drift: subscriptions land outside the hierarchy, an access policy picks up an exemption nobody removes, and administrative rights that were meant to be temporary stay switched on. This assessment gives the board an independent scored position on the platform estate, with a remediation list carrying owners and dates. It is our own assessment and not an official Microsoft review, audit or certification.

• An independent read on the tenant, separate from the posture score the platform team reports.
• Identity is usually where this bites: who holds standing administrative rights, and how strongly they authenticate.
• Evidence for cloud scope in ISO 27001, SOC 2 or sector resilience assessments.
• Not an official Microsoft review, audit or certification, and not endorsed by the provider.

195 questions across 12 pillars and 39 categories: subscription and management group governance, Entra ID and conditional access, privileged access, platform logging, detection and posture, network exposure, data platform and residency, Key Vault and workload credentials, compute and container hardening, application and edge exposure, backup and recovery, and managed AI services with the release path. A read-only collector runs first and pre-fills answers, leaving the assessor session for judgement, exceptions and the things only your team knows. This is the Azure platform estate - not Microsoft 365, and not Microsoft's Zero Trust guidance, both of which are separate assessments.

• 195 questions, 12 pillars, 39 categories; reader-scoped collection with no writes and no agents.
• Three pillars carry 20 questions each - Entra ID and conditional access, network exposure, and compute and container hardening.
• Subscription owners need roughly an hour each; there is no change freeze and no production disruption.
• Re-runnable, so the following cycle shows movement against the same 195 controls rather than a fresh opinion.

The collector reads the tenant and its subscriptions through the platform's own read APIs: management group placement, policy assignments and the exemptions standing against them, resource locks, tenant authentication methods and passwordless adoption, conditional access coverage and exclusions, guest and cross-tenant access, application registration credentials and their age, eligible versus permanently active directory roles, RBAC assignments at each scope, activity log and diagnostic setting coverage, workspace retention, Defender for Cloud plan coverage and Sentinel rule state, network security group and firewall rules, public address allocation, private endpoint and service firewall defaults, storage account exposure and whether access keys remain enabled, SQL and Cosmos DB endpoint and encryption state, Key Vault protection and key rotation, managed identity adoption, virtual machine and AKS hardening, Update Manager coverage, App Service and Function runtime settings, gateway and API Management exposure, TLS policy, vault protection, and the network exposure and content filtering on Azure OpenAI deployments. Every signal arrives as a suggested answer with its raw value beside it, and the assessor accepts it or overrides it with a reason that is published in the report. A setting the collector could not read - a scope the reader identity was never granted, a subscription outside the agreed list - is recorded as not evidenced, never as a failure.

• Reader-scoped collection through the platform read APIs; no writes, no agents, and no reads of customer content.
• Conditional access is scored on coverage and exclusion rather than policy count - an exemption with no expiry is a finding.
• Privileged access questions separate eligible activation from standing assignment, and check break-glass accounts on their own.
• 15 questions cover managed AI services and the release path: deployment exposure, prompt telemetry, content filtering and registry provenance.