Azure and Microsoft 365 Security Review Checklist: Validate Access, Detection and Recovery

The checklist addresses identity, endpoints, collaboration, Azure workloads, application permissions, detection, recovery, and governance. Turning those topics into a useful review requires evidence—and a clear definition of what passing each check actually means.

Start with scope, permissions, and ownership​

Clear Path recommends mapping tenants, subscriptions, management groups, landing zones, shared services, and administrative responsibilities before assessing individual controls. It also identifies mergers, new integrations, changes of service provider, and incidents as reasons to revisit the architecture.

For a practical review, assemble a working evidence pack:

• An inventory of in-scope services and their business owners.
• A diagram showing important identity, application, and data dependencies.
• A record of privileged access and inherited permissions.
• Named owners for remediation and incident escalation.

Microsoft’s Azure landing-zone guidance adds an important boundary: workload teams should generally receive role-based access at the subscription or resource-group scope they need, rather than at management-group scope. Broad inherited permissions can create unnecessary access across multiple subscriptions. Management groups are particularly useful for applying common Azure Policy requirements.

Passing this stage means being able to explain both who owns a service and how someone gains administrative control of it. An organizational chart alone is not an access map.

Review identity without breaking emergency access​

Clear Path places Entra ID, privileged roles, Conditional Access, MFA, and guest governance at the center of the review. Its recommendation is to examine standing administrative access and replace it with time-limited elevation where appropriate.

One immediately useful procedure is to investigate legacy authentication before changing access policy. Microsoft documents the following inspection path:

1. Sign in to the Microsoft Entra admin center with at least the Reports Reader role.
2. Open Entra ID > Monitoring & health > Sign-in logs.
3. Display the Client App column.
4. Filter Client App for legacy authentication protocols.
5. Repeat the inspection on User sign-ins (non-interactive).

Microsoft recommends initially deploying its legacy-authentication blocking policy in Report-only mode, evaluating the impact, and then enforcing it. Conditional Access requires appropriate licensing; Microsoft identifies security defaults as an option for blocking legacy authentication where those licenses are absent.

Emergency access deserves a deliberate exception to ordinary hardening. Microsoft recommends at least two cloud-only emergency accounts, using the tenant’s onmicrosoft.com domain, with phishing-resistant authentication. They should be excluded from Conditional Access policies that block or restrict sign-in, monitored, and validated at least every 90 days. Microsoft also specifies permanently active Global Administrator assignments for these accounts rather than eligible assignments requiring activation.

The architectural test is straightforward: can authorized staff regain control if normal federation, authentication devices, or privileged-role approval paths fail? A recovery account that depends on the failed system is a spare key locked inside the house.

Check what “compliant device” really means​

Microsoft documents device compliance and access enforcement as connected but distinct functions. Intune evaluates device configuration; Entra Conditional Access can use that compliance result to decide whether access should be allowed.

There is a particularly useful setting to inspect: Mark devices with no compliance policy assigned as. Microsoft documents Compliant as the default and recommends Not compliant when using compliance policies with Conditional Access to ensure that access depends on an actual compliance assessment.

A suggested validation exercise is to compare access from a device with an assigned, satisfied policy against a device without an assigned policy. Record the policy evaluation and resulting access decision rather than relying solely on enrollment status.

For Windows administrators, the takeaway is practical: “managed,” “evaluated,” and “allowed access” should be separate evidence fields, not one reassuring green checkbox.

Inspect Microsoft 365 sharing at every relevant layer​

Microsoft’s SharePoint documentation establishes that external sharing operates at both organization and site levels. Where those settings differ, the more restrictive value applies. OneDrive can be configured as restrictively as SharePoint, or more restrictively.

That makes a tenant-wide screenshot insufficient evidence for a collaboration review. Suggested checks include:

• Compare the organization’s sharing ceiling with sensitive sites’ actual settings.
• Inspect whether links require authentication or permit anonymous access.
• Review membership and permissions on Microsoft 365 group-connected sites.
• Verify whether SharePoint and OneDrive use Entra B2B integration.

That final point matters because Microsoft documents different external-sharing models. With Entra B2B integration enabled, Entra guest-invitation settings and collaboration restrictions apply to the relevant sharing workflows; reviewers should not assume identical behavior across both models.

Data protection needs a separate coverage check. Microsoft Purview DLP supports locations including Exchange, SharePoint, OneDrive, and Teams messages, but policies act on their configured locations and activities. Microsoft’s planning guidance starts with stakeholders, sensitive-information categories, and protection goals—not simply enabling a template.

Clear Path additionally recommends reviewing sensitivity labels, retention and deletion, mailbox forwarding, and workload-specific sharing settings. These are distinct review items, not interchangeable protections.

Prove Azure private connectivity—not just its existence​

A private endpoint is not, by itself, evidence that a workload is private-only.

Microsoft explains that clients need appropriate DNS resolution to reach the private endpoint address. It also explicitly separates DNS resolution from access control: a successful public DNS lookup does not grant data-plane access, and disabling public network access or denying a caller through the service firewall can reject the connection regardless of that lookup.

A useful review test therefore has three parts:

1. Resolution: Does the application’s actual client environment resolve the service to the intended private address?
2. Connectivity: Does the legitimate application connection succeed over the intended path?
3. Restriction: Do service network settings reject access from locations that should not be allowed?

If the first test fails, investigate DNS configuration and forwarding before treating the problem as an application-permission issue. Microsoft documents private DNS zones and Azure Private Resolver as configuration options, while recommending hosts-file overrides only for testing.

Clear Path’s broader network review also covers public exposure, segmentation between environments, management paths, and lateral movement. Private connectivity should support those boundaries rather than replace their review.

Review application identities as carefully as people​

Microsoft documents managed identities as a way for applications to obtain Entra tokens without developers handling the underlying credentials. That removes a credential-management burden, but access still requires authorization to downstream services.

For each important application identity, a useful review record should identify its owner, hosting resources, authorized dependencies, and assigned permissions.

Lifecycle matters too. Microsoft distinguishes system-assigned identities, which are tied to a resource’s lifecycle, from user-assigned identities, which exist independently and can be attached to multiple resources. That distinction provides a concrete question for reviewers: is the identity’s reuse intentional, and does its permission scope match every attached workload?

Clear Path also calls for examining application consent, API permissions, service principals, and secrets in code or deployment pipelines. These extend the review beyond human sign-ins.

Demonstrate detection and recovery​

Microsoft’s cloud security benchmark guidance recommends collecting identity, resource, management-plane, and network evidence, then centralizing analysis and setting retention around business and investigation requirements. It explicitly describes this as recommended guidance, not certification or compliance attestation.

A suggested acceptance test is to select an approved administrative change and follow its evidence through collection, investigation, and escalation. Record whether the responsible team can find the event and explain the response. A connector’s existence is less persuasive than a demonstrable investigation path.

Recovery needs equally concrete evidence. Clear Path recommends recording backup scope and recovery objectives, separating backup administration where possible, and testing restores rather than relying on successful backup jobs.

For Azure Backup, Microsoft provides a specific caution: vault immutability can protect recovery points, but locking the immutability setting is irreversible. Microsoft recommends understanding and validating the vault and policy settings before locking them. Support also depends on vault type, workload, and region.

Those Azure vault controls should not be treated as proof of Microsoft 365 backup coverage. The review should explicitly document what each recovery system protects.

Finish with decisions, not just findings​

Clear Path recommends prioritizing remediation by business impact, exposure, and implementation effort. It suggests annual formal reviews for many UK SMEs, supplemented by reviews after significant changes; that cadence is its recommendation, not a universal Microsoft requirement.

A useful final deliverable is a short, actionable register containing:

• The affected service and verified evidence.
• The business consequence.
• The proposed fix and accountable owner.
• Any temporary exception and its expiry.
• A validation test for closing the finding.

The goal is not a thicker checklist. It is an environment whose access boundaries, operational responsibilities, and recovery paths can be explained—and demonstrated—before an incident puts them to the test.